BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Gmail,累觉不爱

| 作者 张天雷 关注 4 他的粉丝 发布于 2015年12月2日. 估计阅读时间: 8 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

近日,FreshInbox的邮件开发人员Justin Khoo发表文章表达了对Gmail的不满,指出Gmail从多个方面破坏了邮件本身。文章一经发表便引起了网友的热烈讨论。

在文章开篇,Justin就指出,谷歌在两年前就宣布要利用Scheme.org来丰富邮件内容。由于Schema.org允许发件人在邮件中嵌入丰富的元数据,而任何邮件客户端都可以根据结构化的数据展示邮件内容,很多开发人员都认为Gmail将会和Schema.org合作,引领邮件的革命性创新。例如,收件人可以在不打开邮件内容的情况下,直接通过邮件主题对产品/服务排名或者实时更新航班的预约信息。

然而,根据Gmail support forum的消息,Schema.org完全没有这样的计划。而且,原来计划研发的Grid View也在今年莫名的取消了。尽管Gmail API似乎更吸引眼球,它所吸引的也不过是试图将App与Gmail整合在一起的开发人员,而不是设计、自动化和发送邮件的开发人员。是开发人员对邮件创新不感兴趣呢?还是他们只是不看好Gmail所描绘的前景呢?

重要通知:接下来InfoQ将会选择性地将部分优秀内容首发在微信公众号中,欢迎关注InfoQ微信公众号第一时间阅读精品内容。

Gmail使得开发人员不敢接触Email

Gmail和其一大堆的渲染问题是很多开发人员不敢在邮件上开发的主要原因。开发人员期待良好定义和丰富文档的环境,而邮件就是一堆乱七八糟的东西。尽管很多邮件客户端都会遇到渲染问题,在Gmail的电脑版和移动设备版中显示邮件才是让开发人员最头疼的地方。

Justin表示,他不认为Gmail故意造成了这样的情况。他更倾向于,Gmail团队是太热衷于创新,以至于无意间破坏了邮件本身。因此,如果想要更多的开发人员接受Schema.org或者Gmail API,Gmail首要需要解决的问题就是修复已经破坏的功能和影响。

Gmail是如何破坏邮件本身的呢?

Gmail是唯一不支持<style>的邮件客户端。很多刚开始接触邮件的开发人员都非常吃惊,他们竟然不能使用网页开发技术来设计邮件的样式。只有对于Gmail,每一个CSS样式需要内嵌在邮件内。手动把CSS样式代码嵌入到邮件中非常耗时,而使用第三方的小工具又会在开发工作流中加入一个非常没有必要的步骤。此外,它还会显著增加邮件的大小。Justin表示,对于谷歌这样如此注重效率的公司,这种情况不会让其觉得尴尬吗?

Gmail应用是原生安卓应用的后退。

安卓手机本身一般都会预装邮件客户端应用。针对移动设备,开发人员都会在应用中加入媒体查询(media query)来获得设备的屏幕尺寸,从而调用相应的移动响应式代码,很好的完成邮件在移动屏幕中的渲染工作。然而,Gmail应用不支持查询操作,使得最新版安卓(Lollipop)内置的邮件客户端无法支持Gmail

多个会议以及Gmail团队召开的Reddit问答环节中,开发人员都对该情况提出了不满。但是,目前仍然没有任何的Gmail移动客户端支持媒体查询。

每一种Gmail客户端渲染邮件的方式不同!

Justin指出,用户或许没有注意到,每一种Gmail客户端都拥有自己的一些不足之处。因此,在利用这些客户端创建邮件时也各有不同:

  • Gmail.com Webmail。支持<style>,但不支持idclass。
  • Gmail Webmail for Businuss。不支持<style>
  • Gmail App for iOS。不支持<style>,而且字体会随机增大50%
  • Gmail App for Android。不支持<style>,而且随机性忽略容器宽度。
  • Gmail App for Android(针对非Gmail.com地址)。不支持<style>、随机性忽略容器宽度以及不支持背景图像
  • Inbox by Gmail for Android。不支持<style>、以一种与Gmail App for Android不同的方式随机性忽略容器宽度。
  • Inbox by Gmail for iOS。不支持<style>,但是似乎存在的问题比其他客户端要少。

更严重的是,频繁渲染Gmail还会引起不可预知的渲染变化!Justin表示,在这样的情况下,还有哪个开发人员愿意花时间对Gmail邮件进行改进!

帮人帮己

Justin认为,尽管Gmail的表现如此糟糕,很多开发人员仍然对邮件充满了热情。他们依然期待着Gmail的Schema.org的改进能够成功,而且应用到其他邮件客户端中。Justin呼唤更多的开发人员能够投入到这样的行列中。同时,Justin在文章中给出了Gmail改善自身影响的若干建议:

  1. Gmail需要在网页邮件中支持classid,在移动应用中支持媒体查询。

  2. Gmail需要透露更多有关邮件渲染的技术细节。
  3. Gmail需要统一所有的客户端,令其给出同样的渲染效果。而且,Gmail团队最好给相关开发人员一个反馈问题的渠道。
  4. 谷歌应该联合雅虎、微软和AOL等创建一个支持CSS和HTML的统一标准

推动邮件向前发展

尽管文章指出了很多Gmail令人不满意的地方,Justin在文章最后还是对Gmail提出了希望。Justin表示,广大的邮件设计人员和开发人员并不要求Gmail一定要十全十美。就像iOS版本的邮件客户端一样,只要它能够满足最紧迫的需求(例如,支持CSS),大家仍然能够忍受,并乐于进行相应开发。Justin希望,Gmail也能够拿出这样的心态,与开发人员进行合作共赢。

Justin的文章一经发表便引起了广泛讨论。很多网友纷纷表示认同,表示Gmail存在不支持子字符串搜索、转发消息格式混乱以及隐藏邮件时间等问题。针对这些问题,有网友分析其根源可能在于公司理念的问题——管理层以及员工认为,只有重新编写软件才能创造更高的价值、享受更好的收入。因此,相关团队宁可重新编写,也不愿意维护/改善现有的软件。此外,有网友认为Gmail没有采用Schema.org的原因主要在于后者本身并没有发展成为标准,而力挺Gmail团队现在的做法。


感谢杜小芳对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群InfoQ好读者(已满),InfoQ读者交流群(#2)InfoQ好读者)。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT