与 Google 畅谈 Chrome 操作系统, HTML 5 以及 Web 的未来(下)
作者: its
|
发布: 2010/1/23 (9:45)
|
阅读: 60750
|
评论: 0
|
静态地址
|
内容源码
这是 Ars Technica 的记者 Jon Stokes 与 Ryan Paul 对 Google Chrome 操作系统的项目工程师 Matthew Papakipos, 公共关系部的 Eitan Bencuya 做的一次访谈,谈到了 Google Chrome 操作系统的孕育,现状与技术,谈到了 HTML 5 以及未来的 Web。这是第二部分,第一部分请参阅与 Google 畅谈 Chrome 操作系统, HTML 5 以及 Web 的未来(上)。
Web 应用 vs 文档,以及 Web 的天性
JS:
Web 存在这样两种模式,一种是文档,一种是应用,Google Maps 是应用,Ars Technica 是文档,但你们将文档和应用同时放到一个浏览器窗口中。
我知道你们仍在改进用户体验,我想知道的是,你们会停留在文档模式,还是向应用模式转换,这样,你们的应用将拥有类似 OS X 般的窗口,而不是现在网页的模样。
MP:
你的问题很到位,现在的 Web 人有些古怪,它们中的大多数还是静态的内容,看上去更像文档,甚至CNN,The New York Times, Wall Street Journal 这样的站点仍是一些静态网页,虽然他们的内容是动态输出的,还包含广告,这本质上,是你从页面上阅读,而不像 Gmail, Picasa, Netflix 一类的站点,它们更像应用,你可以把一些东西拖来拖去,改变次序。
目前,在Chrome中,我们没有对二者作出太多区分,因为Web也不是按二者严格区分的,但我们开始在 Chrome OS 中做很多事,增加一些特殊功能,这些功能是真正的应用。比如,Chrome OS 中的 mailto 链接,通常,这类链接是打开浏览器外部的一个 Windows 邮件程序,但如果你使用 Gmail 这就罗嗦了。所以,我们在研究,如何能从当前的 Tab 直接跳到运行 Gmail 的 Tab 或窗口,或者,直接弹出一个写字板,这样,你就不会打断当前你正在浏览的东西。
所以,我们开始在这方面做研究,如何将不同的链接方式定位到不同的 Web 引用上。比如,如果我有一个 Web 版的 JPEG 图片查看器,如果有人在 Chrome 或 Chrome OS 设备中想打开一个JPEG 图片该怎么让它们关联起来?
还有一个例子,.doc 文件。如果我点击了一个 doc 文件,我是想在 Office Live 中打开,还是希望用 Gview 查看,抑或是把它存储到 U 盘?用户该如何告诉 Chrome 他想怎么处理?
JS:
这似乎是 Windows 早期遇到过的问题,诸如 OLE,注册表之类,然而在 Web 上,这将是同样重要的问题,只不过环境不同。
MP:
我希望用一种简单但灵活的方式解决这些问题,在 Windows 中,那是非常复杂的,不同的程序都想争夺某些文档的处理权,Quicktime 和 Windows Media Player 争斗,后者又同 Chrome 争斗,对用户来说,这很难处理,而现在的 Web 已经开始具备这种能力,你可以注册文件格式,我们在这方面是领先的。
你另一个问题是,我们是否将让这些应用看上去像 Tab 还是别的?目前,我们只是想让他们像 Tab 以及一些看上去不太一样的窗口,让它们全像 tab 似乎更好。
我一天当中绝大多数时间是活在浏览器中,每次当我不得不运行一些浏览器之外的应用时,都感到麻烦,所以我们希望让它们都保留在 Tab 中。但这都属于 UI 的层面,以后还会改变,我们面向消费的发布还在一年以后,很多东西都会改变,但那是我们目前的想法。
JS:
Mailplane 在我们 Ars Technicia 非常受欢迎,你用过吗,或看到过别人在用吗?
MP:
没有。
JS:
那时一个对 Gmail 的包装应用,包含一些 mail 相关的饰件。
MP:
在 Chrome 中有类似的东西,让 Gmail 使用特别的界面运行,在你的桌面上安装一个 Gmail 图标,就像传统桌面程序那样。
EB:
任何网站都能使用传统桌面图标打开。
MP:
Google Gears 能让你为一些应用创建桌面图标并让 Web 程序看上去像桌面程序。
EB:
它是内置在 Chrome 中的,现在你可以直接用这些快捷方式打开 Gmail 或任何站点。
MP:
...不使用那些 Tab 或按钮...
JS:
对,有一个 Fluid 程序,可以将给定的 URL 转换为一个桌面程序,你见过没有?
MP:
是,这就是他所描述的 Chrome 中已经拥有的一些东西,我想这些东西在传统操作系统中更适合。
JS:
我想我这样说的意思是,我们已经有一些方法,让 Web 应用更像应用,这样,从用户体验的角度,他们在界面上和普通的应用一致,而不是硬塞进一个 Web 文档,对我来说,这是好事,好过将所有东西都塞进浏览器窗口。
但这是一个很大的哲学话题。
MP:
我想我们在 Chrome OS 中有办法把这两种概念融在一起。现在我们感觉有点古怪,因为我们这些浏览 Tab 是由浏览器管理的,而我们的操作系统管理不同的应用。在 Chrome OS 中,所有东西都是 Tab,我们可以让窗口管理器管理这些 Tab。
所以,从某种方式,事情应该变得更清楚,用户模式也变得更清楚。因为不再有两种不同的应用(桌面应用和 Web 应用 - 译者注),只有一种应用,如何展示这些将因时而异,要看哪种对用户更适合。
目前,我们在 Chrome OS 中有两种方法来处理,一种是,应用和页面作为 Tab,另一种是使用预览模式,可以看到多个 Chrome 窗口,你可以在不同窗口间挪动 Tab 和应用。
但我们正在研究,是否将这些东西称作 Web 应用,它们是否可以拥有更广的能力,比如处理文件类型和 mailto 链接。
程序细节
RP:
从程序员的角度,我关心这样几件事,特别是,是否有办法使用诸如 NACL 的东西编写本地代码,实现浏览器和应用之间的接口?Google 是否考虑将 NACL 一类的东西纳入 Chrome OS?
MP:
是,确切无疑,我们计划这样做。
RP:
是否已经有了一些原型?
MP:
Chrome 本身就是。你现在使用某些特殊参数运行 Chrome,可以调用一些实验性的本地客户内容。
不过在具体发布之前,这些还会有变动,在稳定发布版的 Chrome 中还没有,还存在一些安全问题,在解决这些问题之前,我们还不想默认打开这些功能。但这些都确切无疑在进展中,还且肯定会包含在 Chrome OS 中。
RP:
是否有计划将硬件访问通过 JavaScript 暴露给诸如 NACL 一类的东西。
MP:
你说的硬件访问是什么意思?
RP:
比如,如果有人想访问摄像头或 GPS,我知道现在已经有一些像 geolocation 之类的 API,但其它那些还没有被 Web 标准所支持的外设呢?
MP:
这个问题很好。我们正寻求将那些设备加入到 HTML5 API 中,以便可以通过 JavaScript 访问,或者通过 C++ 在本地客户中访问。
你是对的,我们仍有大量的工作要做,如果让我把那些设备清单列出来,那我们现在需要做的有声音设备,摄像头,麦克风,线路输入等,另外,我们还没有像杜比5.1声道那样的东西,P2P网络,甚至连客户端-服务器这样的 API 都少得可怜,这些东西,我们都在做。
这是很庞大的工作量,让 JavaScript 和本地客户访问这些 API 还有待时日,但我们尽可能加快速度。
RP:
那你们是否有计划在 Chrome OS 中加入 Dalvik 运行时,这样人们可以运行 Android 程序?
MP:
还没有。我们主要将精力放在 Web 应用层面。不过,我们的本地客户是一个很好的东西,我个人为之振奋,但我们对用户的期待也要抱务实态度,那还有待时日。
JavaScript API 也是一样,我们希望有 JavaScript API 可以访问摄像头或麦克风,但必须考虑安全问题,用户是否接受?如何防止某些网页 Tab 在你穿着泳衣的时候通过摄像头偷窥你?这些问题很棘手。
EB:
当然,我们将以一种开放的方式来做,但这需要时间。HTML5 也需要时间。
Web 应用的优先级和权限
RP:
我还想问,有没有办法让某些 Web 应用获得高优先级?
MP:
这颇不容易。现在的操作系统是这样做的,有明确的 ECLs 和权限分配,我们从传统操作系统中学到的教训是,用户很难对它们进行管理。
如果和 Web 模式比较,Web 的观念是,你不应该在 Web 应用中做任何不好的事,这个观念让 Web 运行得很不错,你浏览 Web 的时候,一般不需要担心会出现不良的东西(译者注:作者这里是从应用的角度讲),尽管有浏览器漏洞和恶意软件,但总体是不用太担心的。
我们尽量避免传统操作系统中的 ECL 及许可列表的问题,所以我们很谨慎,但我们确实在努力实现。geolocation UI 是我们目前做过的最难的东西,这个 UI 很棘手,需要非常谨慎,因为你不能泄露用户的地理位置,虽然你可以让用户选择是否向网站暴露自己的地理位置,但必须做得让人愉快一些。
现在的一些手机,如果你访问一些使用了 HTML5 Geolocation API 的站点,会不断弹出窗口,问你是否愿意提交自己的地理位置,这很烦人,有时候,人们习惯了一率点是,这回很危险。我们必须研究出怎么做,要做得简单,不那么烦人,但目前还没有答案。
一般来说,浏览器处理这种事情是通过信息条或对话框,但我们更趋向于使用信息条,因为对话框会锁住浏览器,直到你作出反应,这会降低用户体验。因此,很多浏览器,包括 Firefox 趋向于使用信息条显示提示消息,你可以做出反应,也可以不理会继续浏览。
比如,Chrome 在提示你记住用户名和密码的时候,会将消息显示在消息条上,我们在许可配置这些 UI 问题上,趋向于这种模式。
对 Chrome OS UI 进行扩展
RP:
在对 UI 和 操作系统进行扩展方面,似乎 Chrome 扩展是主要的方式,是吗?
MP:
对 Chrome 浏览器来说,是这样。
RP:
对 Chrome OS 来说,是否有计划增加其它扩展方式?比如,针对不同平台定制功能?
MP:
我们还没想到,不过这是个有趣的想法,你是否有具体的想法?
RP:
我不知道,我只是在想菜单问题,在宽屏幕上网本上,增加侧边栏,虽然在常规的浏览器上,这没什么用,但在一个以浏览器为主题的操作系统中,这或许有用。
MP:
这个想法很好,确实,当我们浏览网站的时候,屏幕两边都有很多空白空间,我们可以在这些地方放置侧边栏,我们已经在 Chrome OS 中考虑侧边栏 UI 问题,做一些试验,侧边栏放在什么位置,我们不断调整,我们有200 多 Google 试验者每周都使用 Chrome OS设备,我们经常在里面加一些新东西,看看他们是否经常使用,通过这些试验,我们不断迭代。
本地应用 vs Web 应用问题
MP:
Ryan,我想听听你对 Chrome OS 的看法,是否有一些东西在你看来是古怪的?
RP:
我抱一种走着瞧的态度,我觉得有很多变数,主要的问题我觉得是,相对于那些基于常规操作系统的 Chrome 浏览器而言,Chrome OS 能给用户带来什么价值?
在将所有东西都纳入浏览器这件事上我仍然有点疑虑,我们看看现在的一些 Web 应用,他们相反正将在提供一些桌面版,如 Twitter。
我在想,如何只靠浏览器实现全部这些需求。
MP:
嗯,是,如果有一些东西浏览器不能实现,我们会对浏览器进行扩展。
JS:
那就是前面谈论我们谈论的 Fluid 和 Mailplane 应用。
MP:
我仍然认为,我们应当看着这些应用,并想到,为什么它们必须是本地程序,我们可以增加一些功能来实现。一个很好的例子是,很多本地程序可以在后台运行,于是人们希望在 Web 程序中实现后台进程,比如,在 HTML5 中实现后台上传文件,这样就不必浪费一个 Tab 并让浏览器开着。
EB:
还有提示消息,在 Twitter 的桌面程序中,每当你收到一个新 Tweet,就会给你一个提示消息,在浏览器中,也有 notifications API 实现类似的功能。
MP:
我们还在研究上传问题,因为上传是很常用的用例,当我向 Picasa 上传照片的时候,我们必须开着一个 Tab 或者安装一些复制程序,我们需要研究出一些方法让这些功能内置在 Web 中。
内置的媒体播放器
MP:
还有媒体播放器问题。我们将一个完整的媒体播放器集成到 Chrome 浏览器和 Chrome OS 中,人们常常为此困惑,这很微妙,但非常重要,因为从某种意义上说,我们是在将一个相当于 Windows 媒体播放器的东西集成到 Chrome 中。
在普通电脑中,我们需要一定的方法来离线播放 JPEG, MP3 和 PDF 文件,比如,如果你有一个 U盘,上面有 MP3 文件,你可以插上去,听那些音乐,并没有对应的网页来控制这些,我们做了很多工作,在 Chrome 和 Chrome OS 中处理这些用例。
RP:
你们的方法是标准的,基于 HTML5 的视频和音频吗?
MP:
是的,绝对的。
RP:
你们会让 Video 标签支持更多编码吗?
MP:
我们并不是单单增加一些编码那么简单,而是为整个 video/audio 标签提供方案,因为 video/audio 标签的设计是针对网页的,比如像播放网页上的某个媒体,但如果你有一张 U盘,想播放上面的 MP3 文件怎么办?你如果浏览到那些文件并对它们进行播放。
再比如,如果在 Gmail 中收到邮件,上面有 MP3 文件,你不应当退出 Gmail 在外面播放那个文件,我们希望直接在 Chrome 里面播放,而且整个过程要十分清晰。
这就是我们在 UI 层面的重要事情,将整个媒体播放器集框架集成到浏览器,这并不稀奇,因为别的浏览器也在这样做过,但 Chrome 之前没有。
本文国际来源:http://arstechnica.com/business/news/2010/01/chrome-os-interview-1.ars/ 中文翻译来源:COMSHARP CMS 网站内容管理系统官方站
|