大设计
我就喜欢在晚上看书怎么了？
Aug 10, 2020
交互维度，阅读软件如何适配DarkMode<!--more--> 内容导航： · 现状以及和其他产品的区别 · 落地过程中遇到的一些问题和思考 1. 深色模式or夜间模式 2. 阅读软件的特殊性 3. 阅读背景和系统状态的关联和冲突处理 4. 内嵌h5的处理思路 · Darkmode可能带来的坑和落地注意事项 自从iOS13推出darkmode之后，已经有很多文章对于深色模式做了介绍，相信大家也看了不少文章甚至于已经有了自己的一套最佳实践，这里分享下在交互维度我们的思考和实践。 iOS13+覆盖率越来越高，iOS14马上推出。也许之前还抱着只是在尝鲜的各大产品，在顶流产品的微信适配DarkMode之后，可能马上就坐不住了。**对darkmode的支持极有可能成为以后产品的一个基础能力**，而与之对应的Android 10也支持了系统级的夜间模式。在这样的大趋势下，没有支持的产品在整个夜间体验上将变得得越来越不合群。  ##现状以及和其他产品的区别 作为人均阅读时长过百分钟的阅读产品，Darkmode和夜间模式是我们无法逃避的话题。**和工具类产品不同的是，用户需要长时间将视觉焦点驻留在阅读场景中，而夜间同样也是内容消费的高峰期**，因此用户对于夜间模式的需求非常旺盛。 事实上起点很早就以黑色蒙层的处理方式简单支持了日夜间切换。在18年我们又做了核心阅读场景下的真正的夜间模式。这是一种基于一套新的颜色映射关系构建的局部的真夜间模式。我们尝试将指定的局部页面设置了白名单，映射这套对应关系。而不在白名单中的页面，则不响应这个映射，仍然是简单的黑色蒙层处理。 视觉同学基于日夜间构造的颜色映射关系 通过这种方式在开发资源紧张的情况下，升级了夜间的体验。但是因为并不是全局夜间，所以当用户离开阅读页之后不得不经受由黑变白的糟糕体验。 借着这次iOS13+的契机和之前的颜色映射基础，我们尝试让产品支持全局的深色模式。在这里也整理一下对于深色模式落地的一些思考。 > 1.深色模式还是夜间模式？ 深色模式通常不能和夜间模式或是护眼模式做等号。尽管Apple对它的期望是夜间对眼睛更友好。但是事实上他就是一种可以在白天使用的深色主题。 基于这点的话，本质上他和很多产品早早提供的夜间模式并不一样。iOS已经有了夜览这种夜间护眼功能。所以对于darkmode，苹果并没有寄希望于它可以起到所谓的护眼能力。 而目前很多产品提供的夜间模式，可以分为2大类： 1类是用主题的思路来去做，在iOS13推出DarkMode之前，就有一些app支持了黑色主题，通常被用做为适于夜间浏览的夜间模式。 2是简单的在所有页面的最上面盖一层黑色蒙层。起点读书之前在端内对于夜间模式的处理就是第二种方式。  **对于用户而言，深色和夜间是2个很难区分的概念**，即便是很多设计师也不一定能很清晰的做出两者的区分。那么对于一个受众多为二三四五线用户群体的起点来说。从一开始我们就并不指望用户能清楚的区分两者的关系。因此在认知维度我们希望用户能产生一个认知：深色模式（DarkMode）=夜间模式，浅色模式=日间模式，无需刻意的区分两者的关系。考虑到夜间模式对于安卓用户的认知更为友好，所以我们保留了这个叫法 > 2.阅读软件的特殊性 对于很多常见的工具类软件而言，适配深色模式，只要按苹果的建议和官方示意一整套实现即可。 但是对于阅读软件，这种全局一个规则的方式并不合适。在晚上阅读页的场景下，用户希望夜间模式是一个深色的阅读背景，在光线很暗的地方不伤眼睛。而iOS13对于DarkMode的定位更像是一个深色主题，他同样支持在白天的使用，对应的字体的颜色也更亮。 基于此，我们将对于深色的处理分为2个部分： - **长时间停留的阅读页**：深色背景+低对比度字色。 没有选择高对比度的文字，是希望确保在夜间长期阅读时，不至于太累。保证在白天也可以正常识别文字。同时在夜间进一步降低屏幕亮度或是启动夜览之后，可以更进一步的让文字和背景的对比度减小。阅读起来更轻松。关于字色的设定，可以参考Web 无障碍指南（WCAG）提供的对比度规范，很多文章里也有说到，这里就不再赘述了，感兴趣的同学可以自行了解。 - **停留时间较少的全局UI界面**：深色背景+高对比度字色。 除了阅读页以外，其他页面用户都不会做太久的停留。高对比度文字，在这个场景下并不会非常明显的影响读者的使用。同时可以很好的兼顾一些用户把夜间模式当作深色主题来使用的习惯，保证了在白天光照很强时依旧可以正常的识别。  除此之外，对于一些用户同样可能长时间浏览的页面，如社区、专栏等内容区域，也可以和阅读页一样的方式来进行处理。 > 3.阅读背景和系统状态的关联和冲突处理 适配DarkMode之后，不得不面对的一个问题就是app和系统的日夜间冲突的问题。比较常见的也有2种处理方式： 1.完全跟随系统，用户在软件内无法进行日夜间切换。切换必须通过系统的深浅切换。 2.用主题的模式，完全和系统剥离。不管系统的日夜间状态。 这两种形式各有优劣。但是我们并没有完整的采用其中任何一种思路。而是尝试了一种新的解法 a.默认跟随系统深浅模式。 我们希望当iOS13的用户升级之后，在夜间打开起点读书的时候，可以直接看到夜间模式的样子。毕竟做了功能就希望有更多的用户看到并使用 b.允许用户因为个人喜好而调整日夜间模式 我们在功能维度，允许用户给每一本书设置不同的阅读背景。当前的夜间模式在开启之后，会展示一整套完整的黑色主题包括页面和阅读背景。而用户回到日间模式后，则会恢复用户所有之前的阅读背景的设置。即所有的个性背景都会被认为切换为日间模式。 可能到这里大家会产生疑惑，为什么不允许用户在黑夜模式单独设置阅读背景呢？这个问题我们也考虑过，这样的话在用户做过几次阅读背景+界面ui的日夜切换后，就会出现阅读背景是黑色，外面却是日间的情况，反之亦然。这是非常容易产生疑惑的。而我们支持darkmode这件事的初衷是，希望解决在夜间使用时用户离开阅读页，页面骤然变白的体验。显然上面的方案违背了我们的初衷。 c.日夜间跟随系统开关 用户进行任何一次日夜间切换（逆系统状态的）操作时，在用户二次确认后，会完成日夜间状态的切换。同时自动关闭跟随系统日夜间切换的开关。除非用户再手动开启关联开关。否则会一直保持手动切换日夜间的状态。    d.关于已经在使用自定义阅读背景的用户的处理 如果用户是在阅读页退出app时，那么在下一次启动app后将直接进入到对应书籍的阅读页中。因为我们希望iOS13+的用户在升级之后可以第一时间体验到darkmode，因此做了全局的默认跟随系统设置。而阅读页的背景也会因为在夜间，所以变成默认的黑色阅读背景。 前面有提到起点有一个功能是支持用户给每一本书设置不同的阅读背景。因此我们也很担心用户会在升级之后的首次进入产生困惑，我之前设置的阅读背景是不是都丢失了？为了避免这样的疑惑，在用户升级后的首次直接进入阅读的场景下，会给到一个提示。告知用户切换回日间模式后，仍会恢复他之前设置的阅读背景。  > 4.内嵌h5的处理思路 相信很多产品都是native和h5混合搭建的。而对于起点来说，一些流量较高的签到等页面就是内嵌的h5页面。当全局升级为深色模式后，这样的h5页面也应该对应的升级，才可以保证体验的一致性。因此我们在前端同学的支持下，内嵌h5页面也使用了和native一致的颜色token，可以进行对应的颜色映射。只需要在h5页面打开时，获取到app的日夜间设置即可。 ##Darkmode可能带来的坑和落地注意事项 1. 对于一个时间比较久的产品而言，适配全局的darkmode的工作量在真正落地时，还是非常大的。因为早期的页面设计并没有使用新的颜色token，设计侧对于整体的页面又进行了一次刷新。包括使用了更新的组件和颜色、文本等。 而对于研发侧而言，也需要对所有的页面进行重构。那么在这样的前提下，依赖分支进行开发，会让后续的其他功能的迭代的合入变的困难。所以如果你们想支持darkmode，那么最好有拿出一个版本来完整支持的资源 2. 目前来说，我们是基于组件级去监听系统的日夜间切换，在这样的情况下，在后期的走查过程中，也许darkmode状态是正常显示的，但是当你做系统级的日夜切换时，就会出现部分组件因为没有监听对应的变化而显示异常。 3. 如果涉及到页面的重构，那么还是需要大量的测试资源来去保证基础功能的正常使用，而非单纯的看样式变化。认真走查吧，有的时候你会发现改了夜间，结果日间模式也会受到影响。 4. 如果你同样采用了颜色映射的方案的话，支持了darkmode，意味着你同时拥有了一套支持主题切换的能力。 5. 之后版本的需求，在视觉设计时对于图标、图形等元素都有了更多的要求，需要兼顾到夜间的情况，这块是一定程度上会增加工作量的。 最后，相信Darkmode是未来产品的基础能力，也希望这些经验对你有所帮助，找到适合你的darkmode适配方案。 
· The End ·
Next Page
👉
Copyright © AirDesign.cn 2013-2020 All Rights Reserved.
苏ICP备18059914号-1
