2007年12月30日星期日

我嘅 2007

(以下的是实验性文章,全文使用Cantonese书写而成,附带Mandarin翻译,请将鼠标移至带有下划线的短语上以查看翻译。)

點解成個博客園都喺度“我2007”,仲要大部分都差唔多……好,我就寫唔同,例如……人脈啦。我要,技術唔係最重要唔係管理,而係人脈。

2007年,個人發展上兩個重要事件,一攞咗微軟MVP,二B家,兩樣都要靠人脈(要多謝人自然非常多)。,第一你要認識人際網絡中充當關鍵節點個人,第二個人要睇得起你。簡單,如果你有能力,無論係技術定係管理,首先你要識得渠道(或者叫中間商),其次要覺得你超值,先有機會賣得出去,而且賣個好價錢。渠道前提下,大家都明白廠家直接向客戶銷售成本有幾高,你一個人能夠聯係買家數量就非常有限

如果一開始,我唔係Dflying同埋Jeffreyblog上評論,佢哋唔會blog,亦就唔會佢哋鼓勵我將文章發到首頁,咁嘅話,可能dudu亦就唔會知道我存在,dudu推薦我去MVP就知從何談起。所以,MVP呢件事一定要多謝Dflying、Jeffrey同埋dudu。當然,仲要多謝所有讀者,特別有留言嗰啲,因爲有留言自然激發思考。

然而,MVP並唔係終點,只係另一個起點。之後,有中國MVP峰會,Bean介紹我唔少微軟同埋其他MVP,先有后嚟一啲合作項目,例如netcast啦。所以,認人有得做,因爲好多係呢度,我要多謝Bean、Jeffrey、dudu,特別dudu,完全講求回報支持我哋做netcast。

另外一件事,就關於賣身㗎嘞,我意思搵工。寫“我2007”入邊多人寫自己今年畢業搵工如何如何,我又可以寫啊。搵實習事就,全職申咗好幾間有噃咁上吓大嘅IT公司,包括BGM,其中B家G家過人做推薦(多謝布丁同埋Junyu)。B家最早offer,所以就賣B家算嘞G家M家申請算“無疾而終”(拒信,hold咗喺唔知邊個環節)。但係,我想唔係點樣賣畀大公司而係推薦有重要

如果人推薦,你簡歷可能石沉大海都話畀你知,而且石沉大海概率仲唔細添但係,有人推薦嘅話,你就清楚流程,其中每個環節對你評價如何都透明一啲你就可以不斷調整自己。推薦人熟悉公司内各個職位差別嘅話,對你選擇職位亦有幫助,好似高考選專業蠱蠱吓唔好啦。(如果你高考嗰時已經識得師兄問清楚專業你可以跳過。)

當然,最重要嘅係推薦你個人真係認爲你值得擁有呢個職位,而唔係應付你。積極幫你,就反映一點,影響推薦效力。唔好以爲幫你ERP或者HR之類系統填落力幫你件事,幫你同你面試官溝通你情況,你成數就越大。如果你搵到個人只係礙于人情而推薦你,根本覺得你將來成爲同事嘅話公司都有好處,你得到好處無非就係免筆試,對促進你公司之間互相了解一啲作用都

免筆試……免筆試又有用呢?其實筆試過後離offer仲有十萬八千里遠。聼講G家美國本來就筆試,只係中國應屆畢業生實在太多就筆一筆,篩一篩。有時甚至筆嘞,咁樣推薦推薦都係一面起步,你希望你優勢更好傳達面試官嘅話除咗面試時候表現要好,就靠推薦人溝通

最後,通過一個故事結束本文。曾經,Mary總係好有激情同人同埋新公司,其中一個聽衆就係Unity Way董事會成員:John Opel。五年之後,John Opel,亦就係IBM董事長,要為IBM機器一個操作系統。邊度?去WashingtonRedmond會見Mary即係Bill Gates。多謝同埋IBM單生意,Bill Gates做首富。如果John Opel從嚟聽講嘅話,IBM絕對唔會派人去Redmond一間當時幾乎Microsoft一樣默默無聞公司。

點樣放電

將件衫,特別係羽絨,剝落嚟,然後隨便搵嚿金屬物掂吓,咁就會放電嘞!喺北京D咁乾燥嘅地方,隨時都有可能無啦啦畀電親,真係抵死。不過我今日要講嘅放電唔係呢种放電……我要講嘅係attractive呢种放電。

要放電,首先要有電壓,亦就係一D你有佢冇嘅嘢。例如話,錢啦。又或者係一D更加虛無嘅嘢,所謂嘅demonstrate higher value就係無中生有搞D咁嘅嘢出嚟嘞。例如,你只係一般醒,但係扮到鬼咁叻鬼咁競,又搞到人哋信以爲真喔,你就搞咗個高電壓出嚟啦,如果人哋又過電,咁就掂晒嘞。

其中最重要嘅就係佢要信,咁先過電,於是你放出嚟嘅嘢就一定要係佢理解能力之内嘅嘢,而且最好係佢明知冇但又無能爲力嘅嘢。最好就係佢好希望自己能夠擁有嘅,咁既然佢得唔到,就當然希望從你身上得到啦。事實就係咁簡單。

2007年12月29日星期六

编写 iPhone Friendly 的 Web 应用程序 (Part 5 - 交互入门)

我们已经研究过XHTML和CSS了,现在开始看看最后一部分,也就是JavaScript,以及它所提供的交互能力。

无AJAX交互

第一种我们要看的交互,是完全不使用JavaScript,这其中一个例子就是GMail。GMail的iPhone版其实就是由普通的GMail移动版修改过来的,界面上更贴近桌面版GMail了,然而交互性并没有怎么提高,每一个点击都对应一次刷新,没有任何AJAX可言。

事实上,不用任何AJAX效果并不会让你的iPhone Web App低人一等,如果有人讥笑你的应用没有引入任何AJAX功能,你可以直接跟他说“GMail也没有”。因此,如果你在开发的过程中决定不把任何时间投入到AJAX相关技术的研究,这是没问题的,确保你的服务器响应速度,并且交互设计得当,那就行了。

以服务器端为中心的AJAX

接下来我们看看另外一些应用,例如之前说到的几个,就拿最简单的AppMarks来说说吧。首先,使用User Agent Switch更改你的Firefox的user-agent属性,伪装为iPhone,然后打开AppMarks,并且打开Firebug。接着点Menu -> Add -> Browse,看到出现AJAX请求了吧?猜猜这个请求是什么类型的,面向内容(传输更新上去的XHTML)、面向脚本(传输进行更新操作的JavaScript)还是面向数据(传输更新相关的JSON)?答案是——面向内容的!

这可是Web App哦,不是一般带有一点点AJAX的网页哦,我们要MVC,我们要“先进”的面向数据,为什么要“落后”的面向内容呢?至今为止,我们能够看到的大部分iPhone Web Apps,都将MVC保留在服务器端了,客户端唯一需要知道的就是内容更新,不存在任何的客户端MVC模型。暂时我还没看到有面向脚本或者面向数据的,如果你见到有应用这样做了,请告诉我。

我们继续说MVC的事情。现在大多应用的设计方式是这样的:每一个应拥有一个view framework,然后每一次点击所作的操作就是切换view。例如刚才说到的AppMarks,从Menu进入Add是一个view切换,不过因为Add这个view的内容是固定的,因此一早就包含在页面里,不用AJAX请求直接加载就行了。另外一种情况,就是好像加载Browse那样,是需要AJAX把view请求过来才能加载的。除了切换view,我们还需要action,例如提交数据就一定需要action的。说到这里,感觉是不是和RoR或者类似框架扯上关系了?事实上,RoR,或者类似框架,确实很适合用来做iPhone Web Apps。

以客户端为中心的AJAX

那么除了RoR,我们还有别的选择吗?我们可以选择使用一些客户端框架来实现类似的效果。这样说吧,类似RoR那样每一个view都是一个模板,但不是rhtml,而是普通的html,没有复杂逻辑,点击连接后不是由RoR引擎调在服务器端用rhtml,而是客户端自己直接拦截了链接点击并用AJAX的方法去请求该html然后更新内容。这样一个框架,可以在Wrox的Professional iPhone and iPod touch Programming : Building Applications for Mobile Safari一书中见到。这本书写着2008年1月出版,但实际上已经出版,并且可以下载源代码。我暂时还没办法买到这本书,但源代码中就包括了这样一个客户端框架。

然而,这种以客户端为中心的做法并没有真正在客户端引入一个MVC,它只是简单地把服务器端的MVC裁减掉了,服务器端只能简单的发送内容或响应提交,因此只适用于比上面的以服务器端为中心的模型更简单的情景。如果你正在编写的应用不涉及大量的提交操作,或者根本就是Web1.0网站,我的意思是,单向传递信息不接受任何用户提交的网站,那么这种轻量级的模型就非常适用了。

小结

在这次的文章里,我们介绍了三种常见的iPhone Web Apps交互方案,没有哪一个是绝对更好或者更坏的,按照你当前开发的应用做出选择吧。将来我们写文章深入探讨其中的一些实现细节,或者是交互模式,但前提是我先完成了几个iPhone Web Apps。欢迎订阅本系列文章:

2007年12月27日星期四

编写 iPhone Friendly 的 Web 应用程序 (Part 4 - CSS)

说到编写CSS,大家的第一反应肯定是——有没有选择性CSS。有!我们可以设计一个CSS,使得只有iPhone上的Safari会采用它,其他浏览器都会无视它,这样我们就可能可以复用现有的XHTML页面代码,仅仅为它们引入新的CSS就能够适用于iPhone,无须重新编写页面。这个选择性CSS链接语句如下:

<link media="only screen and (max-device-width: 480px)" href="small-device.css" type= "text/css" rel="stylesheet" />

Safari是支持media选择的,only screen声明该CSS仅用于屏幕显示(不用于打印),同时Safari还支持max-device-width这样的选项,限定屏幕宽度小于480的设备才采用该样式表,这就把iPhone与桌面浏览器划分开来了。

另一个做法是在服务器端就判断当前浏览器是否是iPhone上的Safari,从而选择返回哪个CSS文件,这可以通过user-agent进行判断,iPhone的如下:

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543 Safari/419.3

判断了浏览器之后,就可以开始针对Safari编写CSS了。Safari比较爽的一点是对CSS3的支持,设计PC端网页时总是要兼顾那个“后进”的IE,从而避免使用CSS3,或者需要确保IE在无视CSS3规则后仍然正确显示,现在不用为此而头痛啦,只要是Safari支持的就能用,针对一个浏览器设计就是比针对一堆浏览器设计要爽!

CSS3

接下来我们就列举一下Safari支持的CSS3属性吧:

边框

背景

色彩

  • HSL - HSL色彩
  • HSLA - 带Alpha通道的HSL色彩
  • opacity - 透明度
  • RGBA - 带Alpha通道的RGB色彩

文本特效

用户界面

  • -webkit-box-sizing - 可以让盒模型变得基于边框而非内容
  • resize - 让用户可以更改盒的大小(iPhone上不支持)
  • outline - 设置盒的外边框

选择器

Safari支持大部分的CSS3选择器,你可以自己使用桌面端或iPhone上的Safari打开CSS Selectors Test进行测试,桌面端与iPhone上的Safari测试结果是一致的。Safari完全通过测试的CSS3选择器包括:

*, E, .class, #id, E F, E > F, E + F, E[attribute], :link, :visited, :before, ::before, :after, ::after, :first-letter, ::first-letter, :first-line, ::first-line, E - F, :root, :not(), :target, :enabled, :disabled, :checked

其它

  • media - 根据media选择性加载CSS
  • multi-column - 内容分栏支持(iPhone上不支持)

还有一些Safari自己做的CSS扩展没有列举出来。Safari完整的CSS属性支持列表请看这里:Supported CSS Properties

表单

Safari支持对<input />元素比较高自由度的CSS定义,例如这样的:

实现所需的CSS属性上面已经列举了,所以不再详细说明,灵活运用就是了。值得注意的是,某些<input />的默认背景并非纯白色的,而是半透明的,这使得这些元素能够更好地和不同的背景颜色进行颜色混合。为了说明这一点,请先看白色背景下的示例:

然后再看看蓝色背景下的:

小结

CSS相关的话题也说完了,很简单是不是?大部分针对桌面浏览器进行符合Web Standards页面设计的设计师都能轻易掌握这部分内容,然而这只是实现设计的手段,到底如何设计一个界面,在iPhone上才算是拥有高度易用性的,这才是真正的问题。这个问题我们将在以后探讨,至少现在你能够将你自己的设计在iPhone上准确无误的实现出来了,那么我们下一步就进入JavaScript的讨论环节了。

本iPhone Friendly专题的订阅地址如下:

编写 iPhone Friendly 的 Web 应用程序 (Part 3 - XHTML)

在接下来的两篇文章中,我们将探讨iPhone上的Safari所支持的XHTML与CSS,之后才进入JavaScript的讨论。作为一款现代化的浏览器,Safari当然是基于标准的,那就让我们看看Safari支持哪些标准吧:

  • HTML 4.01
  • XHTML 1.0
  • CSS 2.1 以及部分 CSS 3
  • JavaScript (ES3)
  • DOM (Level 2)
  • AJAX (XMLHttpRequest)

熟悉这些标准并且平常也坚持Web Standards实践的朋友估计要笑出来了——就这些吗?我们天天在用啊,还有必要专门写文章来说明吗?事实上,Safari之前作为一款无PC版的浏览器,一直用户数量就不高,因此对它的研究也就不多,然而Safari其实有不少自己的扩展,因此还是很值得研究的。既然我们是针对iPhone设置,其实就是针对Safari设计,无需考虑兼容其它浏览器,这时候为什么不好好利用这些扩展增强自己的应用程序的可用性呢?

好吧,不说废话了,进入Safari对XHTML支持的介绍吧!

链接

iPhone对一下这样一些链接有特殊支持:

邮件

传统的mailto:地址iPhone将能自动使用内含的邮件程序处理,直接进入编写邮件的界面。完整的mailto:格式请参考RFC 2368

电话

iPhone上的Safari会自动对看起来像是电话号码的数字串(包括已经加入连字符或括号格式化过的)添加电话链接,点击之后会询问用户是否想要拨打该号码。如果你不希望开启这个自动识别,可以将它关闭:

<meta name="format-detection" content="telephone=no" />

如果你关闭自动识别后,又希望某些电话号码能够链接到iPhone的拨号功能,那么可以通过这样来声明电话链接:

<a href="tel:13800138000">13800138000</a>

Google Maps

Google Maps的地图链接会自动调用内置的Google Maps客户端软件打开,而非在浏览器内浏览。链接可以是一个地点查询:

<a href="http://maps.google.com/maps?q=cupertino">Cupertino</a>

也可以是一个路线查询:

<a href="http://maps.google.com/maps?daddr=San+Francisco,+CA&saddr=cupertino">Directions</a>

YouTube

如果链接是指向YouTube视频地址的,将会自动调用内置的YouTube客户端打开播放。能够识别的YouTube地址格式为:

http://www.youtube.com/watch?v=<video identifier>

http://www.youtube.com/v/<video identifier>

其中<video identifier>替换为视频的id。

图片

由于用户浏览时有可能使用Wi-Fi,也有可能使用EDGE(GPRS),因此你必须优化你的图片以确保即使是在使用EDGE访问你的网站的用户也能流畅的打开页面。因此你必须优化页面上的图片,尽量减少它们占用的传输带宽。另外Safari本身还对图片有如下的限制:

  • GIF(包括GIF动画)、PNG与TIFF解压后的体积小于2m。意思是,原图的长度乘以宽度再乘以每一个像素的位数,得出来的大小要小于2m。
  • JPEG解压后最大的体积是32m。解压体积大于2m的JPG会被进行二次抽样,最终显示给用户的是二次抽样后的结果。这使得Safari能够显示数码相机直接拍摄出来的照片,但显示时实际上是降低了精度的,以提高程序的执行效率。

为了尽量提高效率,例如你要将100*100的图片显示为10*10,就要在服务器端执行压缩操作,而不要直接用10*10的<img />来引用100*100的原始图片。

表单

text, password, textarea

在设计文本框的时候,必须记住用户点击后会出现软键盘,这时候可视区域就减少了:

另外在文本框中输入时,iPhone提供了自动大写与自动更正两项功能。自动大写的意思是,在输入开始的时候,以及在一个句号并空一个格后,自动会启用shift,输入一个字母后该shift自动消失。自动修正的意思是,iPhone会自动根据词库,包括自带的以及从你过往输入分析而来的,来对你的输入进行自动更正。我们都知道用手指点击那么小一个软键盘很容易误按旁边的键,这时候你可以不用忙于修正,只要iPhone提示的自动修正的词正是你想要的,你就可以按空格然后输入下一个词,iPhone会自动修正前面那个词。

要关闭这两项功能,可以通过autocapitalizeautocorrect这两个选项:

<input type="text" autocapitalize="off" autocorrect="off" />

select

必须留意到的是,iPhone上的<select />以不同的方式显示,以便于用户操作:

upload

iPhone不支持任何的文件上传下载,因此<input type="upload" />总是会显示出来,并且是……disabled的!

多媒体内容

iPhone上支持显示的多媒体内容,除了图片还包括QuickTime音频视频以及PDF。

如果需要创建视频,可以使用QuickTime Pro。如果你正在使用一台MacBook或者iMac,并且已经将QuickTime升级为QuickTime Pro,可以马上就试一试!你需要做的就是打开QuickTime Pro,然后开始录像,(接着请对着镜头傻笑3秒,或者做点别的),最后选择"Export for Web"。其中iPhone格式与iPhone (cellular)格式分别适用于Wi-Fi与EDGE环境,iPhone在播放时会自动根据当前的环境选择适合的流媒体文件进行下载与播放,另外poster是指影片播放之前在页面上显示的那一帧静态图片。导出后文件夹里ReadMe.html说明了如何将这些文件添加到XHTML中。

(事实上,导出结果中QuickTime控件引用的那个mov文件不包含任何视频数据,它只是一个引用,类似我们编程时所说的引用,用于指向真正的视频文件。不过这个引用指向的是多个视频文件,客户端根据当前的状态自动选择正确的视频文件来播放。)

其他琐事

虽然说是琐事,但也必须注意到,这样才能让你的页面更好地受到Safari的支持。这包括:

  • 声明正确的doctype
  • 避免使用frameset
  • 每一个独立的资源文件,HTML、CSS、JavaScript、以及非流媒体的其他多媒体文件,限制在10m之内
  • 顶级入口的JavaScript执行时间限制为5秒,超时将自动终止。
  • JavaScript分配内存上限为10m。
  • 同一时间最多在Safari内打开8个子窗口(同时浏览的页面)。

小结

XHTML部分到这里就讲完了,可以看出iPhone对XHTML的支持与桌面端的Safari是类似的,只是加入了更多扩展功能而已。下一期将开始讲CSS,欢迎订阅:

2007年12月26日星期三

编写 iPhone Friendly 的 Web 应用程序 (Part 2 - Viewport)

在了解到iPhone的一些常见布局法后,我们就可以开始着手编写一个真正能在iPhone上跑的页面了。小声说一句,之前我说要布局讨论完了,要进入交互逻辑开发,后来细心一想发现不行,有些东西不讲的话将会对布局带来问题,绕过去的话并不怎么优雅,因此继续讲布局。

首先要说的就是viewport,也就是可视区域。对于桌面浏览器,我们都很清楚viewport是什么,就是出去了所有工具栏、状态栏、滚动条等等之后用于看网页的区域,这是真正有效的区域。(无论你屏幕多大,如果你装足够多的toolbar,你的viewport最终也会消失掉。)在桌面浏览器中,viewport的大小是与浏览器窗口大小直接相关的,窗口大了viewport自然就大,同时随着viewport的改变,页面布局可能也跟着变。例如width: 100%的页面宽度就总是和viewport宽度一致。

然而iPhone的Safari不是这样理解viewport的,它基于viewport呈现页面,然后用户缩放页面后viewport保持不变,仅仅是页面内容按比例缩放了。举个例子,在不设置viewport的情况下,默认viewport为宽度980(单位是像素),这时候页面的呈现出来的布局和在桌面短viewport宽度为980时呈现的结果一致,然而因为iPhone屏幕宽度为320,因此按比例缩小了。因此,一张宽度为320的图片,在默认viewport下会这样显示:

可以看到,图片按比例缩小了,这对于传统Web页面直接在iPhone上面显示来说是很好的事情,因为如果传统Web页面在980宽度的桌面浏览器viewport中显示正常的话,iPhone上显示也绝对正常。然而这对于Web应用程序来说则不是好事,因为我们需要按照980宽度来设计将来会以320宽度显示的页面,一个应该显示为320*80的元素,必须设计为980*245,这多麻烦!

因此我们需要改变viewport,让它变成这样:

实际上应该怎么做呢?我们有几个选择,因此先让我们看看到底我们能够设置哪些属性吧。我们可以操作的属性有4个:

  • width - viewport的宽度
  • height - viewport的高度
  • initial-scale - 初始的缩放比例
  • minimum-scale - 允许用户缩放到的最小比例
  • maximum-scale - 允许用户缩放到的最大比例
  • user-scalable - 用户是否可以手动缩放

这6个属性,我们可以设置其中的一个或者多个,iPhone会根据你设置的属性自动推算其他属性值,而非直接采用默认值。这点很重要,在完全不设置的时候有默认viewport,在你设置一个属性后其它值是自动推算出来的,不再是默认的。

如果你把initial-scale=1,那么widthheight在竖屏时自动为320*356(不是320*480因为地址栏等都占据空间),横屏时自动为480*208。

类似地,如果你仅仅设置了width,就会自动推算出initial-scale以及height。例如你设置了width=320,竖屏时initial-scale就是1,横屏时则变成1.5了。

那么到底这些设置如何让Safari知道?其实很简单,就一个meta,形如:

<meta id="viewport" name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;"/>

在设置了initial-scale=1之后,我们终于可以以1:1的比例进行页面设计了。下一步我们就可以正式进入页面布局的细节设计了,如果你想继续关注iPhone开发话题的话,欢迎订阅:

2007年12月23日星期日

编写 iPhone Friendly 的 Web 应用程序 (Part 1 - 布局入门)

用过iPhone的朋友应该知道,iPhone上面的一些应用程序是能够随机器转动自动适应的,也就是说竖着拿的时候就竖着显示,横着拿的话就横着显示,iPhone中至关重要的Safari浏览器当然也支持这一点了,因此我们考虑设计iPhone friendly的应用程序时,首先要考虑兼容这种情况,不能把页面定死在一个宽度上。且慢,我们不是说设计自己的应用程序吗?这和内置的Safari有何关系?iPhone被设计为不允许安装任何第三方应用程序(破解不在讨论范围之内),一切第三方应用程序必须以Web的形式来跑,小到一个国际象棋的游戏也如此,因此我们现在说的应用程序就是指Web,但是与传统意义上以提供信息为核心的Web又不同,我们所说的是以提供交互操作为主的应用。

好吧,在我们正是进入布局的讨论之前,先来赏析一下已有的iPhone应用:

Facebook iPhone Edition

Facebook的iPhone版。如果你已经习惯了在iPhone上使用过Facebook,第一次在PC上浏览这个页面会被它的“肥大”吓坏的。从这个页面我们能够得知,让页面自动适应iPhone屏幕的方法就是尽量使用百分比来定义宽度,特别是全页宽度一律用100%,如果是导航栏里面4个项目并排的就每个25%。

AppMarks

AppMarks可以说是一个应用程序的书签,当然也有人把它作为Safari的首页,那就相当于桌面了,因为你收藏的应用程序就在这个页面直接显示,以大图标的方式。AppMarks以前是可以直接在PC上浏览的,现在已经自动将非iPhone的请求重定向到介绍页了,不过这里有一个AppMarks Demo能在PC上看看。我们能够看得到图片是4个一行地排列的,共12个,然而横屏会怎样了?当然是变成6个一行,仍然能够在一屏内显示完,并且不会有不满行的图标。其实这是一个很tricky的做法,12是4和6的公倍数,因此虽然竖屏和横屏的显示方式不一样,但你不会觉得有什么缺陷。

Newsgator Mobile iPhone Edition

终于有一个ASP.NET写的iPhone应用了,其实和上面的Facebook看起来差不多,同样采用了宽度为100%的做法,同时页面上的元素要么向左对齐要么向右对齐。这听起来很废话,其实意思是,中间尽管留空,不要想把整个宽度为100%的块区都利用起来,说明性文字可以放左边,操作及视觉反馈放右边,这样无论屏幕怎么旋转都好看。如果中间塞满了内容,只会让Safari进行比例缩放操作,把页面整个缩小,这其实是不利于操作的。

GMail

这不是普通的GMail吗?怎样才能看到iPhone版?这就需要通过修改user-agent属性欺骗它了。iPhone上的Safari所用的user-agent如下所示:

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3

使用Firefox的User Agent Switcher修改一下user-agent就行了,然后你就能看到iPhone上看到的GMail了。仍然和上面的网站一样,可点击区域是一大个宽度为100%的块区。

小结

实际上,设计iPhone friendly的界面,在CSS的层面上来说一点也不难,甚至可以说是非常简单,因为基本上就是宽度为100%的块区,少数时候要用到按百分比划分的块区,但实际上我们也应该避免这种情况。为什么呢?别忘记了,iPhone的用户是没有鼠标的,他们必须通过手指来操作页面上的一切,因此可点击区域必须尽量大。

既然他们看不到鼠标指针,你也就不用考虑可点击区域必须是链接或者cursor: pointer,因为用户无法通过鼠标指针的改变来判断一个区域是否能点击。然而这同时也就引入了另一个问题,如何让用户了解一个区域能否点击呢?这时候你必须给出明确的视觉暗示,例如看起来是链接的文本,蓝色的文本有无下划线通常都挺诱惑人去点,这方面Facebook是一个例子。另一种做法是让界面看起来是菜单式的,好像AppsMarker和Newsgator那样,菜单右侧的符号让人挺熟悉不是吗?只要我点击这个菜单项,就会展开下一级菜单。最后一种做法就是基于用户已经熟悉的独创暗示来提示用户,习惯使用GMail的用户一看到邮件标题那个大大的蓝色区域,就知道点击是打开邮件,这是不需要任何指引的,最坏的情况下,用户不知道点击什么还是会点击邮件标题,之后他也就会用了。

到此为止,就已经把设计iPhone friendly应用界面的一些布局因素解释清楚了,我们下一步就要进入交互的环节,让我们的应用程序真正执行起来,并且是在客户端JavaScript环境中执行起来。如果你想继续关注本话题的话,欢迎订阅:

网络使用时间积累可能导致时空感扰乱

有时候会回想,到底大学三年干了什么呢,然后发现好像很难想起来,特别是后面那年。原因?我认为和花了多少时间对着电脑有关。

如果你每天有很多时间接触人,那么你的印象会很清晰,今天见到了这个人,昨天见到了那个人,之间的交互都是明确不同的。然而在线挂着就不同了,每天的东西看起来是很有建设性的,读feed增加资讯积累,写代码提高纯熟度,然而因为每天的动作都差不多,时空感很快就开始衰退。到底这件事是发生在昨天还是前天呢?我们是上个周末见面的还是再上一个周末呢?

我正在尝试观察这种现象,看看身边的人,特别是那些严重依赖于网络而且平时生活没什么特别的人,是不是很容易产生时空扰乱。同时我也尽量避免自己陷入这种问题当中,尽量确保自己每一天都是唯一的一天,通过特殊的事件作一个唯一的标记,这样我才能清晰记住某一个事件到底发生在哪天。

如果你对这个问题有所体会,或者有什么见解,欢迎留言。

2007年12月18日星期二

Apple 的帮助比 Microsoft 的要好多了

作为一个MacBook新手,当然很多操作都很不习惯,总是想用Windows平台的做法去完成一些任务,然而却发现做不到。最简单的,如何为一组mp3设置album photo呢?我尝试选中它们,但是直接在播放时设置album photo仅仅设置了当前播放拿首。然后我就查看帮助了,原来要打开info来改,这样才能实现批量修改。

总体感觉而言,Apple的帮助要比Microsoft的准确而且使用得多,当我想要做某个操作时,我总能找到有效的帮助,并且帮助上的信息也是确实可操作的,不会操作到一半发现有问题卡住了。从这点上看来,还是Apple的东西可用性比较好。

2007年12月15日星期六

iPhone + MacBook

终于把iPhone拿到手了,也就终于有设备能够和我的iTunes同步了,podcast才实现了其真正意义——自动下载,自动同步,无需人手干预。另外,iPhone的照片也都发到Facebook了,想看的可以过去看看。

使用了一个星期的MacBook之后,慢慢开始习惯了,反正现在不就是Web平台的时代嘛,什么东西不能在Firefox里面解决?OS上缺少什么软件也无需太在乎,有Web就好。

其实同时使用MacBook与PC最大的问题就是快捷键不适应,整天会想在PC上按command键,然后才发现在手上的是PC。然后用了几个小时的PC之后,再换回MacBook,同样的问题又出现了,又要重新习惯MacBook的键盘。

有一点比较怪异的就是,MacBook对我的移动硬盘还是不太“适应”,不知道是不是Spotlight索引的时候要锁住硬盘,反正硬盘刚刚插进去会自动卸载,然后又再加载。

最后要说的就是,好像我最近发blog都是那么短的,完全没有什么深度的,应该发到Twitter的那种类型。事实上,最近实在太忙了,除了公司的工作以及翻译的工作,还要忙于玩MacBook和iPhone呢,没时间去思考什么了,咔咔。

2007年12月10日星期一

使用 fluid layout 时记得设置 min-width

希望aw不介意我拿他的blog来做例子,因为第一次想到这个问题是我在手机上看aw的blog时碰到的。我的手机屏幕小,然而Opera Mini运行在完整视图时会以贴近Opera PC的形式处理CSS,因此fluid layout的多个列不会自顶向下顺序显示,而会保持原来并排的布局,同时因为fluid layout没有强制width,因此Opera Mini就会使用手机浏览器的宽度来显示整个页面,可想而知原本一个列会被压缩到多么的窄。

因此,使用fluid layout时,要加上min-width属性,加在哪个具体元素上看具体情况而言,但是凡是你不希望被缩得太窄的列,你都应该加上min-width属性。这时候,Opera Mini会发现无法压缩页面宽度,就只能显示横向滚动了,不过这看起来至少会好一些。

2007年12月8日星期六

MacBook 到手了!

梦寐以求的MacBook终于到手了,并且已经装上了最新的Leopard。因为是托熟人到香港买的(总害怕自己带过关会有问题),因此所谓的“第一次开机”已经看不到了,语言也选好是简体中文了。对于我这样有洁癖的人来说,哈哈……第一件事当然是重装,并且最近什么都装英文版,因此干脆装英文版好了,反正Mac OS的多语言支持是与系统界面语言无关的。

界面真的很漂亮,可惜看了说明书也不知道怎么用……我的意思是无法好像Windows那样灵活使用起来。什么文件要怎么用,都不知道,只能自己慢慢摸索。我在写这篇帖子的时候,机器还处于漫长的Mac OS安装过程中,因此也没什么好说的。

至今为止,我小小的一个办公格子中,就已经有三台PC了,真是有点点壮观,于是立即拿DC拍了下来,传到Facebook作为留念。如果大家想和我交流MacBook使用经验,那是绝对欢迎的事情。

Facebook 真正的重点在于 News Feed

其实我一直就觉得Facebook的news feed做得很不错,但是又说不出有什么特别。直到有一天,Jeffrey Zhao问我如果要实现一个Facebook的news feed我会怎么做,我才开始认真思考这个问题。这个news feed说起来就像是Google的搜索结果排名一样,你不可能用一些简单的规律来描述,但是你总能得到有用的信息。

首先,Facebook的news feed可以说是各好友的mini feed的聚合,但这又不是简单的聚合,否则就变成毫无意义的flooding了。暂时而言,我只能看出这种聚合反应的是一种趋势(trend)。例如有一天我看到我有六位好友换头像了,显然不可能一天之内发生这样的事情,只能说几天的时间里好友更换头像的事情聚合为一条新闻了。几天之后,这条新闻不但没有消失掉,还变成了八位好友更换头像的新闻了,最后变成了九位,前后总计在我的news feed上停留了一个星期。

虽然对我而言,更换头像就算是一个trend也没什么意义,我不会去跟风换个头像,更不会消费什么。然而有些trend是能够带来消费的,这时候把trend聚合出来,就能吸引更多同类消费了。例如现在比较成功的apps吧,如果有若干同好的好友用了同一个app,那么我就会比较好奇那个app是干什么的了。因此,将来如果Facebook有了更多涉及资金流的apps,news feed将推动好友之间的资金一同流动。

最后,预测一下技术的发展,所谓的PeopleRank估计已经有不少网站在研究了,其实大家都想知道如何去评估一个人的价值量,或者说以这个人为核心的信息的价值量,只是怎样才算是成功的算法,还有待验证。

2007年12月1日星期六

SNS 的世界会变平吗?

我们都听说过“世界是平的”这一说法,全球化无所不及也难以抵挡,那么在SNS上又如何?

今晚去北航听了王兴关于创业与SNS的讲座了,他提到的一个说法就是“仿生”。不是真正的仿生物,而是在线服务一般都仿照一个现实中存在的服务来做的,例如新闻门户是仿报业集团,购物网站是仿超市,C2C网站是仿跳蚤市场……他说SNS就是仿城市,一个城市里面,什么服务都有,上面的都包括了。

那么既然你已经看到城市这一步了,我就肯定要想知道下一步是什么。其实这个发展过程很像人类部落发展到大城市的过程,一开始有一些人定居,有贸易,由公共服务,就成为小部落了,然后再慢慢发展到大城市。至于API逐步开放的过程,王兴说的和我想的也差不多,开头是计划经济社会,城市里面所有服务都是官方提供的,然后逐步开始私有化,最后变成第三方竞争的提供服务。

那么到底现代城市建成之后,下一步如何呢?那就是城市之间的互联互通,以及建立新城市的成本会降低。互联互通方面,我觉得OpenSocial API可以说是潜在的UPS,全球化的物流枢纽。以往你在一个城市里住,就接受它的一切了,服务和文化之类的,没得选择,就好像我跑来北京实习就必须接受它的一些现状。然而客运与物流能力的提升,肯定能够消除这些限制的,让你不再需要考虑这个城市有什么,只要一件物品存在于物流网络中,你就能够要到它。

在这里必须强调OpenSocial API与SNS单方面开放API的差别。单方面开放API只是说明外部商业可以进入,然而OpenSocial API为连锁商业提供了标准,一个标准之下能够在多个城市提供服务。

与此同时,Ning这样的平台为建立新城市或者说新城区提供了便利。既然UPS已经能够使得城市间无缝连接,那么住哪里不一样?不一样的其实也就是与谁一起住,除此之外也没什么需要选择的了。天时、地利、人和,暂时而言,成功的SNS得到的是人和,这是一个完全的人为因素,然而完全不受人控制的天时,以及只能局部选择的地利,对于SNS来说又是什么呢?这可能将会成为决定人们定居的真正选择因素。