這個Watch Lists其實很長，有幾十項，表現(xiàn)出來是這樣：每頁只顯示5項，可以顯示在一屏內(nèi)，然后翻頁。
在PC網(wǎng)頁的設(shè)計時我們知道：把更多的內(nèi)容放在一個頁面里展示，比跳轉(zhuǎn)頁面更好，用戶更容易看到。幾米長的門戶首頁就是這么來的。
突如其來的手機(jī)應(yīng)用，可能是讓一些設(shè)計師有點兒不知所措了，覺得手機(jī)屏幕小，單手指操作有特點，等等我也不是很清楚的原因，最后得出了這么個結(jié)論：每個頁面都不能滾動。這個結(jié)論顯然有點兒不妥，而且，想要嚴(yán)格的實現(xiàn)，幾乎不可能。
不斷的下一頁下一頁，再上一頁上一頁，每次翻頁又都需要載入新頁面，顯然不好用了，相比之下，“自選股”這樣一個長列表會好一些。
要處理一個長列表時，放在一頁里上下滾動會比切分成多頁更好。嗯，這個結(jié)論或許下的有點兒早。
“短列表+翻頁”的一個大問題在于每次都要載入頁面，使得下一頁的顯示需要一些時間，不流暢了。對于一個長列表如果滾動的時候不流暢，會卡，當(dāng)然會讓人覺得不爽，那短列表不斷翻頁，可以看做是一種更大的卡吧，顯然更不爽。
那么，如果短列表+翻頁，但不卡呢?事先加載好了，只是不用滾屏的形式，每頁都是沒滾動條的，一頁頁很流暢的翻，是不是ok?
Feedly就是這樣。
每頁剛好顯示一屏，不滾動，向上滑動翻到后面一頁。
如果“短列表+翻頁”預(yù)先加載好了，那么，“短列表+翻頁”與“長列表”兩種形式的差別僅僅在于給用戶的表現(xiàn)模型不同：一個是盒裝紙巾，一張又一張;另一個是成卷的衛(wèi)生紙。這兩種模型都是不難理解的。
不過類似Feedly這種表現(xiàn)形式需要解決一個額外的問題：如果我已經(jīng)翻到了第12頁，此時想返回去看第4頁的某個內(nèi)容，怎么才能快速的到達(dá)?
對于一個大頁面，當(dāng)前屏幕只能顯示其一部分的時候，如何告訴用戶當(dāng)前顯示的是整個大頁面的哪個部分;應(yīng)該提供怎樣的功能讓用戶可以高效的回到頁頂，去到頁底，或達(dá)到頁面中某一個特定的位置。這一系列問題，在PC上是由窗口滾動條負(fù)責(zé)解決的，不用細(xì)說了，大家再熟悉不過了。
手機(jī)系統(tǒng)中的滾動條退化了，只能顯示當(dāng)然所在位置，而不能提供操作了。android可以使勁兒的滑動一次性滾動更遠(yuǎn)，IOS可以點列表頂端接縫處快速回到頂端，快速的滾動也能一次滾動更多，但似乎沒有android的效果明顯。這些都是為了頁面內(nèi)的導(dǎo)航，但還都不如pc上窗口滾動條強(qiáng)大。
Feedly把正整卷衛(wèi)生紙裁成了一張張的，將原本的頁面內(nèi)導(dǎo)航問題變成了頁面間的跳轉(zhuǎn)，于是連手機(jī)系統(tǒng)里提供的這一點點頁面內(nèi)導(dǎo)航功能都用不上了。如果我翻到了第12頁，想回去看看第4頁，就得往回多翻幾次了，或者回到第一頁，再往后翻三下。哪種方法效率都不太高。
手機(jī)因為小，設(shè)計上總體的方向是簡化，減掉的自然應(yīng)該是少數(shù)用戶、少數(shù)時候會用到的功能。對于feedly這個手機(jī)版閱讀器，多數(shù)用戶每天只是來看看新聞，并不需要經(jīng)常的精確的去查找某篇文章，甚至可以說，不需要實現(xiàn)從第12頁快速回到第4頁的功能，但別的產(chǎn)品也許就是比較需要的，比如，有100項的股票列表。
一個使用了feedly這種“短列表+翻頁”形式的股票觀察列表，或許可以自己單獨做些導(dǎo)航功能，為自己的這個裁剪成多段的長列表服務(wù)，讓各段間的跳轉(zhuǎn)更高效。
既然如此麻煩，那干脆就“自選股”這樣，直接就長列表，簡單，直白，也省掉了那些麻煩。最樸素的形式是有其簡樸的魅力，不過真是個100項的長列表，要從第12屏回到第4屏其實也不很快，也得滾好幾下，而且操作不容易很精準(zhǔn)，你也估計不出來到底得滾幾下。
手機(jī)通訊錄里有那種通過字母快速到達(dá)的導(dǎo)航功能，或許應(yīng)該廣泛應(yīng)用;或許也需要我們?yōu)樽约旱拈L列表做些單獨的頁面內(nèi)導(dǎo)航，只靠操作系統(tǒng)提供的通用功能并不總夠用。
重慶分公司
重慶分公司
