交互設計:從詳情頁返回列表頁,應該是回到頂端還是回到原地?
在一個列表頁上點擊某個項,進入詳情頁,再從詳情頁返回列表頁,應該是回到頂端還是回到原地?
返回到列表時,列表不應刷新、頁面不應回到頂端,應該是返回原地,回到剛才離開的那個位置。
對于PC的網頁,這個問題并不典型,因為,新鏈接是在原窗口打開還是在新窗口中打開,這都還沒個定論,如果是在新窗口中打開,也就不存在返回列表頁的情況了。
現(xiàn)在移動設備上,尤其是手機這么小的屏幕上,無節(jié)制的打開新窗口肯定不是什么好事兒,是得在同一個窗口里打開詳情頁了,那么,從詳情頁返回列表后的問題也就更明顯了。
PC網頁、移動設備APP、軟件…應該說,在所有數(shù)字產品中幾乎都會遇到這個問題。
像是這個客戶端:
點擊了左側某個項,右邊開始播放,左側tabs收起,再次打開左側tabs時,其實也是列表返回后的問題。
應該返回原地,因為…
剛才點進去看某一篇了,現(xiàn)在回來,很可能是想要繼續(xù)往下看列表。而且,回到原地才最不陌生,在不陌生的頁面上繼續(xù)操作,才最不恐懼。
其實我覺得并不需要太多的說理由,因為原本就該如此。
列表就是一張張文件疊放在一起,每一張露出個標題來,從上往下捋(lǚ)著看,看到哪個標題感興趣了,就拿出來看看,看完之后,接著往下看列表。
展開、彈出詳情使得返回原地看上去更合理
用這些形式展示詳情,返回列表后列表保持不動顯得更為理所應當。
如果彈出的詳情頁面更大些,充滿整個屏幕,完全擋住列表,要再看到列表,就得點彈出窗口上的叉子,這與跳轉到詳情頁就是一回事兒了。頁面內的展開也是類似。這些應該說是更形象的展示方式,比起最原始的跳轉頁面,更形象了。
這些形式也與普通的跳轉到詳情頁一樣,列表保持不動,都要面對一些問題,也正是這些問題才讓更多的設計者選擇了刷新頁面,回到頁頂。
返回原地要面對的問題:
以前沒移動設備,頁面主要是PC的網頁。返回后把重新載入頁面,頁面刷新了,也置頂了,這樣做的好處:
1、可以展示更新了的內容;
2、知道當前位置。頁頂?shù)膶Ш秸故境隽水斍笆窃谀膫€頁面,用戶也知道現(xiàn)在是在頁面頂端。
如果是返回原地,那這兩個好處就沒有了,變成需要解決的問題了。
為了這兩個好處而刷新、置頂,有點兒舍本逐末了。是否返回原地,判斷依據應該是:怎么才是用戶好理解的,用起來方便的。既然有這樣的問題,我們就做出些配套設施直接來解決問題就好了。
配套設施
配套設施一、展示導航
展示出導航,讓用戶知道返回后回到的是哪個頁面。
移動設備上,第一級的頁面會用整行的導航,或在屏幕頂端,或在底端。二、三級的頁面是有頁面標題和返回按鈕。移動設備上的產品層級通常不多,又有比較明確的設計規(guī)范,基本上,移動設備上的產品,確保返回后的頁面展示清楚導航都能做的比較好。
對于PC軟件,像上面看到的搜狐影視這樣的客戶端產品,展示清楚導航基本也沒啥問題,內容的列表怎么滾動,導航或在上,或在左側,不跟著滾動,一直都在。
對于PC網頁,就比較悲催了。由于古代網頁的技術局限,形成了現(xiàn)在網頁的傳統(tǒng),所有內容都是在一整個頁面里的,頁面往下滾動,導航就滾出去了。不過現(xiàn)在也越來越多的網頁產品不再拘泥于這個局限了,當導航要滾出屏幕時,讓導航浮動起來,卡在頁面最頂端,比如,淘寶的詳情頁。這雖然也不見得是最好的形式,但至少這是個有益的嘗試。這個頁面需要有導航,而不僅僅是這個頁面的首屏需要有導航。
配套設施二、用滾動條展示當前所在位置
設施一是為了展示當前頁面在整個產品中的位置,設施二是為了展示清楚當前屏所顯示的是此頁面中的哪個部分,是頁面內的導航。
其實并不需要強調要“用滾動條”,這是具體的表現(xiàn)形式了,要的是展示清楚當前屏在整個頁中的位置。不過,貌似除了滾動條似乎也沒有什么更好的方式了。
現(xiàn)在移動設備操作系統(tǒng)中,右邊的那個條,相比起傳統(tǒng)意義上的滾動條,變窄了,也不能操作了,純粹是為展示當前位置用的了。
IOS上的窄滾動條只在用戶滾動列表時才出現(xiàn),意思是說,你要滾動頁面時才會需要了解當前位置,在閱讀頁面上內容時,并不需要窄滾動條。這個思路挺好的,對于小屏幕的移動設備,“適時出現(xiàn)”這個設計思路尤其有用。但是在返回列表這個時候,我覺得也還是應該忽現(xiàn)一下子。窄滾動條出現(xiàn)的原則應該是:需要的時候出現(xiàn),而不是滾動屏幕時出現(xiàn)。
配套設施三、提供“返回頂端”操作
回到了原地,這原地可能已經是列表很靠下的位置了,要回到頂端,觸屏上連續(xù)向下翻動也好,pc上連續(xù)滾鼠標滾輪也好,都是體力活兒,而且是浪費體力的活兒。所以需要有個返回頂端功能,不過形式倒不必拘泥。
pc上有越來越多的網站給自己的長列表右下角加上“top”按鈕了。移動設備上,如果總是在屏幕上貼個“top”按鈕就太討人嫌了,IOS提供了很隱蔽的top功能:點列表最上面分割線的區(qū)域。這也是個很智慧的方式。因為,操作系統(tǒng)是個針對熟手的產品,功能隱晦些,需要些學習成本是可以接受的,學會了以后,用起來效率很高。
配套設施四、“新信息”提示
以前網頁上返回直接就刷新頁面,更新的內容就刷出來了。如果是返回原地,那么,有了新消息,就給及時告訴用戶。
用戶是老板,面對著排成一列的大批文件,正在逐個文件標題的看,其中一些會抽出來仔細看。這時,又來了幾分新文件,作為一位稱職的秘書,應該怎么做?不告訴老板肯定不對;把文件放在文件長列的最前面并把老板直接拉過去,這也不好;應該告訴老板一聲:“又來幾份新的”如果能更體貼,還可以附加一句:“其中還有一份是特重要的某某項目的文件。”
稱職的秘書就是我們的產品,有新消息時,應該提示,而且得讓用戶看見,目前的微博,移動設備的版本,會在屏幕底部的導航上顯示出個數(shù)字,而網頁版的只是在列表最上面多頂出來一行提示,只要頁面滾下去了,就看不到這個提示了。
配套設施五、跳去“新消息”之前的閱讀位置,應該mark
這個功能出現(xiàn)在用戶去查看新消息之后,是上一個功能:“新信息”提示的補充。
用戶點擊了“新信息”的提示,去查看新信息了,看過了最新的之后,很有可能是要回到剛才中斷的那個位置繼續(xù)往下看。如果之前已經滾了好幾屏了,那個位置就不那么容易找了。
這個功能是一個典型的為任務而設計的功能,完全是為了這種特定的任務情景而設計的,與產品的結構沒什么關系。
之所以會想到這么個功能,源于對任務的羅列,我自己甚至將其成為“任務羅列法”,這個方法是這樣的:在完成了產品基本架構設計的基礎上,無限詳盡的描述所有可能的任務,來檢驗現(xiàn)有的產品,確保重要任務很順利,次要任務能達成,沒有任務完不成。
補充上以上五個配套設施, “返回原地”基本上就比較ok了。提供這五個個配套設施的基本思路是:
1. 描述當前狀況;
2. 提供可行的操作。
設施一、導航,設施二、頁面內導航,都是在展示當前狀況。設施三、回到頂端,對于提供了可以做的操作。設施四、提示有新信息,即是描述狀況同時也提供相應操作。設施五、mark之前的閱讀位置,描述的是用戶點擊了新消息之前的狀況,同時提供相應操作。
“返回原地”的適用范圍
對于PC、移動設備、網頁、APP,“返回到原地”這個設計方案都是適用的,但在時間維度上,卻不能無限制的擴大。
如果是昨天睡前刷過微博,在一個詳情頁關閉了微博APP,今天早上起來再打開微博APP,還要保證返回到列表頁原地不動,恐怕價值就不大了。
“返回原地”隱含的前提是:剛才從這兒離開的,返回來時,用戶應該多少還對位置有點兒印象。
“返回原地”目的是:用戶繼續(xù)瀏覽列表比較方便,如果昨天看過微博,今天早上起來再打開微博,恐怕“繼續(xù)閱讀”的可能性就很小了。
這里討論的是從列表離開的情況,如果不是列表頁呢?如果是從一個首頁,或者其他什么頁面,進入某個下一級頁面,然后再返回來,是不是也應該返回原地呢?
以列表為研究對象,是從比較簡單也最常見的情況入手研究問題。搞清楚了之后,對于更復雜的情況,我們也可以依據這些結論來做判斷。
扯遠了…
關于“描述當前狀況,提供可行的操作”,這里設計配套設施用到了。以前關于按鈕應該表狀態(tài)還是表操作曾經討論過。對于有開/關兩種狀態(tài)的按鈕,比如靜音按鈕,播放/暫停按鈕,按鈕上的圖標應該表達怎樣的含義?是表達“當前是有聲狀態(tài)”?還是表達“按這個按鈕可以靜音”?最完整的表現(xiàn)就是應該表現(xiàn)出:1、當前是什么狀態(tài);2、還能做什么操作。
在返回列表這個問題上又用到了這個理解。實際上這是一個具有普遍意義的理解方式,對于一個系統(tǒng),首先應該展示清楚當前是什么狀況,比如:正在下載中,處于編輯狀態(tài),系統(tǒng)故障中…然后還需要根據當前狀態(tài)提供對應的操作:正在下載,那應該提供中斷操作;正在編輯狀態(tài)中,提供編輯的功能;系統(tǒng)故障中,是不是可以刷新?
關于列表這種形式與現(xiàn)實的映射,這個理解,在這兒是為了輔助理解列表的返回,其實這種理解還有更多的價值,比如:列表與詳情頁之間的切換形式,列表頁之間的切換形式,翻頁與向下加載更多的取舍…
關于“用戶是老板,產品是秘書”,這是一種對產品的定位,在研發(fā)產品的過程中,這種角色定位不僅是對產品整體方向的把握這種抽象層面的指導,對于新消息該怎么提示這種具體設計也有價值。
當然,并不見得所有產品都得是秘書,也許你的產品是位專業(yè)的顧問,或者是熱情洋溢的主持人。
關于“任務羅列法”,無限詳盡的去描述用戶在使用這個產品時會是什么樣子。雖然我們平時也經常在設計完成后這樣過一遍,看看能不能走通,但往往是檢驗的過于簡單。我建議將這些任務的描述寫下來,像寫小說那樣,幾百字幾千字,寫著寫著就能發(fā)現(xiàn)問題了。
有些產品,結構簡單,但卻會被反復使用,使用情景很多很復雜,比如:一個下載列表,一個郵件收件箱,對于這樣的產品,任務羅列往往比較有用。
本文地址:http://m.likemindfilms.com/tutorial/id1849.html