突然就到了周日傍晚。你永遠不會知道自己的生活在接下來的一周當中能夠發(fā)生多少變化；各種不可預知性所帶來的更多是快感還是焦慮與不安，冷暖自知。相比之下，白天工作當中那些需求列表與排期文檔就顯得那么可愛了，哪怕有各種臨時任務或需求變更，也最多只是讓人在身體上疲勞一些而已。但有些事就遠沒這么簡單了。
無名無狀的話說到這里。今天的這篇更新是iOS7界面設計規(guī)范預發(fā)布版本第一章的最后一個小節(jié)了；我這邊的漢化工程暫時告一段落。正如之前提到的，接下來會有我現(xiàn)在的一些同事參與進來，大家一起貢獻更多的力量。屆時，相關內(nèi)容可能會首發(fā)到團隊博客當中。那，眼下先感謝各位最近兩周的鼓勵與支持唄；從下周開始，沒有意外的話，Beforweb會繼續(xù)回到各種UX文章的更新上來。
重要：這是針對于正在開發(fā)中的API或技術的預備文檔(預發(fā)布版本)。雖然該文檔在技術精確度上經(jīng)過了嚴格的審核，但并非最終版本，僅供蘋果開發(fā)者計劃的注冊會員使用。蘋果提供這份機要文檔的目的，是幫助你按照文中描述的方式對技術的選擇及界面的設計開發(fā)進行規(guī)劃。這些信息有可能發(fā)生變化，屆時，你的設計開發(fā)方式需要基于最終版本的操作系統(tǒng)及文檔進行相應的調(diào)整和測試。該文檔或許會隨著API或相關技術在未來的發(fā)展而進行更新。
譯文最后更新時間：2013-06-30
使用標準UI元素
盡可能使用UIKit框架定義的各種標準UI元素。使用標準UI控件而非自定義元素，你和你的用戶都會受益：
- 如果iOS本身經(jīng)過重新設計，那么標準的UI元素在系統(tǒng)更新時可以隨之自動更新，而自定義的UI元素不會。
- 人們會立刻了解怎樣使用你的應用，因為他們已經(jīng)習慣于標準的UI元素。
為了充分發(fā)揮系統(tǒng)標準UI元素的價值，你必須：
在使用任何一個標準UI元素的時候都要依照設計規(guī)范的指導。當一個UI元素無論看上去還是用起來都符合用戶的期待時，他們就可以依靠已有的經(jīng)驗來更快更容易的使用你的應用了。你可以在UI元素一章中找到各類UI元素的規(guī)范。
通常，不要為標準的交互行為創(chuàng)建自定義UI控件。首先問問自己，為什么要創(chuàng)建一個行為方式與標準UI控件完全相同的自定義控件？如果你只是想要一種訂制化的外觀，可以考慮通過UIKit框架當中用來訂制外觀的API來改變標準UI元素的樣式，或是改變元素的配色風格。如果你想得到的行為與標準控件的行為有些許區(qū)別，那么首先要確認能否通過屬性的調(diào)整來使標準元素完成同樣的目標。如果你需要的是徹頭徹尾的訂制化交互行為，那么在設計自定義控件的時候，要確保它看上去不會與標準控件相似。
技巧：Interface Builder可以幫你很輕松的創(chuàng)建標準UI元素、使用訂制外觀的API、設置外觀屬性、向控件中添加系統(tǒng)預設或自定義圖標等等�？梢詤⒖糥code用戶指南了解更多詳情。
不要為系統(tǒng)預設的按鈕和圖標賦予其他的含義。iOS提供了很多按鈕與圖標，你要讀懂相關的文檔，了解這些按鈕與圖標在語義上的含義，不要單純依靠自己對它們外觀的理解。如果你發(fā)現(xiàn)預設的按鈕或圖標無法準確的代表你想要表達的功能含義，那么可以自己創(chuàng)建。你可以在欄按鈕圖標一節(jié)當中找到相關規(guī)范，幫你更好的設計自定義圖標。
如果你的應用可以帶來沉浸型的體驗，那么打造完全自定義的控件是合理的做法。因為你在創(chuàng)建一種獨特的體驗環(huán)境，對于用戶來說，探索與該環(huán)境進行互動的方式也是他們所期待的體驗之一。
對橫豎屏切換的響應
人們通常會希望能夠在任何定向方式下使用iOS設備，所以最好讓你的應用可以在這些情況下做出恰當?shù)捻憫?/p>
讓用戶在橫豎屏狀態(tài)下都能聚焦于最重要的內(nèi)容。這個目標具有最高優(yōu)先級。人們需要在應用當中查看他們所關注的內(nèi)容，并與之交互；如果橫豎屏切換會使用戶失掉焦點，他們便會感到迷失，并覺得喪失了對應用的控制權。
通常，要讓應用能夠運行在各種定向模式當中。人們可能會期望在任何定向方式下使用你的應用，能滿足他們的期望是最好的。特別是iPad用戶，他們會希望你的應用能夠運行在他們當前所使用的任何持機方式下。當然，有些應用確實只能運行在豎屏或橫屏當中；如果你的應用是這樣，那么你應該參考以下幾點原則：
- 應用在啟動時只按照默認支持的定向方式進行加載，忽略當前設備的屏幕方向。如果一款游戲或媒體瀏覽類型的應用只能運行在橫屏下，那么就直接以橫屏模式啟動，即使設備本身是處于豎屏狀態(tài)的；這種時候人們會明白需要調(diào)轉(zhuǎn)屏幕才能正常瀏覽內(nèi)容。
- 避免在界面中通過UI元素提示人們調(diào)轉(zhuǎn)設備屏幕。直接按照默認支持的定向方式啟動應用，這就已經(jīng)清楚的告訴用戶需要旋轉(zhuǎn)設備了，不需要再增加多余的UI元素進行引導。
- 同時支持兩種子狀態(tài)。譬如，如果你的應用只能運行在橫屏當中，那么無論當前橫屏的方式是Home鍵在左手邊還是右手邊，人們都可以正常使用；如果人們在使用過程中將設備調(diào)轉(zhuǎn)180度，那么應用最好也可以進行響應，自動調(diào)轉(zhuǎn)180度。
如果對于你的應用來說，調(diào)轉(zhuǎn)屏幕方向是用戶輸入方式的一部分，那么你可以通過特定的方式進行訂制化的處理。例如，在一款游戲當中，人們需要通過旋轉(zhuǎn)屏幕來產(chǎn)生相應的行為，那么游戲本身就不可以再響應橫豎屏切換的規(guī)則了。這種情況下，你可以允許用戶在進入主線流程之前仍然能夠切換子狀態(tài)(Home鍵在左手邊或右手邊)，而一旦進入主線流程，那么旋轉(zhuǎn)屏幕就只能用來觸發(fā)游戲當中的特定行為。
在iPhone上，判斷用戶在調(diào)轉(zhuǎn)屏幕方向時的需求所在，并進行響應。人們從豎屏切換到橫屏時，通常是因為想要“看到更多”。如果你只是簡單的將內(nèi)容尺寸放大，那么未必能滿足用戶的期望。試著調(diào)整每一行文字顯示的字數(shù)，如果需要，甚至是重新調(diào)整UI布局，使其能夠呈現(xiàn)更多的內(nèi)容。
在iPad上，盡量支持所有的定向方式，滿足用戶的期望。由于iPad自身屏幕規(guī)格較大，所以上一條中提到的“用戶旋轉(zhuǎn)屏幕以便看到更多”的需求是相對較弱的。相比于iPhone，人們不太關注于iPad的設備框架限制，以及Home鍵的位置，所以在很多時候，人們不會將iPad看做一種有默認定向方式的設備。如果可以，盡量讓人們在任何持機狀態(tài)下都能在iPad中與你的應用進行互動。
在為iPad應用設計橫豎屏響應規(guī)則的時候，遵守以下幾點規(guī)范：
- 考慮改變輔助信息或功能的展示方式。雖然你必須確保重要內(nèi)容始終能夠獲取用戶注意力的焦點，但對于次要信息或功能，可以考慮隨著橫豎屏切換而改變呈現(xiàn)方式。以iPad內(nèi)置的郵件應用為例，賬戶和郵箱列表就屬于次要信息(當前選中郵件的詳情是主要內(nèi)容)。在橫屏時，次要信息被放置在左側(cè)面板中，而豎屏時，則是呈現(xiàn)在彈出面板里的。對于某些游戲，在橫屏狀態(tài)時的界面邊界到了豎屏當中也許需要進行重繪，這就有可能導致邊界上下留出額外的空余空間。這種情況下，可以考慮在這些空余空間當中展示一些游戲輔助信息或?qū)ο蟆?/li>
- 避免無意義的布局變化。盡量在所有定向方式下都提供具有一致性的體驗。具有相似性的體驗可以讓用戶通過已經(jīng)掌握的使用模式在橫豎屏當中輕松操作。如果你的iPad應用會在橫屏時以網(wǎng)格的形式展示圖片，那么在豎屏時，就沒有必要一定更改為列表形式。
- 如果可能，在切換橫豎屏時盡量避免對信息內(nèi)容樣式的重新定義。盡量保持內(nèi)容具有相似的格式樣式，特別是對于文字內(nèi)容來說，不要讓用戶因為切換橫豎屏所導致的版式變化而無法找到之前閱讀到的地方。如果有些內(nèi)容樣式必須發(fā)生變化，那么要通過動畫過渡效果來幫助人們更好的跟隨這些變化。例如，當橫豎屏切換時，內(nèi)容當中必須增加或減少一行文字，那么可以考慮在增加和減少的過程里使用漸入和淡出的動畫效果。為了讓自己設計出更好的橫豎屏切換方案，可以想象一下，如果你是在現(xiàn)實世界當中與這些內(nèi)容進行物理性的互動，那么它們有可能表現(xiàn)出怎樣的行為規(guī)律。
- 為橫豎屏各提供一張單獨的啟動圖片。這樣，無論人們在那種持機方式下打開應用，都可以感受到平滑的啟動體驗。與iPhone當中的系統(tǒng)首屏不同，iPad的系統(tǒng)首屏是支持橫豎屏切換的，人們有可能在任何方式下退出前面一個應用，并繼續(xù)打開你的應用。
弱化文件和文檔的處理過程
iOS可以幫助人們創(chuàng)建和管理文件，但這不意味著人們在使用iOS設備時必須思考文件系統(tǒng)方面的問題。
在iOS當中，不存在類似OS X系統(tǒng)中的Finder這樣的應用，用戶也不應該被要求與文件直接打交道，特別是不該去面對任何會讓他們聯(lián)想到文件源數(shù)據(jù)或存儲位置一類信息的東西，例如：
- 確認打開或保存文件的對話框。
- 關于文件訪問權限的信息。
盡量讓人們在不需要打開桌面端iTunes的情況下管理各種文檔�？紤]使用iCloud來幫助用戶訪問他們在不同設備上的內(nèi)容。要為用戶提供更好的iCould體驗，可以參考iCould一節(jié)。
如果你的應用提供創(chuàng)建及編輯文檔的功能，那么可以嘗試提供某種“文檔選擇器”，幫助用戶打開已有文檔或創(chuàng)建新文檔。理想情況下，這樣的文檔選擇器應該：
- 具有高度的圖形化外觀。讓人們可以輕松的通過圖形化的界面外觀來識別出他們想要的文檔。
- 讓人們使用最少量的手勢來完成目標操作。例如，通過封面流或網(wǎng)格的形式組織文檔，讓用戶通過滑動手勢進行瀏覽，并通過點擊來打開。
- 提供新建文檔的功能。不要讓用戶必須到其他地方創(chuàng)建新文檔，而是直接在文檔選擇器當中點擊文檔圖形上的某種默認占位圖片來直接創(chuàng)建。
提示：你可以使用Quick Look預覽功能讓用戶在你的應用中對文檔進行預覽，即使你的應用并不支持這類文檔的打開操作。參考Quick Look一節(jié)了解更多。
給用戶一種安全感，讓他們知道自己的工作成果始終會被保存，除非他們主動取消保存或進行刪除。如果你的應用提供創(chuàng)建及編輯文檔的功能，要確保這些數(shù)據(jù)無需用戶手動執(zhí)行也可以得到保存。iOS應用應該承擔起幫助用戶保存輸入內(nèi)容的責任，無論是他們在當前文檔仍然處于打開狀態(tài)的時候去查看另外一個文檔還是切換到其他應用。
不過，如果你的應用的主要功能并不是創(chuàng)造內(nèi)容，但你需要讓人們可以在查看信息與編輯信息在兩種模式間進行切換，那么在這種情況下你可以提醒用戶對信息變更進行保存。通常，可以在查看信息的視圖界面中提供“編輯”按鈕，當用戶點擊了這個按鈕之后，就會進入編輯狀態(tài)，同時原來的“編輯”按鈕變?yōu)?ldquo;保存”和“取消”這兩個按鈕。這種變化可以提醒人們，他們現(xiàn)在正處于編輯模式，可能需要執(zhí)行保存操作，而“取消”按鈕則為他們提供了在不保存變更的情況下直接退出編輯模式的出口。
必要的時候提供設置方式
有些應用可能需要向用戶提供安裝或設置選項，不過多數(shù)應用是不需要的，或是可以推遲必須進行設置的環(huán)節(jié)。成功的應用可以讓多數(shù)用戶立刻上手使用，而且會在UI當中提供一些可以調(diào)整體驗模式的方法。
盡量避免將用戶打發(fā)到系統(tǒng)的“設置”當中進行操作。要記得，用戶必須首先離開你的應用才能進入系統(tǒng)的設置，你不會希望鼓勵用戶這樣做的。
如果你能按照目標用戶群當中大多數(shù)用戶的期望來設計產(chǎn)品，就可以減少這種設置方面的需求。如果你需要用戶的某些信息，可以首先試著從系統(tǒng)當中存儲的用戶信息當中進行查詢，而不是讓用戶再次進行輸入。如果你決定必須在應用中提供設置功能，可以參考iOS應用編程指南當中的“The Settings Bundle”一節(jié)了解更多信息。
如果有必要，讓用戶盡量在你的應用內(nèi)部進行設置。在應用內(nèi)提供設置選項，可以讓相應的變更可以直接體現(xiàn)出來，讓用戶即時的看到變更結(jié)果，而無需在你的應用與iOS的“設置”之間進行切換。
如果需要，盡量在應用的主界面中提供設置選項。特別是當設置選項對應著應用的主要任務，或是用戶可能頻繁的變更設置的時候，最好將相關的設置選項直接放置在主界面當中。如果你要提供的設置功能對用戶來說只是偶爾才會用到，那么就盡量將它們放在單獨的界面當中。