Allan.Blog()

虽然是很俗的景点,但是在那下面看着,金门大桥的确很好看

标准的旧金山居民区

驶过大桥后,往前开了没多远,就到了一个小镇叫Sausalito

在Sausalito远眺旧金山,那个应该是海湾大桥

机场门口

刚去的第一天住在5号州际公路旁,能看到远处的大雪山

干净的街道@tacoma

去Seattle Downtown的公交车上,扫过波音公司的专用机场

集贸市场,也是这地的旅游景点

卖菜的也能刷VISA

和新发地比比有啥区别么?

码头上的游艇

市区能看到远处的大片雪山,翻过去应该是加拿大和阿拉斯加了

从码头看downtown

西雅图图书馆,设计出自北京CCTV新大楼同一设计师

太空针塔

比较有意思的细节,国外的工地怎么就这么干净?

Downtown

西雅图和华盛顿州地标性的大雪山

西雅图downtown建在山丘上,好几次看见人家开的车往下溜..

科幻博物馆,主要展出一些模型,有个科幻商店看上去不错,但是晚上没有开放

其它照片放在Flickr

在美国,特别是西部,没有汽车简直无法出行,而这促成了租车业的发展与服务的完善,这次分别在西雅图租车,旧金山租车与到洛杉机异地还车,各方面感觉到的租车服务业中的人性化设计,所谓用户体验.

首先租车成为了一种服务,跟航空公司的柜台一样,在出机场的时候,就有各大租车公司的柜台,可以直接去租,或之前在网上都处理好,去了报自己的last name一类的,就能根据之前预订的情况拿到汽车.

像西雅图由于机场较小,租车公司停车场就在机场对街,有天桥直接通过,非常方便,大概是一个5层左右的大型停车建筑,每一层就是一个租车公司的车库.当时办好手续,工作人员告诉我在N层N号车位,当我过去的时候,一辆车停在那里,连后背箱和车门都帮我打开了,知道我要放行李,钥匙在车上,自己开了就走了,完全没有人在身边.

而在旧金山,由于机场太大,租车公司放在离机场远一站地的一个区域,但机场的内部地铁交通系统就有Rental Car这一个Station名称,从机场出来后就能直接坐内部地铁系统到达租车公司的停车大楼,非常方便.

洛杉机的话没有地铁运输,但下了飞机后,可以直接在租车柜台说一声,没一会就有租车公司的小型巴士来接你去停车场,也是非常方便.

而每辆车中都有呼叫按钮,有情况按一下就直接与公司客服联络.而还车的时候,也是如此,当把车开回各机场的时候,高速路上的车道标识便直接有一个指示如果要Return Car的话该走哪个车道,直接开回租车点,开回去就有人拿着小型收银设备上来检查汽车并打印帐单给你,就可以直接走人了,不需要再回到主柜台.

所以租车业就跟公车一样已经与机场的服务连为一体,密不可分,而且效率很高,从网络订车到现场取车到还车一套完全无缝的流程帮助客户最高效率得到服务.各公司的竞争应该主要就靠网络订车的易用性,价格与车的质量一类的

另说一句,美国租车都是采用新车,估计租个一二年就卖掉了,租了二次车,里程分别是2000和4000英里左右.车内还有很重的塑料味

2008 MVP Summit在上上周已经在Seattle结束了，这次是头一次参加这种世界级的各路高人参加的会议,感觉收获很多,而在与其它MVP,以及在与Seattle一些当地公司的交流中,发现其实国内行业里与外面的差距真的不是一点半点.

记得在产品组晚餐里,见过一位美国白发老头,估计少说有60-70岁,胸牌上写着,FrontPage MVP,我当时就问他,现在还在用Frontpage?老头回头很肯定,还在用2003,没有换其它工具.当时心里想,在国内,如果不是年龄在20岁,会个Dreamweaver 2010或Ajax一类的,还能找到个工作?而在美国,60岁老头用Frontpage就能一直干着自己的本行,简单说还在干着几十年的HTML,足以说明人家对技术的坚持,或者说任何技术都可以成就一个所谓的专家,不浮不燥把本职做好,同样可以活一辈子干到70岁.

转眼第二天,与这老头一起参加Expression产品组的小组讨论,当讲到一些Steam Media的时候,老头问了好几个很专业的问题,关于流媒体与现有技术的区别,如何应用在表层中,是否需要新的控件一类的等等许多,这时候才发现,人家其实干的是HTML,可骨子里真是真刀真枪的了解的所谓网站建设中的方方面面,绝非只是一个写HTML Code那么简单.

当然,在整个MVP会议中,见到的白发老爷爷老奶奶绝非一个二个,同样四,五十岁的专家比比皆是,参加一些Open Session的时候,一些各国MVP的讨论有点让我像是回到了看过的各路原版技术图书中,有关项目管理的,有关用户体验的,人家是真正实际的在用各种工具,手段,去实现所谓的项目管理,用户体验.把真正工作中遇到的问题说了出来,绝非我们只是画几张IA那么简单,足以说明我们目前与国外部分专业人员的差距.回想我们的年龄和我们的工作,不少人自称为专家,但是就同一起跑线来比的话,人家年龄上吃的米还真是比我们吃的要多,我们还称得上专家吗?

差距看到了,值得我认真反思,有更多事情值得所为.

看出异常了么？在Silverlight 2的实践之中，发现如果不选择字体的情况下，对中文默认将由雅黑来显示，但是总有一些文字变成宋体。感觉在这一版本中，runtime中被嵌入了一个小型的雅黑字库(雅黑大字库有10好几M)，如果文字不在字库中，就得转用系统宋体了。。目前还没发现类似device font以及打包字体的选项，也许这应该是下一版beta或是Expression Blend工具中需要加强的一个功能，收集使用的字体，并打包为资源，供发布使用。

这二周工作很忙，几乎就周六晚上才能休息几小时，看了这部给人惊喜的英国电影，非常推荐

《移动设备交互设计》(Mobile Interaction Design)　推荐

11月初,收到了博文视点的一本外版翻译图书的目录《移动设备交互设计》(Mobile Interactive Design)，希望给写一篇推荐。看到书名之后，有点意外，同时又充满了兴趣，没想到这样一本有关移动设备交互设计的经典图书，这么快能够在国内得以翻译出版。而且也很幸运，虽然我的工作没有全职投放在移动设备的设计之中，但是与此相关的信息总能保持联紧。

与原版图书《Mobile Interactive Design》初次接触应该源于是2006年。当时因为Flash Lite项目的缘故，参与了一个开发团队，开始了有关手机上的内容与应用产品的设计开发工作，产品虽小，但是却花费了不少精力。自已是首次在手机设备上做相应的设计工作，希望能够拿出一个够格的作品，在整个开发的过程中，与团队成员，以及其它朋友都进行了深入的交流，对小屏幕以及小键盘上的这种设计进行了多次探讨，不少朋友给了很多优秀的建议，记得当时在一个下拉菜单的设计上，从交互方式到视觉设计，都做了不下几十种不同的方案进行比较。最终的成果还是令人满意，获得了认可。

在整个过程中，与大家讨论的核心就是，“小屏幕上，如何去做设计”。对Web开发虽然有着多年的经验，但是走到小屏幕上时，几乎要放弃掉在Web上的近70%的知识体系,全面围绕着那五向方向键的最大可用性进行设计。在开发过程中，资料也非常稀缺，当时在Amazon上看上了几本移动设备方面的图书，这本《Mobile Interaction Design》也包括在内。

屏幕虽小，但却有着比大屏幕更严格，更高要求的设计目标。记得当时项目完成时，非常具有成就感，因为感觉跳出了由鼠标和键盘控制的世界，用五向方向键，设计出了全新类型的产品。当时团队成员笑称，做小屏幕上的设计更有挑战，更有意思。

花了一个下午，在楼下的咖啡厅读完了本书的中文译本，我觉得用书中的几个章节的关键字，更容易理解这本书的内容：

Keyword:T9输入法

对于大多数人来说，可能也没有任何人去追究手机上比普通输入打得更快的T9输入法的历史。而这本书中给出了这个答案。事实上T9输入法是在非移动设备上（大屏幕）研究的一种来帮助残疾用户的快捷输入方式。他们研究如何使用有限的交互设备来帮助输入，包括使用一种能定位的眼镜来帮助输入，由于眼镜只能精确注视屏幕上的8个区域，因此这个解决方案帮助匹配眼镜注视的输入内容。而转到移动设备上，我们的键盘不正也是只有9个按键区域的有限交互能力吗？

大屏幕的大阅读空间与各种交互装置（键盘/鼠标/…）使我们有更多的交互能力，而转到小屏幕上，交互能力的局限性迫使我们使用新的思考方式、手段去找到更有效更方便的交互方式。避开交互能力对我们的限制。

Keyword:Heckl定律

Heckel定律：如果用户觉得用具的价值很大，那么，用具的用户界面的质量在决定是否采用该用具的过程中是相对次要的因素。
Heckel逆定律：在使得人们能够接受一个用具的过程中，用户界面设计的主要性与用具被感知的价值成反比。(Derrett,2004年)

这个定律让我想起最近网上讨论比较多的，在交互项目的团队之中，设计师越来越不被重视，提出的设计往往被PM的项目控制原则所阻挡，让设计者感受不到UE/交互设计上的信心。产品最终恶性循环，最终交付给用户的只是廉价粗劣的产品。书中也提到，界面不等于交互，作为设计师，我们是否是以界面为出发点去做产品设计，还是以交互为出发点去做？这决定了设计的采纳程度与最终PM与项目控制者的决策。书中有大篇的章节在描述如何理解产品/用户，实际上是在帮助我们转变思维由纯视觉设计者转为一个交互设计者。只有真正在交互上去做设计，才可以提升交互在产品中的价值，与产品价值形成正比。

Keyword:原型

在Web与Desktop产品开发中，我们都用到原型式的快速开发方式。与移动设备的原型开发不同在于，你在屏幕上做的原型设计，就是最终可能要采用的东西，而你在屏幕上做的移动设计的原型，最终要放在一个比你屏幕小上许多倍、而且没有标准键盘和鼠标的地方运行。

小屏幕完全让我们失去了设计上的自由度，无论你用图形软件或是PPT绘制出了感觉良好的交互体验，与在真实的移动设备上的操作体验是完全不同的。就算是开发模拟器用大键盘中的数字键区或是方向区来模拟手机键盘操作，从本质上也不能真正还原场景。因此原型开发在移动设备的设计中，更需要一种全新的还原场景方式。书中提到了手绘、即时贴及手机屏幕卡片还原的各种原型方法，正是有关小屏幕的原型解决之道。

另外引用书中的一句话更好帮助我们理解原型：“制作原型是一种让你快速失败(Fail fast)的方式，如果我们失败的次数足够多，那么，最终将得到正确的设计”。

Keyword:映射与一致性

映射是指在用户的行为和产生的结果之间，提供一些清晰，自然的对应关系。无论是移动设备还是标准屏幕，不去谈映射的理论，从实际出发也能看到，映射正在以更自然的方式触动我们的交互体验。

书中提到apple ipod滚轮设计的成功，其原因之一就是卓越的映射体验：首先转圈式的指间触感给人很舒适的感受：连续、平滑、简单。而顺时针转动与逆时针可以很方便的让人去理解，在转动一个列表进行上下翻页时，顺时针指“有更多”，逆时针指“更少”，而无论是选择歌曲还是调整音量，都采用滚动的方式给产品带来前所未有的一致性。用户在任何扩展的产品功能中，都可以采用一致性的交互方式。而从交互心理上，我们留意一下收音机音量旋钮及音乐带来人的节拍感，这无形中都让ipod的交互让人们更有节奏、更流畅的去控制产品。

而另一方面，我们最近也看到了一些新产品，如微软的Surface计算机，有一次听设计者介绍如何设计无键盘方式下，进行照片浏览软件的设计，实际上是通过研究真实生活中的一家人，不同年龄不同性别，如何在一起分享和讨论照片。于是Surface的照片软件设计，就如同真实在桌面上操作一样，用手去抓照片，放照片，让每一个人都能找到真实的感受，不需要说明书，就和平时真实生活一样去观看照片。其它软件如酒吧点菜、购物等应用的设计，也是在不断的去做真实的用例场景映射，从视觉设计上，交互方式上，提供给用户完全直接的用户体验。

几个关键字无法了解一本书的全部。相对于传统交互设计，移动设备交互设计还是一个新的领域，也许计算机键盘和鼠标几十年都不曾改变，但是移动设备的交互能力发展肯定不会那么缓慢，每一次输入方式变革，都将带来交互设计上思维的改变，从数字键盘到全键盘，触摸屏到如今的iphone的Multi-Touch，都应证了这一点。书无法面面俱到，无法预测未来变革，但却能告诉我们这样一个有关交互能力与交互设计之间的这么个巧妙的道理所在。

Mobile Interaction Design 原版介绍

该书已经上市，不久会发上链接

Silverlight 2.0 beta出来后，在很多方面比起以前的1.1有着非常大的变化，其中之一就是开发与布署的结构，首先我们发现，Silverlight默认已经将所有文档编译打包为了一个全新的文件叫.xap并放置在ClientBin目录下，如何理解xap呢？

xap目前就属于最终需要布署的核心文件，有点类似于Flash的swf，不同的是，xap其实本质上是一个zip文件，如果你把他改名为zip，那么是可以正确解压的。通过打开xap文件，我们能看到一些类似于如下的内容：

先来看几个dll文件，在这个文件结构中：
SilverlightApplicaiton1.dll是本解决方案中的主应用程序程序集
SilverlightClassLibrary1.dll是在本解决方案中建立的一个Class Library的程序集
System.Windows.Controls.dll及另一个.Extended.dll按我的理解就是这次编译中所需要的一些内置的控件所用和程序集
AppManifest.xaml是一个描述文件，描述本包中的各程序集，以及入口程序(EntryPoint)是哪一个，如果用文本编辑器打开的话就能看到这个文件的描述：


<Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" EntryPointAssembly="SilverlightApplication1" EntryPointType="SilverlightApplication1.App" RuntimeVersion="2.0.30226.2">
<Deployment.Parts>
<AssemblyPart x:Name="SilverlightApplication1" Source="SilverlightApplication1.dll" />
<AssemblyPart x:Name="SilverlightClassLibrary1" Source="SilverlightClassLibrary1.dll" />
<AssemblyPart x:Name="System.Windows.Controls" Source="System.Windows.Controls.dll" />
<AssemblyPart x:Name="System.Windows.Controls.Extended" Source="System.Windows.Controls.Extended.dll" />
</Deployment.Parts>
</Deployment>


对应在解决方案中，我们能看到这样的结构：

那么这种解决方案的生成方式，按文档的说法，被称之为In-Package Deployment，打包布署形式，所有的程序集都打包在xap之中，但这样引发的问题是，用户在第一次下载所要求的文件量太大。因此Silverlight提供了另一种应用程序布署方式称之为On-Demond Deployment，按需布署，可以将一些辅助的程序集不放在这个xap之中，具体做法如下：

首先我们找到主应用程序引用我们的ClassLibrary的地方，打开他的属性：

在下面的Copy Local设置中，我们将默认的true设置为false，实际意义在于，我们这个项目的Project中，原有的一句描述：


<ItemGroup>
<ProjectReference Include="SilverlightClassLibrary1\SilverlightClassLibrary1.csproj">
<Project>{06133EAC-ECC0-421F-B424-DC3F63145F10}</Project>
<Name>SilverlightClassLibrary1</Name>
<private>True</private>
</ProjectReference>
</ItemGroup>


其中的


<private>True</private>


将变为


<private>False</private>


表示此程序集将不被打包进xap之中，这样就解决了该程序集自动被打包的问题，那么这个时候我们就需要在真正使用这个程序集之前，用代码手工去加载这个dll，相关代码如下：

使用WebClient来加载程序集


WebClient wc = new WebClient();
wc.OpenReadCompleted += new OpenReadCompletedEventHandler(wc_OpenReadCompleted);
wc.OpenReadAsync(new Uri("SilverlightClassLibrary1.dll", UriKind.Relative));


加载完成后的事件中，使用该程序集:


void wc_OpenReadCompleted(object sender, OpenReadCompletedEventArgs e)
{

}


每一个加载进来的程序集，我们需要使用AssemblyPart类进行一次装载，记得之前xap中有一个AssemblyPart的描述吗？就是代表这个意思，现在我们手动加载，然后便可以随意使用该程序集中的各种Class与Control了。

需要注意的是，注意在发布的时候，将SilverlightClassLibrary1.dll拷贝到最终运行的站点中的ClientBin目录下，或是设置这个Class Library的发布路径属性，直接指向那个目录，以方便每次将程序集dll文件自动拷贝过去。

通过这样的方式，我们就可以在真实的应用程序开发环境中，使用不同的程序集及按需下载的方式来加载相应的内容。

头次尝试DeepZoom的时候，发现Source无法设置为相对路径，经过测试才发现，原来MultiScaleImage的Source目录的指向是ClientBin下面，所以如果设置

Source=assets\info.bin

那么info.bin的发布路径应该在

ClientBin\assets\info.bin


实际上在装了Silverlight Beta1 SDK后，并没的提供真正的CHM格式的文档，需要在这个地方单独下载