交互設計：手機上的長列表

　　這個Watch Lists其實很長，有幾十項，表現出來是這樣：每頁只顯示5項，可以顯示在一屏內，然後翻頁。

　　在PC網頁的設計時我們知道：把更多的內容放在一個頁面裡展示，比跳轉頁面更好，用戶更容易看到。幾米長的門戶首頁就是這麼來的。

　　突如其來的手機應用，可能是讓一些設計師有點兒不知所措了，覺得手機屏幕小，單手指操作有特點，等等我也不是很清楚的原因，最後得出了這麼個結論：每個頁面都不能滾動。這個結論顯然有點兒不妥，而且，想要嚴格的實現，幾乎不可能。

　　不斷的下一頁下一頁，再上一頁上一頁，每次翻頁又都需要載入新頁面，顯然不好用了，相比之下，“自選股”這樣一個長列表會好一些。

　　要處理一個長列表時，放在一頁裡上下滾動會比切分成多頁更好。嗯，這個結論或許下的有點兒早。

　　“短列表+翻頁”的一個大問題在於每次都要載入頁面，使得下一頁的顯示需要一些時間，不流暢了。對於一個長列表如果滾動的時候不流暢，會卡，當然會讓人覺得不爽，那短列表不斷翻頁，可以看做是一種更大的卡吧，顯然更不爽。

　　那麼，如果短列表+翻頁，但不卡呢?事先加載好了，只是不用滾屏的形式，每頁都是沒滾動條的，一頁頁很流暢的翻，是不是ok?

　　Feedly就是這樣。

　　每頁剛好顯示一屏，不滾動，向上滑動翻到後面一頁。

　　如果“短列表+翻頁”預先加載好了，那麼，“短列表+翻頁”與“長列表”兩種形式的差別僅僅在於給用戶的表現模型不同：一個是盒裝紙巾，一張又一張;另一個是成卷的衛生紙。這兩種模型都是不難理解的。

　　不過類似Feedly這種表現形式需要解決一個額外的問題：如果我已經翻到了第12頁，此時想返回去看第4頁的某個內容，怎麼才能快速的到達?

　　對於一個大頁面，當前屏幕只能顯示其一部分的時候，如何告訴用戶當前顯示的是整個大頁面的哪個部分;應該提供怎樣的功能讓用戶可以高效的回到頁頂，去到頁底，或達到頁面中某一個特定的位置。這一系列問題，在PC上是由窗口滾動條負責解決的，不用細說了，大家再熟悉不過了。

　　手機系統中的滾動條退化了，只能顯示當然所在位置，而不能提供操作了。android可以使勁兒的滑動一次性滾動更遠，IOS可以點列表頂端接縫處快速回到頂端，快速的滾動也能一次滾動更多，但似乎沒有android的效果明顯。這些都是為了頁面內的導航，但還都不如pc上窗口滾動條強大。

　　Feedly把正整卷衛生紙裁成了一張張的，將原本的頁面內導航問題變成了頁面間的跳轉，於是連手機系統裡提供的這一點點頁面內導航功能都用不上了。如果我翻到了第12頁，想回去看看第4頁，就得往回多翻幾次了，或者回到第一頁，再往後翻三下。哪種方法效率都不太高。

　　手機因為小，設計上總體的方向是簡化，減掉的自然應該是少數用戶、少數時候會用到的功能。對於feedly這個手機版閱讀器，多數用戶每天只是來看看新聞，並不需要經常的精確的去查找某篇文章，甚至可以說，不需要實現從第12頁快速回到第4頁的功能，但別的產品也許就是比較需要的，比如，有100項的股票列表。

　　一個使用了feedly這種“短列表+翻頁”形式的股票觀察列表，或許可以自己單獨做些導航功能，為自己的這個裁剪成多段的長列表服務，讓各段間的跳轉更高效。

　　既然如此麻煩，那干脆就“自選股”這樣，直接就長列表，簡單，直白，也省掉了那些麻煩。最樸素的形式是有其簡樸的魅力，不過真是個100項的長列表，要從第12屏回到第4屏其實也不很快，也得滾好幾下，而且操作不容易很精准，你也估計不出來到底得滾幾下。

　　手機通訊錄裡有那種通過字母快速到達的導航功能，或許應該廣泛應用;或許也需要我們為自己的長列表做些單獨的頁面內導航，只靠操作系統提供的通用功能並不總夠用。