app-shell

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

The App Shell

应用外壳

The shell is the part of the screen that does not change when the user navigates: the bar across the top, whatever sits in it, and in heavy tools a strip along the bottom. Everything between them belongs to the application. The shell is small, and it carries more weight than its size suggests — it is the only thing a user sees on every screen of every tool.

外壳是用户导航时不会发生变化的屏幕区域：顶部的导航栏及其包含的内容，以及重型工具底部的状态栏。两者之间的所有内容都属于应用本身。外壳的尺寸很小，但作用远超其大小——它是用户在每个工具的每一个屏幕上都会看到的唯一元素。

The Shell Belongs to the Estate, Not to the App

外壳属于生态体系，而非单个应用

One company rarely has one application. It has a public site, a shop, a customer portal, an internal admin tool, and something older that nobody wants to touch but that people depend on. The user crosses between them during a working day, and each crossing is where the sense of one company either holds or breaks.

The rule: the top bar is estate-level furniture. The app owns everything below it. An app that restyles the shared bar to fit its own look has taken something that was not its to change — the bar's job is to be the one fixed point.

But fixed is not the same as full. What the shell contains may shrink to whatever of its jobs are still unanswered here; what remains is identical — same position, same behaviour, same wording. Quantity flexes, treatment does not.

This also settles a hierarchy question that otherwise gets argued per team. Anything above the application in scope lives in the shell; anything within the application lives in the app's own navigation.

Lives in the shell (above the app)	Lives in the app's own nav (within it)
Tenant / customer / organisation	Sections, modules, pages
Region or market	Filters and views
Language and locale	Entity-level actions
Identity, role, sign-out	Feature settings
App launcher	Search within this tool

If a control changes what the whole estate shows you, it is a shell control. If it changes what this tool shows you, it is not.

一家公司很少只有一个应用。通常会有官网、商城、客户门户、内部管理工具，还有一些没人想碰但又不可或缺的旧系统。用户在工作日会在这些应用间切换，每一次切换都关乎用户对公司品牌统一性的感知。

规则：顶部栏是生态级组件，应用仅拥有其下方的所有内容。 如果某个应用为了适配自身风格而修改共享顶部栏，相当于改动了不属于它的东西——顶部栏的职责是作为唯一的固定锚点。

但“固定”并不等同于“完整”。外壳包含的内容可以精简到仅保留当前场景下未被满足的功能；但保留的部分必须完全一致——位置相同、行为相同、措辞相同。内容数量可以灵活调整，但呈现方式必须统一。

这也解决了原本可能需要各团队争论的层级问题：任何超出应用范围的内容都属于外壳；任何应用范围内的内容都属于应用自身的导航系统。

属于外壳（应用上方）	属于应用自身导航（应用内部）
租户/客户/组织	板块、模块、页面
地区或市场	筛选器与视图
语言与区域设置	实体级操作
身份、角色、退出登录	功能设置
应用启动器	本工具内搜索

如果某个控件会改变整个生态体系的显示内容，那它就是外壳控件。如果仅改变当前工具的显示内容，则不属于外壳控件。

How Small the Shell May Get

外壳可以精简到何种程度

A sub-application entered only from its parent has one estate-level job left — the way back — so the shell may collapse to a single line: one label, one icon, on the same background as the content, no bar and no chrome. Everything else the shell would carry was already answered upstream, and repeating it is noise.

The condition is the entry path, and it is the whole rule:

Entry is always through the parent — a return affordance is enough.
Entry can be direct or lateral — a deep link from chat, a bookmark, an email button, another tool — then a return affordance points at nothing, because browser history is not hierarchy. Carry a home affordance instead. It can still be one icon.

Name it by destination, not by action.

← Dashboard

stays true when history and hierarchy disagree;

← Back

does not. Back is a history concept, up is a hierarchy concept, and a shell that conflates them lies exactly when the user is most lost.

仅从父应用进入的子应用，其生态级职责只剩一项——返回路径，因此外壳可以精简为一行：一个标签、一个图标，与内容背景一致，没有栏框和边框。外壳原本承载的其他内容已在上级应用中处理完毕，重复显示只会造成干扰。

精简的条件取决于进入路径，这是唯一的规则：

始终通过父应用进入——仅需提供返回按钮即可。
可直接或从侧面进入——比如从聊天工具、书签、邮件按钮或其他工具的深度链接进入——此时返回按钮毫无意义，因为浏览器历史并不遵循层级结构。取而代之的是主页按钮，它可以仅用一个图标表示。

按目标命名，而非按操作命名。 当历史记录与层级结构不一致时，

← 仪表盘

依然准确；而

← 返回

则不然。“返回”是历史概念，“向上”是层级概念，混淆两者的外壳会在用户最迷茫的时候给出错误指引。

The App Launcher

应用启动器

When a user has access to more than three tools, the shell needs a launcher: one icon in the top bar that opens the full set. It is what replaces the bookmark folder and the link someone pasted in chat two years ago.

Show everything the user can reach, and nothing they cannot — a launcher listing tools that return a 403 teaches users to distrust it
Name tools the way people name them out loud, not by internal project codename
Mark what opens in a new context — a 2006 system that will not share the shell's look should say so, quietly, rather than surprising the user
Order by the user's use, then alphabetically — not by the org chart of who built what

当用户可访问的工具超过三个时，外壳需要一个启动器：顶部栏中的一个图标，点击可展开所有工具列表。它替代了书签文件夹和两年前有人粘贴在聊天里的链接。

仅显示用户可访问的工具，不显示不可访问的——如果启动器列出的工具返回403错误，会让用户对它失去信任
用用户日常称呼的名称命名工具，而非内部项目代号
标记会在新环境中打开的工具——比如2006年的旧系统无法适配外壳风格，应提前悄悄告知用户，而非让用户感到意外
按用户使用频率排序，其次按字母顺序——而非按开发团队的组织架构排序

Tenant, Environment, and the Colour Trap

租户、环境与颜色陷阱

In a multi-tenant or multi-customer tool, the user must always know whose data is on screen. Two related controls, one important difference.

Environment is worth a colour. Production, staging, and a local build should be impossible to confuse, because the cost of the confusion is a real change to real data. A coloured strip or a tinted bar is the right tool, and this is one of the few places where deliberately breaking the calm of the shell is correct.

Tenant is not. Tinting the whole UI per customer is a tempting idea that makes every customer a different-looking product, breaks the brand, and quietly wrecks contrast the moment a customer's colour is not one you chose. Show the tenant as a label in the shell — name, and an avatar or initials if you have one — not as a theme. If a tenant genuinely needs its own visual identity, that is a white-label decision made once at the product level, not a per-session tint ([[brand-visual-language]]).

Whoever is selected, the shell states it plainly and permanently, and destructive actions repeat it in the confirmation ([[ui-context-and-scope]]).

在多租户或多客户工具中，用户必须始终清楚当前屏幕显示的是谁的数据。有两个相关控件，但存在重要区别。

环境值得用颜色区分。 生产环境、预发布环境和本地构建环境绝不能混淆，因为混淆的代价是对真实数据造成实际变更。彩色条或着色栏是合适的方式，这也是少数可以刻意打破外壳简洁性的场景之一。

租户则不需要。 为每个客户给整个UI着色是一个诱人的想法，但这会让每个客户看到的产品外观都不同，破坏品牌统一性，而且一旦客户的颜色不是你选择的，还会悄悄破坏对比度。应在外壳中以标签形式显示租户——名称，如果有的话加上头像或首字母——而非主题色。如果租户确实需要自己的视觉标识，那应该是产品层面的白标定制决策，而非会话级着色（[[brand-visual-language]]）。

无论选中哪个租户，外壳都应清晰且持久地显示，并在破坏性操作的确认弹窗中重复显示（[[ui-context-and-scope]]）。

The Status Bar

状态栏

Heavy tools — dispatch boards, data managers, editors people sit in for six hours ([[operational-expert-tool-ui]]) — benefit from a strip along the bottom that carries ambient state. It answers questions the user would otherwise have to go looking for:

connection and sync state · environment · active filters and how many records they match · selection count · last saved · the one keyboard hint that matters here

It is ambient, so it stays quiet: the same small, muted type as the rest of the shell, no animation, no colour except when something is genuinely wrong. A status bar that flashes is a notification in the wrong place ([[notifications-and-recovery]]).

Consumer products almost never need one. If the user is not in the tool long enough to build a habit of glancing down, the strip is just a stolen row of screen.

重型工具——调度面板、数据管理器、用户会长时间使用的编辑器（[[operational-expert-tool-ui]]）——底部的状态栏可以承载环境状态信息，非常实用。它能回答用户原本需要主动查找的问题：

连接与同步状态 · 环境 · 激活的筛选器及其匹配的记录数 · 选中项数量 · 最后保存时间 · 当前关键的键盘快捷键提示

状态栏是环境信息载体，因此要保持低调：使用与外壳其他部分相同的小号、柔和字体，无动画，除非真的出现问题否则不使用颜色。闪烁的状态栏属于放错位置的通知（[[notifications-and-recovery]]）。

消费类产品几乎不需要状态栏。如果用户使用工具的时间短到还没养成向下扫视的习惯，状态栏只会占用一行屏幕空间。