信息
问题
Are.na 围绕连接而生。你把一个区块存进频道，再把这个频道连到另一个频道，如此重复——几个月、几年——最后积累下来的东西不太像文件夹，反而更像一种思考方式。
可你并不能真正看见它。连接都在那里，只是隐形了。你只能一次翻一页，沿着直线走过它们，就像读一本关于城市的书，却从未真正站进那座城市。
我想看看它究竟长什么样。
一个关键决定
Kabo 是一种观看方式，不是一种操作方式。这个单一约束，让其他大多数决定都顺理成章。
它不是什么
最容易做出来的版本，是一块分析仪表盘：区块数量、连接深度、被链接最多的频道。我很早就把它排除了。
会想用它的人并不打算优化什么。他们是慢慢收集的研究者和收藏者，只想换一种方式重新遇见自己已经做出的东西。指标只会成为噪声。
所以：没有统计，没有导入，也没有导出。每个节点都会连回 Are.na——Kabo 只是借用一种视角，并不拿走你的数据。图谱也会不断积累：每次点击都在原有基础上增加，而不是替换。你靠漫游建立语境。这就是全部模型。
它怎么用
Kabo 会抓取频道，并在深色空间里把它渲染成力导向 3D 图谱。频道是微微发光的球体；图片区块是悬浮平面，上面放着真实图片；文字区块则是小小的彩色立方体。连接线细而安静——一直在场，从不喧宾夺主。
其中的区块会出现，并和刚才打开的内容相连，图谱随之向外生长。反过来点击区块，就会载入它所属的频道——一张存在某处的照片，也许还住在三个你从未去过的频道里。这些关联会自己浮现。
频道球体戴着小小的方括号——[ ]——安静地暗示它可以被打开。选中后，侧边栏滑出：名称、内容、预览、返回原始页面的链接，以及你一路走来的轨迹。
技术决定
这是整个项目里最重要的性能决定。移动节点只更新它的 transform，而不是重新生成几何体。响应式开发里这点很容易做错——每次状态变化，都在诱惑你从头渲染。
纹理以区块 ID 为键，保存在模块级映射中。第一次访问会上传 GPU，之后每次都直接返回缓存。没有它，重访任何图片都会明显卡顿。
一个频道最多打开 20 个随机区块和 5 个子频道；一个区块最多打开 3 个频道。这些不是 API 限制，而是产品限制。第一次点击就丢出 200 个节点，会直接毁掉这段体验赖以成立的东西。
Are.na API 有速率限制，因此彼此独立的请求会同时发出，退避重试则交给代理。即使一次从多个地方拉取内容，扩展过程依然利落。
下一步想做什么
现在图谱只存在于当前会话里。如果网址可以序列化已展开频道的 ID，你就能把一个研究项目的形状直接交给别人——不需要数据库。
超过大约 30 个节点后，寻找某个具体内容会变难。按名称轻轻高亮会有帮助——但它必须保持环境感。弹窗式搜索栏会打破空间体验，而空间感恰恰是重点。
我还没推到 100 个节点以上。Three.js 应该撑得住；我更担心力导向布局先吃不消。缩小时自动聚类，大概会是答案。
环绕、缩放、WASD——这些都无法自然映射到手机。触屏版本必须是一套真正不同的界面，可能还是 2D。我会先弄清真实使用场景，再动手画。
我学到的事
最难的工作其实不是技术，而是对噪声说不：每个默认工具提示、每个弹窗、每条跃跃欲试的通知。安静的思考空间需要主动保护，它不会白白出现。