隐藏在背后的交互设计

交互设计最重要的两个因素：信息互动

1.信息

人们天天面对那么多信息，在杂乱的信息中筛选出对用户有价值的，呈现给用户，帮助用户作选择，指引用户完成任务。信息的筛选直接影响着用户使用，在用户须要的时候没法提供有用的信息，将致使任务没法进行下去。因此信息是交互设计师须要关注的第一要素。

2.互动

有了信息后，就须要设计用户如何与这些信息进行互动了。信息的分类、布局将影响用户与信息的交互。用户获取信息后，作出了反应，采起了行动，应用也须要有来有往地给予足够的反馈，来协助用户完成任务。

 

以上2要素，都是从用户直观感觉上去体现的，也就是说每每是表如今用户界面上。咱们能够把它称之为“看得见的交互设计”。

具体的形式包括：

信息架构：把筛选好的信息进行分类，经过页面来承载这些信息，而且把信息（页面）的层次规划好

界面设计：把信息在一个页面上进行布局

流程设计：把一个任务中涉及的页面信息串联起来，使任务造成一个线性流的关系

以上三个关键点，是对交互设计师的基本要求，不少状况下，非专业人员也能作得7788，但还有一部分的交互设计，并非直观能看到的，也许用户会轻微感觉到，但他总在不经意间使用户使用得更加流畅。咱们能够把它称之为“看不见的交互设计”。而这些看不见的交互设计，也是初级交互设计师容易忽略的。

 

现在移动互联网发展迅速，移动产品对这些看不见的交互设计更为注重。由于移动应用的使用场景、网络环境、使用心态都与用户在使用web产品时有着大大的不一样。因此在了解这些看不见的交互设计时前，须要对移动应用的情景有必定的了解。

1.使用场景

用户在使用移动产品，有可能会在户外人多的公众场合使用，这时候须要特别注意移动应用设计的隐私安全。

用户有可能在家里、在床上、在厕所，用着各类姿态使用产品，因此对交互的便利性和容错性要特别注意

2.网络环境

网络环境是“看不见的交互设计中”很是关键的一点。用户会在2G、3G、wifi甚至无联网的状况下使用产品，因此对于各类网络环境进行合理的交互设计是移动产品交互设计师须要考虑的重中之重

3.使用心态

产品的存在是为了解决用户的问题，而移动产品是用户的贴身工具，当用户须要时，能马上开始运做，须要快速、直接、有效，用户不喜欢等待。有研究结果表示：

 

在移动产品这种特殊的环境下，“看不见的交互设计”会相较于web产品更为重要，特别是针对网络环境和用户等待的体验须要特别注意

下面将展开讨论一下“看不见的交互设计”

总的来说，能够归结为三大点：

1.加载机制

2.刷新机制

3.缓存机制

 

 

加载机制

一般状况下，咱们使用的绝大部分是网络App，他的工做原理是这样的

用户在客户端的界面上进行操做，客户端发送请求到服务器，服务器处理请求，返回数据给客户端，并显示给用户

其中，客户端和服务器的交互过程，用户是感知不到的，而他确实会耗费时间，在不一样的网络环境下耗费的时间也会有所差别，如何让用户在这段时间里有友好的体验呢？这时候“加载过程”起了做用。

 

加载过程的关键能够总结为：

1.让用户感知产品正在努力为他运做

2.让用户有基本的心理预期须要等待的时间长短

3.让用户在无聊的等待中得到更多乐趣

 

进度条是一个针对加载过程很好的设计

动态的加载进度表示产品正在工做，总进度和当前进度能让用户及时了解状况，让用户能根据这些信息预判时间，有了心理预期

有趣的进度条设计or在加载过程当中展现一些功能介绍提示（经常使用于游戏）能有效减小用户等待时的焦躁心理，也能有效地提升用户的容忍度

 

进度条是web产品时代的产物，还有另一种加载设计，就是加载图标

因为移动产品请求的数据量并不大，因此进度条每每会在一瞬间就完成了，在这种情境下，简化了加载的设计，不少移动产品转而使用加载图标来表示加载过程

以上为两种比较经常使用的加载方式，下面将具体介绍他们与移动产品结合的用法

 

页面加载机制

移动产品的信息都是经过页面来承载的，页面的加载方案设计是交互设计师面临的一个重要难题

方案一：单页面总体加载

这种加载比较简单，通常运用在页面内容比较单一的状况下，因此直接一次性加载完全部数据后再显示内容

 

单页面加载失败的状态也比较好处理

 

方案二：单页面分块加载

这种方案的特色是，能让用户逐步看到内容，在这个渐进的过程当中下降用户的焦虑心理

其中又能够分为，模块间有关联性的，先加载父内容，再加载子内容

如优酷，先把栏目加载出来，再加载各栏目的内容

模块间没有绝对关联性的，可独自加载各自模块内容，根据请求的速度不一样分别显示。这样处理有必定概率让用户在没彻底刷出数据的状况下就能找到本身须要的功能，如大众点评、淘宝客户端

 

框架固定，内容更新的，可先把框架显示出来，再把各模块的数据各自加载显示，如各类iOS自带应用，云音乐

 

这种分模块加载的须要特别注意加载失败的状态，毕竟每一个模块都提示加载失败，点击重试是很挫的一件事，能够根据信息的优先级来决定哪些数据失败了采用默认状态，哪些数据采用失败提示

 

方案三：跨页面加载

父页面&子页面 or 同一app内，页面间字段能够复用的，在加载子页面时不须要从新加载新数据

 

 

方案四：预加载

这种加载方式的特色是，在加载一个页面内容的同时，预测用户的下一步行为，并为他下一步须要使用的页面加载内容，使得他在下一步的操做中能马上获取信息而不须要加载等待。

预加载提供给用户无缝的产品使用体验，使得用户在使用产品的过程当中更直接流畅，没有被打断的感受。

具体的例子有：

在浏览图集的时候，当看到第一张的图片时，就自动后台加载第二第三第四张图片，用户浏览完第一张图片切换到第二张时就不会有加载等待的过程

在浏览新闻列表时，就把每篇新闻的内容在后台进行预加载，用户选择看某篇新闻时，能马上阅读到内容

 

可是这种方案须要面临不少的问题，最直接的是流量问题，由于会自动跑掉不少用户可能根本用不上的数据流量，因此通常状况下能够设定在wifi环境才采用这种加载模式。又或者设定加载规则，只把主要内容预加载，而部分次要内容能够在用户真的用到的时候才加载，例如预加载新闻正文的状况，能够只加载文本信息，图片信息等到用户进入内页才加载。这种预加载与分块加载结合的方式也广泛运用在各个场景。

另外，预加载也须要时间的，他只是不在客户端显示给用户，默默在后台运做而已，须要特殊考虑未加载完用户就使用到那些信息的状况，因此在作预加载设计时须要同时考虑另外一种适合该状况的普通加载方式。

预加载须要根据具体的场景来进行设计，设定好信息优先级，综合考虑各类类型信息的具体大小流量，总体考虑预加载的方式，这些都是须要通过精心分析思考的。

随着网络环境的发展，预加载将成为之后产品广泛的加载方式，他提供给用户的无缝使用体验大大地提高了产品的可用性。

 

操做加载机制

除了页面的信息须要加载，页面内的操做也是须要经过给服务器发送请求记录的

方案一：加载层

进行一个操做后，弹出模态的提示层，告知用户正在加载。

采用模态的提示主要是防止用户在该过程当中进行其余操做，致使当前加载出错。因为采用模态的提示，而且有可能由于网络缘由致使长时间处于加载状态，建议提供一个“关闭”的操做，停止本次加载，恢复App可用状态。加载失败时可在当前浮层变换为失败提示。

模态提示层是最稳妥的方式，但他会使用户在使用过程当中有打断的感受。

 

方案二：控件自身加载状态

这种方式是把操做加载的状态与控件的样式结合起来了，对某个控件进行操做后，控件变换为加载状态，此时控件不能重复操做

因为这种加载方式是控件的自身状态，不影响其余操做，因此用户也能够对页面进行其余操做，可能会致使同时有多个请求的状况，增长了加载失败的风险，这也算是这种方式的弊端，不过这种极端状况不多出现。请求失败后，可配合Toast提示告知用户失败的缘由。

 

方案三：后台加载

用户在操做后，客户端马上反馈操做成功，而后把请求放到后台与服务器交互，这一过程用户不须要了解，不须要等待，在正常状况下体验是很是棒的。

可是在极端状况下会出现一些莫名其妙的情况，因为是后台记录请求并与服务器交互，因此实际请求是否成功客户端是不说明的，所有以操做成功来显示，这就会致使用户误觉得操做成功了，但实际上下次来看发现没有成功。因此这种加载方式是须要根据具体使用场景来权衡使用的，对于一些重要的操做，建议仍是使用模态的方式加载，对于一些小操做，如点赞、订阅、关注，可采用后台加载的方式。

 

 

刷新机制

刷新机制也是设计师很容易忽略的问题，合理的刷新机制能让产品使用起来更流畅

广泛状况下，刷新机制有如下三种：

方案一：手势刷新

经过手指在屏幕上的左划右划上划下划达到刷新的目的，也包括一些浏览器产品的自定义手势，如横折折勾，进行刷新

最多见的下拉刷新也属于手势刷新的一种

 

方案二：点击刷新

经过点击一个按钮达到刷新数据的目的，可是现在刷新按钮的存在已经成为一种过期的表现，何况在手机那么小的界面上还须要为刷新按钮腾出空间，会挺费劲的。不过避免形式主义，用得恰到好处才是设计的精髓，这种刷新方案仍是按需使用吧。

 

方案三：自动刷新

根据设定好的规则，如时间、事件规则自动向服务器获取新数据并替换旧数据。使用自动刷新须要根据场景来考虑是否合适

场景一——对于频繁更新的内容、有时效性的内容，用户在一个设定的时间没有使用，则可考虑在下次使用时，自动刷新，把新的内容推送给用户

相似微博、新闻这种具备时效性的产品，用户在24小时内未打开产品，则在下次打开时帮用户自动更新Timeline

场景二——对于一个相对稳定，数据不会常常变化的页面，能够考虑设定时间规则，在后台为用户默默更新数据并替换旧数据

 

 

缓存机制

“缓存”这个词在web时代也常常听到，但在移动产品上，他的重要性获得了很好的重视

一张图解释什么是缓存和缓存的做用

“缓存”就是把已经加载过的数据保存起来，并在下次须要重复使用的时候，不须要向服务器加载，直接获取本地数据

我理解的“缓存”可以下分类

临时缓存经常使用于一个功能页面内，保存各栏目的缓存。同一个功能里会把子功能分为多个栏目进行划分，每一个标签栏目下的内容在本次使用中均可保存为临时缓存，在该功能里切换栏目，不须要从新加载数据，使用缓存显示。对于用户来讲，使用时达到了无缝切换浏览，对于服务器来讲，在短期内数据不多会有更新，因此在通常状况下能知足用户的正常需求，并达到体验优秀

临时缓存的清理机制是：退出该功能模块就清除以前的缓存。也就是说下次进入该功能模块，须要从新获取一次数据

不少时候咱们都会用到临时缓存，由于那些信息真的不是那么重要，并且不须要常常反复查看，那对于那些咱们常用并且常常须要反复查看的信息，咱们就会采起固定缓存保存在本地，方便下次翻阅时不须要再一次向服务器请求数据了

其中又会细分为可手动清理的缓存，和不可手动清理的缓存

第一种是咱们最多见的缓存，几乎全部产品都采用这种缓存方式。平时用户浏览文章、图集加载的数据就以这种形式缓存在本地，下次看回这篇文章、图集时就不须要加载了。用户也能够手动把这些缓存清理了，释放空间。

而对于某些特殊场景，例如一些相对固定的数据，咱们不肯意一开始就打包进App里，这样会占太大容量，形成产品包很大，也不肯意每次进入页面都向服务器加载这些信息，那怎么办？解决方法就是咱们能够只加载一次就永远存在本地了，这样安装包也不会大，之后也不用加载了。

例如一些页面的背景图，相对固定不常更换，因此在用户首次进入该页面时就加载背景图并保存在本地，这种缓存是不可清理的，下次再进入该页面就读取本地缓存显示便可。

这种缓存方案使用得不多，由于场景太少，具体使用场景还有待开发。

 

对于这些保存在本地的缓存，都是会占空间的，手机的容量是有限的，那产品是经过怎样的方式清理缓存的呢？

你们熟知的有手动清理，通常App都会在“设置”里提供一个清理缓存的功能，一键把空间释放。除此以外，App最好要设计自动清理机制。

能够经过两个维度来设计这个机制。

时间

经过设定一个固定的时间，或者根据用户使用周期灵活设定时间来清理缓存。每一个产品的场景不一，用户使用频率不一，设定这个机制的时候就须要结合实际状况考虑了

容量

通常是设定一个容量上限，采用堆栈的设计原理进行缓存清理，溢出堆栈的旧数据将自动清除