Category Archive: 小想法

Nov 01 2014

对北京PM2.5数据的初步分析

103114_1825_PM252.png

抛砖引玉。 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 美国大使馆提供了自2008年4月8日以来,到2014年8月31日的中国主要城市pm2.5历史数据,包括一天24小时,365天。 数据链接:http://www.stateair.net/web/historical/1/1.html。 根据这一数据,我采用最简单的OLS回归分析方法进行了简单的计算,结果很有意思。 首先,pm2.5的统计量均值为97.7,和其他数据的估计基本吻合。 Variable Obs Mean Std. Dev. Min Max pm25 50478 97.73793 88.20039 0 994   其次,我构建了若干潜在的解释变量,比如 用白天(8~20点)来刻画一般性的人类活动; 用rush_hour(7~10以及16~19)刻画与私家车出行以及堵车的相关影响; 用冬季采暖期winter_heat来控制冬季燃煤采暖; 用春节假期(初一到初六),国庆长假(10月1到7日),和2008北京奥运会比赛日,来控制周边地区工厂生产的因素; 另外,我控制了年变量(2008年为基准)和月变量(1月为基准)。 回归结果如下: 结果表明, 高峰期变量不显著,表明堵车对污染物排放的影响也许不显著,也许在时间上有滞后。 白天的污染水平比夜晚显著偏低,且点估计超过平均污染水平的10%。这个我无法解释,也许光照对控制pm2.5有帮助。 冬季采暖的对污染物排放的贡献显著。 国庆节、春节、奥运会期间的污染排放显著偏低,特别是春节,平均可降低三分之一。 从2008年以来的污染水平没有明显的改善/恶化趋势。 以月份看,4、5、8、9四个月的污染水平相对较低。

Aug 29 2012

商业/消费级的云计算服务

纯粹的外行吐槽,希望也许能有点意思吧。 为什么要搞云 最近在写点简单的马特拉博(Matlab)程序,但是为了在各台电脑上都能方便访问,就要在各台电脑上安装庞大的软件套装,每次就很不爽,希望Mathworks能推出个便宜的超简版……另一个不爽的地方就是电脑大多数时间都处于空闲状态,敲代码嘛,但是当进行点随机模拟,或者解个方程组,就要颇等一会结果,而运算的时候,机器热就不说了,干点别的啥都会有点卡。 于是,我就有了这么个云计算的想法,对于一部分可能有一定运算量的程序,为啥不能提供这种消费级的云计算服务(商业性的大型机或者集群的计算业务是一直都有的,只不过门槛非常高)。一个程序可以分成两个部分,本地运算和云服务端,本地运算主要就处理点文本、排版、输入输出,并进行简单的计算,参考我对马特拉博的吐槽。但如果运算量比较大的时候(比如单机运行10分钟以上),程序会建议我把任务提交到服务器端完成,在这过程中,我的代码被版本控制标记好,我可以继续修改、扩充,如果超过估计的运算量还没得到结果,云端反馈给我初步的结果并询问是否继续运算(很有可能是我的垃圾代码写错了)。这个模式有两个优势,第一是对本地的运算能力要求大减,符合移动计算的低功耗,高续航,处处可访问的新形势;第二是大大提高了运算的速度,本来一台苦逼小破本要跑个一天的程序,服务器端可能五分钟就给搞定了,省时间就是省钱啊。 进一步,拜乔帮主所赐,我们有了便携、持久但性能弱小的平板,人们对其功能扩展的追求使得越来越多的任务都可以远程完成,现在消费级应用里最成熟的比如远程桌面、远程办公和在线游戏。这些应用本身实际上实在云端运行对应的程序,而传递的是压缩过的视频内容。我曾体验了一把Gaikai的在线游戏试玩,无需安装任何客户端,直接在浏览器里就可以完整体验最新的游戏,过程流畅,效果惊人,如果未来网络连接速度能稳步提高(Google Fiber 威武),游戏主机与发烧级电脑将逐步被淘汰。而且,我觉得未来的云游戏服务肯定能实现无缝延续游戏体验,让各种Loading去死。闲言少叙,回来说我惦记的云计算服务,这个对带宽的要求可就比游戏和远程桌面小多了。什么,你说你的数据很大,要传到服务器上去?啊,亲,云存储的普及肯定使得您的数据已经都在云上了啊。 怎么实现? 这么个想法很简单,就如同任何一个研究想法一样,都被大家各种做烂了。之前已经有了很多的实战案例,我自己就依稀记得在上世纪末互联网方兴未艾的时候,就已经有一个帮助寻找外星人的分布式计算程序曾一度流行(大约是SETI@HOME)。而这样的思路也被广为采用,据维基百科的不完全统计,有至少85个项目在运行中,主要是科学计算,包括生物学、物理学、天体物理、数学等复杂的计算项目,还有工程和艺术上的多媒体渲染,还有尝试破解密码和发行货币(Bitcoin )的。俺也没有仔细的看是不是有和我想法一致的,反正咱也不是专业认识,随便聊呗。 我的想法是提供一整套统一的解决方案,而不是百十个项目各干个的,而且,要走出象牙塔和极客圈,面向终端消费者提供商业服务。当然,聪明人这么多,十几年过去了还是一团散沙肯定有其内在的道理。我个人浅见,可能有以下几个困难: 分布式计算要求程序的可并行性。不过似乎大量的应用都是可并行的(或者局部可并行),比如3D渲染,比如随机模拟,比如全局的最优化过程,其实最直接的还是3D游戏,天生适合云计算啊。但是,传统的程序语言(好吧,我就学过Basic和C),使用的循环结构,常常不能区分运算是不是并行的,反正我的垃圾代码随机模拟也是用了个for循环……如果我这个问题琢磨的靠谱,那么,是不是就需要改变程序结构以及我们写程序的习惯。 待解决的问题要能够跨平台,既然要搞云计算,那么,要解决的问题本身就必须能拆解成不同系统都可以计算的形式,无论是破解密码,计算蛋白质结构,还是寻找外星人,都要能简化成一样的基本运算单元,这可能又是一个麻烦。 运行、管理这样一个系统要能盈利,至少不能大亏吧。是否能得到大赚特赚的软件公司支持是个问题,不过也不用太担心,有很多开源的项目可以做商业软件的替代品。比如GNU Octave就是屌丝山寨版的马特拉博。 我对于运营这样的一个系统,也有两个思路,也许能有点靠谱的元素。 模式1,巨头们出马,利用闲置运算能力赚点外快。 P2P的分布式运算,管理起来实在是太麻烦,最简单直接靠谱的办法还是利用现有的超级计算机模式,由某个巨头出马,推动云计算的普及,好了,我想的就是Google,谁让你有这么多服务器呢。虽说巨头们不断的修建新的数据中心是为了满足人民群众不断增长的物质、文化需求,但是就像电网供需有波动一样,巨头们也有打盹的时候吧,当系统没有满负荷的时候,捎带手的分点运算能力给乞丐们,不是也是一级浮屠么? 可以考虑购买计算时间和流量的计算方法,比如学Evernote,每个月5刀,提供50小时的标准计算时间。所谓一标准计算时间,就是一个运算量单位,比如本台电脑运算一个wPrime 1024要搞个1800秒,那么wPrime2048的运算量就大致是一个标准运算时间。于是,这就给了每个运算标出了时间(价格)。实际操作中,如果我提交了一个请求,运算量相当于1个标准运算时,如果系统正忙,就只能分出4台主机,但因为服务器运算能力猛,还是10分钟就算好了;反之,如果此时系统大量闲置(都在看奥运会开幕式),系统挥挥手,1000台主机上来干活,瞬间俺的问题就解决了。无论哪种情况,都比在我的老爷机上跑一个小时要愉快的多。即使程序不能实现并行计算,云端也可以选择一台更高主频的主机来加速运算。 如果不是巨头的话,云服务恐怕就太烧钱了。Onlive在上周差点就壮志未酬身先死……OUYA还在等你哪?也是因为Onlive差点破产关门,本文墨迹到了今天才开始写。当然,似乎亚马逊和谷歌都有提供商业云计算服务的计划,就像风靡全球的网络存储服务商Dropbox(景德镇在墙外,没在全球范围内)一样,初创公司也可以考虑批发巨头的运算服务,来转卖,就不知道能不能挣钱了。 模式2,P2P互助模式。 现有的分布式计算主要依赖于志愿者和非商业机构(比如研究所和大学),这种非营利机构显然缺乏吸引力,不能和发行货币的Bitcoin,以及分享苍老师的影片来竞争。孟修斯曾说过,"天下熙熙皆为利往。"无利不起早,如果开着电脑能挣钱,大家就会努力开着电脑,这样,这个体系才会扩大。像寻找外星人这种只想索取,不想付出的模式很难持久。而永恒不变的只有利益(悲摧的理性人假设)。 P2P是这样的一种模式,类似BT的上传、下载,每个用户既可以买入计算服务,也可以卖出计算服务,而根据电脑满载和闲置的时间差,所有人都会有帕利托福利改进。也就是说,我的电脑通过长时间的半负载运算来积累计算时间,而当我需要进行高负载运算的时候,来花费这些运算时间。入不敷出(比如笔记本开机时间有限),我乖乖付费,或者减少我在云上的运算量。如有富余,我则可以获得收益。是的,闲置的运算能力也许可以获得货币回报。这其实是一个简单的银行储蓄模型,通过时间空间上对资源的配置,就创造了新的价值。 运营这样的一个系统的公司怎么赚钱? 向商业用户出售计算服务。对广大的个人用户而言,电脑的CPU和GPU性能在90%的时间都处于闲置状态,因此,他们都是计算时间的净储蓄者。这些闲置的运算能力显然可以出售给对运算量贪得无厌的商业用户。安全性和私密性也许是个问题,不过通过足够的分散和编译,99%的商业应用应该都能保证安全。对最高级别用户还可以考虑提供公司自建的安全计算网格。 用户的服务订阅费。免费用户相当于自建主机,和网格上的其他用户交换数据(BT模式),主机要保持开启状态,流量消耗大,而计算时间自存自用,相当于原始的(轮会)融资模型,不能变现。收费用户直接和公司服务器交换数据,可以在提交请求后离线,也可以交易计算时间(进行某种形式的拍卖)。 向用户支付利益(甚至是货币补偿)会鼓励用户更稳定的提供服务,而更多的用户提供计算时间,会压低交易的价格,使得购买者可以用更低的价格购买运算量,这是一个正反馈的过程。公司通过赚取交易差价和收取管理费获得回报。 广告服务。对于用户的补偿,可以考虑积分换购的形式,进行商业推广。 如果运营费用的增长速度和系统的规模增速是线性的,那么我觉得此商业模式是有可能盈利的。

Jul 19 2012

Google Now, 从搜索到推送

Google在2012年的Google I/O上面宣布推出最新的手机系统,Android 4.1 Jelly Bean。其中,最为人瞩目的一项新特性是Google Now。尽管Google Now集成了语音识别与搜索功能,提供了类似苹果公司Siri语音助理的功能,更重要的是提出了用推送数据代替主动搜索的智能卡片系统,这是一项堪称革命性的功能。Google前首席执行官施密特(Eric Schmidt)曾提出的,未来的搜索不是搜索而是推送,在用户尚未察觉的时候,信息已经自然呈现。Google Now的推出是实现这一理念的坚实基础。 目前,Google Now的卡片系统还非常简单,但体验已经让人耳目一新。 清晨起来,想知道天气如何,天气卡片已经准备就绪。到公车站,没有时刻表?交通卡片为你提供最近的车站时刻表。下午三点要去见客户,手机会提前通知你准备出发,并计算路上的时间,保证你准时到达。要去机场接人,卡片通知你飞机的飞行进程。第一次到一个新社区,本地搜索卡片告诉你周边的博物馆、学校,还有网友点评的餐厅列表,还可以顺便签个到。 但是,我要说的是,这只是开始。 Google Now的卡片设置太简单,如果我要坐的车不在最近的车站,他就无能为力了。 和Google 本身的产品整合还不够。行程单通知功能很方便,但是在建立新行程的时候,就需要输入具体的地址,这里如果能智能的搜索我的通讯录,或者搜索附近地址,会让填表简单的多。在地图里搜索了一个路线图,直接推送到手机变成一条代办事项卡片会多方便。 还不够智能。下班路上要去超市买个菜,我希望手机能针对这一事件自动帮我计算出超市的路线图,以及之后回家的公车时刻表。 界面还可以再修改。目前的卡片排列是纵向平铺,东西多了就有点麻烦,不如考虑上面添加标签栏,便于快速访问。 我还要更多卡片。知道我喜欢戏剧和音乐会,有知名团体来城里演出,发张卡片告诉我。附近超市大优惠,周末通知我前去。 总而言之,Google Now的信息推送体验远远超过搜索或者Siri的被动应答体验,许多问题在提问前就获得解答,这才是最高效率。安卓系统的开放性让推送功能可以很强大,希望有更多的开发者能利用好信息推送,提供更好的用户体验。

Jun 06 2012

等待完美的Windows平板电脑

随着Windows 8发布日期的日益临近,平板PC又焕发了一次青春,看着诸多设计新颖,功能全面的新品,我也不由得想起,什么样的功能是我所期望的,也就是我眼中一台便携个人电脑所需要拥有的特性。 手写笔。iPhone,iPad的风行使得比尔·盖茨在2001年发布的手写笔输入变得没那么时尚了。但是,作为高效的输入与协作设备,电磁手写笔的精确行与舒适程度远高于触摸屏的手指与电容笔。不管是不是小众,或者守旧,我需要一支笔。在手写笔的应用上,微软有深厚的积累。 12寸及以上尺寸高分辨率的屏幕,12英寸以下的屏幕,只适合进行单任务操作,分屏协作变得困难。高分辨率的屏幕在阅读上有巨大的优势,12英寸1600×900,13/14英寸Full HD 1920*1080的屏幕应该是标准的配置。 可拆卸键盘。既然是平板,可拆卸键盘使得其重量达到能够接受的范围。 5小时以上全功耗续航时间。平板模式应该保证在充满电的情况下可以全亮度、正常运行5个小时,而在链接键盘电池后,达到10小时。为实现这一目的,可以参考Tegra 3的低功耗伴侣CPU设计,在传统双核的基础上,增加低功耗的第三核心,在待机、电影、上网等模式下使用低主频低功耗核心,而在游戏、大程序、高强度运算时启动高速核心。 两种模式: 类似华硕Transformer Book的设计,硬盘、光驱、电池、独立显卡丢到键盘里,平板部分包括CPU和SSD,加上电磁笔就基本满足需求了。问题在于SSD的容量和常用X86平台程序大小之间的矛盾,windows+Office+Matlab+...就非常占空间,恐怕微软需要在磁盘管理上下下功夫。所有的程序都分成核心组件和全PC扩展包,组件装在平板里,扩展包放在外置存储器上,只有接上键盘才能使用。 类似微软早些年胎死腹中的Courier设计,双屏幕,折叠后一侧可做键盘,另一侧为屏幕,展开后,下半部分可以做键盘,上面两侧可以进行协作。 类似的设计还有东芝、宏基、索尼等厂商。 图片来自网络。

Jan 03 2012

我心目中的理想阅读体验

我觉得中文的阅读服务市场还是有很大的发展空间的,按照你们百度的话说,最懂中文嘛,特别是在谷歌自毁长城的局面下。Zite的理念,是我比较认同的思路,但是也还是有改进的空间,特别是在形式上,Zite还是太拘泥于“做一本杂志”的形式,在整合的程度上还不够。 从用户的角度看,用户的需求主要有两方面,内容与阅读体验。 阅读器的销售对象不是一个软件,销售的是服务与体验。所以,应该叫做阅读服务,而不是阅读器。 内容是阅读服务的核心,在我来看,不外乎三个主要的来源,按照主题整理的信息,订阅特定的信息来源,社交阅读与其他。 按照主题整合的信息,类似的产品有谷歌新闻,还有Zaker的预设专题内容。优点是对用户而言可以简单快捷的获得感兴趣的信息,运营商的维护也很简单,整合生成几个专题即可;缺点是定制的程度低,冗余的信息多,也容易错过自己感兴趣的小众信息。 订阅特定的信息来源,类似的产品有,Google Reader,Google Currents,Pulse News等。满足的是用户对若干特定内容源信息的访问,比如CNN新闻,国家地理杂志,经济学家杂志等。这几乎不需要运营商维护,完全是用户主动去发现信息,覆盖个人兴趣的内容丰富。缺点是冗余信息多,需要用户去维护,比如订阅和分类维护。 社交阅读,这其实是一个信息扩散和发现的过程,改版前的Google Reader其实做的是很不错的,可以方便的把自己觉得不错的文章分享给朋友,同样也能从友人处获得有价值的资讯,这是一个良性的信息筛选、扩散过程。 其他内容包括各种常见的信息发布服务,比如说推特、微博、Readitlater等等。 阅读体验是跨越用户与内容之间鸿沟的桥梁,也许要从以下几个方面来考量。 跨平台的同步与平滑转换。移动互联网与Wifi的普及把基于互联网的阅读体验大幅提高,内容可以在不同的设备上获得无缝的同步分享,并获得最恰当的体验。 基于Web的服务主界面。虽然说“Web已死,App当立”,但是在跨平台的可用性上,还没有什么比浏览器更直接有效,把根基和主界面架构在浏览器内,把算法与数据存储在云端,应该是最稳妥的解决办法。而且,PC端有移动平台先天缺乏的强大编辑能力,让用户的各种高级操作如鱼得水。 有了云端的支持,在各个平台的Apps就只需要关注用户界面就可以了。手机端由于屏幕尺寸较小,以文字为主,平板电脑平台应发挥尺寸的优势,以图文混排为主,参考的成功样本还是Flipboard。 离线阅读与用户定制。客户端上必须实现一定的离线阅读、标记、分享的能力。而且,在不同设备之间,应该能实现推送到某设备继续阅读的功能。比如说图文混排的文章选择推送到平板上继续阅读,或者把长文章推送到手机上继续阅读(参考Readitlater)。这样,用户在网络环境下随时准备阅读的素材,在离线情况下阅读、评论、标记,当用户重新获得网络连接后,可以第一时间和云端同步,甚至分享与发微博等功能也一并完成。在后台使用网络功能应由用户定制使用,默认只在Wifi下开通,避免用户产生意外流量。 任务列。由于离线操作的存在,一个特殊的操作——任务应该被引入进来,作为跨平台沟通的方式,而任务本身应该是可以被修改与取消的。比如对某篇文章发评论或者微博就是一个任务。 整合与聚合。说了界面,来谈内容的整合与展示。 标注。来自不同信息源的数据,应该当作一个整体来考量,需要对所有的信息进行分析与筛选,目前看最好的方式应该是按照主题和关键词进行Tag标注,这个标注过程应该包括两部分,一部分是算法的机器标注,一部分是用户人工生成的标注,而用户在人工标注的时候,应该能够参考、利用并评估机器以及其他用户(匿名)标注的结果,不如豆瓣评价电影时的标签推荐。 聚类。有了标注,下面就是如何分类展示内容。时下流行的“泾渭分明”的一字排开,比如Flipboard和Zaker,有预处理过的专题信息,比如新闻或者图片,有某个重要的信息源,比如某杂志的网站文摘,也有独立的短媒体内容,比如微博更新。在这一点上,应该给予用户较大的自由度:比如Reader过来的用户可能喜欢使用详细的目录和Tag来归类,这种Old Fashion Style应该能得到保留;另外一种是更加糟糕的直接罗列信息源,比如Currents和Pulse News;但是,最一般也最有弹性的解决方案是聚类。系统可以默认把用户的内容分成几个大类,一般可能3-10个大类是比较方便的,比如,新闻时事,娱乐,美食健康,以及其他内容,而用户可以进一步选择增加、减少分类,比如系统可以自动把4个分类细分成10个,或者用户手动把国家地理杂志作为一个分类单列出来优先阅读,或者用户把几个标签内容提取出来建立自己的分类。标签的分类信息同样可以算法+用户人工操作相结合。 排序。内容的排序有时候对用户的体验影响很大,谁都希望系统自动离线缓存的文章,是自己感兴趣的内容。一个基本的想法是Zite的人工打分系统,加上类似GReader的Magic算法排序,当然,我觉得GReader的算法相当糟糕,并没有觉得有魔力。当然,应该有按时间排序,或者时间+算法排序的功能(比如对最后一天内的内容优先展示)。 标记。阅读过的内容应该标记已阅并隐藏,除非被标记为推送到其他客户端或者标记为未读。标记已读功能让人吃惊的在目前流行的移动阅读客户端中缺失。 社交与信息发现。 和友邻分享资讯实际上是一个让人着迷的行为,也是互联网的核心价值之一。在这里删去向GReader改版吐槽三千字。友邻分享的内容可以作为一个分类,也可以转换成标签进入各个分类下。友邻间可以共享评论。 友邻社交阅读的另一个价值在于信息发现,当然,友邻分享的信息也被打分排序,而用户评价高的友邻信息源也可以推荐用户进行订阅。 系统每天可以向用户推送一定比例的内容(非商业广告)供读者阅读,这部分内容应该被(不显著的)标记出来,和用户自己的内容相区别,而用户可以选择加以订阅。特别是在用户内容被完全阅读过后,系统会自动为用户推荐新的资讯。对于新用户,系统可以有一个可选的弹性测试题库(要简短有趣),来学习用户的偏好,用来向用户推荐内容。 信息推送的另一个作用是推荐商业内容(广告),这部分内容第一要清楚的标记出来不影响阅读,第二相关性要强。这恐怕要和其他的服务进行整合,比如我在豆瓣上想看一部电影,那系统会在自动查询周边影院的排期,向用户在侧栏推荐影院,甚至完成购买。 用户主动搜索获取信息:服务上线后,实际获得了一个由用户和算法共同维护的巨大数据库,用户甚至可以在服务内搜索,获得相关的文章,而所有用户的评价将作为文章价值的参考(类似谷歌+1按钮)。   从开发者的角度看,用户黏度,用户群扩展速度,盈利模式。 用户黏度:好的产品,特别是好的阅读产品,对用户的吸引力是巨大的。而且,这个阅读服务提供的是大阅读体验,把新闻、博客、微博图片、电影影评、书评,甚至网络小说都整合进来。 用户群扩展速度:社交化阅读、整合短媒体,应该能让产品迅速扩展。 盈利模式: 云存储付费:像类似Dropbox之类,提供若干免费空间,如果超额,需要缴纳一定年费。 去广告付费:使用所有高级定制功能需要支付年费,完全去广告、去系统推荐等。 移动客户端付费:免费客户端只能完成基本的阅读功能,比如在线阅读,而收费版可以离线阅读并完成各项“任务”。 广告点击购买提成:推送商业内容,用户完成点击,或者向友邻分享,都可以向广告商提成。  

Dec 09 2011

界面内容大比拼 Currents vs. Flipboard vs. Zaker vs. Zite

有人说我们应该宽容的去理解接纳新界面,有人说Currents给了小内容商以机会。没有调查没有发言权,让我们图文并茂的来看一看吧。 首页 Google Currents Flipboard Zaker Zite 糟糕的风格……只有一条消息可见,其他是抽象图标。 九宫格图片展示内容,5条图片新闻可见,能够猜测大致内容。界面非常漂亮,最佳视觉体验。 微软Metro风格色块并显示最新的内容条目,不如以前图文混排的样式,但也算清新。 一切为内容而生,内容、内容、内容,最佳内容整合,给用户完整的阅读体验(可惜不支持中文内容)。   点击一次之后 Google Currents Flipboard Zaker Zite 奥,还没到,这里是漂亮的内容分栏。要再点击一次才能看到内容。 内容! Flipboard的内容编排真是精美第一,非常的协调。 内容! 很像真正的报纸分栏。 内容! 把不同来源的内容整合到一起。 在点击二次之后,Google Currents 终于能看到内容了……从使用的体会来看,Google Currents的设计更接近苹果的杂志架,内容之间是独立的,需要逐个点击进入阅读。 至于小的内容供应商是不是有出头之日,目前尚不清楚。正面的特性是Currents提供了搜索功能,在未来,小的消息源可能会通过关键词有出头之日。但负面的消息是Currents的订阅排序某种程度上是基于订阅人数的,是一种赢者通吃的模式。正如fktroll的评论,"Google Currents恰恰比Google Reader乃至Google News都更偏向大媒体。你注册一个新帐号第一次打开Google Reader会看到很多不错的小网站信息源。Google Currents?满屏的主流大站。" 其效果,如下图,     基本上,最前面1-3个信息源占据了主要的订阅数,和后面的次要内容商成指数衰减的趋势。当然,Google Currents刚刚上线1天,长期的趋势也许还会有变化,但是杂志架的模式不利于小内容商的好文章脱颖而出,也确是实情。期待Currents的未来升级会有所改变。

Dec 09 2011

【iShout】Currents 做得不够好:谈谈整合与发现的阅读体验

gofly on 2011-12-9,17:20 Comments (10)   Filed under:Google/Android, iShout, 前缀分类, 观点  Tags: Currents, Google, Google Reader. 这是一篇来自@GoFly的文章,他是一名经济学研究生,乐于畅想,偶尔吐槽。最重要的是,他是重度阅读爱好者,喜欢尝试多种平板电脑上的阅读应用。在 Google Currents 发布之后,他为我们带来了自己的试用报告。 如果您也有一些思考希望能够通过 iShout 这个平台来发声,请通过邮件与我们联系。 今天,Google 推出了一款“山寨”产品 Google Currents,据说是收购 Flipboard 失败之后的产物。我原本抱着很高的期望,跑到 App Store 美国区下载试用,结果失望之情溢于言表,简直就是山寨中的战斗机。先评价一下简单试用的体会。 优点: Currents 拥有比较丰富的网络内容来源,并进行了简单的分类,比如,精选(Featured),推荐(Recommended),新闻,商业,设计,娱乐,科技,等等。并且对每个信息源的订阅人数有统计,便于读者选择。 它对每一个信息来源都进行信息整理(Google Reader 除外),按照不同类型内容的特性进行了简单非栏目,比如科技新时代(Popular science)就划分成四个主题:专栏头条(Top Story),数码产品(Gadget),科学(Science),技术(Technology)。而福布斯除了常见的商业、投资、创业领袖、企业家等主题,还有一个 Google+ 专栏。它包含福布斯作为企业用户在 Google+ 分享的条目。 试图整合阅读器(Google Reader),具体见下。 试图整合简单社交,以及 Google 的 +1按钮。 多了一个近期热点栏目(Trending),显示刚刚发生的新闻。 提供了最新内容的离线阅读(其实 Zaker 早就可以离线阅读了)。 不足: 从用户界面上看(iPad 版本),上方占据半个屏幕的图片新闻只包含可怜的信息量却占据了最有效的视觉空间。 图片下面堆积的信息源图标们如同砌墙的砖头一般排成一排又一排。而且,图标本身不显示任何内容,必须点击进入每一个来源查看。在这一点上,同样是罗列内容的 Pulse 要做的友好的多,起码把每个栏目下最新的内容图片显示出来以便浏览。 对每一个信息源精美的分类整理无法掩盖多个数据来源之间的割裂,同样的内容在不同的来源里可能重复出现,而想要阅读某个专题的内容(比如最新数码产品),可能要在不同的信息源的各个专题之间进行往复的跳跃。 对阅读器(Google Reader)的整合本来可能是 Google 官方程序里的一个亮点,最低的要求也至少是能像一个 Reader 客户端的图文版,可以整合浏览并标记已读内容。可实际在Google Currents 里面的体验是无与伦比的糟糕。如果要添加 Google …

Continue reading »