Yining.write()

I have enjoyed paper/white-board prototyping for a long time, even made it my teams’ one of first “rules of engagement”. I have also been a big fan of Balsamiq Mockups, and today I would like to introduce you another great quick prototyping tool: WireframeSketcher.

In a nutshell, WireframeSketcher is, as its home page says:

WireframeSketcher is an Eclipse plugin for creating wireframes, screen mockups and UI prototypes.

Having tried it out on two small projects in the last two weeks, I am impressed. It’s a neat, and pleasant tool to use and fits very well with both my personal and my team’s development process.

First, a screen-shot showing it in action:

Being an Eclipse plugin, it means

• developer friendly, as it’s right inside an environment already familiar to many developers (80% of my team uses eclipse on a daily basis), there is no extra software or framework or platform to install, and developers can just svn up project’s design mockup folder, then open the mockups in the same IDE, very neat and appealing experience compared to that of other prototype tools;
• cross platform;
• enjoys the benefits Eclipse plugin infrastructure brings, like update mechanism

Highlights I want to mention:

• The fastest and most responsive prototype tool I have tried and used;
• Mockups are stored as xml documents instead of image files, that means it’s friendly to scm tools like Subversion and diff;
• Has annotation support, good for asynchronous communication;
• Grouping of UI elements can be nested, i.e. I can group a label and an input box first, then group them with a button as another group, when ungrouping the latter, the first group of label and input box is still intact;
• Presentation of a mockup or a storyboard is handy, it’s right inside Eclipse. There is no need to export them to images first then pasted to a .ppt file in order to just show the mockups or the sequence of the mockups;

The most pleasant surprise to me is “Master Screen”, which allows me to pick any existing mockup as the base of a new mockup, this helps save time particularly when many of a site pages share the same header and footer. And there’s more. When I later make changes to the master screen, all screens that are “derived” from it automatically get updated without their xml files being modified (again, very friendly to Subversion and the like).

A close look of my sample mockups:

Storyboard example:

Some nitpicks or features I would like to see in the future WireframeSketcher:

• annotation does not provide link from notes to the annotated element
• I strongly believe url is an important element of user experience, but currently there is no way to specify the url on the browser control (I would suggest it takes two lines of input, the first being the page title, and the second line for the url);
• I couldn’t find a way to reuse a group of UI element, my idea is to allow user to have a collection of custom built (e.g. Paginator, Chinese version of “Loren Lpsum”) or assembled controls or control groups (e.g. a text input field always comes with a label and input box) as a separate category, this would help productivity among a project team at least;
• colors support in more controls (e.g. form validation error, and different colors in progress bar, red for slow progressed, and green for complete or near complete)
• One feature I particularly like about Balsamiq Mockups is the command line script to batch process (e.g. export to image files), I use it in my Ant build script to export mockup images. I hope this feature is coming to WireframeSketcher soon;
• Hopefully, a community could grow out of this tool, like what Balsamiq has achieved with Mockups To Go;

Conclusion? I would strongly encourage any developer or any development team that live and breathe in Eclipse to give WireframeSketcher a serious try.

Oh, did I mention a tiny problem with it being an eclipse plugin? RescueTime now can not tell if I am actually using a Dev Tool or a Design Tool … But heck, I sure can live with that given such a great prototype tool.

为什么说“又”呢？

平时工作中在界面设计的时候，我总是要求工程师先在纸上画图，初步确定后，仅仅用HTML+CSS做出静态的界面再次与用户（主要是其他业务部门）确认后，再动手写实际的代码。

纸上的原型设计是经常使用（至少我自己）的初期设计方式，办公室里用白板（空间大，而且环保些）和马克笔。这种办法不仅快，能尽早发现在文字和口头的沟通上理解不一致的地方，同时也尽可能减少开发成本和因为理解不一致导致返工的情况。纸上的原型设计在可用性上能起到很大作用，也有专门一本书介绍和探讨，这就不多说了。

但是这也有它们本身的不足。首先是没法很好地保留设计和讨论的内容，我曾经尝试用数码相机把白板上的内容拍下来，但仅仅是为了保留，没法有效地在后续的讨论和工作中继续使用。

几年前发现过一个做网站的设计草图的工具软件，Denim，这是一个大学的项目，学术性和尝试性的味道强了些，界面设计上有很多新颖的地方，但毕竟不是从每天蹲在“战壕”中的工程师的角度出发，玩玩可以，实际工作上还是不大可能用上。（附：Denim的截图）。

前阵子发现了一个新软件：Balsamiq Mockups，用下来发现它真正抓住了原型设计的核心与平衡点，既能快速设计草图，又能比较好地进入到平时团队工作的流程和工具中，可以说是击中了原型设计的Sweet Spot，强烈推荐。

先看看截图：

再说说功能和亮点：

1. 操作方面，拖拽，控件分组，甚至元素之间的对齐都做得很贴心；
2. 预制了很多界面元素，从简单的输入框，下拉框，浏览器主要元素，到经常用得到的导航条，日历，表格，到复杂的Tag Cloud，Cover Flow, 地图，WYSWYG的格式工具栏等，有了这些不用从头画起，往往比用白板都快；
3. 界面元素的修改很简单，比如导航条的几个标签页的label，就是用逗号分隔的文字，下拉框的选项就是分行的文字；
4. 使用xml语言来记录和保存界面元素和布局，
   1. 这使得每个设计都能被很好得放进SVN，Git，和CVS等工具中进行管理和跟踪；
   2. 可以设计复杂的界面元素，保存后，以后可以重复使用（包括修改）；
5. 可以将设计导出成PNG格式的图片；
   
6. 可以用命令行进行导出操作，这样就能让我写个脚本，从svn里checkout某个目录下的所有设计文件后，导出图片，打包后用邮件发到项目经理，工程师甚至客户那；
7. 跨平台，Balsamiq Mokups是用Flex和Air实现的，所以在Mac OS, Linux和Windows下都能使用；
8. 不仅仅有桌面版本，还有能集成在Confluence，JIRA，和XWiki中的版本，使得异地在线协作更方便有效；

据作者说，现在这款软件的设计就是用它自己来设计的，经典的“吃自己的狗粮”，这也让我对其更有信心，因为它是开发者为开发者写的软件。

更多信息，大家可以到它的网站上了解。

还有值得一提的是Balsamiq Mokups的在GetSatisfaction上的用户支持和服务，作者Peldi对问题报告，新需求的回应很积极和及时。而且根据这个讨论上看，到月底就会有一个专门用来分享界面控件设计的社区网站了，很期待。

再要说的一点是这款软件是要付费的，79美元（也可以免费，具体如何免费，请看网站上的说明），相对于它能节省下来的时间和提高的效率，是很值得的。Peldi说在2008年，这款软件就从1,322位付费用户那获得了162,302美元的收入（其中仅12月份就有39,000美元），这令人鼓舞地证明了只要是提供真正价值的服务和软件，就能够创造很好的收入，即使在经济萧条的寒冬里。

另外说一句, GetSatisfaction也是一个很不错的服务。

这几天在收拾东西，惊喜地翻出95年买的Windows 95和Plus!一套！那天微软全球同步发布Windows 95，晚上（因为与美国的时差）我和同学一起到Funan Center排队购买。当时发布的媒介分CD和3寸盘两种版本（没有MSDN下载，MSJ杂志也还没改名MSDN），轮到我的时候已经没有CD版了，于是先拿了3寸盘的，结果后来补了CD，但3寸盘也留下了。

当时还在上学，系里有个很有名的教授(AP)，出版过IBM360(?)操作系统的专著，于是当年操作系统有一个学期的一大部分课时就是听这个瘦小精干的老头侃IBM的JCL(Job Control Language)。那时候学生个人用的都是DOS和Windows 3.11，学校机房里是Sun的工作站和DEC VAX的终端，几乎没人知道离开自己一个北半球的地方有个将在几年内影响全球IT界的Linux。

那个JCL让我昏昏欲睡，虽然老教授目光炯炯抑扬顿挫，但我知道自己不会在那玩意上浪费哪怕一分钟（当然，要是那时候努力学习并精通的话，也许一辈子工作都有保证了 － 但这既不是当时也不是现在的我想要的）。自己买了Jeffrey Ritcher的Advanced Windows了解Win32，直到现在我还是觉得那是一本非常经典的好书，把Windows上的pre-emptive multi-tasking，32位寻址空间，虚拟内存，线程和进程等操作系统上的核心概念深入浅出解释得很透彻明白，我也从此开始了几年的基于Windows开发的历程，OLE, COM, MTS，COM+, … 甚至一直到工作上使用Java之后，曾经为了实现EJB Container也向MTS借鉴了一番。

我现在基本上已经不用Windows了，改用Linux已经好几年，而且是直接从网络上下载后安装。大部分人包括我自己都不是技术上的弄潮儿，都是被新的技术和发现不断推着向前冲。想想看，如果回到过去看现在，对一切的变化，一定要比站在此时看过去要感到震惊得多。

Windows 95是自己掏钱买的第一套Windows，也是自己掏钱买的第一套操作系统（本来想说也是最后一套，但是想想，那些随笔记本一起的OEM的Windows XP其实也是自己掏钱买的…）。

写了上面这些字，回顾一把；拍几张照，纪念一下。

包装盒外观和当时把Windows95作封面的Newsweek和BusinessWeek：

里面的东西，有CDKEY和正版证书 :)

相关链接：

• Wikpedia上的Windows 95的介绍

今天（4月9日）是今年的，也是第三个CSS裸奔日

嗯，如果你是在Feed阅读器上读到这里，是看不出来裸奔效果的，直接点这里看裸奔效果。

CSS裸奔日的中文介绍页面上说活动目的是：

推动Web标准。简洁为美。使用正确的(x)html，语义标记，良好的层次结构。

碰巧，下午给刚来的实习生介绍HTML和CSS，跟很多毕业生一样，他也是没有DreamWeaver一类工具就不会做网页，从来没有接触过Web标准，更不要说相关的开发经验。因此期待能在短短的一个小时内让他体会到使用Web标准的优势是不可能的。

也许只有在实践中实实在在地feel the pain，才会开始欣赏简洁的符合标准的设计，和开发上提高的效率吧。

另外，在裸奔的时候，就能发现我现在的WP的主题不是非常好，因为Categories，档案，还有blogroll等的列表都排在前面，而正文反被摆在最后了。

测试了一下，裸奔时，WP还是可以留言的。

在Firefox上安装了支持微格式(Microformats)的扩展(Operator, Tail Export等)的，也许会注意到年会注册程序的页面上已经提供了hCalendar的支持。以下是在这些页面上使用几个扩展的截图。

下面是Tail Export在边栏里列出的年会议程页面页面上所有hCalender微格式，用户可以点击export图标把感兴趣的活动/议题加入到本地的程序比如Outlook, Mozilla Calendar项目的软件比如Thunderbird Lightning等。

导入到Outlook里后：

我个人更喜欢Operator这个扩展，因为它还能把微格式导入到在线的日历服务比如Google Calendar和Yahoo! Calendar，而且似乎对unicode支持比较好。以下是截图：

导入到GCal里：

链接：更多关于微格式的截图。

从这些页面和本地程序的数据交互，以及网页和网页之间的程序调用和数据交互，展示了语义网(Semantic Web)，最基础的技术支持(HTML, MIME, HTTP)就能提供很好的在线和本地（尤其是移动终端, iphone, mobile firefox? mobile xulrunner?）集成以及更好的用户体验。

另：年会注册程序里除了hCalendar，年会页面当然也能提供hCard（个人信息）的微格式，但是在没有更好的隐私保护措施和共识之前，对hCard的支持目前还是没有开放出来。其它的格式比如FOAF，hReview，rel-tag, rel-license等的支持，会在将来陆续提供。

P.S. 有点遗憾，因为临时有事，没能来得及在年会开始之前做这个介绍。

从卓越上订购的Prioritizing Web Usability的中文版到手两周，周末翻了一遍，非常失望。

这是本翻译过的书，所以要评价的话，得把原书内容和翻译编辑排版部分分开来说。

先说原书内容部分吧，

首先，大部分内容是非常基本的应该是大多数设计者甚至是程序员所了解的常识，比如字体颜色和背景的搭配要有一定的反差，不要有弹出窗口等。大部分在网络上已经有很多类似的可用性注意点的列表以及详细的讨论 － 它们是免费的。

其次，书里列出的网站的例子，说少也不少（有必要把这些网站的首页截图都打印在书上么？），但是绝对不能说是多，因为它们之中典型的类型并不多，大部分是商业机构厂家，web2.0以来在网页设计和使用上很有影响力的网站几乎看不到一个（注：这本书可是06年才再版的）。

自然，原书作者根本没有介绍或者讨论最近（宽恕我，我知道的，2005年在互联网上已经算不上“最近”了）的以AJAX为主的新的用户界面元素所带来的在可用性方面的影响（再注：这本书可是06年才再版的）。

再说说原书犯的错误和缺陷：

P162, 第六章，6.10，“从主页直接访问”一节关于Mozilla网站首页上的下载区域的评论： “…显然，该区域主要服务于那些想要适用于Windows英文版的人。…”，显然，作者没有明白该网站是根据用户浏览器发送的HTTP请求里的UserAgent以及Accept-Language头信息判断用户的操作系统以及语言设置来生成相应的页面，而想当然地认为是因为“主要服务于Windows英文版的人”（其实是因为作者用的是英文Windows而已）。

关于复杂的URL，“尽管复杂的URL对可用性和搜索引擎优化都有危害…”，很遗憾，没看到作者对于复杂的URL对可用性的危害的解释（至少连粘贴到email里的URL会被email软件断行导致收件人点击无效链接的问题都没提到）。相反，作者推荐了TinyURL这样的服务，却没有提到TinyURL对可用性的影响（比如用户无法从URL看到链接实际指向的地址）。

在关于选择字体的部分，没有提到可以使用CSS和Javascript让用户自己选择字体（至少是Serif还是Sans Serif）和大小，这在今天这样的技术已经很成熟的时候，居然丝毫不提，更不要说提及sIFR这样的手段了。

如果要放截图，没必要整个页面的截图都放进来，只要把相关的，说明问题的页面部分就可以了。一个例子：P72的占了半个页面的截图，说明相关问题的仅仅是右下角的“skip intro”的几个按钮，更不要说这张图片明显要比实际的原图大（图片边缘的锯齿）。

关于上面讲的P162的Mozilla的界面用了前后比对的两个页面，也是只需要把页面的相关部分抠下来，并排摆放，这样用户比较起来更明显更容易，可是，居然用了整页的截图，而且放在不同页面！又是一个毫无必要的浪费，以及其所导致的在可用性上的失败。

书里常常提及用户的“挫折感”，可是，没有看到有关于用户为什么会产生挫折感的深入和系统的讨论，关于这方面，还是推荐《Dont’ Make Me Think》这本经典。

再说说这本中文版：

原书名是Prioritizing Web Usability，中文名称：网站优化。关于这点，请编辑和译者自己读读第三章的3.1.7“浮夸的内容以及空洞的夸大宣传”以及第八章的8.3.2的标题：减轻夸大的宣传。

一本关于可用性的书最难的在于能在各方面要能“可用”，至少不与自己所“推销”的可用性原则产生矛盾。可是我却能在这本书里找到许多反例：

这本中文版没有索引！这是不是指望读者从头到尾就看一遍，还是希望读者将来为了找某个要点得再从头翻一遍？

书里有很多在正文外的文字框，这些文字框的标题栏背景有橘黄色，绿色，深蓝色，而文字背景有白色，绿色，和橘黄色，不同颜色代表什么意思呢，我以为在前言或者介绍部分应该有“如何阅读本书”的部分做对应的介绍，遗憾的是，没找到。仔细看看发现每个章节的小结标题都有不同的背景颜色，比如第一章的是浅蓝色，第二章是浅橘黄色，第三章是浅绿色……有必么？这不仅让读者阅读的时候产生混淆，也让书的成本增加，这都是毫无必要的。

页面排版，每页竖的两栏，跟报纸似的，这跟我们平时看书的习惯不一样（请编辑和译者自己再阅读一下第8章的“为什么用户会进行扫描式阅读”），而且往往中间插入一段横跨一页的说明文字，打破两栏文字的文字框，整个阅读过程必须不断避开跳过这些隔断正文的文字框，跟玩贪吃蛇一样。

总结我的意见：

1. 如果用《连线》杂志常用的评价来描述原书给我的印象，那就是：TIRED and EXPIRED。
2. 从其内容和内容质量来看，这标价89元的书太贵了，毫无必要的贵，不值得买。

如果你从来没有接触过关于网页/网站可用性的介绍和讨论，那么建议你去借一本来看，要是借不到，就在书店里花一两个小时先看看，实在觉得对自己有用那么再买。如果已经对可用性有一定了解，那么没必要看这本书了。

最后，我斗胆在这里做些建议：

1. 读《Don’t Make Me Think》；
2. 学习和掌握网页标准(Web Standards)，近期一些关于CSS和Javascript的书里有很多对可用性的讨论；
3. 网络资源：有很多网站提供可用性研究和讨论；
4. 参与在线讨论（比如DeDream’的Google Group）；
5. 最重要的，多看看一些好的网站，多用些common sense；