主要思想
下面 , 我们来讨论本文的主要思想 。 回到 Intercom 的谬论: 如果网站是一个全屏的对话页面 , 但 Web 组件放在消息内部 , 会怎么样?我们来看看下面这张图 , 并解释一下“反转” 。
文章图片
如上图所示 , 传统网页上的组件被移动到了对话中 。 这个对话代表了与用户交互的整个过程:组件可以被复制 , 也可以处于不同的状态 。 只需向上滚动即可继续与它们的交互 。
这种反转可以让我们利用组件有效地构建 Web 应用程序 。 各个组件都是独立的 , 有人已经很好地应用了这种实践 , 比如Storybook(https://storybook.js.org/)、以及 Next.js 的 url 导入(https://nextjs.org/docs/api-reference/next.config.js/url-imports) 。
但是 , 请不要误会 , 我们没有使用 Intercom 或任何闭源供应商 。 我们希望保持互联网开放 , 简单地通过一个应用程序的运行时 , 将交互变成一个(几乎)不可见的对话 。
你可能觉得这样做没有意义 , 请别着急 , 下面我们会介绍具体的案例 。
不过 , 在此之前 , 我想先讨论一下支持 。
无处不在的支持
许多公司会等到应用程序的构建和发布完成之后 , 再考虑支持 。 例如 , 他们突然意识到用户没有按照预期的方式使用应用程序 。 他们已经做了用户研究呀 , 这是怎么回事?!
人们在支持上投入了大量的精力和资源 。 有的公司求助于 FullStory 等工具来检查用户究竟在干什么 。 有时 , 为了针对某个用户面临的特殊情况调试应用程序 , 却发现根本无法获得完整的上下文 。 调试工具和日志系统只能提供应用程序的间接信息 。
支持必须构建到应用程序内部 , 而且需要遍布各个角落 , 不能留到产品发布后再考虑 。 如果用户通过对话与应用程序进行交互 , 那么支持就只需要在对话中加入客服 。 双方都可以访问相同的信息 , 以及与组件交互的历史记录 。 这种方法不会形成信息的不对称!
这种“无处不在的支持”只不过是对话式交互的副产物 , 但这也是我最关心的方面 , 尤其是现有的支持工具(只能与应用程序并行运行)让我倍感受挫 。
这种 Web 的对话形式可以建立更好的支持 。
案例研究:WAWA
我想通过一个最小化但真实的用例实践这个主要思想 。 由于永远不会脱离 Web3 , 所以我有了一个思路:最简单的加密钱包 , 并为该产品取名 WAWA , 基本功能就是付款、收款和查看余额 。
基本功能: