[自译]设计模式和起源

原文地址：Design Patterns and Sources

原文作者：Ana Oliveira

设计模式是一种问题在大多数情况下的解决方法，避免去重复造轮子。作为UX设计师，我在设计界面的时候会频繁地去使用它们。当整个世界都在通过一种方式来操作某个功能，改变它通常意味着用户不知道如何去使用它。这也是为什么不同的行为组件，在使用中会产生摩擦。例如：“一个下拉列表页可以是carousel吗？”-我可能不会这么做…错误的使用设计模式会弄出奇异的组件。同样的，当一个新功能在几个场景下被广泛使用时，这也会创建一个新的模式。

在发展的过程中，去了解组件的行为是非常重要的，确保模式能过被正确的使用。我们甚至会注意错误的组件库，因为有些行为并不是根据设计模式设计的，它不是通用的，开发人员会错误的实现它。

命名问题

我曾经听过下拉列表（dropdown list）被叫做组合框（comboboxes），工具提示（tooltips）被叫做模态窗（modals），勾选框（checkboxes）被叫做闪烁（twinkles），按钮（buttons）被叫做图标（icons），单选框（radiobuttons）被叫做勾选框（checkboxes）…这样的例子还有很多。有时候这些不同是因为用户对模式的理解，来自于开发人员对库中组件的命名，这个和设计人员在模式组件中所理解的不同。当然，一个组合框可以被写成下拉列表，但是它们是不同的设计模式，应该表现的不同。当你有疑惑的时候，去设计模式的库中看看组件应该如何工作，或从了解设计模式的人那里得到意见。

最佳实践

只给出组件的正确使用方式是不够的。好的组件结合会让界面操作起来更加平滑。UX设计师在选择的时候总会给出合理的建议，不然很可能错误地使用。

我会列举出一些我知道的界面建议，这可能对你会有帮助：

1.哪儿都是默认值

在可能的地方使用默认值。至少有一些用户已经有了他们自己的选择。最差的情况是用户去修改它，如果你把字段空着也会有事情发生。

去选择下拉列表中的选项也是很好的实践。当它不太会有默认值的时候，留下一个输入提示，而不是空字段，就像下面这样。

2.总是让用户知道他们在哪

用户很容易就迷失，选项菜单应该很容易被发现。

在页面层级很多的地方，使用面包屑导航来帮助用户了解当前的位置。

3.组件选择

当你在一个地方有两个选项的时候，radiobuttons可能是最好的选择。

如果你的选项超过了5个，那么你最好选择的是下拉列表。

如果选项超过50个的时候该怎么办？可能你需要选择一个组合框去快速找到正确的选项。

当你有会改变的字段类型，它首先应该符合当前的场景，然后再去适应。

4.列表和数量

在列表中的数字更容易阅读，让他们右对齐的时候，然而，文本应该做对齐。作出不同的调整可以帮助你提高可读性。

你可以自己看看：

顺便说一下，别忘了按队列排序。

5.调整数字

当你处理数据的时候，你知道这可能会成长到上千上万，为数字做好准备。这意味着什么？你需要避免一个大的数字像是这样：

2.112.123（试着大声读出来）

2.1kk，这是不是更好？

当处理这些的时候，你可能需要去对数字进行扩展，但是我相信大多数的时候，用户只是想要一个大致的数字，对数字作出调整可以帮助节省界面的空间，同时增加可读性。

6.无限滚动和页脚

永远不要将这两种混合在一起。如果你想要同时表达这两个，最后只会是一个令人沮丧的结果。在很多情况下我都喜欢无限滚动，但是会忘记页脚。如果你需要加一个页脚。使用分页来替代放置一个“更多”的按钮，在每次的加载后。

7.查阅设计模式的起源

这是一些我目前设计模式的来源，当我有疑问的时候，最适合的一个组件操作是什么，或者是想要获取一些灵感：

http://ui-patterns.com/patterns

http://www.welie.com/patterns/index.php

https://www.pttrns.com/

http://www.mobile-patterns.com/

我希望这些工具和技巧，可以帮助提高一点你的产品体验。你可以去寻找更多的设计模式库，如果你感兴趣，并愿意去挖掘更多的话。这些都是我用得最多的，在这里添加评论，贡献你的经验，也可以解决一些常见的错误使用。