移动产品基础模块设计规范之表情（颜文字）键盘
最近的工作中略有涉及一些表情键盘的相关工作——我们的产品在2.2.1版本新增了自定义表情键盘，在这个过程中，我略有一些思考和体会，分享给大家！
一、表情类型的分类
1、从表情版权方面来看，有三种类型：第三方、自定义或者购买
（1）第三方表情
第三方表情字符大多采用 Emoji 表情。绘文字（日语：絵文字/えもじ emoji）是日本在无线通信中所使用的视觉情感符号，最早由栗田穰崇（Shigetaka Kurita）创作，绘意指图形，文字则是图形的隐喻，可用来代表多种表情，如笑脸表示笑、蛋糕表示食物等。
并且 Emoji Unicode 编码为 E63E 到 E757，而在 Shift-JIS 编码则是从 F89F 到 F9FC。自苹果公司发布的 iOS 5 输入法中加入了 Emoji 后，这种表情符号开始席卷全球，目前 Emoji 已被大多数现代计算机系统所兼容的 Unicode 编码采纳，普遍应用于各种手机短信和社交网络中。
感兴趣的话，大家可以通过这个网站，详细了解 Emoji 的具体内容。会有不少收获的，比如 Emoji 针对不同的平台、甚至是不同的产品订制表情、供其使用。你还会发现 Android 的表情竟然比 iOS 的多近 300 个；不过这并不影响公共部分（约2100个）的使用，其实大多数系统以及应用都会选择通用的近 200 个表情，作为常用表情。
（2）自定义表情
自定义表情，大多是企业针对产品，自行设计表情，供用户使用（付费使用），比较成功的是 Line 的模式。
（3）购买版权
并不是自家公司设计，而是向他人购买版权后植入到产品中。具体说，微信中的这几个表情就是微信向他人购买的。直到现在还很火。
2、从表情的表现形式上来看，有两种类型：静态和动态
很容易理解，就和字面意思一样，分为动静两种状态。
相较静态表情而言，动态表情有更好的扩展性和趣味性，更能促进人与人之间的交流和沟通。
二、表情键盘的分类
顾名思义，与文字键盘类似，表情键盘就是能够输入表情，并发送给他人，促进交流、沟通，也能表现自己的思想、心情等等。
根据我自己的观察，我把表情键盘氛围四种类型：系统键盘、第三方输入法键盘、自定义键盘以及混合键盘。
1、系统键盘
你一定会用到系统键盘，比如 iPhone 的或者 Nexus 5 的。另外，Android 厂商也会自定义系统级的键盘，比如华为、小米等等。
2、第三方输入法键盘
这个我用的比较少，用过的比如百度、搜狗的输入法，中都会带表情键盘。
3、自定义键盘
这种类型的产品很多，大多是应用级的，比如下面（三中）提到的。严格意义上来说，第三方输入法键盘也是在应用级上的自定义键盘。
4、系统和自定义混合
这种类型，我目前看到的不多，只发现微信一家是这样。微信应该是获取了系统的表情位置（或者是用户的使用数据引起的），将其放到自定义的键盘上；并且，自定义键盘中包含微信自家的表情。
三、表情键盘产品解析
就像上面第二部分所描述的，我将表情键盘分为两大类：系统级和应用级。
1、系统级
iOS 下的 iPhone、iPad 等产品；Android 下的各种产品，Google 的产品、第三方手机厂商、Pad 生产商等等。
2、应用级
应用级别，各个应用。比如：
- 输入法应用，如百度输入法、搜狗输入法…
- Facebook Messager、WhatsApp、Skype、Line、BearyChat…
- 手机QQ、微信、微博、钉钉、荔枝fm…
四、如何规划自定义表情键盘
- 确定产品（功能）定义和定位；
- 规划产品（你懂的）；
- 开发评估（特别是字节、存储相关）
- 找到符合定位的表情；
- 设计阶段（排版、输入、展示等）；
- 实现阶段（开发）；
- 测试阶段（针对以上进行测试）。
以上是大致的过程，具体的规划我接下来分开讲一下。
1、确定产品（功能）定义和定位
首先，在早期版本中，我们的产品有提过在发布内容描述以及评论中增加系统表情支持，但由于前任产品在这方面和开发沟通不畅，结果是没有继续往下推进。处理的结果是，客户端以及服务端对表情字符做了阉割处理——完全限制输入。
然后，在2.2.1版本规划前，我做了简单的测试。由于客户端以及服务端限制有漏洞，我巧妙的避开了规则，发布了带表情的内容，效果还不错，有很多用户用表情字符跟进评论。
最后，考虑到系统表情、第三方输入法的使用体验不太顺畅。另外，考虑到用户常用表情的问题。所以决定增加自定义表情键盘。
2、规划产品（你懂的）
这部分基本上是我们常涉及到的内容，比如竞品分析，主要是逻辑、交互、UI等方面的分析和规划。和运营沟通过之后，我们暂时决定不对表情字符进行分组。结合对其他产品中常用表情字符的分析，以及当前产品运营提出的建议，这个版本选了81个在 iOS、Android 等平台常用的表情。排版和布局的方案由设计师解决了。
3、开发评估
这里主要的问题是字节、存储相关，涉及到产品对输入字数的要求；客户端对文字、表情字符转码的要求（比如一个表情字符是多少个字节的问题，这关系到客户端输入的限制）；服务端的最大以及最小输入限制；表情字符是在客户端还是在服务端；表情字符之间的命名规则以及对应方式等。
4、找到符合定位的表情
这部分试运营童鞋帮我解决的，我没有他们感性，也没有他们了解用户，所以由他们协助是最好的。我提供了 Emoji 的官网，他们来帮忙。
5、设计阶段
这部分主要涉及排版、输入、展示（输出）等相关问题。具体涉及到：自定义表情、系统表情、输入文字之间的比例关系、对其关系，前面提到的针对适配的设计；表情图片的处理等。
重点提一个问题，有些产品中，特别是在评论的时候，表情字符的出发控件是在输入内容的区域的，原因是实现系统输入法和自定义输入法之间的切换；当然，也可以做到系统输入法的上面，自定义表情键盘控件也在这一栏中，这是普遍的做法。早起网易客户端的处理方式就是在输入内容区域的。
6、实现阶段
到这部分，你会发现，问题已经很少了。因为在准备的阶段，就基本上把该想到的问题，都考虑到了。
7、测试阶段
等着测试大大怼产品可开发就可以了，其实，并不是。测试在没有进测试阶段的时候，就已经针对需求给出了自己的意见和建议，当然，都是结合在前面的过程中的。
最后
规划过程中需要注意的问题，主要有：
1、是否需要分组
对比三中的产品，你对发现大多数都是有分组的，原因在于：一是表情多；二是减少用户的认知难度；三是方便操作。大家可以对比下微信表情思考一下，或许你还能想到更多。
2、如何布局与删除表情
这涉及到表情在客户端的适配问题，特别是结合删除控件。观察中发现，删除控件多会在最后一排的最后一个表情位置，这会给表情布局带来一定的开发难度。不过后来思考中认识到，这个难度并不大，其实就是对表情进行分页控制，并且把删除控件放到最后一个位置就可以了。但会增加开发在计算方面的工作量，体力活比较多。
3、翻页展示位置
和上面2的问题相关，需要结合删除控件一起思考。主要是在布局、UI等的问题方面。
4、表情在本地还是客户端
一般情况下，表情字符是会在客户端的，即便是在线的表情，也是网络获取后存到本地的。数据库中存下的只是这个表情的名称或者对应的编码，从而为在另外的设备中进行解码查看提供找到本地表情的“钥匙”。
5、表情编码以及字符问题
名称或者编码需要控制，尽量不要占太多位。本次规划中，和开发沟通后，通过名称（iOS 和 Android 命名规则相同）作为关联，每个表情字符占12位（按 utf8 即 4个汉字）。
6、表情命名问题
命名后要考虑结合输入汉字与系统表情的情况下，输入框对应的数据字段存储能力（考虑客户端以及服务端），比如客户端的最大输入限制，服务端最小输入限制以及最大输入限制。
这么考虑有两个原因：
- 产品需求；
- 安全考虑。
推荐阅读： 《表情经济学：表情的背后是什么？》
题图来自 摄图网，基于 CC0 协议
文/郑几块
关键字：产品经理, 产品设计, 表情
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
