Vol 7 应用市场规则大更新、UI基础第一篇-字体系统
😄这些产品有新的动态：
🔨来自应用商店的变化
Google Play
为了使商店评分更具参考性，Google计划在今年11月调整应用的评分展示规则。以往对一个应用的评分，是累计所有国家地区的综合评分。修改后将根据用户所在地区，展示相关评价计算出来的综合评分。改动后的评分可能更据地区参考性，对当地友好性更高的应用，将获得更高的评分。
除此之外，Google还在考虑引入「设备信息」因素，对手机、平板、折叠设备也实行类似的计算方法。计划在2022年初上线。
App Store
苹果这周发布了针对应用商店的规则更新，大部分针对小型开发者，这些都缘起来自一项集体诉讼。结果上除了保留针对小型开发者的佣金抽成折扣，还包括以下重点：
- Apple将允许开发者向用户介绍在iOS App之外的购买选项，且App Store以外的任何购买均不需要向Apple支付佣金；
- Apple还将把开发者的付费价格点数量从少于 100 个扩展到多于 500 个，开发者拥有更多的定价自由；
- App Store搜索改善；
- 保留App申请复议的选项；
- 公开App审核机制的详细数据等；
熟悉Apple支付生态的开发者应该能意识到，第一条改动的意义。目前的提案还需等到法官的批准，批准后，我们将在不久的将来看到这些变化。
虽然看起来改动很大，但并非所有人都满意。Spotify表示：以上措施并没有实际性解决反垄断的任何问题，这些举措知识用来分散政策制定者和监管机构的注意力，减缓世界各地要求纠正他们反竞争行为的意愿。
🎵抖音 & TikTok
抖音正在内测社交卡片推荐：用户在刷短视频的时候，有一定几率随机刷到其他用户的「社交卡片」，卡片会提示该用户关注了你，可以选择是否回关。
同时在短视频页面顶部，增加了线上多人聊天功能，最多支持4个人的「小群聊」，并支持邀请好友加入。
海外版抖音：TikTok，在美国地区开始内测AR工具，对标FB和Snap。另外，其正在灰度逐步放开视频长度上限到5min。
在电商业务上，TikTok终于开启了内测，将允许用户在个人主页开设商店，用户可以从美国/加拿大等地选品，而其他用户可以直接在应用内完成购买流程。
FB增加了源自Messenger的语音和视频通话功能。虽然名为减少用户在两个应用之间切换的麻烦，但其实这是近期FB对旗下产品整合计划的一部分（计划从去年instagram和Messenger实现互通开始，whats app也在计划中）。
对这项计划有两项比较普遍的猜想：
- 让美国政府的监管机构难以拆分公司模块，阻止反垄断诉讼中强迫要求FB取消对当年ins和whatsapp的收购
- 来自Tiktok的分流压力，将所有用户尽可能集中在一个生态中。
📮Whats App
Whats App上周发布了桌面版的客户端，同时支持了Windows和Macos双平台。这是其多设备支持计划2.0的其中一步。对了，for iPad客户端也正在路上了。
在体验上，正在内测类似iMessage的reaction，如果被灰度到了，需要升级到最新版即可体验。
- Twitter开通了正在内测的Communities（圈子功能）开通了官方账号，看样子大范围内测不远了
- 继iOS之后，在安卓客户端上，会员服务Twitter Blue也开始有入口了。会员服务当前仅在加拿大和澳洲两个地区小范围内测
- 在Twitter Space功能上，经过一段时间的内测，iOS的主持人们可以正式为观众选择入场票价了
💭What‘s more
- Notion正在内测支持中文语言。
- Instagram计划下线创新性交互「Swipe up links」，计划以链接贴纸的方式替代。但是，这项功能依旧只对粉丝数超过1万或认证用户可用。
- iOS15中，iCloud支持自定义域名，目前仅对开发者开放，如果你是，可以到这里尝试。
- Spotify的的播客付费订阅功能，向美国播客创作者全量开放。
- Netflix的游戏订阅服务，在波兰开启了首轮内测，当前仅限安卓用户参与，且只有两款游戏
- 支付宝推出针对视障用户的「划一划」密码：用户可在支付宝安全中心提前录入一个图形，需要输入密码时在屏幕划出相应图形即可，解决以往密码被朗读或输入慢等问题。整体方案简单但有效，建议体验。
- 夸克App推出夸克网盘，连续包月会员5元/月、大学生0.99元/月（安卓端）。可以享受文件格式转换、文档扫描、超级视频播放器等智能工具，以及大文件上传、云收藏、云解压等服务。
- 阿里家居应用「躺平」，更新品牌名为「每平每屋」。
✨值得关注的新产品
😈BUD
关注元宇宙概念的小伙伴可能知道这个产品，从版本记录看，已经推出相当长时间了，所以内部设施和内容相当完善。体验下来非常惊讶里面的用户的创造力，建议关注。同时这里简单分享下，作者接触到的现在市面上对元宇宙的理解和派别：
- 由硬件支撑，从体验上突破现实和虚拟边界的，以facebook为代表，应用是上期我们提过的Horizon Workrooms
- 从模式创新，将3D技术应用到App中，典型场景是build个人作品，每个人形成自我的「元宇宙」，以Roblox为代表，Bud更接近这个解法
- 由概念包装，线上体验是线下的一一映射，以Gather为代表
- 由Crypto为支持，基于区块链的技术
💳dot. cards
dot.是Linktree的实体版，两者解决的需求有点类似，社交媒体往往会屏蔽竞品的跳转链接，如果要向外引流，就需要依赖其他服务。linktree提供的就是聚合社媒账号的功能，而dot.提供的实体版方案，更偏商务场景。
👀UI里的字体系统（Typographic System）是什么？
前言：上一篇提到了推特团队新字体Chirp上线后遇到的一系列显示问题，然而对于大部分设计师来说，还不至于要为APP设计一款新的显示字体。那么如何将已有的字体在产品中运用好？
这系列文章来自Medium，Priyanka Godbole（Facebook的product designer）记录的为一个健康信息网站重新制作设计规范的过程，网站涉及大量可视化数据，是研究字体排版的好样本。以下不是完全直白翻译，而是参合了我个人的一些思考和简化，附上原文传送门。
改版第一步：整理现有产品的字体语义层级和视觉层级
如果你是为一个现有产品进行设计优化，首先要做的就是整理现有的字体层级。作者使用了Chrome插件审查原有的EHR网站，使用假数据填充丰富网页查看所有现有字体样式。作者发现原来网页居然有多达51种样式（包括颜色和字重在内）。可以想象如此混乱的样式会给设计师和工程师在实际使用中带来很大的负担和困扰。
仔细看上表，作者最终把字体变量缩减到了6种，5种header和1种正文字体（段落、列表、链接、提醒、占位文字）没有将颜色纳入变量是因为正文字体只有在作为链接是蓝色，错误提醒是红色，占位文字是灰色，其它情况下都是黑色。而标题大多数情况下都保持一个字重，特殊用法再特殊定义）
再来看语义审查，在老的设计中，每个页面页头是H5字号，然后页面内使用了H3，但H3下内容里的表格却用了H4。理想地说，是不应该发生这样的跳级的。
在视觉层级上，我们主要关注字体的字号和字重。可以看到整理出来的老系统里多达9种header，然而产品并不需要如此复杂的信息层级，这显然是个欠缺考虑的决定。特别是对于APP来说，每个页面的信息量更加少，遵循一个步骤做一件事的原则，我们应该仔细考虑页面的信息重点给予突出，而不是给每一个小细节都加上粗体。
改版第二步：从正文字号开始
在了解现有问题后，作者从正文字体开始了这次字体系统重设计，因为这个字号在网页里表现得不错，阅读体验也挺好，所以以它作为一个良好开始。在网页上，10pt是最小可读字号，约等于13px。我比较赞成从正文字号开始设计字体系统是因为它出现频率最高，而在APP上由于手机分辨率越来越高，即使是10pt英文字体也是看的清，但是要尽量避免这种在可读性上打擦边球的行为，而且随着屏幕变大和考虑到适老化，正文字体建议不要低于14pt。许多主流阅读类APP正文都在15~16pt左右。
改版第三步：为基础字号制定行高
作者通过填充数据，反复体验得到了13号字的合适行距20px，测试数据基于8px/4px的倍数。
此时20px行距并不满足作者原先制定的8px的网格系统（网格系统是为了保证UI间距上的视觉延续性）但是作者却没有因此改变策略。对于更小，需要紧凑间距的字体系统、icon采用4px作为基本距离单位，而整体模块布局则采用8px作为基本距离单位，提供更可辨识的UI层次。说到底，设计系统是为了减少视觉不统一和更简单的执行。
合适的行高需要通过多次体验来确定，不同平台上的体感也不一样，网页字体一般比APP要有更大的行高（考虑到阅读距离和屏幕大小）
第四步：从正文字号通过比率缩放得到其它字号
基础知识：
比率缩放工具 - Tim Brown’s Modular Scale：https://www.modularscale.com/
Rem - 相对单位比例，例如网页默认1rem=16px，那么1.5rem= 24px
作者通过20/13得到目前字体系统比率1.538，缩放后发现由于比率过大导致字号分散，可用字号太少
为了保证20px依旧在新的比率上，选择了1.538折半后的1.25比率，这样既能维持行高垂直空间上的节奏又能得到一个更为紧凑的字号区间。
第五步：重新梳理页面语义
基础知识：
Header - HTML中的标签，用于定义文档的页眉（介绍信息）
在从上一步得到有效的字体中选取合适的实际应用到页面中，在旧官网上，每个页面页头是不统一的。有些是16px <header 1>,有些却是32px <header 5>，为了连贯使用header 1，作者统一制定了24px <header 1>作为每个页面标题。
第六步:制定你所需要的header数量
根据信息复杂程度决定我们需要多少种header，值得注意，即使是EHR里信息密度最大的一个页面也没有使用超过5种header，普通的页面3种header就够了
第七步：为字体系统里的所有字号制定行距
通过最初的20/13得出的1.538比率等比例得到每个字号的行距，通过网格系统筛选出合适数值。（下图）
可以看到Teambition的Clarify Design里（下图），20px以下中文字号比例是1.125（递增为2px）， 20px以上的较大字号则是1.25(递增为4px）。也符合越大的元素需要更大的间距去区分的常识。最后的设计可以根据最后实际场景和用途进行调整，避免一些含糊的字体层级。
第八步：为每个header制定字重
选择合适的字重，既不能容易被人忽略，或是太突出显得不平衡
第九步：将字体系统运用到网页页面上
基础知识：
HTML DOM ：文档对象模型 - 当页面被加载时，浏览器会创建页面的文档对象模型（document object model）,是中立于平台和语言的接口。
因为这次涉及我不熟悉的代码知识，建议感兴趣的直接查看原文。总之就是借助DOM，保证页面的语义和视觉上的连续性。
总结
遵循以上过程
- 你可以轻松排除那些冗余不重要的视觉信息
- 你团队里的设计师会知道如何去使用字体，不再存在认知混淆
- 同理，工程师通过已有标准能加速开发进程，而不用一遍遍去审查设计稿
对我来说：
在从0到1做一个产品的时候，设计师每天需要做许多决策，间距多宽，字号多大，按钮多高等等，这些细小零碎的决策最终会决定整个APP的质感。这些决策并非拍拍脑袋就能做出，结合理论知识可以帮助我们更快地做出决策。
同样，当APP已经到了稳定迭代的阶段，设计师一定要尽早系统地去构造产品的设计系统，不然问题会随着时间积累，渗透到每一个页面，UI上给人参差不齐的感觉，同时还会影响迭代的设计效率。
制定一个完善的设计系统还能让后来参与的设计师能很快接手工作，以及节约开发和测试的时间。