信息架构与体验决策

信息架构与体验决策

本文记录站点界面调整的理由和验证标准。后续改动应优先解决明确的用户问题，而不是单纯增加功能。

D-001：首页从时间流改为专业入口

• 用户问题：首次访问者无法快速判断作者擅长什么，也无法找到代表性内容。
• 决策：首页优先展示定位、核心主题、代表性文章和最近更新。
• 理由：个人专业站的首页承担建立认知和提供入口的职责；纯时间流更适合已经熟悉站点的订阅读者。
• 保留：最近更新仍然展示，但不再是唯一内容。
• 验证：访问者在首屏可以回答“作者关注什么”和“从哪里开始读”。

D-002：导航从发布形式转向阅读任务

• 用户问题：“技术”和“教程”边界容易重叠，无法承载跨分类系列。
• 决策：保留现有分类 URL，同时增加“主题”“系列”和“归档”入口。
• 理由：主题支持按问题域浏览，系列支持连续阅读，归档支持按时间回溯，三者对应不同任务。
• 验证：任何文章至少能通过分类、主题或系列中的一种方式再次被找到。

D-003：文章页强化上下文和下一步

• 用户问题：从搜索直接进入文章的读者不知道内容是否仍然有效，也缺少继续阅读入口。
• 决策：显示文章类型、更新时间、更新说明、标签、系列位置、相关文章、订阅和反馈。
• 理由：这些信息分别回答“这是什么”“是否新鲜”“接下来读什么”“如何持续获得更新”。
• 验证：文章正文前能判断范围和时效，正文后有明确但不过量的后续动作。

D-004：订阅入口同时提供 RSS 与邮件

• 用户问题：技术用户和普通读者的订阅习惯不同。
• 决策：RSS 直接链接现有 Feed；邮件订阅在未接入第三方平台前使用预填邮件申请。
• 理由：RSS 零依赖且适合技术读者；预填邮件在纯静态站点上可以立即工作，并保留迁移到 Buttondown、Loops 等服务的配置入口。
• 限制：人工处理邮件订阅，不进行自动群发。
• 验证：入口不依赖 JavaScript也能完成订阅意图。

D-005：“是否有帮助”采用低基础设施反馈

• 用户问题：作者无法判断文章是否真正解决问题。
• 决策：文章末尾提供“有帮助”和“需要改进”两个反馈入口，生成包含文章地址和反馈类型的预填邮件。
• 理由：当前内容规模不足以支撑独立反馈后端；邮件方案不收集隐式行为数据，也不会引入第三方追踪。
• 后续：反馈量稳定后，再接入可配置 API，并保持界面和数据字段兼容。
• 验证：两次点击内可以提交带文章上下文的反馈。

D-006：分享功能优先复制摘要和链接

• 用户问题：平台专用分享按钮覆盖有限，而且容易增加无效入口。
• 决策：提供复制“标题 + 摘要 + 链接”的通用操作，并保留原生系统分享能力。
• 理由：复制内容适用于聊天、邮件、笔记和任意社交平台；Web Share API 在支持的平台提供更短路径。
• 验证：桌面端和移动端至少有一种可用分享方式。

D-007：侧栏按页面目的显示

• 用户问题：所有页面固定使用归档侧栏，压缩专题页和搜索页空间，移动端则完全消失。
• 决策：布局支持 sidebar: false，专题页和搜索页使用完整内容宽度；文章与列表页保留发现入口。
• 理由：侧栏是辅助导航，不应成为所有页面的结构约束。
• 验证：关闭侧栏的页面不保留空列，文章页仍可发现搜索和归档。