中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

那些大的軟件公司，譬如Apple、微軟、Google等等，通常會為第三方app設(shè)計師們提供一系列設(shè)計指南。這樣做的目的在于：

• 一方面，設(shè)計師和開發(fā)者可以比較輕松的上手打造在質(zhì)量方面至少符合“基礎(chǔ)標(biāo)準(zhǔn)”的產(chǎn)品，而無需重新思考和驗證全新的設(shè)計模式及UI元素。
• 另一方面，如果某一平臺當(dāng)中的所有產(chǎn)品都遵從統(tǒng)一的設(shè)計規(guī)則，那么用戶也將受益于界面外觀與互動方式的一致性。

遵守設(shè)計指南，這幾乎是一條鐵打的規(guī)矩。但是在實際當(dāng)中，“官方標(biāo)準(zhǔn)”未必能很好的適用于各種情況。我們不清楚為什么有些元素會出現(xiàn)在設(shè)計指南當(dāng)中，也許是因為官方所做的測試不夠徹底，或者說這些元素和模式是用來解決某一類設(shè)計問題的最基礎(chǔ)最具適用性的解決方案。

本 文當(dāng)中提到的4種UI元素都是Apple慣于在自家app中使用的，其中的一些也出現(xiàn)在了官方的設(shè)計規(guī)范當(dāng)中；自然，不計其數(shù)的設(shè)計師也會跟從這些用法。 而另一方面，我們(Nielsen Norman Group)在一次又一次的可用性測試當(dāng)中也真真實實的發(fā)現(xiàn)了這些元素所導(dǎo)致的可用性問題。

說不定Apple的諸神會用雷劈我們，但我們?nèi)匀唤ㄗh各位設(shè)計師在使用這些UI元素時多加考慮，或嘗試優(yōu)化/替代方案，因為這些元素在可用性測試當(dāng)中的表現(xiàn)確實存在問題：

• 頁碼指示符(小圓點)
• 導(dǎo)航欄里的完成按鈕
• 加號(+)圖標(biāo)
• 拖拽圖標(biāo)

1.頁碼指示符(小圓點)

iOS的頁碼指示符，在形式上就是橫排的圓點，用來表示一系列可以通過橫滑瀏覽的分頁視圖。其中，代表當(dāng)前視圖的圓點處于高亮狀態(tài)，其他的則是灰暗的半透明狀態(tài)。

iOS 系統(tǒng)首屏，頁碼指示符用來表示頁面總數(shù)以及當(dāng)前所在位置。我們時常見到這種通過系統(tǒng)首屏來演示頁碼指示符使用方式的范例，實際上，頁碼指示符能完美適用的 界面環(huán)境并不多，而系統(tǒng)首屏正是其中之一，因為用戶明確的知道自己的手機里裝有很多app以至于第一屏無法完整呈現(xiàn)，需要通過橫向滑動查看更多。

很多app或網(wǎng)頁都會使用這種元素來暗示用戶可以通過橫向滑動來查看同級的其他頁面，也有一些是將其用在界面中特定的區(qū)域來暗示其中存在更多內(nèi)容。不能否 認(rèn)，這種形式的頁碼指示符在app和移動Web的界面設(shè)計當(dāng)中都很流行，但是要知道，它同時也是用戶最容易忽略掉的界面元素之一。在我們所做的一系列可用 性測試當(dāng)中，用戶經(jīng)常難以發(fā)現(xiàn)這些在尺寸上過于微小的圓點，進(jìn)而錯失了那些可以通過橫滑來查看到的內(nèi)容或功能入口。所以，我們認(rèn)為圓點形式的頁碼指示符至少不能被用作關(guān)鍵功能和內(nèi)容的唯一導(dǎo)航方式。

雖然iOS允許你將這些圓點渲染成其他顏色，但想要使如此微小的元素一目了然的突顯在界面當(dāng)中還是非常困難的，除非你能確保將其置于高對比度的純色背景上。 很多產(chǎn)品會將圓點們放置在五顏六色的banner圖上，使這些本就難以被留意到元素不知不覺的融入到背景當(dāng)中，進(jìn)一步降低了可發(fā)現(xiàn)性。如果一定要這樣做， 那么必須確保圓點和背景色之間始終具有較高的對比度，最好是使用純色背景。

iOS的Zappos，在第一張底圖上，頁碼指示符已經(jīng)很弱了，而在右側(cè)第二張底圖上，幾乎完全消失了。

有一部分產(chǎn)品則在iOS的基礎(chǔ)上進(jìn)一步自由發(fā)揮，將圓點改為方形或其他形狀，布局上也更加隨意。不妨設(shè)想，即便用戶已經(jīng)習(xí)慣了iOS的小圓點模式，現(xiàn)在他們 就算發(fā)現(xiàn)了界面中的這些小元素，還要猜想這些方塊會不會就是代表著以前的那些小圓點 – 可發(fā)現(xiàn)性沒有顯著提升，同時還造成了認(rèn)知上的困難。如果要使用頁碼指示符，盡可能使用用戶已經(jīng)熟悉的圓點模式，并將其居中的置于對應(yīng)內(nèi)容的下方。

Android中的Fab，借鑒了iOS模式的小圓點，但將其置于了內(nèi)容的右側(cè)，相比于居中的位置，更難被發(fā)現(xiàn)。

即便用戶能夠注意到頁碼指示符，這里還有一些潛在問題，譬如小圓點們可以讓用戶知道有多少同類型的信息視圖以及當(dāng)前所處位置，但無法提供任何與內(nèi)容本身相關(guān) 的信息。此外，用戶對互動的控制權(quán)也非常弱，必須按照次序逐一瀏覽，無法直接跳轉(zhuǎn)。所以，如果在你的需求當(dāng)中這些體驗要素比較重要，那么小圓點恐怕不是你 的最佳選擇。

鑒于小圓點頁碼指示符所存在的一些可用性問題，我們建議：

• 首先考慮你的內(nèi)容是否適宜通過橫滑的方式依次瀏覽，還是可以通過更復(fù)雜同時也更靈活的其他導(dǎo)航方式進(jìn)行架構(gòu)。
• 對于橫滑瀏覽的內(nèi)容，盡量采用右邊緣露出一部分內(nèi)容的方式來加強對于“更多”的暗示，而不要單純依靠頁碼指示符。

2.導(dǎo)航欄里的完成按鈕

iOS中很多代表“完成”操作的按鈕時常被置于導(dǎo)航欄當(dāng)中右側(cè)的位置，包括表單界面的提交按鈕也是如此。如今這種模式也開始潛移默化的影響到一些Android平臺里的app。

根 據(jù)我們的可用性測試所得出的結(jié)論，不說跨平臺的影響力，單就iOS本身，我們也不建議將“完成”性質(zhì)的按鈕放在這里，原因很簡單，將最終操作放置在界面頂 部，有悖于自上而下的信息流向。用戶在填寫表單或編輯內(nèi)容時，交互行為通常是由上至下的，當(dāng)他們即將完成的時候，也會預(yù)期在結(jié)尾處看到結(jié)束處理的操作。多 數(shù)情況下，當(dāng)人們無法在結(jié)尾處找到這樣的功能時，便會產(chǎn)生迷惑并開始四處尋找。

在下面的案例當(dāng)中(左側(cè)是Pinkberry，右側(cè)是 Nordstorm)，用戶填寫完表單之后需要點擊登錄或下單按鈕。這樣的布局就是我們所說的有悖于自上而下信息流向的形式，用戶的全部注意力都隨著表單 而逐漸下移，最終發(fā)現(xiàn)在結(jié)尾的地方?jīng)]有任何完成操作，剩下的就是茫然無措。要知道，即使是在手機這樣的小屏設(shè)備上，四處尋找某種UI元素也是需要耗費很多 額外的注意力成本的；將完成按鈕直接放置在內(nèi)容底部是最符合直覺的做法。

當(dāng)然，從另外一個方面講，將完成按鈕置于導(dǎo)航欄當(dāng)中的模式也有其自身的優(yōu)勢：因為導(dǎo)航欄是固定在頂部的，所以用戶在編輯內(nèi)容時可以隨時點擊到，而且當(dāng)內(nèi)容區(qū) 域較長時，放置在頂部的按鈕也不會被鍵盤所遮擋。如果用戶確實無需完成全部內(nèi)容的填寫便可以進(jìn)行完成操作，那么你可以考慮將完成按鈕固定在底部，并會隨著 鍵盤的起落而相應(yīng)的移動。這種方式的缺點是會占用一定的縱向空間，但優(yōu)點也是很明顯的：即符合直覺，又隨時保持可見，同時相比于頂部右端的位置來說，更易 單手點擊操作。

鑒于導(dǎo)航欄里的完成按鈕所存在的一些可用性問題，我們建議：將按鈕置于內(nèi)容底部；如果內(nèi)容較長，可以嘗試將按鈕位置固定，并使其不會被鍵盤遮擋，以便用戶可以隨時點擊。

3.加號(+)圖標(biāo)

見過的app越多，你越會發(fā)現(xiàn)，在不同的環(huán)境當(dāng)中，加號圖標(biāo)往往會代表各種不同的功能。當(dāng)加號位于導(dǎo)航欄當(dāng)中時，通常表示“新建”功能；如果被放在 列表單元當(dāng)中，要么是表示將這條內(nèi)容添加到某種分組當(dāng)中，要么是用來展開詳情。無論是在同一個app的不同界面，還是在不同的app之間，同一元素承載著 不同的功能含義，這對于用戶的認(rèn)知與記憶都是一種負(fù)擔(dān)。

加號圖標(biāo)的可用性在很大程度上取決于它在界面當(dāng)中所處的位置。當(dāng)位于導(dǎo)航欄時，加號通常能夠表達(dá)準(zhǔn)確的含義，即創(chuàng)建一條與主要內(nèi)容相同性質(zhì)的新內(nèi)容。然而，當(dāng)加號出現(xiàn)在主要內(nèi)容當(dāng)中時，多種含義的可能就會給用戶帶來迷惑。

舉個例子，Any.do曾經(jīng)的一個版本當(dāng)中，會在待辦事項分組標(biāo)題右側(cè)放置加號圖標(biāo)。在這個環(huán)境下，你不知道點擊這個圖標(biāo)是會展開其中的全部事項，還是會在這個分組中創(chuàng)建新事項。在最近的一個版本中，他們將加號放在了界面右上角，明確的用于創(chuàng)建新事項。

無論是Web還是移動app，位于界面內(nèi)容當(dāng)中的加號圖標(biāo)通常用來表示該內(nèi)容可以擴展查看更多信息，有時還會搭配箭頭圖標(biāo)同時使用。通過加號來觸發(fā)其他類型 的功能很可能破壞用戶所習(xí)慣的預(yù)期。例如，在LinkedIn的app當(dāng)中，取決于所在位置的不同，嵌套在圓環(huán)當(dāng)中的加號圖標(biāo)代表著關(guān)注或是加入某小組的 功能。在我們的可用性測試當(dāng)中，很多用戶抱著查看詳情的預(yù)期去點擊該按鈕，卻發(fā)現(xiàn)自己關(guān)注了對方動態(tài)，進(jìn)而感到莫名其妙。

取決于產(chǎn)品類型及目標(biāo)用戶行為習(xí)慣的不同，你的app當(dāng)中的加號圖標(biāo)可能最適于表達(dá)某個特定的功能含義。無論怎樣，要盡量避免在app當(dāng)中隨處使用，因為取 決于所處位置的不同，用戶確實很容易將其理解為不同的含義，或是抱著一直以來習(xí)慣的認(rèn)知進(jìn)行操作而導(dǎo)致與預(yù)期不符的結(jié)果。

鑒于加號圖標(biāo)所存在的一些可用性問題，我們建議：

• 導(dǎo)航欄是一個相對安全的位置，而在其他位置使用加號按鈕則需通過可用性測試來確保用戶能正確的理解你想表達(dá)的功能含義。
• 要徹底避免加號圖標(biāo)帶來的潛在問題，不妨徹底避免使用它，取而代之的，通過箭頭來代表詳情擴展，通過簡單明確的文字按鈕來清晰準(zhǔn)確的傳達(dá)其他功能含義。

4.拖拽圖標(biāo)

和移動設(shè)備上的很多其他圖標(biāo)一樣，拖拽圖標(biāo)也并不能很直觀的體現(xiàn)出背后的含義。我們發(fā)現(xiàn)很多用戶其實并不明白這個圖標(biāo)代表著所在元素是可以被拖拽移動的，而 且縱向排列的三條橫線也很容易讓人誤以為是某種菜單圖標(biāo)。實際上，這種形象隱喻的是可拖拽物體上的防滑條紋，好像你把手指放在上面就可以拖動整個對象而不 至于打滑。通常，用戶需要長按這個圖標(biāo)，使對象整體進(jìn)入某種激活狀態(tài)，然后拖拽到合適的位置。

在可用性測試當(dāng)中，我們發(fā)現(xiàn)，用戶更傾向于點按對象本身進(jìn)行拖拽，而不是去按住一個含義模棱兩可的小圖標(biāo)。相比于列表單元這樣的對象，圖標(biāo)在尺寸上太小了，如果要求用戶必須通過按住它來拖動整個單元，那么交互成本的增加就是必然的。此外，用戶也會認(rèn)為一個單元整體只會觸發(fā)一種行為，也就是無論拖拽小圖標(biāo)還是單元本身，都可以使其被拖動。

Yahoo! Finace使用了標(biāo)準(zhǔn)的iOS拖拽圖標(biāo)，用戶長按該圖標(biāo)可以使單元進(jìn)入可拖動狀態(tài)。雖然列表單元本身是目標(biāo)更大、更易操作、更符合直覺的對象，但用戶卻無法通過長按單元本身來達(dá)到觸發(fā)拖拽的目標(biāo)。

此外，我們還是要強調(diào)一下拖拽圖標(biāo)與我們所熟悉的漢堡包菜單圖標(biāo)真的過于相似了：

外形相同或過于相似的對象，所觸發(fā)的事件是截然不同的，這種情況會使人迷惑不安。雖然行業(yè)中關(guān)于漢堡包圖標(biāo)的爭論愈發(fā)激烈，但越來越多的用戶已經(jīng)開始習(xí)慣了 “點擊三根線的圖標(biāo)展開導(dǎo)航菜單”的模式。當(dāng)他們發(fā)現(xiàn)行為結(jié)果和他們所習(xí)慣的、所預(yù)期的東西不一致時，就會產(chǎn)生挫敗與迷茫。

鑒于拖拽圖標(biāo)所存在的一些可用性問題，我們建議：

• 至少允許用戶長按目標(biāo)單元整體也能實現(xiàn)拖拽的目標(biāo)，而不要只將交互區(qū)域限制在拖拽圖標(biāo)上。
• 另一方面，對于漢堡包菜單圖標(biāo)，可以嘗試更清晰明確的表達(dá)方式，例如在三根線前面增加三個點，或是同時放出“菜單”標(biāo)題在圖標(biāo)旁邊。

小結(jié)

背離“官方的”、“常見的”設(shè)計模式，總會讓人覺得不安，況且與大家的模式保持一致也能幫助用戶降低學(xué)習(xí)成本。但是，無論你決定遵從怎樣的設(shè)計規(guī) 范，我們都建議你通過必要的可用性測試來驗證這些模式是否真的適用于自家產(chǎn)品及目標(biāo)用戶。至少，在我們自己的研究過程當(dāng)中，我們見到了很多用戶在本文提到 的4個常見模式上遇到了足夠引發(fā)我們進(jìn)行思考的可用性問題。

原文地址：http://www.nngroup.com/articles/4-ios-rules-break/

譯文來自：http://beforweb.com/node/748

作者：C7210 – UX玩家、交互設(shè)計師、貓奴、guitar fucker，現(xiàn)就職于騰訊ISUX(上海)