新年新服务： MVP 播客上线

其实我很早就想做podcast（播客），10月份从三亚回来一直在筹备一个MVP博客，最终在前天完成了第0集（pilot episode）的录制，并将于今天稍晚时候上线。在整个过程中，我需要感谢dudu以及博客园对podcast提供的支持与服务，感谢Bean与Jeffrey对podcast准备工作与录制的投入。

首先，我介绍一下podcast为什么叫做podcast。过往，我们能够订阅feed，从而好像收取email那样收取网上的信息。例如，我订阅了ABC World New，设置了我的电脑每天早上7:00自动开机并打开feed reader下载feed，那么当我准备好早餐后，我就可以一边享受早餐，一边阅读新闻了，这和传统的喝早茶看早报没什么区别。

然而，ABC World New的新文章，附带了一个新闻视频片段，以龟速的下载速度，我可不能等下载完看完再去上班，因此我希望我的feed reader能够识别视频音频片段并且自动下载。RSS 2.0的<enclosure />标签是第一个出来把问题解决掉的，只要把这一个feed entry相关的文件放到<enclosure />链接内，feed reader就应该懂得自动去下载。之后，我把电脑自动开机时间改为早上5:00，预留两个小时，什么龟速也能把几分钟的视频片段拉下来吧。然后，我还是边喝着早茶（或者咖啡），边看新闻，不过这次不用读文字了，视频里面有人说给我听。

随后，iPod和iTunes又把这个应用提升到了一个全新的层次。如果你使用iTunes订阅新闻，起床后我只需要按一下同步按钮，视频音频都传到iPod上面去了，然后专心吃我的早餐，出门口时记得把iPod从同步底座上拔下来带走就是了。我在地铁或公交上有足够多的时间，把iPod拿出来看看或者听听头条新闻的时间是绝对是有的，甚至还能听听有声电子书。

由于这个功能在iTunes与iPod上就被命名为podcast，而且iPod在美国相当普及，所以大家就都叫podcast了。不过，Microsoft貌似避忌所有pod字开头的东西，以保持和Apple之间的距离，所以就坚持把同样的东西叫做netcast，这样显得中立一些。不过Zune2里面的功能菜单就写着podcast，看来负责整理Zune2菜单字符串资源的人有被炒鱿鱼的危险了……另外，国内有一些名为播客的东西其实不是播客，土豆一开始就给人如此批评了——不支持RSS订阅，也不允许下载，更别说放到iPod上了，这也想带上播客的头衔？

好吧，对podcast的介绍到此结束，稍后MVP博客的第0集将会发布到netcast.cnblogs.com，并且我还会另外发贴详细说明如何订阅podcast。敬请期待！

我嘅 2007

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

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

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

如果一開始，我唔係喺Dflying同埋Jeffrey嘅blog上評論，佢哋亦唔會嚟睇我個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嘅機器搵一個操作系統。佢去咗邊度搵？去咗Washington嘅Redmond會見Mary個仔，即係Bill Gates。多謝同埋IBM嗰單生意，Bill Gates做咗首富。如果John Opel從嚟未聽講過佢個名嘅話，IBM絕對唔會派人去Redmond睇一間當時幾乎同Microsoft一樣默默無聞嘅公司。

點樣放電

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

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

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

编写 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。欢迎订阅本系列文章：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

编写 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属性吧：

边框

• -webkit-border-image - 让边框支持图片（iPhone上支持存在bug）
• -webkit-border-radius - 让边框支持远角
• -webkit-box-shadow - 让盒区域支持阴影（iPhone上不支持）

背景

• -webkit-background-origin / -webkit-background-clip - 控制背景的定位与剪裁
• -webkit-background-size - 控制背景的大小
• background - 多背景，如同单背景一样定义一个背景图片，多个图片定义之间用逗号分隔（未经测试）

色彩

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

文本特效

• text-shadow - 让文本支持阴影
• text-overflow - 控制文本溢出时的裁剪与视觉反馈
• word-wrap - 控制长单词换行

用户界面

• -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专题的订阅地址如下：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

编写 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会自动修正前面那个词。

要关闭这两项功能，可以通过autocapitalize与autocorrect这两个选项：

<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，欢迎订阅：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

编写 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，那么width和height在竖屏时自动为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开发话题的话，欢迎订阅：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

编写 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环境中执行起来。如果你想继续关注本话题的话，欢迎订阅：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

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

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

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

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

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

Apple 的帮助比 Microsoft 的要好多了

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

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

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呢，没时间去思考什么了，咔咔。

使用 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会发现无法压缩页面宽度，就只能显示横向滚动了，不过这看起来至少会好一些。

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估计已经有不少网站在研究了，其实大家都想知道如何去评估一个人的价值量，或者说以这个人为核心的信息的价值量，只是怎样才算是成功的算法，还有待验证。