之所以想到这个问题，是因为刚好看到了这篇不错的文章：《思考计算设备的无干扰设计》。

　　里面提到了关于新闻页的设计，举的例子有LifeHacker和《纽约时报》。

　　然后我就在想，当我看新闻的时候，我一般会干些什么事？

～

　　由于一般新闻中，总会有一些前提内容是我不知道的（我不是Wiki，这点真让人沮丧），所以看到我不了解的内容的时候，我总会去搜索相关内容，以确保我没有理解错原文，或者确保我能够真正理解全文。

　　这个过程是需要跳出以搜索的，但无论理由为何，这种跳出总是会打断当前思路的。

　　我自诩为人形（伪）多线程智慧生命体，但频繁陷入Wiki之牢【就是怀抱着目的A进入Wiki，然后打开了几十个知识点An和Bn以及Cn的页面，最终线程锁死……】总是让人不爽的。

　　但，如果放任不管，当我看完全文后我可能就忘了我之前对哪些东西有疑惑了，需要回头重新看一遍。这样的回炉重造也不是好的体验——即便我所需要的所有知识点都在文章末尾的脚注了，但因为产生疑惑和解决疑惑不是同步的，我依然需要回头去重温当时我到底是怎么想的，从而再度陷入回炉。

　　我希望的是：一遍下来，怀揣疑惑，奔赴Wiki之牢。

　　所以，如果让我设计新闻页，它会是这样的：

－

　　当用户初次阅读的时候，全文通篇是没有Link的——无论是指向它页，还是指向脚注。

　　随着用户将页面向下滚动（自然也包括刚载入的初始时刻），在页面可显示范围内的所有HintPoint都会很淡地低亮（也就是很低调地高量）后，进入SideBar的“知识点”组了。这个过程可以结合window.scrollY，document.documentElement.scrollTop，以及HintPoint所在span或者a的getBoundingClientRect来做到。

　　同时，用户可以用鼠标划词，划好以后的词自动进入上述知识点区，然后选区自动消失。

　　这个过程中用户收到的干扰极小，而且没有链接，也不需要打开别的页面（去Wiki），所以用户的整个阅读过程是连贯的。他／她／它唯一要做的是将自己不清楚的东西选出来，然后继续阅读——HintPoint自己是自动跳进碗里去的，不需要用户操作。

　　当用户全文阅读完毕后，所有知识点区的内容都在文章末尾自动以脚注的形式列出来——HintPoint本来就是脚注链接，这点无妨；用户自选词可以给出到Google的链接跳转，或者直接到Wiki的链接跳转。

　　整个过程用户所以要做的就是选择自己有疑惑的，然后就是网站自己来帮用户搞定。

　　用户不存在说“我忘了我前面想查什么”的情况，也不存在“哎我前面查这个时候读到哪了呀”的疑惑。

　　这样的体验，我感觉是极好的。

　　PS：上面这句话好恶心，我受不了了，容我出去吐吐……

　　接着，当用户第二次阅读的时候，体验就不同了。

　　一篇文章，初次阅读和再次阅读，用户的目的是不同的，而这也就决定了用户想要获得的服务是不同的。

　　第二次阅读，HintPoint可以直接以文内Link的形式出现，而不需要上述过程——因此此时用户想要的本来就已经不是连贯地通读全文了，而是对某一段文字的深研。此时，查资料查因果是主要任务，连贯地获取信息不是首要内容。

　　因此，此时HintPoint是直接文内超链接，而划词以后是自动弹出菜单让用户选择进行什么样的搜索——Google？Wiki？草榴？扔到Dropbox还是Evernote？这都随你！

　　当然了，用户自然也可以选择回归到初读模式，这是人家的自由嘛。

＝

　　同样的，对于写作的IDE来说，也是如此。

　　一般人，写作过程都可以分解为两部分：

　　１，文字编写；

　　２，排版布局。

　　最好的情况，就是这两件事是分开的，你先写完内容，然后根据内容来做排版布局，插图插画，强调突出整理列文献编目路索引，这些都应该是第二部分来完成的。

　　但，事实上，由于IDE的界面复杂性，很多人在做第一部分工作的时候，会被第二部分的功能给误导，然后就陷入了泥潭。

　　所以，好像是从2003开始，Office就让编辑版面是可以缩起的，增大可编辑区域，同时避免IDE对使用者的注意力产生干扰。而工具栏展开后，也可以根据内容性质的不同选择不同的工具界面。

　　既然IDE可以如此，阅读软件自然也可以如此来做——所以就回到了上面那部分的设计思路了。