How to build a better bot - 推酷
How to build a better bot
The bots have landed. And as is usually the case, some early products shipped that could have
. Personally, I’ve yet to use a bot that’s really impressed me.
But we’ve all seen this movie before. Bumpy starts and rough edges in early days are to be expected. Fortunately, there’s a time-tested, proven way to get it right.
Keep building better products.
So let’s talk about what building a great bot actually means.
What have we learned about building humane software in the last decade, and how can we apply those learnings?
As you may know, I’m building a bot company called
. It’s insanely fun, but the challenges are many. We’re building lots of new technology to do stuff we used to get for free.
Every new human computer interface paradigm faces significant early headwinds. But there’s at least one reason why bots have been around for decades in various incarnations, yet never really gone mainstream as consumer products.
It’s hard to build software that talks to humans the way humans talk to humans.
Like, really hard.
Designing rich, complex conversational interactions presents an entirely new set of challenges. The tools definitely aren’t fully baked yet, and the few primitives we have are still more academic than battle-hardened.
What’s worse, when bot interactions go awry, they can be frustrating in a way that app errors just aren’t. There’s something deeply, irrationally frustrating about not being understood by a piece of technology whose first and most important job is to parse what you’re saying. It’s enough to make some people want to throw their devices across the room.
That potential for frustration is relatively new, and not to be underestimated.
But here’s the good news: all of the fundamental lessons you’ve learned about good product design? They still apply. Every last one of them.
Clarity, brevity, direction, momentum, decision guidance, usefulness, attention to detail, doing fewer things better, and above all else, empathy: these are still the key ingredients to crafting great bot experiences.
The patterns and best practices we’re already used to employing -- from wireframing interactions, to prototyping, to iterating obsessively, to getting your product in front of users to see how it breaks -- are every bit as relevant in bot creation.¹
In fact, if one pays close attention to their first principles, they’ll undoubtedly discover that designing conversational interactions is remarkably similar to that of designing graphically driven interactions. (I also happen to have written an
, which I humbly suggest reading if you’re thinking about building bots.)
Bots may be new(ish), but humans, and the cultural contexts they bring to the table, the metaphors they understand, and the way they interact with machines, haven’t changed a lick.
The tools may change, the details of implementation may be new, and now you may find yourself in need of a good copywriter. But if you care about making a great experience for your users and consider yourself a student of the craft, you’ve already got the fundamentals you need.²
“Bots”&!= “Conversational”, “AI”
Without getting into the wheel-spinning of over-defining an early space (I’ll leave that to others), let’s embrace the idea that not all bots are conversational, strictly speaking. Let me explain.
Most bots will be available in mediums where humans communicate with each other, yes. And most of those contexts will be conversational -- which is another way of saying they’ll be messaging apps.
Here’s a bot that really just does not want to talk to you.
But that doesn’t mean your bot has to actually hold a conversation. CNN’s Facebook bot is a great early example of this. Here’s a bot that really just does not want to talk to you.
What it does want to do, however, is tell about the news. And you know what? That’s great. Not only is this a completely valid direction, it’s a highly effective use of a bot as a means of clutter-cutting. The CNN bot knows what its job is: making timely, curated information available in a way that fits into an intimate, realtime context.
In my last post about bots I talked about
, and CNN’s bot is an early standout in large part because it does such a good job at maintaining alignment.
Not unlike the old trope that a product should always do less than the people who make it think it should, the same is true for bots. It’s okay for your bot to do less, and it’s definitely ok for your bot to be dumb. And the less a bot actually does, the dumber it should probably act.
Which is to say, you should never let your bot’s witty repartee write a check that your software’s abilities can’t cash in full.
Anyone making a bot will find the right balance for their product, but what’s important is for anyone building bots to be intellectually honest with themselves up front, because ultimately that intellectual honesty will be reflected in how smooth (or not) it is for people to interact with their bots.
A trip to the Robot Store
One metaphor I’ve been known to trot out with the Beginners is taking a trip to the Robot Store . Imagine there’s a bright, shiny, beautiful, store with shelves lined with hundreds of different robots, designed and lovingly built by dozens of companies from all over the world.
You’ve got all kinds of choices: a kitchen-cleaning robot that does the dishes, a weather robot that monitors local weather patterns and tells you what to expect, a travel robot that drives your car, or helps you book travel plans. Go ahead and pick out a robot to bring home with you.
Once you get it home, how would you want and expect that bot talk and interact with you in your personal space? Is it appropriate for this robot to speak, even if not spoken to? Is it ok for it to activate and start roaming around the house without your permission? When engaged, should the robot chatter incessantly, or should it be terse?
The answer to these questions may vary, but inviting a software helper into your messaging chat app isn’t really any different from a physical helper into your personal space. The rules are the same.
To make a great bot, we have to start by stripping away the artifice and focusing on doing something really well -- no more and no less.
What makes a good bot good?
Software, as most folks know it today, operates at human scale. Input and output are more or less paired and synchronous, and the value you get out of your software is roughly equivalent to the effort you put into learning it and using it.
But part of what makes a bot a bot is that it is (or can be) autonomous, which means it can augment human behavior on a potentially exponential scale. And as a function of messaging interfaces’ severely constrained context, bots have no choice but to present lightweight, high-impact output.
This is why the best bots will be value-adders.
Being a value-adder means taking a minimal amount of input or direction, and adding unique value to it beyond the basic functions of computers (i.e. storage, retrieval, processing, transit, etc.).
A good bot will store and retrieve information in a timely, frictionless way, like any other software. A great bot will help relieve some kind of stress, or save a meaningful amount of time for a human.
Which is also to say that if you’re building a bot that some may say would work better as an app, they may be right. I’m of the opinion that apps aren’t going anywhere (nor the web).
But unlike apps, the potential value a good bot can deliver its users will be far greater than the amount of work that goes into initiating it or sending that bot on its way.
A worthy bot will also anticipate the needs of its user, and try to meet them with minimal friction. A network of bots tied to your identity should behave like an high functioning team of support staff working tirelessly behind the scenes to make your life easier in any way possible.
Are we there yet?
Bots have been around along time, and sometimes I get asked: why now? What’s changed? (As you might expect, this came up a lot while fundraising.)
The next great technology is always built on the matured, commoditized technologies that preceded it. Bots are no different.
Every building block required to make a great bot piggybacks on important, recent trends: advancements in machine learning and natural fast, scal a huge ecosystem of API and robust adoption of presence, messaging, and the notification layer.
The good news is whether you’re bot-curious or actually out there building a bot of your own, the raw materials are finally here.
That doesn’t mean it’ll be easy or fast to make something great, but nothing worth making ever is.
Bots are super hard to build. But that’s no excuse for a frustrating user experience.
All the lessons we learned about creating humane software over the last ten years still applies to building bots.
... especially that old chestnut about doing fewer things better. Bots need to walk before they run.
Conversation is not a necessary feature of bots. Minimize artifice, focus on adding value.
The autonomous augmentation of human behavior, and the ability to relieve pain points or save time is where bots will be truly differentiated.
This whole bot thing is happening now because the right technological ingredients are finally in place. But that doesn’t mean it must happen. Anyone making bots is going to have to get out there and earn it.
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致114网址导航热门推荐：
　　本文作者是微信产品经理Dan Grover，美国人，一个对这个世界充满好奇心的人。2014年，他写了《中国移动应用设计趋势解读》一文，以一个外国人的角度记录了中国移动应用设计中铺天盖地的二维码、小红点……并和美国的移动应用进行了比较。文章全面、细致，在中文和英文互联网世界都引发了巨大的反响。PingWest品玩曾对Dan Grover做过一个访谈。
　　最近，Dan又写了一篇长博文：Bots won’t replace apps. Better apps will replace apps，说了自己对最近在Facebook、微软大热的聊天机器人（Chatbot，简称Bot）的理解。他的洞察力让人惊叹，希望这篇文章能为产品经理细致观察和准确描述的典范。
　　在Dan看来，Facebook、微软关于Bot的看法大错特错，他们对Bot的理解还停留在让后者更像人的“拟物化”阶段，但实际上，饥肠辘辘的我们对“定个披萨要按键73次”是深恶痛绝的，Bot花了太多精力在无用的“寒暄暖场”上。在这一点上，微信公众号比Bot做得好太多了。
　　Dan觉得，现在的app包括手机操作系统需要改进的地方太多了，改进之后的他们才会替代现在的app，而不是聊天机器人。
　　以下是全文翻译，开头至“聊天气泡简史”部分由蒋鸿昌翻译，余下部分由萧颖翻译，均已获得Dan Grover授权。在此特别感谢萧颖，她希望有更多翻译的机会，她的邮箱：。
　　Dan Grover的微博：@dan_grover
　　注意: 以下仅是我自己的观点而不代表我雇主的立场。我的微信团队同事们一定有不同的观点。所以，这篇文章不能被理解为腾讯的立场。
　　最近，所有人都在谈论“对话UI”。这是The next big thing。但是，关于这个话题我读的文章越多就越生气，我花了很长的时间才说明白为什么。
　　WIRED写到，对话可以做传统的图形用户界面做不了的事；Matt Hartman把文本驱动的app的火热等同于一种“隐形的屏幕”；Techcrunch说，“忘了app吧，现在Bot要接管了”；Fin的创始人认为这是所有app发展的标杆；Dharmesh Shah怀疑，对话UI的崛起意味这设计师的厄运；Emmet甚至说，“设计，就是对话”。
　　Benedict Evans预测新的趋势是“所有的消息都会不断扩展，直到它包含了软件。”
　　“人们并不想在每一件事上都使用app，”Facebook Messenger负责人David Marcus说到，“……一个在精心设计的气泡中的信息……比app的体验好得多。”在他的主导下，Facebook正在尝试这条路，和高级合作伙伴一起把功能整合到Messenger，并开放了Bot API。
　　我们还看到了把这个想法做到极致的例子，比如Quartz最新的app，它将新闻变成一种对话的形式；游戏Lifeline；甚至有简信这样的app承诺把邮件转化为对话，解放我们。
　　好吧！
　　2014年，在介绍中国的app设计的文章中，我自己有一个段落的标题是“对话是通用的UI”（Chats as Universal UI），我的这篇文章有可能因此会被指责。
　　最近的“Bot热”主要受两个不同趋势的影响。一是人工智能正变得越来越好，证据是人们正在真正地使用Siri和Alexa，它们不再只是噱头。另一个趋势是硅谷正试图学习亚洲的聊天软件，他们对这些app，尤其是微信是如何把那么多和聊天无关的功能集成到里面非常困惑，又非常着迷。背后的理论是，聊天应用而不是独立的app中集成了第三方的服务，用户会更频繁、深入和有效地使用他们。
　　过去两年，我的工作是和聊天信息朝夕相处，我发现，很多关于什么让聊天应用流行以及他们能解决什么问题的想法都有着重大的误解。
　　我后面会解释，聊天应用同时能集成这么多功能并不是“聊天UI”的作用。他们的成功对不断试图满足用户全部需求的硅谷手机操作系统开发商有重大的教育意义。聊天应用已经演化为“元平台”（meta-platforms）。他们很多像平台的而且弥补了操作系统的缺陷的功能都和核心的聊天没有关系。“聊天UI”不仅是个红鲱鱼（推理小说中，红鲱鱼通常代表误导读者思路的诱饵，让读者在看到结局之前，误以为某人或某事件为凶手或破案关键），如果我们认真观察，会发现聊天UI已经突破了它的限制，正在细分。
　　不过首先，我们回过头来看看这件事最初是怎么发生的。
　　聊天气泡简史
　　我们先看一下“聊天UI”的基本组成部分，聊天气泡。让我们先回到2003年。
　　那时候，发短信使用的UI是这样的：
　　在很多手机上，短信被当成“迷你邮件”，有收件箱、发件箱和草稿箱。太麻烦了！
　　时间过去10年后，聊天功能都开始以类似的卡通对话气泡出现。智能手机出现后，它自然地被应用到了第一版iOS和Android的短信应用。
　　智能手机出现后不久，在欧洲和亚洲地区，默认的短信应用的光芒就被第三方聊天软件遮盖了。一开始，他们完全复制短信应用——唯一的不同是他们以流量计费而不是运营商的短信套餐。
　　这些要取代默认短信应用的聊天应用有着各种各样的对话气泡：圆的、方的、肿胀的、扁平的。在20年没有限制的发展过程中，聊天应用增加了更多的功能。为了支持这些功能，出现了很多新的气泡：
　　微信真的很重视这个。它的气泡有文本、语音、视频、小视频、包含新闻标题的卡片、支付、
　　文件、连接、地理位置、联系人。有一次我浏览了一下代码，发现它支持将近100种不同的定义，绝大部分我从来没有在实际使用中见过。
　　除了支持这么多不同的信息，微信的另一个高级功能是它认为聊天应用需要不同种类的帐号。他们观察到品牌商和名人注册个人帐号，然后邀请粉丝建一个超大的群。他们觉得有更好的方法，这就是微信公众号！
　　下面是最早的微信公众号之一，中国南方航空，在2012年上线时的样子：
　　是的，这个Bot不是万能的HAL 9000哦。
　　我生活的城市的地铁系统的公众号是这样的：
　　为什么用户要输入数字？这些帐号的创建者这么没有想象力，在一个新的媒介上还用这么老的方法？
　　当然不是！实际上，关键词是可以自定义的，聊天信息甚至可以上传到第三方的服务器，它们可以定制任何自己喜欢的回复。但是在这个例子中，输入关键词或者更复杂的中文是很糟糕的。这种情况下，输入数字其实是最好的UI选择。
　　更重要的是，这比用流量或不稳定的Wi-Fi下载单独的app，或者是打******然后一直等待要好得多。微信公众号取得了很大的成功，现在有超过800万个公众号。它还向第三方开放了API，来满足不断增长的应用场景和需求。
　　其中一些新的API加深了对话的深度，并增加了新的可能性。语音信息可以在被语音识别之后上传到公众号的服务器上。图片中的物体可以被识别。高级的自然语言处理甚至能理解用户发的信息中所指的确切的定义。用户可以像和朋友对话一样和商家的***中心沟通。甚至，我可以在聊天中选择一条信息然后保存到印象笔记官方帐号中。很酷，对吧？
　　另一方面，更大的成功之处是计步器或者聊天UI的改进等提高。
　　一个启发是增加三个固定的标签菜单。现在，微信公众号可以用菜单键直达用户最常用的功能，而不是输入任何信息。广州地铁的标签菜单如下：
　　这些标签不仅能发送关键词，还能打开网页。集成在其中的Web app能够识别用户。微信还有可以扩展的Java API，他们能集成app的任何功能，甚至是和蓝牙基站通信。
　　微信公众号能够收发金钱。每个帐号都有二维码——既有帐号本身的，也可以有能附加其他信息的。他们可以为商家增加了Wi-Fi验证的功能。公众号不仅能向用户发送新闻标题，如果他们愿意，还可以发送公众号文章的链接，让用户评论，甚至打赏。他们都和聊天无关，但是非常酷！
　　当疯狂正在中国蔓延的时候，美国西海岸的竞争者们给我们描述了怎样的未来？让我们看看微软最近的Bot平台首页，这是他们认为的我们未来定披萨的过程：
　　好家伙，我要按键73次（ 注释1），才能告诉披萨机器人我想要什么。而且这还是它一开始就知道我是谁的情况下。
　　哥们，数数这些按键次数真的让我非常饿！中国没有太多披萨，但是有必胜客，让我打开它的公众号看一下：
　　总数：按键16次（其中6次是输入支付密码）
　　我只按键16次就定到了披萨。其中1次是选择“中号”，1步关闭他们的提示页，6次是输入支付密码。甚至，必胜客的公众号发给了我一个链接，我可以追踪它的进度：
　　微信成功的关键是它很大程度上精简了app的***、登录、支付和消息通知。在它的聊天UI内，也根本不用考虑适配。
　　不需要太多详细的分析，下面，我会指出在最近的热潮下一些公司的Bot和聊天UI明显的愚蠢之处：
　　以上这些Bot解决问题的方法其实是一种拟物化，和通讯录软件加上阴影和圆环把自己弄得像Rolodex***本一样。上面例子中用“please”、“thank you”这样的客套话来按顺序请求和披萨有关的选择。这种人类交流习惯的残留根本就不实用（他们反而让任务受阻）。
　　为一个完成特定任务的对话设计UI就要求我们有所取舍，我们要在UI层面考虑任务的每一个方面，以及他们怎么在时间和空间上安排。再想一下必胜客的公众号：我可以看到一个中号的披萨被切成绩快，天福牛肉披萨上面有多少玉米，配送地址，以及价格。
　　所以，我把过去几年在中国的经历称为“伟大的聊天UI之旅”。在这里，有一个可以同时满足用户和商家的消息平台（Facebook、Kik和Telegram拼命都想做的）。它大胆又认真地高举着“让每一个行为都变成对话”的火炬。它在API中增加了数不清的功能——尽管其中真正成功地给用户带来价值的是剥离了对话的“聊天UI”。而且，这些成功为找到品牌商和用户真正的使用场景以及怎样去满足他们提供了例证。
　　你会发现Facebook和其他尝试Bots的早期尝鲜者们已经开始有这样的直觉了，Telegram的做法就忠于它从互联网中继聊天系统的斜杠指令中获得的灵感。
　　平心而论，这么多种类的app和服务都能硬塞到聊天式的UI中还是让人称奇。难怪，它能随着人工智能和从这里那里获得的UI灵感而不断发展。
　　我也要承认，在聊天中解决特定任务还带来了其他一些好处，和app相比，它需要更低的带宽，更加灵活，而且按照连贯的顺序来完成任务。而且，它的所有东西都随手可得、离线可看，又可以搜索。我可以搜索，并快速跳到媒体文件和链接。我可以把其中的一部分打包分享给朋友，或者收藏。
　　当一些引我注意的事情发生时，通过消息传送与某一些服务互动而非通过独立的应用，这些线索会蹦到我的收件箱，而不是淹没在海量的推送通知和电邮中。
　　虽然我们都很清楚，纯粹的会话界面是一个完全不会成功的妄想，最后一部分或许比它最初看起来更加重要。
　　收信箱是最新的主屏幕
　　收信箱设计得恰到好处。当然，我非常偏心，不过我觉得微信有同类应用中最好的收件箱。我甚至可以大胆地说收信箱是应用中被人们忽略的亮点。与我们在电邮和短信服务中使用的收信箱相比，微信收信箱一些关键的改进包括：
　　置顶功能：如果我想将收信箱中特别的消息保留置顶（不管是来自个人的，群聊的，公众号的，或者其他开放的功能），我能将其“粘”在最顶端。
　　免打扰选项：任何消息我都能将其设为免打扰模式，但它仍然会像消息一样出现在收信箱中，带着一个不起眼的红色标志而不是数字“1”。
　　拉黑权：如果我不想收到来自某些地方某些人的信息，只需要两步就能把他拉黑。
　　分级：公众号能向我推送新闻和促销资讯，当这些信息送达时，应用中只会弹出“订阅号”的标签并显示最新文章的标题，而不会跟其他信息提示混在一块。如果某个服务号专门发送信息给我，信息将会出现在主信箱中。我发现这种方法比Gmail的“内嵌式信箱”法，即将讯息分进不同的收信箱来得高明。我心心念念想开发出一种功能将信息分类到用户创建的文件夹中（为了整理我的群聊）但恐怕这可能将界面复杂化了（ 注释2）。
　　状态：持续的过程/状态能够显示在置顶的一个特别的框框中，包括像登陆网页/PC客户端，使用微信连接WIFI，播放音乐或是在手机间传数据。
　　可搜索：主屏幕中的搜索栏不仅仅能搜索联系人，还能搜索我的群组，聊天历史，收藏夹中的东东，网上的文章，我所订阅的文章，应用中的功能名称等等。
　　人们都会说，我收到了一条“微信”，而不是说我在“聊天”或是收到了一封“信”，这点与其他的聊天应用非常不一样。
　　事实上，整个体验的基础是融合了短信、通知和资讯的一种常见的，半分化的信息流整合，并能用统一连贯的集合加以控制。人们自然不会用微信及其附属服务去替代短信，微信可以说是一种手机操作系统的雏形，其用户界面范式并非以呆板的应用为核心而是以跟帖为核心（严格说来，也不是会话核心）。
　　当你这么想，其实没有必要将收信箱中所排列的东西视为会话本身。但，从最抽象的角度来说，这里面向我发送更新和通知的账号，在发送讯息时均改变了位置，保持着已读/未读的状态。最重要的它允许作为用户的我掌握着上述一切的控制权。
　　如果我们将这个想法发挥到极致，当我打开收信箱框框时，出现什么内容都无所谓。——我能对话、听歌、看视频、新闻头条、地图导航、计时器或是其他类似的小组。真的，怎样都行。不过我觉得最好是动态的或是服务的类型（我肯定不想这样使用计算器或是相机）。
　　玉米片app的兴起
　　App这个词出现也有一定年头，随着智能手机的普及才成为人们的日常用语。这一点也不让人意外。约是在2007年，在智能手机操作系统加入应用是一个革命性的进步，比电脑客户端好用多了。***和卸载软件头一次变得如此轻松。还让人省心放心，因为这不会毁了你的全部系统（主要是因为沙盒系统和认证模式）。
　　那时，智能手机应用被视作电脑客户端的兄弟。在苹果手机的操作系统，像邮件和日历应用催生了相关的Mac电脑版。苹果推出了袖珍版本的应用像是Pages, GarageBand和 iMovie。在最初的几年，设置苹果手机还需要将其连接到电脑，并与iTunes同步，非常麻烦。
　　虽然某些应用是迷你版的电脑版应用，充分利用了我口袋里的计算小怪兽，不过其中有超过一半的应用可不太一样。这些应用仅仅是诸如新闻，通知，讯息等稳定信息流的载体，这些信息流以及其他即时的信息最终是储存在某个地方的终端服务器。这些应用本身并没有贡献什么实质内容。这就像玉米片的主要价值其实不在于玉米片本身，而是为了搭配芝士和辣椒。
　　我们所使用的智能操作系统很大程度上将手机当做迷你PC，而不是信息的“玉米片”。因此，如果你是这些应用的制作者之一，就必须让你的应用每天（或者更频繁）给我供应新鲜热辣的内容，否则你的应用就没有理由存在。这些信息最好是放在我每天经常查看的另一个应用之中，像是社会新闻订阅器或是消息应用。为了使这些应用免遭淘汰，操作系统为这些应用提供的唯一资源，是那些相当笨拙的推送通知（像Toady的widgets小部件或是安卓的主屏幕挂件）（ 注释3）。
　　智能手机系统让我们失望的其他地方
　　在中国，人们变得依赖微信以后，微信俨然成了一个独立的系统。毕竟，微信可不仅仅是我的聊天软件，社会新闻订阅器、资讯和博客订阅器（很多还只能在这个应用里看到）、数字钱包、读书单。微信还能通过我和朋友们所使用的蓝牙设备直接读取走路步数；还能扫描二维码，这理应是操作系统该做的事，但系统做不到。（以后我们再详细聊这个）。微信还能够识别正在播放的歌曲，甚至是从照片中识别书籍和物品。而且，你还能将这些讯息以你希望的方式在不同功能间轻易地转化。
　　有时候，微信让我想起在九十年代早期那些跌跌撞撞的过渡时期，人们可能从磁盘操作系统中运行WINDOWS或是其他shell环境，时不时跳出去做别的事。切换出微信也是遵循同样的原理，跳到主页面，慢慢进入其他打开的应用。
　　这没什么值得一惊一乍的，那么，我想说的是，近来，我的操作系统为我做的远远不够。这是怎么回事？如今，智能手机操作系统的本职除了那些我们习以为常的低端苦力活（管理内存和信息储备云云），还有就是为应用提供所依赖基础功能和高级服务。那么应用就能专注于它们擅长的领域。同时，操作系统似乎在很多方面的作用都泛善可陈。
　　下面的每一个小标题的内容看起来似乎琐碎凌乱、透着一丝愤愤不平，但很快就能瞄过去哦，——我在写这些的时候，也感觉觉得自己像乖戾而脾气暴躁的Y一代的Andy Rooney。
　　通知——当我浏览主屏时，处处都有红点。我的目光马上扫到一些我能解读地方。微信，然后自然是邮箱。我的收信箱中有8108封未读信息，但只要数字变成8109我肯定会留意到它。
　　我的“社交”文件夹收到了4条提醒，一条来自脸书，我会查看，其余三个来自其他应用，带着数字“1”的提示。我不确定这些应用要通知我什么，也不知道我打开应用后清理了红点后要做什么。我想其中一条可能来自我的朋友，几个星期前我回旧金山的时候，和我朋友去了酒吧。他用Foursquare通过了我的验证，因为我当时站在他旁边所以我很清楚，而且那时候通知已经发到我的手机上了。进入之后琢磨怎么清掉红点也不会让我觉得麻烦。一条也许是来自Instagram，它觉得寂寞的时候总是弹个红点点在上面。我知道了只要我的“社交”文件夹显示的数字是3，就可能没什么东西可看，而显示的是4或者5就可以进去查看了。
　　系统的短信应用我在留在主屏上，上面显示还有39封未读信息，很多都是验证码信息，银行交易通知还有一些垃圾短信。这里面的短信没有啥实质内容和目的。我的“消息”文件夹里是关于应用更新的信息。Airpocalypse的标记提示我现在广州的空气质量指数是93.星巴克也贴了个“1”。这是啥？我的积分够兑换一杯咖啡了？我看看先。非也，只是一条应用的未读信息，写着“欢迎使用星巴克应用！”
　　比这些在主屏幕上眼巴巴望着我的通知更糟的是那打扰我的那些通知。当我***了一个新应用后，这样做其实挺冒险的，因为我不知道他们会发送什么，以怎样的频率发送。通常会打开选项允许其发送通知。iPhone（更坏的是是Apple Wtach）给我提示多余的信息时，我并不能及时地吼它“闭嘴，不要再用这种东西骚扰我。”我娴熟地打开设置，找到应用，把它给关了。或者直接将应用删除掉来得更简单。MIUI还有其他的Android系统至少允许我在收到某个应用一次通知后就将其设为免打扰。很多应用能够设置选择需要提示的消息类型，但这个选项每个应用都藏在不同的地方，没必要那么费劲去关闭这些提示。
　　就算直到最近，我在iOS系统解锁手机打***或查找东西时，错过了些重要通知的话，仍然无法快速返回找到那些通知。iOS 9里的消息盒子和Android的有异曲同工之妙，默认了按时间从近到远地排列通知，而不是按应用来归类——花了五年的时间，迈出了伟大的一步。
　　最后，那些多功能设备上的情况更是糟糕。当我下班回到家，敲开我的笔记本电脑，我又一次收到过去几天已经收到的那些消息，在领英看过的所有邀请（因为他们给我发送了邮件，手机上已经收到推送了），还有所有朋友们的生日提醒。
　　二维码——当我离开美国的时候，二维码还没有被认真对待。在物品上贴上二维码是在暗示人们你很二，就像是戴上蓝牙耳机很做作装13。曾经，二维码在中国待遇也大致如此，直到微信赋予了它第二次生命。现在，人们通过扫描二维码加入群聊，关注商家，付款，登陆，等等。其他的应用也加入了这些功能。在这里，人们扫描二维码节省了无数时间，扫描二维码是链接线上和线下世界的绝妙的不二法门。但是二维码也存在一些不足。一个是他们看起来像是机器人的呕吐物。另一方面就是如果用错误的应用去扫描二维码，你会进入一个页面，不是遇到一些完全不知所云的东西，就是告诉你要***正确的应用。
　　一些曾经被定义为开放标准的东西如今不接地气了。我预测Facebook和Snapchat将会大力推进于二维码的美化工程。即便如此，我还是希望手机操作系统能扫描所有的二维码（或是从照片中识别到二维码）完成它本该做的事，但我们似乎看不到这样的机会了。
　　应用分发——应用商店除了那些明显的弊端：低级的搜索功能和前后不一的评分机制，我在上一篇文章写过一些题外话，在中国ios苹果商店是如何错失目标。简而言之，就是应用下载很慢，还不支持二维码（每一个应用宣传中都有的二维码）。
　　App太占储存空间——更不用说，如今的app都太大了。Twitter，一个用来发布140个字符短信的应用竟然要占用72MB。人们不太可能消耗流量或是在信号不好的Wi-Fi环境中下载占大空间的app。这些应用更可能被用户删掉，而每次要用的时候重装又得重复这些步骤。苹果尝试利用“应用瘦身”和“请求式资源”来解决这个问题，但似乎没有什么作用。David Smith在他的文章“16G是糟糕的体验”一文中犀利地总结这个问题，我还想说，拥有这种体验的人不成比例地分布在发展中国家。
　　通讯录和社交图谱——通讯录应用背后的理念（不仅仅是在给***号码加上名字）是创建中央资料库，即只要有一个简单的联络人信息的切入口，就能关联到各种各样的***号码，地址，或是我所知道的ID。苹果是基于Mac OS X的通讯簿和NeXTStep。理论上，我可以根据我的需要在应用中储存或检索某个人的资料，而不是在一大堆孤立的应用里保存相同的联系人信息。 实际上，它不是这么运作的。脸书或微信里的个人信息和其他地方的个人信息是分离的。
　　不仅如此，添加交友的方式还能更酷哦。有一次我认识了一个妹子，她说要扫描我的二维码（而不是在我的手机里存号码或者是在脸书里搜我），那一刻我突然就开窍了。从那以后我都通过扫二维码（或蓝牙）的方式添加刚刚认识的朋友或是同事，我再也不想用其他方式加人了。为什么不这样添加新认识的朋友呢？掏出手机，主屏解锁，利用人们愿意分享的任何***号码，网页，消息应用的用户名去添加他们呢？
　　联结性——我之前写过人们很不情愿花费流量去下载应用。我也提过微信、支付宝和小米如何致力于帮用户过得好一点，毕竟他们是如此依赖Wi-Fi。在中国或是其他发展中国家这都是个大问题。操作系统应该能更直接地解决这个问题，不管是优化公共热点的认证过程，还是提供更有效的监控流量使用的模式。
　　验证——当我第一次打开大多数应用时，他们不是让我用邮箱注册新账号，用Facebook就是让我使用其他第三方服务登陆，亦或是越来越普遍的用手机验证码登陆。这些真是超级烦人。应该在我第一次打开应用时就自动登陆。操作系统无需过问就应该自动给应用提供一种灵活的身份认证信息，经批准后再补充更多细节。如果用户要转换账户，或许可以采纳火狐浏览器Persona的方式。不管是啥总比现在这种混乱的登陆局面要好。
　　数据交换——我的app在共享数据方面非常糟糕。很多朋友将文章，聊天记录，推文甚至其他app截屏后发给我。有些时候我想读文章剩下的部分，或者进一步了解截屏中的东西，却碰上压缩图片失真看不清文字真让人恼火。如果我在Facebook里打开一个页面，而我想将这个页面分享到推特里，我需要选择“在Safari里打开”，重新加载页面，再从这里面分享出去（Facebook对自己干的一切心知肚明）我希望app里的数据能更灵活自由地分享出去，在线下也能打开，稳定地被检索。但是这种事情自OpenDoc 和OLE之后就是白日梦了，或许这是一件你渴望而不可及事。
　　线下储存和储存管理——因为人们那么舍不得用流量，线下储存应用很占空间。所有的音乐和电影应用都是需要储存，新闻应用和热门的第三方浏览器也是如此。有一些给用户提供了详细的界面以便管理储存，甚至做出了小型的饼状图。我喜欢这种控制程度，我希望所有的应用都能具备这种功能。我更希望自己不需担心储存空间，但如果需要清除数据，我想在系统的界面清理而不是进入到单独的应用里去清理。（或者气急败坏把整个应用给删了）
　　支付——我之前写过，在中国线上支付很受酷炫受欢迎的。那些需要我付款的网页或应用很多用的都是支付宝钱包或微信钱包。在美国，我每***一款新的应用就需要我输入信用卡和地址信息。操作系统可以通过Apple Pay和Android Pay来解决，但似乎只在某些地方和严格符合近场通讯条件的地方使用，这限制了潜在的网络效应。解决方法妙就妙在覆盖多种混合的情景和硬件设施，不管是对着昂贵的POS机举起我的手机；还是扫一下店主印在塑料板子上二维码，还是网上付款，第三方应用付款，向不认识的人进行面对面的付款；不管你是个应用菜鸟或者是个大妈，还是开个便利店，你都没有理由抗拒这些付款方式之一。作为用户，没有地方会让你花不了钱。什么时候我在美国也能在应用里这么轻易花掉我的血汗钱？
　　发酵中的元平台之战
　　那么诸如微信、Facebook、LINE和其他类似的媒介平台都来关注并着手解决以上提到的棘手问题。他们提出了解决办法。但不管是那些公开的网页还是那些封闭的应用商店模型都有考虑不够全面和长远的地方，或许也缺乏推行的激励政策。
　　一开始，面对受到屏蔽和封锁的设备和应用商店，我们出于折中所接受的承若是在“墙内花园”的世界更美好。但是几年过后，很多很多种子萌芽了，其他人闯入花园并砌了另一堵墙，在这堵墙内又造了一个花园，还来了另外一个看门人。
　　上世纪90年代，操作系统厂商害怕浏览器边缘化它们，从而放手一搏（比如微软害怕网景浏览器，最后自己做了IE），而下一个挑战在十年后才隐约可见，而且是以一种聊天应用的奇特模式出现。虽然它完全取代用户和应用开发者使用的高端系统还很遥远，我们已经能清晰窥见这种侵蚀的端倪。
　　那么问题来了。我们该怎么做？
　　少一点会话，多一点行动
　　我不知道你的想法，但我希望能看到这一切发生。
　　我希望能点一下操作系统的主屏幕按钮就能出现一个中央信箱，只要有我聊天应用的收件箱一半好用就够了。我希望它能整合我所有的消息接收器、邮箱、订阅的文章和通知，让我整理的时候有绝佳的控制权。不再到处都是的红点点，不再一划屏就错过通知。让操作系统变得更多维和立体一点，更好地将原生应用整合在一起。让它们能恰到好处地在我的设备间同步和终止切换。只需要将全部消息一目了然地呈现并让我能简便操作。我的手机在一天都只需要停留在这一页，当我需要打开计算器或玩无尽之剑时，我只需要轻轻一划。请给我上一道“美味的信息玉米煎饼”作为煮菜，而不是一片一片碎碎的玉米片。
　　下一次我回到美国。我希望我的手机能够支持类似谷歌浏览器的应用，但保留一些有用的功能，而不是那些只能连上网页的占地儿而奇怪的图标。我想坐在T.G.I Friday里扫一扫我桌面上的二维码就能连上他们的Wi-Fi、下订单、付款。我不需要浪费流量包下载占空间的应用、注册账号、***时还要连接一个名片。想象如果我也能这样在医院这样挂号或是搭乘交通工具就太好了。或者是这样办登机手续。
　　作为用户，我希望我的应用，不管是本地的还是网上的应用都能相互同步身份信息、付款、线下储存和数据分享。我想便捷地将人们添加到我的通讯录，不管是亲自添加还是从他们的网页添加。下一次我创业的时候，我希望将时间专注在为我的用户解决个别特殊的问题，而不是让他们为那些普遍的麻烦费心。
　　我其实不在乎过程是怎样的。或许操作系统开发者不玩了。或许Facebook、Telegram或是Snapchat会优化他们的聊天产品进而解决这些问题。天，可能谷歌或UC浏览器也不甘落后。又或者上天听到人们的祈祷天神显灵般地，使得开源的块环链，GNU的解决办法从天而降呢。。。不管啥颜色的猫咪，能抓老鼠的就是好猫。
　　最要紧的是，比起大家都研究bot，我希望科技产业能专注于帮人们消除主要的烦恼和解决我所描述普遍问题，而我的手机本应该能游刃有余地处理这些问题。
　　你还可以看
　　如果这是你第一次看到有关奇怪又令人赞叹的中国软件世界，可以看我在2014年对这个话题的讨论以及2016年后续的讨论。
　　感谢Kevin Shimota, Jeff Dlouhy, Andrew Badr, Jon Russel, MuzzammilZaveri, Sonya Mann, Stephen Wang, Hank Horkoff和Mark Evans对这篇文章的草稿进行审阅修改。
　　1. 有人或许不赞同以上敲屏幕的计数的方法“那语音识别怎么算啊？为什么不能像钢铁侠里的贾维斯那样？首先，你不是Tony Stark 。其次，在既定的任务下，仅仅是在用语音描述任务时比手打要快时，才突出了语音识别的省时作用。我只用过一次语音助手：我离开自助洗衣店时吩咐她“设一个35分钟的闹钟”以便我回来将衣服拿去烘干。也就是说，我亲手设置闹钟的时间比我说出“设置闹钟”要花费更多时间。完成更复杂和需要做出选择的任务时，像是预定披萨 用语音界面要比用经过优化的会话式界面花费更多时间。（尤其是等待拟合声音回应的时间）在那些大于1个指令的对话中，使用这样的用户界面感觉就像是在和Zootoia里的树懒说话而不像是个钢铁侠。唯一我觉得这个用户界面好用的时候是我不能用手的时候。
　　2. 其实呈现这些来自不相关来源/应用的即时信息的方式有好几种。你可以选择传统的收信箱，如上所写的当下的聊天应用风格的收信箱，仪表盘插件/砖（就像Windows的METRO风格的界面）经筛选的脸书风格的订阅消息，未经筛选的推特风格订阅，或是谷歌现在的卡片风格。但我觉得这里详细介绍的聊天风格的收信箱可谓万能。
　　3. 闭嘴。你在这个星球的另一边待上一年后，你就非常想吃这种食物。这披萨上面还有玉米呢，玉米！
请先登录再操作
请先登录再操作
微信扫一扫分享至朋友圈
有品好玩的科技，一切与你有关
2733文章数
知名IT评论人，曾就职于多家知名IT企业，现是科幻星系创建人
未来在这里发声。
新媒体的实践者、研究者和批判者。
立足终端领域，静观科技变化。深入思考，简单陈述。
智能硬件领域第一自媒体。