移动产品基础模块设计规范之表情（颜文字）键盘

最近的工作中略有涉及一些表情键盘的相关工作——我们的产品在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、表情命名问题

命名后要考虑结合输入汉字与系统表情的情况下，输入框对应的数据字段存储能力（考虑客户端以及服务端），比如客户端的最大输入限制，服务端最小输入限制以及最大输入限制。

这么考虑有两个原因：

1. 产品需求；
2. 安全考虑。

推荐阅读： 《表情经济学：表情的背后是什么？》

相关阅读

移动产品基础模块设计规范之注册登录

移动产品基础模块设计规范之意见反馈

移动产品基础模块设计规范之应用缓存

移动产品基础模块设计规范之应用更新

 

题图来自 摄图网，基于 CC0 协议

本文由人人都是产品经理专栏作家@ 郑几块   原创发布于人人都是产品经理 。未经本站许可，禁止转载。