ABG 欧博（ABG）中国站 记录查询

观察 · 11 篇 / 6 组 / 每篇 3 条论据

导航为什么这样摆

栏目怎么排、词怎么用、图怎么压——这些决定通常不出现在页面上。这里把它们摊开，写成 11 篇可以直接拿去讨论的观察。

欧博（ABG）中国站把内容分成情境、观察、教程、变更记录四种形态，观点专栏承担解释的那部分：为什么入口固定在同一位置、为什么兼容要求写成逐项清单、为什么变更记录按版本倒序。每篇观察给出一个判断和三条论据，判断可以被反驳，论据可以被逐条核对。

11 篇观察
6 个分组
3 条论据 / 篇
4 分钟平均阅读

分组一 · 2 篇

导航与信息结构

入口摆在哪、栏目叫什么名字，直接决定第一次访问的人要花多久才能找到东西。这两篇算的是位置与命名的成本。

  1. 固定入口的位置，比首页省下的那块面积更值钱

    判断：把同一个入口放在每一页的同一栏，收益大于首页少一个装饰区块省下来的面积。

    三条论据

    • 第一次访问的人在第二栏就能看到记录查询，不必先读完首屏才知道它存在。
    • 位置保持一致，用户只需要记住一条路径，而不是每页各记一条。
    • 首页失去的那块装饰区域，可以用更低的误点击率补回来——访客少走一次回头路。

    导航切换 应用场景

  2. 栏目名先给答案，再给范围

    判断：栏目名里带名词范围，比带动作词更容易被记住，也更容易被站内互相引用。

    三条论据

    • “应用场景”“更新日志”这类词本身就说明了页面里装的是什么。
    • 带动作词的栏目名会把访客推向某一个流程，而流程在不同设备上并不一样。
    • 命名稳定之后，站内互链可以只写栏目名，不必每次补充解释去处。

    站点结构 关于我们

分组二 · 2 篇

双端一致与兼容策略

PC 与移动端到底要对齐到什么程度，兼容要求又该用什么形式交给用户，这两件事经常被混在一起谈。

  1. 双端一致指的是结构一致，不是像素一致

    判断：把 PC 与移动端做成同一张像素稿，是一个既费成本又没有收益的目标。

    三条论据

    • 屏幕区间分成三档之后，同一个模块在不同档位承担不同密度是合理的。
    • 真正需要一致的是入口名称、入口顺序与术语，而不是字距与边距。
    • 追求像素一致会逼着页面在窄屏上压缩字号，最后损害的是可读性本身。

    兼容核对 使用教程

  2. 兼容要求写成清单，比写成建议更省沟通

    判断：把兼容条件写成可以逐项打勾的清单，比写一整段建议更省来回。

    三条论据

    • 清单能让访客定位到具体哪一项不通过，一段建议只能给出整体判断。
    • 7 项清单每项写明检查对象与预期结果，访客可以自己走完，不必先问一遍。
    • 条目稳定之后，变更记录只需要说明哪一项发生了变化，不必重写整段说明。

    兼容核对 更新日志

分组三 · 2 篇

术语与文案口径

同一个词在十个页面里被解释成十种意思，是内容站最常见的溃口。这两篇讨论的是答案归属和状态词的写法。

  1. 同一个问题只在一页被完整回答

    判断：把完整答案摊在多页，会让每一页都变得不好引用。

    三条论据

    • 记录查询、导航切换、兼容核对、加载说明这四个术语都被绑定到唯一页面。
    • 其他页面遇到同一问题时只做指向，不重新解释一遍。
    • 代价是单页更长，收益是每条结论只有一个出处，引用时不需要挑版本。

    术语口径 关于我们

  2. 状态词应该区分进度，而不是区分情绪

    判断：状态词的价值在于说明事情进行到了哪一步，而不是表达态度。

    三条论据

    • 已复核、进行中、已归档描述的是处理进度，谁看到都知道下一步该做什么。
    • 重要、推荐这类词描述的是态度，落不到任何一个具体动作上。
    • 状态词表固定之后，标签的位置与尺寸也就顺势统一了。

    术语口径 使用教程

横向的雪脊线与深色区块边界，留白充足

前三组谈的是位置、双端与用词。从这里往下，话题转到文件大小、记录方式和复核节奏。

分组四 · 2 篇

加载与性能取舍

图片压到什么程度、内容按什么顺序出现在屏幕上，这两件事不是纯技术问题，它们直接改的是阅读体验。

  1. 图片单色化，是用细节换首屏

    判断：把配图统一压成单色调，牺牲的是画面细节，换来的是首屏更早出现。

    三条论据

    • 单色处理之后文件更小，多数页面只需要 1 至 4 张图，最多不超过 15 张。
    • 配图只承担氛围与结构示意，本来也不需要保留真实色彩。
    • 代价是同一张图在不同栏目看起来只是色偏不同，辨识度要靠位置而不是内容。

    加载说明 更新日志

  2. 先定栏目结构，再定加载顺序

    判断：信息层级是先决条件，把加载顺序当成设计起点，最后会把层级打乱。

    三条论据

    • 首屏关键样式内联，前提是首屏已经确定要展示导航与路径。
    • 单页图片数量的上限，是由各栏目的定位共同决定的，不是单独设的指标。
    • 如果为了指标去改栏目结构，访客先感受到的是内容顺序变乱了。

    加载说明 使用教程

分组五 · 1 篇

记录与可追溯

用户回头找“我当时看到的是哪一版”时，记录用什么单位来叙述，决定了这个问题好不好回答。

  1. 变更按版本讲，比按日期讲更好核对

    判断：版本序列比日期更能回答“我当时看到的是哪一版”，也更容易被引用。

    三条论据

    • 单页收录 13 条变更，分四类倒序排列，读者可以按类别直接跳到关心的一类。
    • 访客记住的通常是“V3 之后”，而不是某个月份。
    • 不写具体日期，也就避免了页面长期挂着一条已经失效的时间线索。

    变更记录 更新日志

分组六 · 2 篇

复核与更新节奏

内容站的问题很少出在写不出来，多半出在改得不整齐。这两篇讨论复核周期与对外条目数的约束力。

  1. 每月复核一次，比随手改更稳

    判断：固定周期的结构复核，比零散的局部修改更能维持页面之间的一致。

    三条论据

    • 每月一次复核，把命名、术语与入口位置放进同一轮里检查。
    • 随手改动往往只改一页，留下与相邻页不一致的口径，后面越来越难对齐。
    • 复核节奏公开之后，读者也能预期内容什么时候会变。

    站点结构 关于我们

  2. 条目数是对外承诺，不是装饰

    判断：栏目写明的条目数，等于告诉读者这里能查到多少东西。

    三条论据

    • 应用场景 10 个情境分 5 组、观点专栏 11 篇分 6 组，都是对外口径。
    • 数字一旦公开，拆分与合并就要同步更新，不能只改页面不改说法。
    • 稳定的条目数，让“这个栏目值不值得点进去”变成一个可判断的问题。

    站点结构 应用场景

延伸阅读

判断之后，去哪儿核对

六个分组各自对应一个更详细的位置：操作步骤在使用教程，兼容与加载的变化记录在更新日志，入口寻址看应用场景，口径与节奏写在关于我们。

  1. 01 导航与信息结构 应用场景 · 入口寻址 使用教程 · 导航切换操作
  2. 02 双端一致与兼容策略 使用教程 · 浏览器与屏幕区间确认 更新日志 · 兼容与适配
  3. 03 术语与文案口径 关于我们 · 术语统一口径
  4. 04 加载与性能取舍 更新日志 · 加载与性能
  5. 05 记录与可追溯 更新日志 · 13 条变更记录
  6. 06 复核与更新节奏 关于我们 · 内容更新节奏