主要思想
下面 ， 我们来讨论本文的主要思想 。 回到 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 ， 基本功能就是付款、收款和查看余额 。
基本功能：
