一开始，我见周围的人都在使用这个网络工具，但是我并不了解大家口中的微信到底是什么?所以在一次偶然的机会下，我也去申请了一个帐号，慢慢的去了解微信风靡的原因，结果在这之中，慢慢的，我好像也开始喜欢使用微信了呢！因为它有 许多的功能，比如说:我们可以得知朋友现在的近况、也可以在他们生日时为他们最即时的送上祝福、还有，我们可以在别人的文章下面给一个赞、给一个赞同、或是和好朋友玩互戳的游戏，联络感情。在各方面看来都是个是个很方便的APP。
有很多的时候，我内心的千言万语不知道要该如何 表达时，就会透过微信来和大家分享我的心情，而且，我很喜欢在发完文章时，有人可以给我一个赞，因为这个小小的赞同，常常会让我有一种被肯定的感觉，并有着愉悦的好心情呢!所以我也常常给别人一个赞，让每个人都有和我一样愉悦的感觉！平时，我除了会自己发表文章，也会去浏览朋友们的近况，了解他们最近过的好不好、或是开不开心呀！并在他们情绪低落时，给予简单的问候!上次，我还透过微信，找到一位我多年不见的好朋友呢！
但 是因为微信的方便，也造成了许许多多的麻烦，像是我们常常使用分享功能，让朋友知道自己曾到过哪些地方游玩，却是不小心的一点一滴像坏人透露自己的行踪；或者是自己的隐私，在自己不知情的状况下，已经被所有的人一览无遗了呢；甚至还有人，因为沉迷于微信里多样化的游戏、功能，而完全离不开自己的手机 呢！
深受大家所喜爱的微信，虽然有好，但也有坏，我们要有能力去判断他的是、非、善、恶，才不会一不小心，就影响到自己的人身安全、或是自己的隐私了呢！
微信轻应用是时下的一个香饽饽。一方面是因为随着H5语言的定稿及其开发经验的沉淀，开发者以较低的成本即可打造出具有一定可用性的Web App。另一方面，微信作为一个超级社交App，天然具有巨大的流量入口价值与传播分享价值。因此，在微信平台宣布全面开放接口后，无数互联网创业团队、企业，甚至是个人，纷涌而入，杀成一片红海。
但是，实际使用时，微信轻应用的体验并不是那么的“爽”。诚然，这与H5语言的技术局限性有着很大的关系。但抛开这一点，走肾而不走心的设计也是造就“不爽”体验的重要原因。本人在体验过一些的微信轻应用后，尝试总结出了一些对微信轻应用交互设计的思考。
在亮出个人总结之前，我想先谈谈进行微信轻应用设计时的难点与机会。
微信轻应用设计的难点源于H5技术的局限性以及微信平台本身的局限性。
1. H5的局限性：
2. 微信的局限性：
但很多时候，限制即是机会。 “聊天气泡+底部操作栏”的设计规范，反而为应用的信息框架与导航设计提供了更多的思路。一方面，IM工具的输入/反馈机制，为用户与应用的交互方式和信息的呈现方式带来了新的可能；另一方面，底部菜单栏可以是对Native App中Tab Bar选项的隐喻，恰当使用可以降低用户学习成本。
废话了一大箩筐，下面马上向个人总结页面跳转。
用户的认知模式是长这样子的： 会倾向于把公众号的对话窗口视为微信轻应用的首页。底部菜单栏中，每一个标签即是一个功能模块的入口（相当于Native App中的Tab Bar）。点击标签后进入的第一个页面即是该功能模块的顶层页面，从该页面返回则必然是回到对话窗口。
这带来的启示之一是，在设计页面架构时， 可以考虑将对话窗口中的底部菜单栏视为Native App中Tab栏的隐喻， 将功能模块平摊到这些操作栏中，并削弱模块之间的关联性。如微信轻应用“Yolo优洛会”中，每个底部操作栏标签均对应一个功能模块，且功能模块之间彼此独立，点击进入后可获得独立、完整的沉浸式体验，让用户专注于任务本身，并降低了学习成本。
启示之二是， 对话窗口与功能模块的顶层页面之间必须建立唯一的上下层级关系。 一个反例就是，“行动流”微信轻应用中，点击对话窗口底部操作栏中的“圈子”，进入新页面后，再点击左上的“圈子”按钮，试图返回，却发现跳转至了一个全新的页面。该页面顶部是Icon和Slogan，下面是“我”、“圈子”、“梦想”这三个功能的快捷入口，正是设计师眼中的“首页”。然而，该页面的到达路径并不符合预期，容易把用户灌醉。
微信已经强制为所有应用套上了顶部导航栏枷锁，其中就已经包含了“返回”按钮。然而，仍然还有不少应用坚持添加上自己亲手设计的“返回”按钮。
双重“返回”样式增加了认知障碍、挤占了屏幕空间。就算是出于“左上返回按钮位于拇指热区外我们来让它更容易被点到吧”的出发点来考虑，其存在意义也仍然十分牵强。相反，将其移除后，腾出来的空间可以激发更丰富的设计思路(比如，用来放置全局导航)。
即使是在高配置、强网络的条件下，页面跳转在微信轻应用中仍然是非常痛苦的体验。而灵活高效的导航是减少页面跳转的一大杀器。
微信轻应用上，常见的导航样式如下：
1. 对话窗导航
2. 一级导航
3.全局导航
4.场景式导航
H5的技术限制，使得一些在Native App上司空见惯的动效套用在微信轻应用上时显得笨拙无比。当然开发水平是影响动效是否流畅的一个决定性因素。但过重的动效需要占用大量的用户资源，同时也加大了开发的成本与难度，违背了“快速开发”的初衷。因此，在进行微信轻应用的设计时，要尽可能地避免“使用动效解决问题”的思路。
但这并不意味着要舍弃一切动效。事实上，比起Native App，微信轻应用对“微交互动效”更加依赖。主要表现在以下几个方面：
1. Loading态
微信轻应用需要源源不断地发送网络请求，也就留给了用户大量用于等待的焦虑时间。而Loading态的微交互的使命正是化解这股焦虑。
Lodaing态的对应加载方式是全局加载，这种方式比较适用于数据请求量不大的页面加载场景。而数据量较大的页面则普遍使用异步加载的加载方式。异步加载即各项元素按照一定的优先级顺序来进行加载，因此在加载过程中会出现各种空元素。这时候就需要缺省态的微交互上场了。
由于H5的效能问题，在“用户进行操作”与“系统执行操作”之间往往会存在一小段延迟。在这段延迟期间，若没有任何反馈，用户很容易会误以为自己操作失败而做出什么不好的事来。操作反馈的微交互可以间接加快应用的响应速度，阻止用户犯错误。
正在输入的文本框必须要在视线焦点范围内。这点听起来似乎是天经地义。但很不幸的是，这个世界上存在着太多的无情无义的微信轻应用了。
“如何让用户觉得运行速度很快”是进行微信轻应用设计面临的一个核心问题，而页面加载的速度正是衡量“运行得快不快”的一个重要尺度。
用户是如何感知、判断页面加载的速度的？这主要取决于第一个可视元素出现所用时间和“感觉这个页面已经完整了”时所用时间。将这些用户视角的体验需求转化为指导设计的方法论则是， 减少页面中可感知到的信息的数据加载量。 这些可感知到的信息必然是重要的、高展示价值的。至于其他 次级信息 ，可 选择性地将其隐藏，并降低其加载优先级。 这样，即使次级信息仍在加载中，但由于其已被隐藏，用户感知不到，因此仍会认为当前页面的加载速度是nice的。
隐藏信息的方式总结有以下几种：
1. 将一段长信息不完整展示
由于技术限制，现阶段大部分微信轻应用从详情页面返回至列表页面时，并不能定位到最后停留的列表位置上。
突破该技术瓶颈固然是最有效的解决方法。但据观察，目前只有微信钱包中自带的“京东”轻应用解决了该问题。因此可以基本断定该解决思路暂时无法实现。
面对如此艰苦的设计背景环境，另一个解决思路是 提高列表筛选效率，降低用户从详情页返回列表页的概率。 比如，往列表中注入更多的辅助用户决择的信息字段；又或者是将详情页中的关键入口前置，缩短用户到达路径。
在微信钱包中自带的“大众点评”轻应用中，店铺列表页处囊过了该店铺的团购入口，一来团购信息可以辅助用户进行店铺筛选，二来缩短了购买团购的路径，极大地提高了列表的筛选效率。
设计师或许掌握了成吨的让跳转页面无感化的技巧，但一切真相都逃不过“返回”按钮的审判之眼。按照微信的逻辑， 每一次点击“返回”的结果，必然是回到上一次加载的页面。 这使得一些在正向操作时感觉高效简洁的设计方案在逆向操作时让人疼到无比。
比如微信钱包中自带的“美丽说”轻应用中，使用Segmented Control控件承载化妆品分类。切换类别时，体验近乎无感。然而，当点击“返回”按钮时，并不是回到微信钱包首页，而是回到上一个化妆品类别的列表视图，严重不符合用户预期（明明就是同一个页面，怎么点了返回没反应的）。
正因为如此， 在技术上无法解决该问题的前提下，并不十分建议使用那些容易引发“不需要进行跳转”的错觉的导航样式 ，比如Tab式导航。不仅在正向路径中违背了“肯定不需要跳转啊”的用户预期，也在逆向路径中也显得臃肿低效。
用户正在使用微信轻应用，手机突然震动了一下。这时候用户是会选择将当前任务进行到底，还是会离开应用查看微信信息呢？这取决于用户使用应用的目标强度以及获取新信息的迫切程度。但无论如何，用户一旦离开了应用，如果想要再次回到最后停留的页面，就必需从头开始。
无论是对用户还是开发商而言，这种交互逻辑都不是什么好东西。那么， 能否在浅层级的页面中提供返回最后停留页面的入口呢？ 比如，在轻应用的页面中提供“稍后阅读”按钮，点击之后，公众号可以将该页面的链接以信息流的形式推送给用户。这样，用户只需要重新进入公众号对话窗口，直接点击信息中的链接即可以重返最后停留的页面了。
当然，这只是个人YY，是否具有可实现性仍需要技术同学的审批。
由于个人知识体系实在浅薄，关于微信轻应用设计的思考暂时就只有这么多了。在此真心希望H5的开发技术快高长大，让微信轻应用与原生应用之间的体验差距越来越小。
前言：正如微信读书的官宣——让阅读不再孤单。微信读书延续了微信一贯的社交性 ，弱化了电商属性的书城，更多聚焦于认真读书、发现好书以及读书交流方面。在众多读书APP中，像一股清流，没有太浓的商业气息。界面简约清爽，操作简单。当然也存在书籍太少等问题，该问题不在本次设计范围内。本文将从一些交互细节对微信读书进行重设计。
软件版本：微信读书2.2.0
使用设备：iphone7
操作系统：ios11.1.1
体验时间：2017-11-22
以下为微信读书的结构框架图：
1、操作按钮位置混乱。最下面的操作栏顺序不是很合理，建议将删除调至最左边，私密阅读在中间，移动在最右边，比较符合直觉的操作习惯。
用户可以对在架书籍进行自定义分组，其中“归档”是默认的分组，可以往分组里添加书籍。如图，当分组内没有书籍时，右上角是“修改分组”，里面的操作包括“修改分组名”和“删除分组”。当分组内有书籍时，右上角是“编辑”，点击以后变成左上角“修改分组”、右上角“取消”。但从书架页面（第一张图）可以看到，点击编辑后，左上角变为取消。 即按钮的位置是不规律的，不符合尼尔森有用性原则中的一致性原则。
建议将分组的“修改分组”与“取消”交换位置，就会与之前的操作位置相一致，避免用户产生困惑和误操作。
除此之外，想要分组书籍，只能通过“书架-编辑-移动”，建议可以在分组内直接添加书籍，点击添加，打开书架内未分组的图书，通过勾选加入此分组。
修改后如下图所示：
2、发现页右上角的FM42|3入口不是很明显，看上去像是个标签或者logo，并且，大部分用户不知道FM42|3的含义（包括本人）。建议修改为一个icon，让人明白是可点击的，然后里面的内容是一些电台节目。
3、读书界面按钮太多，显得很杂乱。如图，当电台在播放时，可以看到z轴悬浮3个按钮，同时页眉与页脚分别有4个按钮，且一些按钮展开后还有更多功能。面对这么多的按钮，有一些按钮还难以区分，用户使用起来成本较高，这时需要更清晰的逻辑。
首先将读书页面的所有功能整理如下：
改进意见：
a、“语音朗读 ”和“听书 ”这两个功能会使人困惑。笔者一开始误以为是同一个功能，后来发现语音朗读只是对文章的朗读，而听书是语音书评。这两个按钮在同一页面放开很容易混淆，合并在一起性质又不一样。对此，笔者认为可以将听书功能与文字书评合并，都是书评，只不过形式有所差异（一个文字、一个语音）。从而使“语音朗读”和“听书”不在同一个层级呈现，避免误解。
文字书评是通过“相关想法”功能实现的，“相关想法”入口较深，被收在读书界面右上角的“更多”里。“相关想法”包括精彩想法和好友想法，其中精彩想法是按章节顺序呈现的，如图。
将“相关想法”功能与“听书”功能结合，笔者对页面进行重设计如下图所示。新功能命名为“书评”，点击进入有三大模块“听书”、“精彩想法”和“点评书籍”，听书页面与原页面相似；精彩想法包括好友想法和网友想法。相比现有内容以瀑布流为呈现方式，笔者将内容进行了归类：好友想法在页面最上方，出现一条，剩余的可以点击展开箭头查看更多；网友想法按照文章章节划分，每一章呈现5~10条想法，同样可以查看更多 。“点评书籍”是对全书的点评，并可以给书籍打分，按钮在页面右上角。未点评状态时为黄色，点击进入评价；如果已点评，按钮将变灰，可点击，点击后显示“我”的评价。
b、“今天一起阅读本书的人 ”功能其实类似bilibili的当前共同观看人数。但bilibili仅仅是提供了人数，没有细致到个人信息，而微信读书则是有更浓的社交意味。页面内包括“书友”的个人信息、阅读时长、笔记、读书进度以及关于本书的想法。设想微信读书是希望能通过共同阅读来促进交友，再从社交中促进读书。
可以看到，该功能与“相关想法”功能有些重复，微信读书的做法是把“相关想法 ”收在“更多”里。而经过a中的改造，“相关想法”也就是“书评”的功能点增加了，不适合再被收起。此时将作为一个独立的按钮与“今天一起阅读本书的人 ”共同出现在一级页面。所以功能重复的问题就要用其他方式解决。
两者重复的地方主要在“想法”上，“今天一起阅读本书的人 ”有关于本书的想法，“相关想法”则更是想法的聚集地，这样重复显得臃肿多余。
但进一步分析可知，“今天一起阅读本书的人 ”和“书评”功能侧重点不同，“今天一起阅读本书的人 ”侧重于人，“书评”侧重于评论。所以可以通过弱化“今天一起阅读本书的人 ”中关于想法的部分。具体实现方法是在“今天一起阅读本书的人 ”页面隐藏“关于本书的想法”，然后用户可以通过点击名片进入个人主页查看他人相关想法。
c、当前页脚有4个按钮，分别是抽屉式导航入口、进度条、亮度模式、字体。亮度模式和字体都是对阅读体验的调整，可以整合到一起。这样可以腾出位置放置“书评”功能。进度条使用频率相对较高，可以直接显示出来。最终页脚改进如下：左下角为目录、书签、划线等功能的抽屉式导航入口，调整亮度、颜色、字体、字号统一放在一个按钮内，“书评”功能放置在右下角，进度条直接显示于三个按钮上方。
结合以上修改意见，读书界面的最终结构框架如图所示：
（更多中的功能除了“相关想法”被挪出以外，其他功能仍保留，这是为了防止例如“点评书籍”、“书籍详情”一类功能入口太深，降低可用性而做的保险措施。）
4、微信读书支持纯划线摘录，或者划线摘录并写想法。划线可以在抽屉式导航中找到，如图（左），但是没有列出相应划线的想法。这点掌阅做的比较好，把划线和想法都罗列出来，让用户可以轻松看到自己对该书的所有想法，用户体验更好，如图（右）。
5、微信读书可以丰富一些手势操作。如图为多看阅读的多种手势操作，下拉：添加书签；上拉：关闭图书；双指左/右滑动：打开/关闭抽屉式导航。
6、语音朗读时不能通过点击任意某句话开始播放，只能拖动进度条，而进度条不够准确。可以参考音乐播放器中点击相应歌词直接从该句歌词开始播放的形式，长按某段文字直接从该段文字开始朗读。
7、掌阅写想法可以“所有人可见”，也可以“仅自己可见”。而微信阅读个人想法不能选择“仅自己可见”（私密阅读的想法是私密的，但公开阅读的想法无法进行隐私设置），需要改进。
8、笔者发现，阅读时选中一段小于14字的文字会跳出如图左所示功能条，包括复制、划线、写想法、查词典、分享和纠错。而当选中一段大于等于14字的文字时会出现如图右所示功能条，包括复制、划线、写想法、录音、分享和纠错。也就是说字少时是查词典、字多时是录音。这种设计应该是考虑到查字典时通常是查字词，所以字数较少。而录音通常需要录比较长的句子。但是这样的智能切换在实际操作中容易出现问题，比如一段话刚好只有13个字，那就不能录音了？所以建议按钮上都呈现出来，即选中文字后跳出功能条，包括复制、划线、写想法、查词典、录音、分享和纠错7个按钮。
9、掌阅自定义设置较多，比如可以设置行间距、翻页方式、护眼模式等，但这些属于比较次要的功能，微信读书可以在满足产品大方向的前提下逐渐完善。
10、从产品角度看， 微信读书定位于读书社交，但目前做的远远不够。仅仅是分享想法和好友关注，还没有涉及到读书群的概念。比如可以开设作者专栏，建立一个由作者为导向的兴趣社群，书迷们可以在社群内互动，交流读书心得，甚至可以逐步发展线下活动。当然，这也是要看微信读书的产品定位的，暂时是笔者一个不成熟的设想。
欢迎批评指正，欢迎补充！
