关于iphone、QQ通讯录、飞聊联系人排序设计的思考
目前，对于联系人的排序，如果不考虑对方的在线状态，一般都是按照音序排序的。所谓音序排序，也就是拼音字母的顺序：首先是按照整个拼音的首字母（26个字母从A~Z）的顺序排列，如果首字母相同，则依次按照声母顺序、韵母顺序以及音调顺序进行排列；
举个例子来说
如：
阿（a）
白（bai）：与阿相比，首字母b在a之后，所以“白”在“阿”之后；
包（bao）：与白相比，前两个字母ba相同，o在i之后，所以“包”在“白”之后；
本（ben）：与包相比，首字母b相同，e在a之后，所以“本”在“包”之后；
崩（beng）：与本相比，beng比ben多一个g，所以“崩”在“本”之后；
补（bu，三声）：与崩相比，首字母b相同，u在e之后，所以“补”在“崩”之后；
不（bu，四声）：与补相比，字母相同，不是四声，补是三声，所以“不”在“补”之后；
下面，我们来看一下iphone通讯录中联系人的排序：
左侧是字母分组及组下的联系人，右侧是音序条。音序条由从A~Z的大写字母和“#”构成，点击某个大写字母，可定位到相对应的字母分组及组下的联系人，点击“#”则定位到“#”组及组下的特殊字符和数字。
对于包含“音序条”的联系人排序，实际上是把所有联系人按照首字母分成了27个小组（26个大写字母组和一个“#”组），再在每个小组内进行排序，即组外按照大写字母的顺序排列，组内再按照音序排序；
这样分组的意义在于，方便用户快捷的找到某位联系人，比如：用户想找一位姓“李”的联系人，只需要在头脑中思考一下“李”的首字母是“L”，就可以通过点击音序条上的“L”,快速的将首字母为“L”的联系人组找出来；从而缩小查找范围，并减少从上往下滑动的时间和距离；
细心观察，还可以注意到这样一个现象，在iphone通讯录中的联系人，并不是按照昵称全拼的音序进行排序的，在每个字母分组下，根据首字符是中文还是英文，还分成了两个小组，英文昵称显示在前，中文昵称显示在后。英文之间或中文之间再按照全拼进行排序：
iphone通讯录：根据首字府区分为中英文两组
这样排序的原因是：不管中文还是英文，用户要获知其首字母，其实是需要用户在头脑中做有意识的转化的，比如，用户要找一个姓“李”的人，会现在头脑中想到“李”的首字母为L（或者lily的首字母为L），然后定位L，开始在"L"组下进行查找；
目标是中文还是英文，用户自己知道，如果按照中英文分开，用户一眼就可以锁定目标所在的区域，从而在中文或英文的范围内寻找，缩减了浏览范围；如果不区分首字符中英文，则用户必须在整个字母组下去通览一遍，目标范围较大，查找起来效率相对较低；此外，所有英文在一起，所有中文在一起，这种排序从排版上来说，利用了格式塔的相似性原理成组，视觉上也更加工整美观，利于浏览；
最后分析一下，iphone通讯录中把特殊字符放在最后的原因，常规的联系人都是英文或中文的名称，如果是特殊字符，很有可能是没来得及填写名称的联系人，或者是昵称比较奇怪的联系人，这类联系人相对来说数量会比较少，而且重要性程度可能不高，（如果高的话，用户应该会给他备注一个便于识别的名称，特殊字符的昵称本身不便于用户记忆），所以这类用户放置在最后也比较合理；
微信通讯录的排序
微信通讯录基本保持了iphone通讯录的框架，左边是字母分组和组下的联系人，右边是音序条。与iphone通讯录不同的是，微信在右侧的音序条上做了精简，如果通讯录中的联系人中不包含某个大写字母，则在音序条上不显示该字母，从而精简了音序条的数量，使得音序条更为简洁，操作起来也更加精准。但这样做有一个小小的弊端是，当用户的联系人从少向多增加时，右侧音序条上字符会不断的发生位置变化，不利于用户形成的位置记忆；
Sonar上联系人的排序
Sonar的音序条和分组比较特别，它并不显示昵称的首字母，而是显示昵称的首字符，这样对于中文来说，省去了把首字符“李”转化成首字母“L”的意识转化成本，但这却面临一个更大的问题，中文通讯录的姓氏往往比26个首字母更加多样，26个首字母排列的时候密度就比较大，一旦用户的好友的姓氏超过一定的数目，右侧必然会无法显示全部的好友的姓氏，对此，sonar的解决方案是，根据姓氏排序，然后按照可显示的数目，按固定间隔提取姓氏并显示出来，比如左侧显示“阿”“曹”“朝”“车”“陈”，在右侧音序条上就只按间隔显示了“阿”“朝”“陈”，中间间隔的“曹”和“车”就被省略了。
当通讯录中好友较少时，这种形式的查找效率是非常高的，因为减少了用户的有意识转化，一旦通讯录中好友增多，这种形式就非常不利于用户的查找，比如用户要查找某个姓“曹”的好友，可是该好友的姓氏却并未显示在右侧的“音序条中”，用户还需要反应该好友应该挨着哪个姓氏，这种有意识的转化难度比仅仅转化姓氏的首字母难度更大，耗时更久，因此效率更低；
和iphone通讯录还有一点不同的是，sonar将特殊字符的昵称显示在最前面，这也是不可取的，前面我们讲过，特殊字符可能会是因为昵称比较特殊，或者没有存昵称而造成的，这类联系人通常都不是特别重要，放置于前面，会增加用户每次从上到下的浏览负担。当然，也不是说，特殊字符就绝对不能放置在前面，这跟产品策略也有一定的关系，如果产品提供了修改昵称的功能，且希望提醒用户去为联系人设置昵称，就可以将其放置在前面，有助于提醒用户去为他设置一个常规的昵称，如果放置在最后，可能用户就会忘记要为他设置了。所以如果产品本身提供了修改昵称的功能，是可以让特殊字符显示在前的，方便用户修改，但是如果产品本身没有提供修改昵称的功能，则还是建议将其显示在后方，因为它会增加用户的浏览和滑动负担。
QQ通讯录联系人的排序
iPhone自带的通讯录本身存在着一个问题，因为右侧的音序条包含26个字母、搜索和代表特殊字符的#，使得整个音序条在纵向上排列特别紧凑，当用户使用音序条的时候，拇指置于音序条之上，会完全盖住对应的字符，使得用户无法准确的知道当前自己所处的位置，用户必须将视觉焦点移动到左侧的字符分组或联系人上才能判断大概的范围，由此造成了操作区域和焦点区域的分离，在此基础之上，QQ通讯录做出了一步改进，那就是在屏幕中间给出了拇指摁下的字符，相对于左侧的字符分组来说，中间的字母分组离操作区域更近，显示也更加明显，使用户能够精确的知道当前按下的位置；
表面上看QQ通讯录似乎解决了通讯录的精准定位问题，但进一步分析，我们可以发现，这种改进仍然没能够起到帮助用户快速查找联系人的作用，举个例子，如果用户想要查找一个叫“刘林”的好友，用户需要先反应"刘"的首字母“L”，然后通过在“L”组下再去寻找“刘”，而“L”组下可能有十几个姓“李”的用户，（李是中国的大姓，通讯录中姓李的一般都比较多）还有“蓝”“兰”“梁”“郎”“刘”“吕”“罗”等姓氏，用户仅凭第一反应，是很难区分这些姓氏的排序的，所以基本上只能在“L”组下从上至下浏览，直到找到姓“刘”的好友为止，最后再在姓“刘”的好友组中寻找“刘林”；
此外，这种布局还有一个问题，那就是用户按下的的字母，和字母显示的位置距离太远，即：操作区域和反馈区域距离太远。当用户操作右侧的音序条时，中央凹的注意力就集中在音序条上，屏幕上任何不在点击位置1~2厘米举例内的东西都处于分辨率很低的边界视觉内，由于反馈区域是运动的（从无到有，且有变化），所以我们很容易将注意力又集中在中间的反馈区域上，这里也存在一个注意力的转移问题，虽然代价很小，当相对于iphone键盘字符放大的设计来说，还是略有不足。
Iphone键盘放大的效果
飞聊在QQ通讯录的基础上更进一步，中间不再显示当前按下的首字母，（首字母其实在页面左侧是包含的，如果中间是首字母，那么屏幕左侧、中间和右侧都是大写字母，也有累赘之嫌），飞聊中间显示的是姓氏的“首字符”：如果是英文昵称，则首字符是英文的首字母，如果是中文昵称，则直接显示第一个汉字，无需用户做再次转化。
同时，当用户手指移开音序条在整个列表中滑动时，页面中间也会显示相应的首字符，方便用户在滑动过程中快速而精准的定位；
飞聊联系人的排序
总的来说，在iphone通讯录的基础上，各家的设计师们也都在积极的推陈出新，就目前而言，我觉得飞聊在音序条上的设计还算是比较完美的，欢迎大家拍砖，探讨更好的排序形式~~
