交互设计：从详情页返回列表页，应该是回到顶端还是回到原地？

　　在一个列表页上点击某个项，进入详情页，再从详情页返回列表页，应该是回到顶端还是回到原地?

　　返回到列表时，列表不应刷新、页面不应回到顶端，应该是返回原地，回到刚才离开的那个位置。

　　对于PC的网页，这个问题并不典型，因为，新链接是在原窗口打开还是在新窗口中打开，这都还没个定论，如果是在新窗口中打开，也就不存在返回列表页的情况了。

　　现在移动设备上，尤其是手机这么小的屏幕上，无节制的打开新窗口肯定不是什么好事儿，是得在同一个窗口里打开详情页了，那么，从详情页返回列表后的问题也就更明显了。

　　PC网页、移动设备APP、软件…应该说，在所有数字产品中几乎都会遇到这个问题。

　　像是这个客户端：

　　点击了左侧某个项，右边开始播放，左侧tabs收起，再次打开左侧tabs时，其实也是列表返回后的问题。

　　应该返回原地，因为…

　　刚才点进去看某一篇了，现在回来，很可能是想要继续往下看列表。而且，回到原地才最不陌生，在不陌生的页面上继续操作，才最不恐惧。

　　其实我觉得并不需要太多的说理由，因为原本就该如此。

　　列表就是一张张文件叠放在一起，每一张露出个标题来，从上往下捋(lǚ)着看，看到哪个标题感兴趣了，就拿出来看看，看完之后，接着往下看列表。

　　展开、弹出详情使得返回原地看上去更合理

　　用这些形式展示详情，返回列表后列表保持不动显得更为理所应当。

　　如果弹出的详情页面更大些，充满整个屏幕，完全挡住列表，要再看到列表，就得点弹出窗口上的叉子，这与跳转到详情页就是一回事儿了。页面内的展开也是类似。这些应该说是更形象的展示方式，比起最原始的跳转页面，更形象了。

　　这些形式也与普通的跳转到详情页一样，列表保持不动，都要面对一些问题，也正是这些问题才让更多的设计者选择了刷新页面，回到页顶。

　　返回原地要面对的问题：

　　以前没移动设备，页面主要是PC的网页。返回后把重新载入页面，页面刷新了，也置顶了，这样做的好处：

　　1、可以展示更新了的内容;

　　2、知道当前位置。页顶的导航展示出了当前是在哪个页面，用户也知道现在是在页面顶端。

　　如果是返回原地，那这两个好处就没有了，变成需要解决的问题了。

　　为了这两个好处而刷新、置顶，有点儿舍本逐末了。是否返回原地，判断依据应该是：怎么才是用户好理解的，用起来方便的。既然有这样的问题，我们就做出些配套设施直接来解决问题就好了。

　　配套设施

　　配套设施一、展示导航

　　展示出导航，让用户知道返回后回到的是哪个页面。

　　移动设备上，第一级的页面会用整行的导航，或在屏幕顶端，或在底端。二、三级的页面是有页面标题和返回按钮。移动设备上的产品层级通常不多，又有比较明确的设计规范，基本上，移动设备上的产品，确保返回后的页面展示清楚导航都能做的比较好。

　　对于PC软件，像上面看到的搜狐影视这样的客户端产品，展示清楚导航基本也没啥问题，内容的列表怎么滚动，导航或在上，或在左侧，不跟着滚动，一直都在。

　　对于PC网页，就比较悲催了。由于古代网页的技术局限，形成了现在网页的传统，所有内容都是在一整个页面里的，页面往下滚动，导航就滚出去了。不过现在也越来越多的网页产品不再拘泥于这个局限了，当导航要滚出屏幕时，让导航浮动起来，卡在页面最顶端，比如，淘宝的详情页。这虽然也不见得是最好的形式，但至少这是个有益的尝试。这个页面需要有导航，而不仅仅是这个页面的首屏需要有导航。

　　配套设施二、用滚动条展示当前所在位置

　　设施一是为了展示当前页面在整个产品中的位置，设施二是为了展示清楚当前屏所显示的是此页面中的哪个部分，是页面内的导航。

　　其实并不需要强调要“用滚动条”，这是具体的表现形式了，要的是展示清楚当前屏在整个页中的位置。不过，貌似除了滚动条似乎也没有什么更好的方式了。

　　现在移动设备操作系统中，右边的那个条，相比起传统意义上的滚动条，变窄了，也不能操作了，纯粹是为展示当前位置用的了。

　　IOS上的窄滚动条只在用户滚动列表时才出现，意思是说，你要滚动页面时才会需要了解当前位置，在阅读页面上内容时，并不需要窄滚动条。这个思路挺好的，对于小屏幕的移动设备，“适时出现”这个设计思路尤其有用。但是在返回列表这个时候，我觉得也还是应该忽现一下子。窄滚动条出现的原则应该是：需要的时候出现，而不是滚动屏幕时出现。

　　配套设施三、提供“返回顶端”操作

　　回到了原地，这原地可能已经是列表很靠下的位置了，要回到顶端，触屏上连续向下翻动也好，pc上连续滚鼠标滚轮也好，都是体力活儿，而且是浪费体力的活儿。所以需要有个返回顶端功能，不过形式倒不必拘泥。

　　pc上有越来越多的网站给自己的长列表右下角加上“top”按钮了。移动设备上，如果总是在屏幕上贴个“top”按钮就太讨人嫌了，IOS提供了很隐蔽的top功能：点列表最上面分割线的区域。这也是个很智慧的方式。因为，操作系统是个针对熟手的产品，功能隐晦些，需要些学习成本是可以接受的，学会了以后，用起来效率很高。

　　配套设施四、“新信息”提示

　　以前网页上返回直接就刷新页面，更新的内容就刷出来了。如果是返回原地，那么，有了新消息，就给及时告诉用户。

　　用户是老板，面对着排成一列的大批文件，正在逐个文件标题的看，其中一些会抽出来仔细看。这时，又来了几分新文件，作为一位称职的秘书，应该怎么做?不告诉老板肯定不对;把文件放在文件长列的最前面并把老板直接拉过去，这也不好;应该告诉老板一声：“又来几份新的”如果能更体贴，还可以附加一句：“其中还有一份是特重要的某某项目的文件。”

　　称职的秘书就是我们的产品，有新消息时，应该提示，而且得让用户看见，目前的微博，移动设备的版本，会在屏幕底部的导航上显示出个数字，而网页版的只是在列表最上面多顶出来一行提示，只要页面滚下去了，就看不到这个提示了。

　　配套设施五、跳去“新消息”之前的阅读位置，应该mark

　　这个功能出现在用户去查看新消息之后，是上一个功能：“新信息”提示的补充。

　　用户点击了“新信息”的提示，去查看新信息了，看过了最新的之后，很有可能是要回到刚才中断的那个位置继续往下看。如果之前已经滚了好几屏了，那个位置就不那么容易找了。

　　这个功能是一个典型的为任务而设计的功能，完全是为了这种特定的任务情景而设计的，与产品的结构没什么关系。

　　之所以会想到这么个功能，源于对任务的罗列，我自己甚至将其成为“任务罗列法”，这个方法是这样的：在完成了产品基本架构设计的基础上，无限详尽的描述所有可能的任务，来检验现有的产品，确保重要任务很顺利，次要任务能达成，没有任务完不成。

　　补充上以上五个配套设施， “返回原地”基本上就比较ok了。提供这五个个配套设施的基本思路是：

　　1. 描述当前状况;

　　2. 提供可行的操作。

　　设施一、导航，设施二、页面内导航，都是在展示当前状况。设施三、回到顶端，对于提供了可以做的操作。设施四、提示有新信息，即是描述状况同时也提供相应操作。设施五、mark之前的阅读位置，描述的是用户点击了新消息之前的状况，同时提供相应操作。

　　“返回原地”的适用范围

　　对于PC、移动设备、网页、APP，“返回到原地”这个设计方案都是适用的，但在时间维度上，却不能无限制的扩大。

　　如果是昨天睡前刷过微博，在一个详情页关闭了微博APP，今天早上起来再打开微博APP，还要保证返回到列表页原地不动，恐怕价值就不大了。

　　“返回原地”隐含的前提是：刚才从这儿离开的，返回来时，用户应该多少还对位置有点儿印象。

　　“返回原地”目的是：用户继续浏览列表比较方便，如果昨天看过微博，今天早上起来再打开微博，恐怕“继续阅读”的可能性就很小了。

　　这里讨论的是从列表离开的情况，如果不是列表页呢?如果是从一个首页，或者其他什么页面，进入某个下一级页面，然后再返回来，是不是也应该返回原地呢?

　　以列表为研究对象，是从比较简单也最常见的情况入手研究问题。搞清楚了之后，对于更复杂的情况，我们也可以依据这些结论来做判断。

　　扯远了…

　　关于“描述当前状况，提供可行的操作”，这里设计配套设施用到了。以前关于按钮应该表状态还是表操作曾经讨论过。对于有开/关两种状态的按钮，比如静音按钮，播放/暂停按钮，按钮上的图标应该表达怎样的含义?是表达“当前是有声状态”?还是表达“按这个按钮可以静音”?最完整的表现就是应该表现出：1、当前是什么状态;2、还能做什么操作。

　　在返回列表这个问题上又用到了这个理解。实际上这是一个具有普遍意义的理解方式，对于一个系统，首先应该展示清楚当前是什么状况，比如：正在下载中，处于编辑状态，系统故障中…然后还需要根据当前状态提供对应的操作：正在下载，那应该提供中断操作;正在编辑状态中，提供编辑的功能;系统故障中，是不是可以刷新?

　　关于列表这种形式与现实的映射，这个理解，在这儿是为了辅助理解列表的返回，其实这种理解还有更多的价值，比如：列表与详情页之间的切换形式，列表页之间的切换形式，翻页与向下加载更多的取舍…

　　关于“用户是老板，产品是秘书”，这是一种对产品的定位，在研发产品的过程中，这种角色定位不仅是对产品整体方向的把握这种抽象层面的指导，对于新消息该怎么提示这种具体设计也有价值。

　　当然，并不见得所有产品都得是秘书，也许你的产品是位专业的顾问，或者是热情洋溢的主持人。

　　关于“任务罗列法”，无限详尽的去描述用户在使用这个产品时会是什么样子。虽然我们平时也经常在设计完成后这样过一遍，看看能不能走通，但往往是检验的过于简单。我建议将这些任务的描述写下来，像写小说那样，几百字几千字，写着写着就能发现问题了。

　　有些产品，结构简单，但却会被反复使用，使用情景很多很复杂，比如：一个下载列表，一个邮件收件箱，对于这样的产品，任务罗列往往比较有用。