微信怎样保持简洁

2014-1-27 评论(2) 分类:互联网

微信已经是很庞大的APP了,功能非常多,但在产品表现上还能做得很简洁,这点挺难得,说说它是怎么做的。

渐进增强

渐进增强是web前端开发的概念,因为web前端需要兼容许多新旧浏览器,新的浏览器可以做到很炫的功能和效果,旧的浏览器做不到,渐进增强的意思是先为旧浏览器做好到基本功能,再在不影响的旧浏览器的基础上针对新浏览器做更多功能和更炫效果。

新旧浏览器类比不同用户及不同层次的需求,微信的很多功能就属于渐进增强,你只会看到基本功能,但它也有高级功能,高级功能隐藏在背后,你需要时才会看到它。如5.2新增的语音转文字,要长按语音才会出现这个功能,隐藏了入口,不打扰原有界面和交互,需要它的人用过一次就知道它在哪里。又例如拍照或截屏后在聊天框自动提醒是否发送这张图片,优化了体验又完全不影响原有功能。还有很多地方是这样的体验优化:会话的图片墙,共享地理位置,转发聊天记录,多选聊天记录删除转发,双击全屏显示聊天内容,搜索聊天记录,聊天表情,收藏,群聊,二维码扫描里的封面/街景/翻译等。

个人觉得摇一摇里的摇歌功能也可以这样做,隐藏起来,有需要的人再去开启。摇歌和摇人有不同的用法和不同的场景,现在这两个功能并列在一起,感觉很突兀,把摇一摇搞混了,多了摇歌的功能又没给微信增色,完全没必要,实际上QQ音乐做这个事更合适,而且它也已经有这个功能了,不知为什么要留恋这样的小功能。

限制入口的增加

包括限制自身和外部功能入口增加。微信至今外部功能放在一级目录的只有游戏和支付,其他外部功能都在公众号和服务号二级目录下,需要时才会推送显示,显得很简洁。对比下电脑上的QQ,按钮有多少,再看看新浪微博APP,连发微博都分了9个按钮,什么签到秒拍红包飞好友圈,眼花缭乱,另外都不好意思说微博web版了。手机QQ在抄微信后简洁了很多,但在动态里还是多了像生活优惠/腾讯新闻/热门活动/阅读中心这些入口。微信作为一个大号APP,按钮入口价值连城,能做到限制入口增加,原因是:产品地位高,不差钱,负责人有产品洁癖,负责人话语权很高。

不过这点有时做得过火了,微信5.0还是5.1的时候,聊天框右上角的魔法棒没了,变成发起聊天,魔法棒下的扫一扫移到了发现tab下,跟摇一摇放一起。可能原意是保持产品逻辑合理,第一个tab就是微信核心聊天功能,扫一扫产品逻辑上不属于这里,所以移到发现tab里,另外也遵循了“一个功能只有一个入口”洁癖原则,不再增加快捷入口。修改后扫一扫的入口等级跟原来一样,都是点一下就能看到,原先是点右上角,现在是点tab,看起来似乎没问题。但这个修改非常失败,微信花了很长时间培养大家点右上角扫一扫的习惯,这样的改变让人很不适应,另外新的入口跟摇一摇放在一起,都是X一X,很难快速分清扫一扫在上面还是下面,经常点错,体验很差,最后还是改回来了。

二维码

要让产品简洁就要隐藏或加深入口,把功能隐藏或加深又不利于推广,怎么办?二维码不仅连通线上线下,还直接解决了功能入口这个问题,真是大杀器。有了二维码,微信可以不用给公众号任何入口,就像没有这个功能一样,只要用户有需要,通过扫一扫二维码,公众号的功能就出现,十分快捷简便。二维码本身就是个大入口,微信可以让很多功能隐藏在它背后,如web微信的登录,微信支付。二维码再配合聊天框、内嵌的网页可以很容易让微信扩展功能的同时保持简洁。

阿里与微信

2013-11-29 评论(3) 分类:互联网

淘宝

淘宝近期屏蔽了微信中指向淘宝的链接,用户无法在微信上浏览淘宝,卖家无法在微信上推销淘宝商品。

有人说这跟用户和卖家的需求背道而驰,但这跟几年前淘宝屏蔽百度是一样的,流量入口不能落入另一个巨头手里,当时如果淘宝没有屏蔽百度,大家逐渐习惯在百度搜东西再去淘宝购买,百度成了购物入口,淘宝活在百度的阴影下,任人宰割。而这次微信成了流量入口,不仅如此,微信除了是入口,还控制着整个浏览过程,用户浏览过程始终留在微信里,加上微信之前屏蔽了网页中跳转到第三方APP和AppStore的功能,显示出微信对在其中浏览的内容控制权,微信不允许从微信APP跳到淘宝APP,直接把整个购物过程包在自己地盘里,比百度更狠,更糟糕的是,以微信的流量,这样下去是有可能包揽淘宝大部分移动端流量的,淘宝应该在有这个苗头的时候就掐断。

那用户和卖家被损坏的利益怎么办?同样参考屏蔽百度的举动。在屏蔽百度里,卖家少了百度过来的流量,买家无法从最常用的搜索引擎中搜索他们想买的东西,看似损失很大,实际上没什么,大家全都到淘宝去就行了。现在也一样,卖家少了一个营销推广渠道,买家无法在常用的聊天工具上分享淘宝的东西(实际上这需求不多),相信淘宝会在淘宝APP或来往上设法弥补这些损失,不过来往是不可能做起来的,完全一样的产品形态很难击败已成熟的对手,况且还是IM这种没有关系链就玩不转的东西,况且微信团队各方面都比来往团队强(从来往的结果看),阿里还不如把搞来往的精力放在支付宝的线下支付。

支付宝

关于微信支付,看了知乎这篇回答后茅塞顿开,原来微信支付有这么大的能量,但有两个问题:

1.微信支付体验很好,绑定银行卡后每次支付只需要输入六位数字,钱就直接从你银行卡飞走了,不论是支付一分钱还是几千块钱,都是这样。体验是好了,但安全和体验是相对的,安全性越大体验越差,体验越好安全性越差,不知道是不是技术的突破打破了这种关系,但就用户角度来看,多数用户会怀疑这样简单的支付流程下的安全性问题,导致不绑定银行卡,至少不会绑定主要的银行卡,用户不想绑定余下的就走不通。

2.如果支付宝做的不是担保,而本身就是银行类似物呢?那支付宝就不是一个中介了,上面的文章提到的问题就没有了,余额宝的出现会逐渐让大家倾向于把钱放在支付宝(余额宝=支付宝)而不是银行,这样实际上用支付宝支付和在微信上用银行卡支付是一样的,甚至更便捷,支付宝的转账等功能远比银行卡转账方便快捷。如果说保守的人还是倾向于把钱放在银行卡而非支付宝,那因为这些人对钱财安全的重视,同样不会去把银行卡绑定微信。

线上支付已被支付宝包揽,线下支付是支付的主要竞争点,不过这个似乎实施起来难度巨大,微信的优势在于除了支付还可以为商家提供跟客户交流的公众号,不过从微信会员卡的实施情况来看,用户似乎并不买账,如果绑定银行卡的人少,将举步艰难,相对来说更看好支付宝,不过支付宝在这方面应该加把劲才行。

题外话,如果一个拥有庞大用户量的产品可以无限延伸做什么成什么,那全国只会有腾讯一家互联网公司,微信是很了不起,但媒体对微信的吹捧太过了,微信支付颠覆了支付宝,微信电商颠覆了淘宝,微信会员卡颠覆了大众点评,微信的公众号可以灭了所有媒体,微信的服务号可以灭了APP,最搞笑的是有人说微信游戏会把APP游戏灭了。。偶然看到这篇文章,感觉挺恶心。

伊书的几次更新

2012-8-14 评论(12) 分类:互联网

6月10日发布伊书以来,至今两个多月,又发了三个版本,从1.0到1.3,算起来两三周一个版本,这个节奏还挺快的,能这么快是因为我业余时间不知道要做什么,就只能做伊书了,提交一个版本后,会马不停蹄开始下一个版本的功能,AppStore审核周期又那么长,1.1和1.2都审核了两周,一般在上个版本上架时,新版本差不多做好了,这次1.2到1.3的更新只花了两周,就是因为这样,1.2上架时,1.3已经做好了,提交审核后6天就上架了。

记录一下这几次更新。

1.1完善了书籍阅读外围的事情,如导入导出书籍,书籍来源的增加,书籍分类等。(7.14)

这些功能最大头的是书籍分类,交互上有很多要做,较繁琐,也为设置按钮的摆放纠结了好一阵,尝试了多种方式都不合适,最终还是把它从书籍列表页去掉,只有阅读页有入口。

itunes导入书籍,需要遍历文件的创建时间以筛选出新文件,找了很久获取文件创建/修改时间的方法,object-c里提供的方法没有只有这个文件真正的创建时间,没有副本创建的时间,搜索很久才找到用C语言获取文件时间的方法stat()。底层知识不熟悉的代价。

1.2完善书籍阅读过程的事情,如书签笔记,字体导入。(8.2)

书签笔记,这四个字包含的工作量太多了。书签还好,只是有点繁琐,设计上花了一些时间。笔记这功能是最难的,因为CoreText渲染出来的文本,是没有选中功能的,需要自己实现文字的选中和操作。文字的选择在1.0版本发布之前就已经粗略调研过,参考了EGOTextView的程序,当时找遍网络关于CoreText文字选择的方法,幸好有EGOTextView,否则要我全部自己研究实现,不知要多久,所以我在第一版发布时就说“enormego是天使般的公司”。在文字选择的各种细节调整上花了非常多时间,还有解决文字标记,点选标记的功能,都碰到不少难题,有的解决了,有的在可接受范围内就不解决了,在“完美”和“完成”上我有我自己的平衡点,自己做APP感觉好的地方是,这个平衡点完全自己掌握。

字体的动态导入,一开始我以为这是做不到的,在能搜到的字体导入方法中,都是字体加入项目工程一起编译,不能让用户自己导入字体。后来有网友跟我说已经有APP实现,我才知道这是可行的,几经搜索终于找到方法。有时候一些事情别人能做到,确定可行,自己才能做出来,先行者与其他人的差别巨大。

1.3支持TXT格式,图片显示,微博分享,分类密码,章内快速翻页等。(8.14)

这个版本更新的内容较多较杂。每一个功能都有点不容易。

TXT格式,我自己不怎么喜欢,用这种格式书籍排版勘误分章什么的质量不会好到哪去,只是顺便支持下。自动分章的功能少不了,阅读软件们给分章起了个更好听的名字,叫智能分章,试一下后发现只是根据第X章X卷这样的关键字去匹配分章,连第X章出现在正文中间也照分不误,很简单,不怎么智能,我也差不多是这么分的,如果有些书籍没这样的关键字分章,就根据长度拆成多个部分。TXT格式的基本阅读是没问题了,当然没达到很好的程度。

书籍内容显示图片,其实在1.2已经有这功能了,不过1.2需要epub在HTML页面里显示指定图片的宽高才能显示出图片,大多数图片还是显示不了,到1.3做了自动读取图片识别宽高,所有图片都可以显示了。除此之外做了图片的放大缩小,因为整个阅读界面的手势太多了,View的层级也很多,比较复杂,费很大劲才把图片放大缩小这功能做出来。

分类密码实现简单,但其实并没有完全实现用户使用这个功能的原衷需求:隐藏不想让别人看到的书籍,因为分类密码在很显眼的分类选择处暴露了这个需要密码的分类的入口,让别人知道了你有这么个分类不想让人看到,会逼问你密码。更好的解决方法是直接隐藏掉加锁的分类,解锁时显示,但由于这样做产品逻辑太复杂,操作交互也繁琐,纠结很久,采用这种最简单的方法,这也是一个权衡。

快速翻页这个功能我自己是不需要的,但似乎很多人都有这个需求,由于伊书内容渲染实现的方式问题,暂时没法做到全书进度条拖动翻页,所以只做了单章内的快速翻页。但这个进度条的入口要放哪里也纠结很久,对于这种(我觉得)不常用的功能,不想为它在显著位置新增一个按钮,最后很隐蔽地需要在阅读时点击中下方,它才会出现。这太难发现了,只是暂时没办法的权宜之计。

微博之旅

2011-10-21 评论(3) 分类:互联网 Tags:

从08年3月开始用微博,到现在三年半了。至今认真用了四个微博,因为不同的原因迁移。

第一个用的是饭否,微博的先驱,有感情的一个平台。可惜用了一年半后,在09年7月7日饭否被关了,被迫迁移到第二个平台twitter,在twitter上混了一年,后来政府慢慢对twitter封得越来越紧,把中文圈全干掉了,我不想折腾,迁移到腾讯微博用了几个月,后来朋友们都去了新浪微博,起初我只是在新浪微博评论他们的微博,后来就慢慢迁移到新浪微博了。

在很早我就说过,我用哪个微博平台取决于我朋友们用哪个平台,相信这是大部分人的选择方式,还有一部分是看明星在哪个微博,不过如果不是狂热的明星粉丝,开个马甲关注足矣,决定真正使用哪个平台的,还是身边朋友。

前两次微博迁移是迫不得已,最后一次是新浪硬生生把人抢过去了,平台效应已经形成了,腾讯微博即使有内嵌QQ的方便,仍比不上新浪微博。不知道在其他人群是怎样,在我所接触到的人群范围内,除了同事 (我在腾讯),其他有用微博的都是新浪微博了。感觉腾讯微博已经输了,不过我猜可能90后那些喜欢玩QQ秀的比较多人用腾讯微博,没研究。

腾讯微博的活跃用户应该远少于新浪,用户数量水分很多,甚至活跃用户的水分也很多,很多是通过Q空间和签名同步,有的是从其他微博同步过去。腾讯微博僵尸粉丝很多,很长一阵子我一发微博就被不认识的人无评论转发,而且是即刻,貌似腾讯微博没严打这些用户,在新浪微博没出现过。在腾讯微博有1000个粉丝,可能只相当于在新浪有100个。

新浪腾讯微博同质化严重,微博这样的平台不需要两家一模一样的,就像QQ。MSN和QQ不是一样的,至少MSN是有主攻市场的,但现在腾讯和新浪就是一模一样的,微博没有用户就玩不转,用户只会越来越聚集在本来就多的那个平台。

新浪腾讯微博上娱乐信息过多,互联网十几年在BBS等地方积累下来的老段子在微博上不断转来转去,重复内容很多,无营养,无意义。不是说不关注某些人就可以避免这些内容,整体氛围如此,避不了。

挺羡慕其他国家有facebook的,微博对所有人都公开,跟facebook性质不同,偏向媒体/传播,个人品牌打造,facebook偏向个人生活,有隐私设置。我发的微博大多是生活,没办法,人人网太不争气了。

饭否在刚复出的时候还好,跟几个朋友在上面交流感觉不错,但一年过去了,饭否没什么跟新浪腾讯微博差异化的举动,只是做了几个应用,不免令人失望。twitter越来越少人上了,已经成为一个高端人群的微博,没事上去看看感觉挺好的。

说说HTML5/FLASH/webApp

2011-9-18 评论(2) 分类:互联网 Tags:

又好久没写博客,我必须凑数做到每个月至少一篇,不然破坏了这几年的传统感觉不太好。

最近HTML5太热门了,在微博上老是看到HTML5又能干嘛干嘛,又做出什么炫酷效果了,然后又跟FLASH对比,FLASH必被淘汰,这种论调出现得太频繁了,感觉挺无聊。用炫酷效果来宣传HTML5实在不是明智之举,现在HTML5能做到的任何效果除了WEBGL的硬件加速其他的5年前的FLASH就已经能很好地做到,而且性能更好得多,随便搜一下FLASH酷站,看看里面的交互,哪个不比目前纯WEB的方式强,感觉WEB使人机交互退步了10年。当然FLASH的优势是交互和效果强,HTML的优势是对内容处理能力强,现在互联网全是内容,一切以服务内容为主,强的交互和设计靠边站,FLASH也只能在游戏和视频上混了,视频上HTML5是可以代替FLASH,但游戏上HTML5提供的功能要在做游戏上赶上FLASH目前的水平恐怕还得四五年,到时FLASH会怎样还不知道。

我不是在唱衰HTML5,只是对那些天花乱坠的追捧和与FLASH的对比有点反感。HTML5只是前端开发的一些功能延伸,给HTML订了一些规范,给JS加了一些接口,给CSS加了一些高级特性,有了这些接口,webApp可以做得更好,没其他的什么。所以真正热的是webAPP,不是HTML5,不过把HTML5作为webAPP的代名词也没关系。就像几年前的Ajax一样。

webApp确实是现在和未来的热门,在移动端上,现在已经可以结合PhoneGap这样的框架给webApp提供底层接口,webApp已经能享用到跟原生APP一样的功能,但是性能上跟原生APP差距甚远,不过这会在未来一两年的硬件升级上把这个问题解决。到时套了PhoneGap的webApp就可以和原生APP媲美了,对于内容展示性的应用,例如微博,邮箱,SNS,由于webAPP开发比原生更容易,能写一次代码跨平台运行,那用webApp代替原生会是更好的解决方案。而对于交互性和性能要求强的应用,例如游戏,地图,QQ还是用原生APP实现,各司其职。

附带一下介绍目前HTML5提供的所有功能的slide:http://slides.html5rocks.com/

新浪微博的“开放平台”

2011-5-16 评论(7) 分类:互联网 Tags:

做了个东西打算用微博帐号直接登录,先做了新浪微博的登录,东西做好放上去了,测试过程才发现新浪微博未通过审核的应用只允许10-15人登录,超出的人无法登录。这个规则貌似是新浪微博的创新,其他开放平台未通过审核的应用只不过限制一下请求次数和发微博时没有显示来源,新浪微博则所有应用必须通过审核否则完全无法用。

经过6天的审核,出了结果,没通过审核,原因很明确:“无应用截图”。这个原因足够充分也合理,但也足够蛋疼,所有审核的应用必须有应用截图,难道程序不会判断一下提交审核的程序有没有截图,然后提醒一下开发者加上?机器0.001ms能做的事情让人工做了6天,效率真高。

截了应用的图,传了上去,重新提交审核。再经过5天的紧张审核,今天收到审核结果了,还是没通过审核,原因是“不符合开发者协议要求”。这是原话,所有的描述。当时感觉好像我写了个程序然后编译器告诉我你语法错误了,究竟是哪一行出错自己找,不懂就去看语法书。多么蛋疼的提示。

我去看了《微博开放平台应用审核规范》,这么长的框框条条有点反感,但还是看了,然后发现我不符合条件的就是我的登录按钮是自己做的,没有用“标准登录按钮”,因为这个“标准登录按钮”太小了和我的网站不搭。于是我违反了“合作网站连接”的第一条规定。不知是不是因为这样才不让我通过审核,我不能确定,上面在想什么我只能猜,这点上新浪微博颇有那个啥的风范。

貌似我见过的做过新浪微博应用的人都对它颇有微辞,什么神奇的事都有,大家都知道它是什么德性了,我只是发发牢骚而已。希望腾讯微博能赶上新浪微博,不然根据目前情况看让新浪一家独大的后果比较惨。腾讯微博在开放上做得还是比新浪微博好的。

简洁与开放

2011-2-12 评论(7) 分类:互联网

简洁

比较一下twitter/facebooe和新浪微博/人人网,可以看到两种不同的风格,简洁和花哨。

新浪微博/人人网上满布花哨的表情/徽章/广告等东西,眼花撩乱七八糟,除了页面花哨,功能也花哨,国外的人看了可能受不了,但似乎国内的人喜欢这样的风格?

国人打开一个网页,如果有很多地方可以点,有很多不同的内容和功能,就会觉得这个网站内容丰富,能吸引自己,所以花哨点好。而外国人则专注于自己需要的信息,其他的不理,所以页面越简洁越好。就像某个调查中国人和外国人搜索的不同,外国人一般目的明确,搜一个关键字,点一个链接,离开google。而中国人搜一个关键字,点N个链接,不断下一页,为此google在中国还把搜索结果的链接设成了新开窗口。

整体上国人逻辑性没那么强。我们的文化是含蓄,圆滑,不像外国那样直接了当。另外国人喜欢热闹,鞭炮响遍春节代表喜气洋洋,网站也要跟上这样的氛围,花哨的页面开起来就是热闹。开发商必须迎合大众的口味做出这样的产品才能获得市场。

但豆瓣似乎是个例外,豆瓣做得足够简洁,跟国外网站差不多,简单的设计,突出内容,没有花哨的表情和广告,唯一的方形广告内容一般也足够酷,这样一个网站在国内也可以有庞大的用户数量,是否可以说明花哨不是必须的?按照官方的说法,豆瓣是4000多万中国都市青年生活的地方,是技术和产品为核心,生活和文化为内容的创新网站。它网站和目标用户的定位都比较高端,高端用户群偏向于喜欢简洁明了的风格,很正常,豆瓣2000万活跃用户在4亿网民中占的比例也不高,从这个官方统计来看,豆瓣的用户确实都属于高端用户。

人人网的iphone和android客户端都做得比较简洁,由此猜测针对高端用户群的应用是需要简洁的,而中低端用户群则需要花哨来取悦他们。

本来校内网有机会做成中国的facebook,成为能与腾讯百度抗衡的网站,但他们运营团队善于降低网站品味来迎合大众需求,把校内网改成猫扑一样,名字也变成很俗的“人人网”,急于在网站上放各种大幅广告,无一点年轻人的理想主义,无法像扎克伯格那样不追求盈利保持简洁,可能这么点理想主义在国内是行不通的,也可能运营团队的性质和能力决定把它做成能盈利的一般网站就够了。

虽然花哨是能吸引大量低端用户快速盈利的方法,但简洁不仅能吸引高端用户获得良好口碑,也能带领中低端用户进入,随着中低端用户的成长忠诚度也会高,带领用户而不是迎合用户在长远来看更有发展空间,曾经的myspace就是花哨的。

开放

facebook在做开放平台时,把自己的相册产品某些功能去掉了,原因是开放平台没有这样的功能,他们要跟开发者保持公平。facebook不会分成应用在这个平台上赚到的钱(除了支付系统),彻底的开放造就了zynga playfish等公司。

而国内的开放平台普遍开放程度不高,还要分走利润的50%以上(人人网52%)。新浪微博的某些API如搜索和地理位置只对合作者开放。

facebook和twitter很少自己做应用,只做好基础服务和扩张用户,国内的人人网和新浪微博则在持续做应用。 可能国内的劳动力足够廉价,公司本身也没什么使命感和野心,做网站是很现实的为了赚钱。既然多招几个人在自己的平台下做几个应用能赚到钱,为什么不做呢。

从长远来看更开放的平台能得到更好的发展,带来更多的利益。但抛下眼前的利益不要在资本公司来说很困难,国内的环境也不由得让你慢慢培养用户,在各投资方和上级的压力和干预下,运营者就算有心也无力。不过现在看来国内所有运营者都无法忍受自己白白提供资源给别人赚钱,即时这让他们巩固了平台的地位。

Android和iOS的体验差异

2011-1-3 评论(11) 分类:互联网 Tags:

最近试玩Nexus one,对比我自己的iTouch2,显得生硬,卡卡的感觉,不太流畅,之前也试玩过milestone,都差不多,为什么这些配置高级的Android机器使用流畅程度上都不如配置过时的iTouch2?本来我以为是硬件问题,Android手机屏幕灵敏度不够,现在觉得,应该是软件问题,Android不重视这种流畅UI体验。

例如,Android浏览器缩放页面时是边缩放边渲染页面。处理页面渲染和响应手指交互是同时进行的,平级的两个事件,结果是,在元素稍微多的页面上移动和缩放都会显得很卡,有时还会忽略了交互事件,因为浏览器忙于渲染页面/处理脚本。

iOS上是在手指交互事件结束后才渲染页面,页面的渲染不会跟交互争抢资源,在复杂的页面上拖动,如果拖动得太快,iOS也会马上响应你拖动到的位置,并且动画效果保持流畅,只是在你拖动过程中那个位置是空白的,在不用响应交互事件的时候才渲染页面。

速度永远是产品体验的第一要素,看看整个iOS系统,响应交互的优先级都是最高的,一般情况下手指对屏幕做出的交互命令都能得到最快最流畅的反应,在硬件不给力的情况下它也可以通过动画或其他各种方式告诉你已经接收到命令了,并最优先处理你的命令。说白了就是iOS把你的命令当作最高指令,Android则认为你的命令跟机器内部的命令是平等的。正如之前在网上看的评论,iOS充满人性化,Android就是一部机器。

上面的举例只是冰山一角,再仔细体验可以挑出很多iOS体验上细致的优化,例如页面到边界时直接撞墙,iOS则有缓冲,双击页面时iOS总能放大到合适的大小,Android不灵。

苹果有这么多粉丝不是盖的,用户体验也不是吹出来的。也只有它有能力把一件产品做得如此细致,因为硬件软件UI全是由它们设计,在世界第一偏执狂乔布斯手下又能把每件都做好,还对每一款产品提供完整的产业链一条龙服务,我想我没成为苹果粉丝是因为我没钱~

不过iOS相对Android还是有劣势的,一条龙服务做到了,各种体验都完美,但代价是不个性化,例如你不能往屏幕上添加widget,永远是那一排排整整齐齐的APP图标,永远只能左右翻动,这也是另外一种生硬。

很多模仿iPhone的手机都是形像神不像,本来以为魅族M9可以做得好一点,我觉得M9该做的就是给Android套上细致流畅的UI体验,但看了网上演示M9的视频,跟其他Android无差别,不知道是不是技术原因做不到。

关于移动web开发

2010-12-30 评论(2) 分类:互联网 Tags:

最近在开发无线js代码库,拿到了Android测试机N1,这几天的测试过程中,发现了Android2.2里chrome lite的一些问题,记录在本文最后。

试用过Andorid浏览不同的网页后觉得,移动web开发应该尽量避免类似桌面应用那样的富客户端体验,因为本身各种手机性能参差不齐,而且性能最好的iPhone4也并没有好到哪里去。桌面的IE6虽然比chrome性能差几十倍,但在强大的桌面硬件支持下普通富客户端应用差别很小,甚至感觉不出来,但手机上就不一样,差别明显,性能低到无法忍受。

我在Android下试了sencha/jqtouch/jquery mobile,体验都不好,很卡很慢,如果只是针对iOS平台的浏览器还好,如果是针对所有平台的,还是不要用这么复杂的框架。速度快是最重要的体验元素,这在移动web上主要表现在渲染的速度。而一些锦上添花的效果有时不仅影响速度,还会有更差的体验出现,例如jquery mobile在滑动切换页面时会不断调整位置,或者隐藏显示地址栏,导致页面闪了几下,体验不太好。

做移动web开发,我目前想法是:

  1. 最重要的是写好css让页面显示适应屏幕,但同时CSS3带来的特殊效果尽量少用,特别是list的渐变背景最好不用,会拖慢页面的渲染。
  2. 少用或不用动画,虽然css3动画在iOS上表现不俗,但至少在Android上表现不佳,很卡的动画比没有动画效果更差。
  3. 功能性的交互可以多(如dom切换/ajax,但要极力优化),效果性的交互尽量少(例如手指拖动元素,slider等组件)。

如果要在手持设备上有足够丰富的交互体验,还是做原生APP靠谱。如果不考虑各种浏览器的兼容,只考虑iOS,那能做的事还是挺多的,感觉sencha touch就只是为iOS准备的。但在iOS上浏览器的性能也无法跟原生APP比,差得很远,而且如果只支持iOS,web失去了跨平台这个特性,也就没多大意义了。

附:Android2.2浏览器的问题

(更多…)

扯扯tangram开源

2010-12-23 评论(20) 分类:互联网 Tags:

百度前端js代码库tangram昨天开源了,http://tangram.baidu.com,目前我在百度FE通用组, 也就是负责tangram开发和维护的组里实习,所以写写我个人的看法。

先不管这个代码库怎样,这是百度第一个在内部走流程正式开源的项目,挺有意义的,以后只要是跟tangram有擦边关系的东西都可以直接开源不通过层层审批,有了第一个开源接下来百度要开源什么东西也会容易一点。这个开源的推动挺不容易的,需要很多人很给力的推动才能成~

扯点别的,百度的技术氛围很好,内部前端的技术文章/调研文章相当多,为什么不扔一点到http://www.baiduux.com呢,以内部文章数量一天一篇都不成问题,如果讲究高质量的话一星期一篇也没问题,这是毫不费劲的事,可以带来很好的口碑,但就是不这么做。之前我在腾讯广研也有相同的疑问。开源和技术分享带来的好处以前说了,提升公司形象,吸引人才加盟,是成本很低的公关,对各方都有好处。想想腾讯的ISD和CDC博客赢得了多少尊重。

扯回来,再介绍一下tangram,tangram中文意思是七巧板,这名字很形象,tangram本身粒度细分到函数级别,每一个函数对应一个文件,所有代码都拆得很散,有支离破碎的感觉,有相应的后端工具处理这些函数的依赖关系,进行按需拼装,组合成自己需要的代码。可以在这里看到其中一个拼装工具:http://tangram.baidu.com/tangram/codesearch.html

这个库的组织形式非常简单,没有YUI KISSY那样的沙盒/核心等东西,一个个方法都单纯地放在各自命名空间里。所以它不叫框架,叫库,提供各种方法,使用它们时不用像框架一样按照它们指定的方式去写代码,其实就是一个工具箱,里面有各种工具可以单独挑出来带回家想怎么用就怎么用。

为什么会诞生这么一个库,因为百度内部产品线非常多,每个产品有各自的特征,每个产品的需求都不同,没法去要求每一个产品的前端都按照一个框架一个结构来开发,所以需要高度可拆装可定制的js库。

tangram追求高性能小体积,高性能除了ext大家都追求,例如baidu.dom.addClass里不会判断这个add的class名在节点上是否已经存在,即使存在也照样加上,因为这个判断会消耗一个正则的性能,所以选择不加。

体积上会尽量避免写不是必要的代码,例如每个方法里都不会有参数类型判断。每个方法尽量减少对其他方法的依赖。事实上这点在UI上还做得不好,现在如果单独拿其中一个UI出来用,把它依赖的方法都取出来体积还是挺大的,特别是那个UI有动画的情况下。事实上我对代码的体积有点偏执,特别喜欢一个可用的东西非常小,呵~

还有一点值得一提的是,tangram大部分代码都通过QA的专业测试和各产品线的使用,质量是很有保证的,我觉得QA的测试老高级了,全自动化,看着他跑测试挺爽的,听这个高级QA讲一讲测试你会觉得测试是相当有趣的。unit test的代码也将会放在github上,上面说了,只要是跟tangram擦边的东西都会开源,只要公司乐意,大家对开源都很积极的。

tangram首先还是针对百度产品线的,主要用户也是百度产品线,不是说开源了希望有多少人用这个库,开源更多的是种开放和互相学习的姿态。事实上我觉得如果是个人开发,没有非常特殊的要求,jQuery是唯一的最佳的选择,而团队开发,或有特殊要求才需要考虑用其他库/框架。