今天看到这样一个议题，觉得非常不错，有兴趣的朋友可以看看，并且留下自己的论点，我个人也同意线上软件将会逐步代替桌面软件的这种看法。只是这个过程还是需要慢慢来的。。但在这个转变过程中肯定是会出现多种多样的创意滴。。 原文来自 apple4us.
前两天，Apple4.us 的内部讨论组里发生了一次关于桌面软件（native app）和线上软件（web app）区别的讨论。这是一个老话题，但其中貌似有很多较难理性解释的因素。很多资深的苹果玩家都坚定地支持桌面软件，至今在用 Mail 处理 Gmail 和 Google Apps 的邮件，但另一方面，技术实力无比雄厚的 Google 一直在猛力推进各种万维网技术（HTML5, JavaScript……）。过去几年里，网页版 Gmail 和 Google Docs 在用户体验上已经日益接近桌面软件。
无论是单纯的好奇，还是出于「力挺线上软件」的使命感，我们都需要知道两者的区别究竟何在。在以下的讨论中，我们试图用文字描述某种很少被言说的感受，愿能起到抛砖引玉之效。—— 编者
Junyu: 大家觉得桌面软件和线上软件在用户体验上的区别在哪？
Lawrence: 主要是快捷键，线上软件不能用 Alt + Tab 切换，用网页版 Gmail 添加附件无法像 Mail 那样 Command + C / Command + V 拷贝。
不过对于不太用快捷键的人来说，体验差别应该不是很大。
其他都是个别因素，不具有普遍意义。比如用 Google Docs 写稿，如果网络状况不佳，可能会导致反复存盘失败，本地文字编辑器当然没有这个问题。
Rio: 我觉得主要是线上软件之间、线上软件和桌面软件之间不能互动吧。比如我可以在 iPhoto 里面拽几张照片到 Mail 里然后发送，Gmail 就做不到。虽然我认为 Gmail 网页版的邮件介面比 Mail 好不知道多少倍，但因为这些问题，我还是在使用 Mail。说白了，就是进程间通信。这篇文章讲得很详细了。
另外，没有网络或网络状态不好的时候，线上软件的稳定性暂时还无法和桌面软件相比。Lawrence 说的那个其实都还好解决，毕竟数据量少，HTML5 本地存储（Local Storage）就搞定了。但是你很难想象把整个 Gmail 都通过浏览器拖到本地——它太大了。而且就算全部存了下来，JavaScript 的执行效率还是没法和本地代码相提并论。用 Google Gears 实现的离线 Gmail 到现在都很不好用，因为有些重要的功能必须要在服务器端实现，比如搜索。
上面两点都是技术上的问题，并非不能解决，只是需要较长时间。我觉得线上软件和桌面软件还有个不易解决的重要区别：信任。我信任 Google，所以重要的邮件、甚至密码我都敢放在 Google 的服务里面（比如 Gmail），我也相信，即使 Gmail 某一天突然无法继续使用了，Google 也一定会在事前给我足够的时间和方法备份好自己的数据。但是随便一个第三方的线上软件我可能就会很小心了，因为它随时可以不见掉，我的数据存在都不能保证，更不用说什么隐私之类的问题了。桌面软件在这个问题上就相对好很多：比如通过开源解决安全问题（确保没有后门之类）。而且一个桌面软件下载安装好后，只要我能确保我有安装文件和安装需要的环境（实在不行可以通过虚拟机解决），我就不需要担心这个软件哪天会突然消失。软件公司可能会随时倒掉，我可能不会获得继续的技术支持，但好歹已有的数据不会丢、还能用。
哦，对了，如果在国内，还要随时担心用的线上软件会不会被墙掉、白名单之类的。自有 VPN 当然没问题，但是如果这个线上软件不是你自己一个人用，而是需要和很多人合作的话，还是很痛苦的。比如想象一下 Dropbox 被墙掉，我就得给爸妈、女友全部配上 VPN 才能共享文件。
Junyu: 仅就拖拽发送而言，目前安装了 Google Gears 后浏览器是可以实现的。
我就真的把十几个 GB 的 Gmail 给搞下来了。当然，同步的内容没有那么多，数据库大概在 3 GB 左右，性能还不错。
至于如果说 Gmail 和客户端邮件程序比——例如说 Outlook 或者 Mail——对于我这样的用户来说，肯定是前者完胜。我 13 GB 的容量，Outlook 收到 2 GB 左右就彻底死了，Mail 大概收了 5 GB 也收不下来了。
另外，也有用户认为线上软件经常会无缘无故发生一些变化，不像客户端，升级与否由自己掌控。
Lawrence：我觉得技术上的壁垒是次要的，更重要的是心理认知上的壁垒。对于用户来说，「真正的软件」就是那种自己单独一个窗口（而不是一个标签页）、单独一个图标（而不是诸多 Firefox 图标中的一个）的东西。这是肇始于 1984 年的麦金塔 GUI 多年以来为大家种下的观念。
如果 iPad 真的翻新了人和电脑交互的方式，再等到 Rio 说的技术问题都不是问题的时候，或许线上软件的景况会不一样。
Junyu: 我非常同意这一点——我想知道的恰恰就是，诸如「单独一个窗口」、「单独一个图标」这种对「真正的软件」的认知还有哪些。例如，「介面文字不可选择」就是之前一次研究中用户提到的一点。
Willow: 我刚想说：如果一个按钮上的字可以被高亮选择，我会觉得那只是后面加了图的文字，而不是一个控件。
Rio: 关于 HTML5 本地存储，我之前试用的结果是，基本每次都不能完全同步成功。数据也不算特别多，2.5 GB 的样子。倒是 Mail 完全拖下来了。看来等 Gears 支持 10.6 之后要重新试试了。
上个星期无聊做了个 JavaScript 的数独游戏，一直在 Chrome 里面调试,还没觉得有啥问题。后来在 Firefox 和 IE8 里试用才感觉到 V8 引擎的强大：什么优化也没做的情况下，IE8 里面跑感觉明显比 Chrome 慢很多。Firefox 也比 Chrome 慢一些，但不是很明显。（注：为了优化 IE8 的速度，代码已经改过了，现在速度差别没那么明显。顺带一提，IE8 的开发者工具还挺好使的。）Computer Language Benchmark 的结果显示几项测试中 V8 甚至比 Python 还要快 10 倍左右。我一直觉得大部分应用能跑到 Python/Ruby 那个程度就差不多了，V8 的确很猛。Node.js 用 V8 来跑，如果库的支持再多一点，可能很多服务器端的应用会从 Python/Ruby 手中抢过不少份额，毕竟服务端和客户端共用一套代码这个诱惑对于服务端处理前端页面的部分实在太大了。
回应 Lawrence，Chrome 在 Windows 上已经可以把一个线上软件变成一个看起来是普通程序的样子了，有单独的图标在桌面上、打开也是单独的窗口，没有标签页的。但还是感觉和桌面软件不同。比如，记得去年上课的时候老师讲过，响应速度对于用户感知的影响是非常大的，虽然很难描述。大概意思就是，一个用户操作，500 毫秒的相应时间和 250 毫秒的相应时间，在开发者看起来其实差别不大，要让用户来描述两个的具体差别也很难说清楚，但潜意识中这样的差距就会慢慢累积起来，成为影响用户体验的重要原因。
iPad 是个机会：全新的交互方式，用户没有那么多思维定势，如果好好做，线上软件可能会变得更加易用一些。这个说起来容易做起来难：因为桌面软件，特别是 Mac/iPhone/iPad 系列的，由于有用户介面规约（Human Interface Guidelines）的指导和整个环境的熏陶，基本能形成一套共通的模式（比如用手拖动滑动条这样的设计在很多应用中都很常见，用户边际学习成本很低）。而线上软件受限制于相对涣散的开发和运行环境，比较难有共识：基本上每个线上软件公司都有自己的一套页面元素的「样式」或者说「语言」，Google 旗下 Gmail/Docs 是一系列样子，Yahoo! 是另外一套样子，Facebook 又不一样，更不用说不计其数的其他线上软件开发商了。用户每次在不同的线上软件间切换的时候潜意识里其实都在习惯不同的视觉元素语言。出于猎奇的目的，这样当然是好的，可以看到各式各样的风格。但这样的线上软件要去模拟桌面软件，没有统一的视觉语言是很糟糕的一件事情。也许像 Cappuccino 这样的框架可以解决这个问题，起码对于苹果用户而言能够尽量做到线上软件的外观接近桌面软件了。
Lawrence: 关于 Prism 这类的尝试还有一点：就算有了不同的图标和单独的窗口，边框（chrome）还是千篇一律，感觉上无论如何更像是同一个软件的不同窗口，而非多个不同的软件。
Rio: 它本质上就是这个，有啥办法。Mac 上的 Fluid 可能还稍微好点，比如 Gmail 还能有个 Dock 上的徽标提示新邮件数量。另外貌似也可以通过 JavaScript 定制样式，不过限于页面内……
FROM： http://apple4.us/2010/04/webapp-vs-nativeapp.html
我们首先介绍的实例产品OpenCalais可能是我们目前找得出的关联数据有关的最佳示例（link）。国际商业与金融新闻巨头——汤森路透公司（Thomson Reuters）在08年2月的时候推出了一个名叫OpenCalais的API（link）。简单说来，OpenCalais将非结构化的HTML转换成语义上经过标记了的数据。它会将数据按照“人”，“地点”，“公司“等类别进行整理。这样，第三方应用程序和站点就能在这些数据的基础上制作出一些有意思的新东西来。
