Arc 是一款备受关注的新兴浏览器。

每月我都会追踪它的更新,并分享我的使用简评。

本篇是 Arc 7 月更新简评。


Arc 1.0

经过漫长的内测,Arc 在 7 月意外地官宣了 1.0 版本。

现在,登陆 Arc.net 即可下载使用 Arc,再也没有 Waitlist 了。

这是一段了不起的旅程,向 Arc 团队表示庆祝。

关于本次 1.0 版本发布。Arc 在 Ins 高管的建议下,做了一份 Arc Engine 模型,展示了用户从注册 Waitlist 到真正使用 Arc 的获客漏斗,如下图所示。结果发现,80% 的用户在 Waitlist 和 Windows 版本上流失了。这是一个很大的流失,也促使 Arc 取消 Waitlist,正式发布 Arc 1.0。

其实理想情况下,如果 Arc 能在今年年底前发布 Windows 版本,那配合 1.0 发布会是一个更好的决策。在此之前,Waitlist 对用户的流失其实可以忍受。虽然流失了,但这能定义,或者决定产品的成败吗,当然不能。所以已经等了一年,再等几个月又何妨呢。但如果 Windows 版本遥遥无期,Arc 应该配合一个大的功能更新,再发布 1.0 版本,效果也会更好。

但不管怎样,1.0 版本发布了。人生哪有那么多理性和完美主义呢,有时一些冲动也未尝不是好事。仓促,冲动,但鲜活。

关于 1.0 版本的发布物料。本次 Arc 准备了若干 YouTube 视频一篇 The Verge 文章一张贴纸一个 Spotify 歌单一个解锁了的推特账号一个新官网等。我个人最感兴趣的是这个新官网。

Arc 一直有一种名人崇拜,在宣传上也爱强调员工来自很多厉害的地方。这是一种天然优势,适当地用于宣传可以增强用户的信任。但在 Arc 新官网上,首屏放上的是 The Verge 的评价,而不是自己的 Slogan,就显得比较少见了(之前更长)。实际上,苹果不会强调自己的员工来自谷歌。如果产品足够好,其实没必要如此强调别人的评价,即使是名人。

对于官网本身。毫无疑问,它是一个具有 Arc 气质的,工艺精美的官网。但内容有些简陋零散,且用户看完可能会很困惑:Arc 究竟是什么?它为什么比 Chrome 强?我想这也是现在功能越来越多的 Arc 需要思考的问题。就我个人而言,我更喜欢 The Browser Company 官网,开头讲了一个关于 Chrome 的小故事,颇有趣味。如果后续能变换为 Arc,让人们知道两者的关联与变化,会更有趣。

最后,一个细节:Arc 官网的网址是 Arc.net,以 .net 结尾。喜欢这个小小的复古情怀。


Toolbar

Arc 更新了一个新功能:Toolbar。现在,你可以在 Toolbar 便捷地使用返回、刷新、插件等基础操作,而无需打开侧边栏。这对于从 Chrome 切换来的用户会友好和易于上手。

打开方式:在 Command Bar 输入「SHOW TOOLBAR」。点击 Mac 菜单上的 View 栏可隐藏。

另外,Toolbar 可以自适应网站颜色,和 Safari 一样。这很棒,这并不容易。但其对于背景复杂的网页的适配不太好,例如 Google Design,后续可以再优化。

在 Arc 6 月更新简评中,我提到过希望加一个永久性的 ToolBar。但如今真的加了,在我使用一天后,还是忍不住关闭了。因为 Toolbar 没有其他 Tabs,不能完成基本的页面协作。在我的日常使用中还是会打开侧边栏。既然打开侧边栏,那白白占据空间的 Toolbar 就没有必要了,于是我便关闭了。

从这个小例子也可以看出。符合逻辑的想法不一定好用。想法一定要真正实现出来,真正上手体验,才能区分方案的好坏。

当然,这并不是说 Toolbar 不好。当前的 Toolbar 只是一个半成品,Arc 并没有提供一个合适的使用场景。很可能是为后续的其它功能做铺垫的。所以再等几个月,说不定使用体验会有所改观。

另外,其实有了 Toolbar,Little Arc 就不需要了,可以删除这个功能以简化 Arc。例如下图, Toolbar 稍加改造就完整替代了 Little Arc。


Peek at any site

Arc 更新了一个新功能:在任何 Tab,按住 Shift 点击都能打开 Peek。

之前 Arc 只能在 Pinned Tabs 打开 Peek 页面。对此 Arc 团队的解释是「it's the best signal we have that you're on something important and don't want to get too far off course」。也就是说, Pinned Tab 是重要的事情,用 Peek 可以确保不分心。而 Today Tab 是随机页面,就没有必要用这种「跳出兔子洞」的设计了。

按照这个解释,或许 Peek 可以增加一个设计:只要用户隐藏了侧边栏,不管是 Pinned Tab,还是 Today Tab,都会自动启动 Peek。因为这时用户都在去除干扰,专注在重要的事情上。

另外,其实 Peek 不是一个完整的设计。如果你在 Peek 页面再打开 Peek 页面,就会混乱。如果当你打开 Peek 页面后,想要将这个页面稍后处理也做不到。设计这些功能很容易,但你会发现很难和侧边栏做结合。想要更强大的 peek,或者说「跳出兔子洞」功能,就要优化侧边栏。

我在文章结尾,会举个例子详细说明。


其它更新

  • Tab 定位功能:可以快速定位到正在打开的 Tab。非常巧妙且深思熟虑的功能。(原本的原型
  • Double click to Tab:双击 Space 空白区域,可以快速打开 Command Bar,新建 Tab。挺好的细节改进。不过在 Library 的 Spaces 页面双击时,也会新建 Tab。但这时用户是想要快速回到 Space。建议改进。
  • Real easy renaming:将页面拖动到 Pinned Tab 后,会自动开启重命名模式。对于不需要重命名的用户来说,这个功能可能会有打扰。其实可以通过「优化 Tab 命名」来减少重命名的需求。例如现在谷歌搜索「Why」时,Tab 名字是「Why - Google Search」,可优化为「Why」。
  • Clear That Archive:在 Archive 页面右键,现在可以快速清除 Archive 了。和「清除历史记录」一样,这是一个基本的功能点,不做评价。不过说句题外话,Archive 和历史记录本就是一回事,其实没必要刻意区分。而且现在的 Archive 页面滚动起来真的好卡 …
  • Paste New Tab:⌥⌘V 可以快速打开剪贴板的链接。(以往需要点击新建 Tab,在 command Bar 里粘贴链接,再回车)。这无疑是一个提高效率的小改进。但目前越来越多的功能和改进是依赖快捷键、输入指令等隐藏方式,让好用的门槛也越来越高了。

小技巧

  • 按住 Option 并拖动 Tab,可以快速复制该 Tab。

在 Pinned Tab 中跳转到其它页面,有时想保留这个页面,但又不想失去原页面,就可以用这个功能快速复制。这也是Figma 等设计软件中常用的快捷键,非常好用。


交互建议

Arc 6 月简评里提到,可以通过设计一个按钮来优化 Folder View 的功能。最近想到,其实不需要单独设计一个按钮,Space 的名字就是天生的按钮。

实现交互如下:点击 Space 的名字,一键折叠所有文件夹,同时探出文件夹内所有正在使用的 Tab。再按一次,会彻底折叠所有文件夹,没有探出 Tab。


实验原型

  • Arc AI

Arc 分享了一些在侧边栏实现 AI 对话的原型。挺有趣的,但这明显会妨碍原侧边栏的使用,可能只是一些原型边角料哈哈。个人推测会像 Raycast 一样通过 Command Bar 唤出,或像 Boost 一样成为一个独立的窗口。不过交互并不关键,关键是处理好「AI 和页面的关系 + 生产内容的承接」。在这个方面,浏览器和操作系统一样,都具有得天独厚的优势。

  • 更窄的侧边栏

推特用户 @gaddafirusli 分享了一个窄侧边栏的设计原型。如 Arc CEO Josh 所说,很多页面图标相同,这时就难以使用了。这个方案适合于收藏页面,因为用户会自定义和记住每个 Tab,例如 Edge 侧边栏。换而言之,Arc 的 Favor Tabs 其实是一样的方案。

  • 2019 年年底的 Arc 原型

Josh 分享了一张 2019 年的 Arc 原型。这个原型非常有趣,将文件夹定位成项目。如果你试过另一款侧边栏结构的浏览器 Horse,你会发现两者结构几乎一模一样,就连定位也相同。实际上,当前的 Notion、Linear、Safari Tab Group 等大多数侧边结构的 macOS 应用,几乎都是项目工具。换而言之,这种侧边栏结构,能折叠延伸,真的很适合作为项目工具。

就当前 Arc 和这个原型的核心区别,看起来是 Space 结构,实际上是 Today Tabs 结构。因为后者让 Arc 从项目工具变成了浏览器。

  • Arc 原型:查看近期 Tabs

还是来自 Josh 分享的旧 Arc 原型。在这个原型里可以看到类似 Safari Tab overview 或 macOS Mission Control 的查看近期活动窗口的设计。这个设计其实挺好的,未来也未尝不可加回。不过更令我感兴趣的是侧边栏,如下图二,文件夹变成了可以自定义图标的项目,还可以聚焦只查看某项目。看到了未来 Arc 项目的影子。


趣闻

  • 推特用户 @takasek 希望 Notion 增加一个网址搜索功能。不再需要打开 Notion 后 ⌘P 开启搜索,而是直接在浏览器里输入 www.notion.so/workspace/search/content 快速搜索。

这是一个很有趣的需求,其隐含的意思是希望脱离 Notion 自身结构,快速触达 Notion 的功能。换而言之,用户一定是通过其它途径替代了 Notion 的结构。在这个例子中,是 Arc

实际上,我也是这样用的。如下图所示,我现在随意新增页面,已经不管 Notion 的侧边栏了,纯粹是把它当成是一个好用的编辑器。新增页面全存储在 Arc 的项目文件夹里,一样的好用。

对于 Arc 来说,这是一件好事,因为用户的结构越存储在 Arc 上,用户越离不开 Arc。但对于 Notion 等应用来说,这并不是一个好事,因为用户会把它当成是一个工具,而不是应用。不过,如果未来 Notion 侧边栏也支持打开网页,会不会是一件有趣的事情呢?


思考:Arc 为什么好用?

回答一下文章开头的问题:Arc 为什么好用?

Arc 现在花哨的功能太多了。想要回答这个问题,我们不妨一个个删除功能,看哪些功能才是最有必要的。

首先,Arc 下载后绚丽的动画、Easel、Note、个性化等功能属于锦上添花,删除都没有影响;其次 Boost 也非必要,在 Boost 2.0 前,Boost 无人问津,也不妨碍 Arc 受人欢迎;最后是 Space,它重要但不根本,精妙但非不可替代,Notion、Linear、Safari 等的 Profile 设计其实就类似于 Space,没有那么精妙也不妨碍原软件的使用。

定位下来,其实 Arc 最好用的是其侧边栏的结构。首先,它完整地替代了 Chrome 的标签,实现了基本的浏览器使用,这是基础。在此之上,Pinned Tabs、Today Tabs 和 Clear 的设计,让它可以克服 Chrome 易于混乱的标签问题,这是改进。在此之上,它引入了 Folder 结构,配合侧边栏,让用户得以结构化的整理网页,发展出了自己的工作流,这才是根本。

相较而言,其实 Chrome、Safari 等传统浏览器经过时间的洗礼,结构是很完善、可用的。并不像各种浏览器颠覆者说得那样过时和不堪。但它们不能很好地组织标签,用户难以在里面沉淀结构化知识,它们便只是浏览网页的浏览器。而 Arc 其实已经突破了浏览器的范畴,成为了一个工作效率工具,未来甚至有潜力成为知识管理工具。

不管 Arc 团队是否认同这一观点,我都希望他们能思考一下:Arc 真正重要的是什么?然后着重去建设它,改善它。而不是像当下一样,功能繁多,让人难以定位,难以简单地介绍。


思考:Arc 如何简化?

简化对 Arc 来说一直是一个难题。

Arc 刚推出时,其侧边栏结构其实已经相当简洁和完善了。给简单的事情做简化是很困难的,最终的结果往往是加上某些结构,看似简化实则复杂,例如 Side Control;亦或是把简化理解为简单地删除,洁癖般地删除各种按钮,牺牲可用性,例如 Arc 对 Pinned Tab 的简化。

实际上,简化并不是简单的删除,也不是一味追求成为孩子也会玩的 iPad。这是结果不是目的。我们不能用这个尺度评判孩子不会玩的 Figma、Final Cut Pro 不是好软件。真正的简化是去除干扰,凸显真正重要的东西。

正如前文所说,我认为 Arc 真正重要的是工作流体验。所以我做了一个简化的 Arc 原型,突出工作流。可供参考。

简单解释一下。首先,紧缩设计,去除花哨的干扰,让用户专注在复杂的工作本身。

再者,将标签栏和地址栏融为一体,类似 Safari。减少分离的割裂感。

同用,将 Library 变为系统 Space,减少分裂感。

在侧边栏底部增加各种针对侧边栏的操作按钮。增幅 Arc 工作流。

等等。

实际上,这些简化都来自我曾经写的「这篇文章」。若有兴趣可以查看更详细的介绍。我原本计划在 Arc 基础上,构思一个专属工作流的应用 AI/R。但我最近意识到,想法本身并不重要,重要的是去实现。所以我决定暂时搁浅 AI/R 的构思,专注于开发出一个我的第一个 iOS 小应用:Cush(PS:不能免俗,第一款应用也是记账软件哈哈哈)。与此同时,以往所有关于 AI/R 的构思都会简单地写在每月更新的 Arc 更新月评里,等合适的时机再作细思。渐进式发展。

另外,简化下来,Arc 结构和使用逻辑都很清晰。套用到 Chrome 的横版布局也未尝不可:


思考:如何优化 Arc 的 Peek 功能

前面提到,Peek 并不是一个完整的设计。如果你在 Peek 页面再打开 Peek 页面,就会混乱。如果当你打开 Peek 页面后,想要将这个页面稍后处理也做不到。下面给出一些优化思路。

首先,提供 MultiPeek 功能,允许多重 Peek。类似于 iOS 里模态叠加。这是一个很自然的需求。

 

MultiPeek 的所有操作,都可以在折叠侧边栏的情况下完成。例如隐藏、隐藏之后底部出现小按钮,点击再显示等等。并且可以便捷地删除、重组、收藏这些页面。这样整体使用是流畅的,是符合工作流的要求的。

展开侧边栏后,会发现 Arc 目前的设计只能容纳一个 Peek。所以引入 Path 功能,让 Tab 也能变成文件夹,内包含页面,这样就能容纳 MultiPeek 的 Tabs 了。但是由于 MultiPeek 可能只是临时页面,没有被 Pinned,所以置灰,可被便捷清除,收藏后才能真正变黑。得以区分收藏与否的页面。

如何快速 Pin 临时页面呢?有很多种交互方案。例如在 Tab 或是 Toolbar 上加个收藏按钮,或是在页面前面加一个指示灯,快速查看哪些页面被打开,点击即可快速收藏等等;如何便捷清除呢?有很多种交互方案。例如在 Tab 或者 Space 名字旁加个类似「Today Tabs Clear」的按钮,或是在侧边栏底部的按钮区加个清除所有临时页面的按钮。交互方式有很多种,就不多想了。

这里可以再延展说说 Path 功能。

当在本页面打开其它页面时,本页面会自动变成文件夹,收纳其它页面,形成一条浏览的 Path。主次分明,人们知道哪些是主线程,哪些是副页面。不会所有页面全部堆在一起。减少了心智负担。当用户同时在做几件事时,尤其清晰。Jump out of the rabbit hole。实际上,Path 其实相当于给打开的页面,按照来源做了分类,和 Space 一样,这也是一种分摊复杂度的方式。

Path 更有价值的一点在于,它还可以记忆上下文关系。你可以手动排序 Path,这样页面关系就能被保留下来,成为结构。页面也可以开发一个功能,自动记录在哪里打开,前进路径是什么。你可以收藏其中的某些路径,加以备注。这样以后就不会忘记为什么收藏这个页面,为什么关注这个博主了。

我连广告词都想好了:Your Past, your Path. 哈哈。

延展开来,如果网页里的每一个片段,每一张图片都能被收藏,被记录上下文关系。彼此相互联系,产生化学反应,那会是一件多么美妙的事情。实际上,Arc 的 Capture 就有这个潜力。所以我说,Arc 有潜力成为一个知识管理工具。


以上就是 Arc 浏览器 7 月更新简评。欢迎在评论区聊聊你的看法 ~

也欢迎加我微信 TheoChangAIR,进入 Arc 讨论群 ~

24
14