微薄客户端元素隐藏功能

提问

前些日子在构思自己理想的手机微薄客户端的时候碰到了这么个问题。

我的某个想法之一是在浏览时，主界面上一些无关的元素自动隐藏，其触发动作(trigger)当然是拉动时间线（timeline）。

问题一：「（往）下拽 timeline」 还是 「（往）上推 timeline」 触发主界面元素自动消失呢？

注: 「下拽」手指向下滑动屏幕；  「上推」手指向上滑动屏幕
有隐藏，当然也相应的必须有元素重新出现才行。所以牵涉到第二个问题：
问题二：用什么操作来促使主界面重新出先呢？
问题二看似很简单，仔细想还是有不少细微之处。后文中我会提出来。

这两个看似简单的问题，可能得费些时间才能说清楚。

文中大多是「我」的一家之言，仅供君参考。

 

Part I: 「上推」 还是 「下拽」 ？

首先是问题一中 上推还是下拽 的问题。

手势背后的用户需求

上推 和 下拽 的真正实质的区别在哪里？
在于我们阅读微薄的方式是  从新往旧（上推）  还是 从旧往新（下拽）

在微薄客户端中，表现形式之一如 ： 更新微薄后，主界面是自动跳转到最新的一条，还是留在更新内容的最后一条。AppStore做的比较好的几个新浪微薄客户端采用了不同的方法。

[caption id=”attachment_4757” align=”aligncenter” width=”300”] 左侧 墨客 采用「下拽」；右侧 Weico 采用「上推」[/caption]

 

自己稍微考量了下，对比如下：（ + 代表优点，-  代表缺点）

新 –> 旧（上推）:

• 能看到 消息 已知的最新版本   （抱歉这个概念说得这么绕口）

•  要阅读刚加入的消息时，不得不离开当前的阅读位置，导致阅读不连续。

旧 –> 新（下拽）：

• 时间线清晰，阅读体验连贯     （最新的微薄会在最顶端按时间加入）

• 可能会读到 消息 的陈旧版本    （最坏的情况是你获得错误的信息）
  以上一张图新浪微薄为例，「墨客」借鉴tweetbot采用的是下拽，而「Weico」则是上推。

转化为用户的实际需求来考量的话，简要的说就是：

阅读连贯性  vs.  消息的实时性

阅读连贯性更重要

在我看来，消息的实时性相比而言不是那么重要。

原因之一：客户端更新内容所跨的时间段较短。以我个人使用为例，我关注了约200活跃用户，在晚上8点左右（发微薄高峰时间之一）更新50条微薄所跨时间大概在15分钟左右。15分钟出现内容反差极大的信息的机率算是比较低（个人经验判定）。

原因之二：微薄于日常主要是生活娱乐和交流的作用，作为碎片时间的填充而存在，可靠程度比不上传统的电话短信等等。重要的消息一是不会只在微薄上发布，二是关注的人也多半不止通过微博一条渠道。

而对于阅读的连贯性来说，这是每次使用客户端都一定会碰到的。

所以，如果我是PM，我会选择优先阅读的连贯性，也就是说采用「下拽」的「旧–>新」方法。

注：墨客 和 Weico 其实都有意无意的相对做了改进，有可能的话，我会详细撰文分析，除此此外，我对于解决 消息实时性问题 想出了一些自己觉得可行的解决办法，如果有机会的话会一并写出。

 

Part II: 元素何时出现，何时隐藏？

首先，以 Apple 自家的 iBook为例:

[caption id=”attachment_4765” align=”aligncenter” width=”300”] 单击屏幕后隐藏所有与内容无关的UI元素[/caption]

 

阅读体验很赞不是么？我甚至觉得最上的状态栏都有点碍眼。（实际上很多阅读类APP都去掉了这个突兀的黑条）

「滑动」是个不错的手势

对于微薄，同样的是内容为主的app，我也希望能有这样的阅读体验。当然，出于很明显的原因，用单击触发 元素的隐藏 是不靠谱的。多次点击更不可靠，一来容易误操作，二来和长按一样，会有使用延时（所以其实在整个移动端都很少用到，我亦未见用得好的）。

剩下常见的还有 「捏」「拖动」「滑动」「旋转」。「拖动」和「旋转」看起来都不是简单而不易误判的货，也不常用、更不适用这里；而「捏」看起来非常简单，而且在微薄中没有冲突（其实图片缩放要经常用到），但是这和日常使用习惯差了太多，培养用户习惯的成本是很高的，况且是要在一个这么基本的功能上，想象一下功能按钮全部隐藏时却不知道怎么把它们弄出来的尴尬情况吧。

那就只剩「滑动」了。现在其实有不少的客户端也在使用类似的功能，但是大部分的逻辑是有问题的。而新浪微薄客户端中，Weico的元素消失功能是做的最好的，我觉得他们不放手普及到主界面的大部分元素真是浪费了…

根据用户需求安排功能逻辑

我来简要分析下：

与「滑动」有关的操作有哪些呢？ 当然要考虑到静止状态。

你可能说也可能直接「上推」到「下拽」，well，可以直接将其考虑为 2和3 组合的静止时间极短特例。

如前文所说的，我选择用「下拽」模式来展现微薄内容。因而在这个前提下各个操作可能的涵义如下：

操作1. ： 刷新后，用户开始阅读内容。（扫读）

操作2. ：看到感兴趣的内容，停下来仔细阅读。（细读）

操作3. ： 回看之前的内容。（细读）

操作4. ：回看完毕。

请着重注意括号里面加粗的内容。

按照我的逻辑，

1. 扫读时，用户会很快速的追求阅读的数量，此时多余的UI元素会干扰阅读。

2. 细读时，用户的注意力集中，而且聚焦在那唯独一条微薄区域上，周围的UI可能会干扰到阅读，但相反的也可能会提供需要的功能。

所以，

操作1：必须要保证隐藏

操作2&3：可以隐藏也可以并不隐藏（其实是有差别的，但现在体现不出来）

操作4 ：一般是要存在的（此时阅读完毕，会使用功能按钮）

 

Part 3：实际问题会复杂不少

上面说的都是很简单的基础逻辑。

实际操作中，在加入了不少的功能或者互动元素之后，原本无关紧要的东西会变得很棘手。

比如，元素UI隐藏 不会只是简单的滑动后立即触发，一般来说，实际中会采用在屏幕 动小段距离 后再触发。在加入这“一小段”的判定后，操作2&3其实是有很大的差别的，改天再分析好了。