正如我多次提及的，我认为Web Apps的最大的优势和特点就是便携性。这一特点是所有Web Apps天生就具有的。不过我认为目前的Web Apps对这一特点的拓展不够广泛。目前大多数Web Apps都是采用Google Docs的模式，将待编辑的文件默认储存在服务器中以实现这一便携性的特点。然而这种做法毕竟不是长久之计。我不是指硬盘空间不够，硬盘是现在最不值钱的东西了，而是指由此带来的对服务器压力的增加。这种做法只能适应于目前使用Web Apps的人数还比较少，因此同时使用的用户并不多，对服务器的压力还不算大。
试想一下，当Web Apps的普及程度达到今日Microsoft Office的普及程度时，如果Google Docs取得了今日Microsoft Office般的垄断地位时，即使是拥有全世界最多服务器的Google我相信也未必能处理得了那么大的对服务器的压力，一旦服务器出现问题那对用户的影响绝对是极大的，而由此引起的对Google的打击也必定是毁灭性的。
因此我认为Web Apps或许可以考虑采用B/S架构与P2P架构相结合的方案来缓解服务器的压力。我认为Ｂ/Ｓ架构和Ｐ２Ｐ架构都各有优缺点，不能完全偏向某个架构。当同一时间使用人数少时，由于网络状况等各种原因，如果只采用Ｐ２Ｐ架构很可能给使用者的使用效率造成很大的影响，这时采用Ｂ/Ｓ架构既可以保证使用者的使用效果又不会给服务器带来太大的压力。而当同一时间使用人数多时，采用Ｐ２Ｐ架构可以有效减少服务器的压力，而且由于使用人数多，应该可以保证大部分使用者都能有一个较好的使用效果，并且可通过对使用者下载速度的检测对部分网络状况不佳的使用者自动切换为Ｂ/Ｓ架构。
并且借助Ｐ２Ｐ架构还可以继续拓展为一种分布式的储存方案，利用每个使用者作为一个储存节点，每个文件都有多个备份，这样也可以有效保证数据的安全性。不过要这个想法似乎就要在保护用户隐私上下很大工夫了，而且必须让用户自己决定是否作为一个向其它用户共享的储存节点。
而Web Apps的第二个开发要素就是用户使用的便捷性和使用速度。目前我在测试众多Web 2.0服务时都经常要面临一种很不愉快的体验，大部分Web 2.0服务都要求我注册一个帐户才允许我使用，而没有提供一个类似来宾帐户之类的试用帐户。
我认为这一点对于新推出的Web 2.0网站而言是很不利的。目前Web 2.0服务针对的用户大多对网络隐私极其看重，因此注册帐户意味着要向一个不知道是否可以信任的陌生网站提供隐私数据。我就经常因为顾虑这一点而放弃了测试许多我应用需求并不强烈的陌生Web 2.0服务。然而那些允许我进行匿名测试的Web 2.0服务我通常都很愿意花一点时间来仔细体验其提供的服务，这就是很大的差距。虽然我在测试过后未必会成为其用户，但至少我进行了测试，这是由测试者转变为使用者的必经过程。而许多Web 2.0服务因为不允许用户匿名测试而将许多用户拒之门外，这对其自身和用户而言无疑都是一种损失。
我上文提及我之所以不愿意注册帐户除了对泄漏隐私的顾虑外还有一个原因是注册帐户的过程十分繁琐。而Web Apps的使用者恰恰是追求使用简洁和速度的。我第一次使用Web Apps就是因为我要对某幅图片进行一点简单的处理，而我又不想为此去下载和安装一个可能只需要临时使用一次的庞大臃肿的工具。因此我就在Google中尝试搜索寻找是否有这样的在线应用，结果我很快找到了一个在线的编辑图像服务并迅速完成了我所需要的编辑工作。从此我就开始使用Web Apps来代替一些软件的应用。
因此某些Web Apps服务（比如Microsoft的Web Apps服务）喜欢用ActiveX控件来开发，我认为这是一种极其愚蠢的行为。先不说ActiveX控件只能用于IE平台，而且ActiveX控件的安装过程耗费的时间不亚于注册一个帐户所需的时间。而且经常会在此过程中由于各种原因造成安装失败（比如我从来没有成功安装过Microsoft的Web Apps......）。因此用以开发Web Apps的最佳平台我认为目前还是JavaScript语言，JavaScript不仅支持各个浏览器平台，而且无需安装即可使用。
由这个例子我们又可以发现Web Apps的一个特点。Web Apps通常在功能上都不如对应的计算机软件。这有一部分因素是由于技术所决定的，而另一部分因素则是由Web Apps的特点所决定的。然而为何Web Apps却能从这些软件用户中抢夺走了一些用户呢？除了我上文提及的便携性外还有一个原因，这个原因我在浅谈应用服务整合一文中已经简单地介绍过。并不是所有的用户都需要一个软件的全部功能，很多时候我只需要用到一个庞大的软件的一个小功能，这时候这个软件对我资源和磁盘空间的占用都是极大的浪费，因此我为了避免这种浪费就转而使用已经能够满足我的应用需求以及对资源和磁盘空间占用极少的Web Apps。
然而虽然Web Apps有资源和磁盘空间占用少的优势，但随着硬盘和内存容量的不断增加，事实上大部分用户对资源和磁盘空间占用相比起以前已不太在意。因此Web Apps要想将这部分用户巩固就必须做到达到和计算机软件相同的使用效率或更高的使用效率。由于服务器和客户端的网络带宽都有限，因此Web Apps必须牺牲一部分Web Apps所针对的用户不常用的占用带宽大的功能，以此来换取用户较好的使用效率及体验效果。而不是一味地追求功能的完善，Web Apps在现阶段功能永远不可能超过同类的计算机软件，而Web Apps又必须受到网络带宽的限制，如果不加节制地增加功能只会造成用户体验效果下降而丧失用户。因此Web Apps必须有一个正确的用户定位才能进一步地进行开发创新。
Web Apps的第三个开发要素就是开放API接口。提供足够的资料供第三方开发相应的支持应用。其实这一点不只是Web Apps需要注意的，开发计算机软件同样如此。我们可以发现，目前十分受用户欢迎的软件（如：foobar2000、Firefox等）大多都是开放API接口并且有十分多的插件拓展支持的软件。可以说正是有了这些插件和拓展才使这些软件成为一个成功的软件。而这些软件之所以能获得如此多的第三方开发应用支持，正是由于其开放的API接口使第三方开发者能很轻松地开发各种插件和拓展来加强和完善这一软件。
Web Apps上的典型示例莫过于Google Maps和Twitter了。相信现在大家都对各种Google Maps Mashup很熟悉了，而之所以会出现这么多的Google Maps Mashup全部得得益于Google开放了Google Maps的API接口。利用Google Maps API才能开发出众多有趣和实用的第三方Google Maps Mashup应用。事实上在这个过程中Google Maps也因为这些Google Maps Mashup而大大提高了知名度，对Google Maps本身的推广也是十分有利的，因此开发API接口可谓是服务提供商和第三方开发商的双赢的选择。
最后一个开发要素就是要注意Web Apps的离线化应用，但由于我之前以专门写过一篇文章来阐述这一开发要素，这里就不再赘述。愿意详细了解探讨的读者请参看从Google Gears看Web Apps的离线化应用。
版权声明：本作品作者为IwfWcf，首发于IwfWcf's Blog，转载请遵循知识共享署名-非商业性使用-相同方式共享 3.0 许可协议并以超链接形式注明出处。
没有评论:
发表评论