| layout | title | permalink |
|---|---|---|
page |
设置 |
settings.html |
应用设置允许用户选择他们对应用行为的偏好。它们授予用户真实的控制感，并且避免用户被同样的问题反复打扰。
由于用户并不需要经常使用设置，所以它们在UI中并不显眼。应用中访问设置时：在任何情况下，进入“设置”的按钮都应简单命名为“设置”。如果当前的页面支持左导航栏，那么把设置放在导航栏中除“帮助及反馈”外的所有按钮的下方。另外，如果当前页面里有工具栏，把设置放在工具栏的更多操作（action overflow）中除“帮助及反馈”外的所有按钮的下方。
当用户访问设置时，尽管这不太频繁，但他们对这个页面抱有与其他页面一样的期待。这个页面应该是组织良好且符合常规的。需要特别指出的是，它应该避免用过多的选项淹没用户。遇到产品上简单的决定时，避免向“就把它作为一个设置吧”的诱惑所屈服。对于每个你考虑放入设置里的控制，通过下列问题来确保它合适：
- 这确实是一个用户偏好吗？信息和操作不是一个用户偏好。如果不是用户偏好，就不要把它当做一个设置。如果它是应用的静态信息（比如版本号、服务条款、开源证书），将它组织到一个帮助页面里。如果它是一个操作（比如刷新、切换账号），在你的应用的主要流程中为它找一个合适的位置。
- 这个选项经常被用户更改吗？用户每次访问这个选项要多次操作会觉得负担重吗？如果是这样，不要把它作为一个设置。可以通过把它放在工具栏或者更多操作（action overflow）中，让这个控制更容易使用。
- 只有少于20%的用户改变这个设置的值吗？如果是这样，不要将它作为一个设置。不管是新的还是本来就有的设置，都应该问这些同样的问题。
- 对于已经存在的设置，最后一个问题应该多考虑一些：如果这个设置项被移除了，这会对那些不再能改变这一设置项的少数用户造成危害吗？如果会，或者你不清楚，那么合适的做法是将它作为一个设置项保留。
当你有很多设置项时，最好通过分组来把一个长列表变成几个短一些的列表。设置项的数量决定了分组的策略。
不需要分组。
试着用1到2个分隔符分隔相关的设置项。如果存在“独立设置”（与其他设置项无关并且不能放进已有的分组中），如下处理：
- 如果是一些你最重要的设置项，把它们放在最顶上，但不用分隔符分隔。
- 否则，将它们按重要程度的顺序排序，放进末尾的“其他”分组。
建议同上，不过试着用2到4个分隔符。
如果存在“独立双选项”（两个互相相关的设置项，但与其他设置项无关）。试着将它们合并成一个设置项。比如你可以把两个相关的复选框重新设计成一个多选设置项。
如果你有四个以上的相关的设置项，把它们分在一个子屏里。对于每个子屏使用上面这些建议。
用户通常期望每个设置项都有合理的默认值。以下问题可以帮助你做决定：
- 在没有默认选项时，大多数用户最有可能选择的是哪个？
- 哪个选项最中立或最中庸？
- 哪个选项风险、争议或言过其实的可能性最小？
- 哪个选项用的电量和移动数据最少？
- 哪个选项最尊重用户的注意力，只在最重要的时候打断用户？