|
3.1. 多种方案的权衡
实现同一个目的，有多种不同的方案，每个方案，都可能在这个方面强一些，在另一个方面弱一些；实际使用上，它们的效果通常并没有非常明显的区别。
这是交互设计的另一项经验：如何设计不完美的作品。
又要易用流畅，又要屏蔽干扰项，又要方便用户随时切换，又要充实又要简洁……这种设计方案是不可能存在的，而为了产品和运营的目标,为了用户看似不合逻辑但切实存在的操作流程, 我们通常面临的需求正是这种复杂需求，同时往往伴随着名为“快速迭代小步快跑”之类的短工期。
这时，对不同方案的细节区分，各自有什么样的优劣，熟练于心，可以方便我们快速地决定一个或是另一个方案，而不是陷入长时间的纠结。(pm非要纠结则另当别论……)
如同这个机票查询的例子，各家的使用方法不同，效果也各有倾向(或者说，由于需要偏重的方向不同，而使用了不同的设计)：
大多数机票查询的入口，都是这样，单程/往返使用两个radio，放在最前面；选择单程时禁用往返，或者隐藏返程时间输入框。
逻辑是这样的：用户最先决定自己是单程还是往返，然后再选择起降地点及时间……这显然是产品逻辑，实际上绝大多数用户都不是一去不回，而是必须回来的。用户随时可能从买单程变成想买往返，而这时候再把注意力返回到页面最上方，又离的很远成为了负担。
不禁用返程，又担心用户被这个框干扰，影响任务往下走。
于是淘宝的版本是这样的，返程时间不禁用，只是视觉相对弱化；返程时间输入框获得焦点时，上方radio自动切换到往返。
同时，要回到单程状态……仍然只能手动通过radio切换。
这个控件组的作用，抽象地说，就是二选一的入口，分别对应不同的内容展示：两个radio/下拉列表/tab，都能起到二选一的作用。下拉列表鼠标操作次数太多，适用于更多选项的情形；tab带有两者平行且无交集的意味，所以这儿也不适用。
一种特殊的二选一，就是是否，是否需要返程，于是可以用复选框：
这时，用户在往返与否之间切换的成本最低。
这并不是说使用radio的方案不正确，只是在只有这两种情形的产品，使用复选框会更好一些，如果考虑扩展的情形：
视觉：栅格、用色、间距……
前端：代码逻辑、可实现性
产品：功能设计
用研：可用性测试
BI：数据挖掘……
同样也不展开说了，这些内容，对交互设计工作都会有相当的帮助，但也不需要精通，基本了解就可以。
|
