做产品，我为什么如此小题大做：一张文件列表，怎样同时说清三件事？
看一张文件列表，通常不会觉得它有多复杂：文件名，大小，时间，一行接着一行。
但把鼠标放上去，再选中一个文件，恰好这个文件还在上传，事情就变了。
界面要同时回答三个问题：鼠标现在指着哪一行？我选中了哪个文件？哪个文件正在传，传到了哪里？
我在打磨 FooCloud 的 macOS 文件列表时，处理过滚动过程中行高亮异常的问题。修正那个问题之外，我更想借这张列表讨论的是：当多个状态同时出现，它们各自该用什么方式说话？
如果三个状态都靠“把这一行涂上颜色”表达，单独看可能都很清楚，叠在一起就需要重新辨认。
尤其是指向与选中。鼠标只是路过一行，并不意味着那一行已经成为操作对象。选中之后，鼠标移开，选择也不该跟着消失。两者都与某一行有关，持续时间和操作含义却不同。
当前 FooCloud 的做法是：鼠标指向未选中的行时，给出轻一些的行背景；选中时，由选中背景表达这个更明确的状态，同一行不再额外叠加指向背景。
上传进度则放在文件名区域里，通过填充长度变化来表达。
图 1：根据当前实现绘制的语义示意，非产品截图。进度比例、文件名及旁注均为示例。
这里用到了一个朴素的视觉编码思路：不同信息尽量有可以分辨的表达线索。进度有长度，选择有行范围，指向则是一种短暂反馈。
系统状态可见性要求人能够了解当前状况；具体到这张列表，信息是否可见，还要看它会不会被另一种状态盖住，或者被误认成另一种含义。关于状态反馈
为了说明取舍，可以把三种进度表达放在一起比较。下面这些是对照分析，并不意味着我过去依次做过三个版本。
第一种，进度铺满整行。它很显眼，横向空间也充足。但选中本来就使用行背景，两种信息会在相同区域竞争。填充经过大小和时间等列时，还可能让人把整行的颜色变化理解成统一状态。
第二种，增加独立进度列。含义可以很清楚，也容易配上数值。代价是长期占据一列：窗口较窄，或多数文件没有传输时，这块空间仍然要安排。
第三种，就是当前采用的文件名区域进度。它靠近具体文件，不额外增加列，也保留了整行背景表达选择的空间。
图 2：统一条件下的方案示意。整行进度和独立进度列是本次讨论用对照，未作为历史版本呈现。
当前方案也有代价。文件名直接位于进度底色之上，需要考虑文字是否容易读；进度靠长度表达，短名称并不意味着进度只填到文字末尾，它使用的是文件名这一列的空间。
如果读者没有理解这块区域的含义，也可能把局部底色误认为另一种选中效果。所以，局部呈现只是提供了区分条件，并不会自动消除歧义。
更关键的检验，是把“选中”和“上传中”放到同一行里，再分别看浅色和深色模式。
图 3：按当前层级关系绘制的状态组合示意，非运行截图，不作为实际界面对比度或无障碍验收结果。
只展示一行没有任何其它状态的进度，很容易觉得方案成立。等到选中背景出现，进度边界还在不在？文件名是否清楚？切换深色模式以后，原来轻巧的颜色会不会糊成一片？这些才是组合状态带来的问题。
我不会因为分别给三个状态都设计了样式，就认为整张列表已经表达清楚。它们必须能一起工作。
具体选哪种进度表达，也要看产品的任务。一个专门监控大量传输的页面，独立进度列可能非常合适；日常以找文件、管理文件为主的列表，则值得考虑怎样少占空间又保留反馈。
FooCloud 目前选择了后者：让进度靠近文件名，把整行的选择关系保留下来，同时让鼠标指向退到较轻的层级。
这件小事给我的提醒是，设计状态时，除了逐个问“看不看得见”，还要把它们放在一起问：用户现在能不能分别说出，每一种变化代表什么。
列表里颜色再多，如果最后只能得到一句“这一行变蓝了”，信息就还没有说完。