可估算总量时必须使用确定进度
别名: 百分比进度 · percent-done · 确定进度条
概念解释
确定进度（determinate progress）用已完成量相对总量的比例说话：三十分之十二、百分之四十、第三条/共十条。当系统已经知道总量——文件字节、导出行数、安装步骤——却仍只给一条来回滑动的不确定条，等于把已知信息藏起来。这一条的主张很硬：总量可估算时必须用确定进度。不确定条留给总量真的不知道的时候；用动画假装比例，是再后面一条。
机制
等待中的人在做资源分配：还要盯着、可以切走、还是该取消。比例提供的是决策用的结构，不是安慰。知道到了百分之七十，就可以判断剩下的是否值得继续占着这条链路；只看见条在动，分配只能靠猜测。确定进度还把「系统仍在工作」和「工作已经走了多远」分成两个问题，前者转圈就能答，后者必须有总量。可估算不等于精确到字节：步骤数、已处理记录、已传分片，都是总量。有总量而故意不展示，通常是实现偷懒或害怕比例会停住；停住是诚实的，藏起来让人无法决定才是更大的失败。
怎么研究
同一段可测长度的任务，比较确定条、不确定条、以及只给转圈。允许中途取消或切到别的任务。
自变量：是否显示比例、比例是否带剩余时间、任务是否真的有已知总量。 因变量：取消是否发生在合理的剩余量上、切走后再回来的比例、主观剩余、是否报告「不知道还要多久」。
实验室若不许取消，确定进度的决策价值测不到，只会剩下「觉得快不快」。把取消和切走算进任务，比例才有东西可解释。注意步骤数很少（一共两步）时，确定条的分辨率不够，被试会觉得它在骗人——那是粒度问题，不是该退回不确定条。
边界
总量会在中途膨胀（发现压缩包里还有文件、服务端追加批次）时，确定条会倒退或突然变慢。倒退很伤，但换成不确定条等于放弃后来又稳定下来的比例；更好的是修正总量并保留已完成量，必要时加一句「发现了更多项」。总量只是服务器随口给的上限、经常离谱，确定条会系统性误导，这时应降级，并在能测真实进度时再升级。短到指示器都不该出场的操作，不必为了「必须确定」硬上一条百分之百闪过的条。
怎么落地
- 凡是能数的传输、队列、步骤，默认确定条；把不确定条当成「总量未知」的分支，而不是默认皮肤。
- 比例旁写单位：12 / 30 张图、已上传 40 MB，不要只给无单位的百分比。
- 总量修正时更新分母，避免条往回跳；回跳实在无法避免，要同时改文案。
- 验证：问正在等待的人「大概还剩多少」。答不出，而日志里其实有总数，就是该用确定却没用。