BalanceTree和交互设计

  "用tree描述交互流程,balance tree优化交互流程".
  这是前两天在G+和Twitter上说的.

  其实想法很简单.
  对于一个应用来说,都会有一个唯一的landing.
  即使是互联网的网站也会有一个理论上的主页,虽然,很多时候其实是某个特定链接.

  不管怎么样,只要使用一个东西,都会有一个最初的入口.
  所谓的landing.

  于是对应到tree,其实就是那个root.

  简单想一下,怎么描述跟这个landing的交互过程,以及由这个landing衍生出的其他东西.
  很自然的,第一个想法是state machine.

  然后稍微加些约束简化下模型,就可以得到一个唯一初始状态的状态机.
  于是,换个角度,其实就是一个tree.

  当然,实际情况可能复杂些.
  尤其是对于互联网,每一个地方都可能是入口.
  所以实际上,这个交互更像是graph.

  回到tree.
  
  其实tree本身便是graph的一个子集,只不过"单向"关系比较多.

  当然,tree也可以是双向的.
  只是,相对于纯粹的graph来说,直觉上联通性比较差.

  如果说实际的交互是一个graph结构,那么换个角度.
  每个交互序列其实都是从某个特定点开始的.
 
  上面说了,无论是graph还是状态机,其实都可以退化到某个特定的点.

  于是,说了那么多,想表达的其实就是,把东西简化下,约束下,交互流程其是就是一个tree结构.
  而且是节点间可以是双向关系.

  这算是解释了前半句.

  仔细想下,其实要说交互能够被tree描述的话,做的约束条件是它必须能退化成tree.
  也就是说必须没有交叉.

  形象地说,其实就是只能有前进和后退两个操作.
  一个前进操作不能越级,回溯到parents的sibling.

  即给定一个操作序列S,把序列里每个节点s的sibling考虑将来则有一个集合O包含s以及它们的sibling.
  也即是说,对于某个s的前进页面的集合F,必然有全集A,满足A=O+F
  即F和O是不相交的.

  只有满足这个,才能将整个交互退化为tree.

  而对于后半句,为什么要牵扯到balance tree呢.
  原因在于balance tree的一个属性在于其节点在插入和删除时候的auto balance.
  
  也就是之所以成为balance tree的原因在于,它的目的是使得整个tree的level尽可能地少.
  
  而诸多balance tree的实现里都是自适应.
  也即任何对tree的operation都附带着对tree level的维护.

  于是,投射到交互流程上面来说,你可以不停地修改增删交互点.
  而在修改的过程里,如果能够严格地保证整个交互满足graph->tree的退化原则,则整个过程其实都会自己维护交互深度/复杂度的.
  
  当然,它的完成结果并不一定是符合直觉的交互点安排.
  但是,它提供了一种辅助手段.

  而实际上,对于交互点的权值设置得越合理,那么对auto balance的最终结果做调整的概率就越低.

  证明很简单.
  当理论权值都是完美的,也就退化为寻常的数值插入了.
  
  而权值的赋予,则不能算是一个很模型话的东西.
  它更多的时候是一个依靠先期的对于交互频度的估计.

  虽然,它可以基于一些其他渠道的统计数据.
  但是,同时应该考虑交互环境异构的多样和复杂性.
  
  统计数据只能说明统计问题.
  说明不了个体问题.
  尤其是,这个统计本身受样本交互流程设计的影响.
 
  最后, "用tree描述交互流程,balance tree优化交互流程"这句话的意义其实在于.
  提供一种简单的约束方式.

  它的基本点其实就在于保证graph的可退化性.
  balance只是一个简单的工具思想.
  
  如此而已.