刚收到Kiko.com的邮件，这个我第一个接触的在线日程管理网站总算是更新了一下。登陆进去看了看，最大的变化应该是添加了多标签操作功能，不同的功能，比如日程表、联系人、设置等等，打开之后被放置在不同的tab上，而不是覆盖掉原操作区域，和支持多标签浏览的浏览器的操作基本相同。众多在线Calendar服务网站的逐步完善，外加Google Calendar一直秘密beta却不知何时真正发布的不确定，在线Calendar服务大概就是众多web 2.0网站争食的下一个领域，或者，一场大战已经开始。
在Google Reader里乱翻，忽然发现Netvibes blog也放出新消息：Netvibes welcome anise, the new netvibes update。比较吸引我的新特性就是这个”multiple pages with tags”，也是由tab支撑的。跑去试了一下，没想到Firefox的CPU占用率一下子飙到50%–我的机器是双核CPU，也就是说平均一块逻辑CPU已经满载了–然后Firefox就失去响应了。今天急着睡觉，明天再仔细看看。
下午在各个feed聚合器里面转时还在想这个问题，像Bloglines这样使用比较传统的树形结构–或者说允许用户使用这种方式–来组织feed的做法越来越少了，流行的做法几乎都是平面形组织feed外加tag。毫无疑问tag有它自己的好处，最显著的一个好处我觉得是类似一种上下文无关的特性，不会造成信息分层过深。在我看来，tag和树形结构的非子结点表现的还是很类似的，只是几乎没有哪个站允许用户自己管理tag之间的关系，而一般都是由网站程序自动来处理，所以由feed层面上升到tag层面来看，feed聚合器组织feed的方式还是局限在平面形式。这引发了我的一个疑问：页面究竟该如何组织？Google Reader貌似试图通过Google深厚的技术实力为用户简化feed、tag以及文章之间的组织管理，用户只要在Google Reader页面左边的垂直滚动部分挑选感兴趣的文章拿来看就可以了，用起来好像连tag都比较多余–有时我都奇怪Google Reader中的tag是为了让用户自己标注、分类还是为了让Google Reader的后台程序来决定文章之间的相关度、相似度等等。Netvibes的做法和Google ig比较类似，也和很多应用widgets的桌面程序–比如Konfabulator–比较类似，feed以及其他功能区域被当作widgets一样在页面上布局，这自然也是另一种处理平面形组织feed的做法，但是问题随之而来：widgets一多起来，操作十分困难，不仅是找某个feed的时候把滚动条拖来拖去让人着急，而且处理widgets布局的工作也相当占用CPU资源，这样一来，几乎无法在一个页面上放置太多的widgets。现在问题看似有了解决方案了：tab。感觉上像是提供了类似树形结构中的第二层结点–根结点自然是无法操作的，而且大部分时间里根结点都是为了模型统一而虚构出的，比如页面本身。我记得平面形组织信息好像是web2.0概念号召的一种观念，只是感觉我在日常使用这些web应用的时候，总是不自觉的疑惑界面究竟该如何处理。tab的出现不是很激动人心的事情，基本上是把桌面软件的界面套用了一下，我所好奇的只是这种类似向树形结构转变的组织信息的方法与平面形式的组织方法在使用时的微妙差异。不知道tab可以走多远？
Recent Comments