做产品，我为什么如此小题大做：界面给了“选择”，就该兑现选择的承诺
如果一个页面给你一行“上传位置”，右边还有一个可以点开的箭头，你会期待里面有什么？
我会期待：打开以后，能找到自己想放文件的地方。
在打磨 FooCloud 的 iOS 分享上传时，我就卡在了这件事上。从其他 App 分享文件到 FooCloud，需要决定文件上传到哪个远程目录。当时，目标位置的候选主要来自最近使用记录，没有记录时，选择余地就更小。
它看起来提供了选择，却没有提供完整的目录浏览。想放进一个从未用过的文件夹，眼前的入口帮不上忙。
我的反馈很直接：要么把远程位置的选择做完整，要么就去掉这个选择组件，明确使用默认位置。卡在中间，让人别扭。
这听起来像是在要求“多做一点功能”。但我真正介意的是：一个入口长什么样，会影响用户以为自己能做什么。
图 1：产品承诺的概念对照，非产品截图。左侧是讨论用方案；中间概括旧版限制；右侧概括当前结构。
如果产品只支持固定去向，写一句“将上传到：收件箱”，是一个完整的表达。用户可以判断这个去向是否接受，再决定要不要继续。
一旦把它做成选择器，问题就变了。用户会尝试更改，会寻找新位置，也会根据这个入口规划后面的操作。
等到他已经打开入口、开始找目录，才发现这里只有最近几项，缺失的就不只是一个候选。此前形成的预期也要重新调整：是不是找错地方了？能不能换目录？是不是要先退出，再去主应用里设置？
这些疑问原本可以由产品把边界说清楚。
这里还有一个容易混淆的地方：最近使用记录当然有价值。它省下重复浏览的时间，尤其适合总往几个固定目录里放资料的人。
只是，“最近去过哪里”和“现在可以去哪里”回答的是两个问题。前者可以帮人抄近路，后者决定这条路是否真的通往目的地。
所以，FooCloud 后来的调整，是保留最近位置，同时补上完整的目录选择：可以查看自己有写入权限的远程位置，继续进入子目录，再确定上传去向。
这里的“完整”有明确范围。有权限写入的地方才应成为上传目标；一个只读目录，即使看得见，也不能因为界面承诺了选择就假装能写进去。
图 2：按当前交互绘制的流程示意，非产品截图。目录名为示例；最近位置作为独立快捷入口。
做完整选择，也不意味着每个人都要先逛一遍目录树。
存在可写的默认位置时，当前面板会先选好这个去向。不需要改的人，可以直接继续；想调整的人，再点开去向；经常去同一个地方的人，可以用最近位置加速。
这符合渐进呈现的思路：先让常用路径保持简单，把更完整的选择放在需要时展开的层级里。前提是入口足够清楚，后续能力确实可达。关于渐进呈现
“默认值”和“选择权”因此可以同时成立。默认值替人省下一次决定，选择入口则给不适合这个默认值的人留出余地。
我觉得这也是一个值得区分的产品判断：为了让第一屏简单，可以把内容分层；但如果用户需要的能力根本不存在，仅仅把入口做得简洁，并没有解决他的问题。
当然，补上目录浏览，也带来了新的责任。
目录可能很深，名字可能相近，网络也可能让列表暂时加载不出来。选择过程中需要知道自己在哪里；回到上传面板后，需要能核对最终去向。否则，选项虽然多了，用户仍然可能不确定文件会被送到哪里。
所以，选择器的价值不能只数“支持多少个目录”。更值得看的是：想用默认值的人能否继续，想更改的人能否找到目标，更改之后能否确认结果。
如果产品定位就是一个固定收件箱，我仍然认为清楚说明固定位置是成立的。一个明确的限制，往往比一个超出实际能力的入口更容易理解。
而 FooCloud 这次选择了支持浏览，我就希望把这份选择兑现到用户真正需要的那一步。
以后再看到一个下拉框、一个箭头、一个“更改”按钮，我会多问一句：点开它的人，预期接下来能完成什么？
界面已经作出的承诺，产品应该接得住。