開發者也是用戶 - 第二部分：改善 UI 和 API 可用性的五條指導原則

時間 2019-11-17

原文原文鏈接

原文地址：Developers are users too — part 2: 5 More guidelines for a better UI and API usability

原文做者：Florina Muntenescu

譯文出自：掘金翻譯計劃

本文永久連接：github.com/xitu/gold-m…

譯者：tanglie1993

校對者：corresponding，hanliuxin5

咱們對本身與之交互的全部東西的可用性都有相同的預期，包括 UI 和 API。因此，咱們用於 UI 的指導原則也能夠被轉化到 API。咱們在前一篇文章中已經看到了前面五條指導原則。如今，是時候看看剩下的了。html

開發者也是用戶 — 第一部分 _改善 UI 和 API 可用性的五條指導原則_medium.com前端

6. 識別而不是回憶

UI: 識別出熟悉的事物所耗費的認知代價是最小的，而且它還能被上下文環境所觸發。回憶意味着從記憶中取出細節，它須要多不少的時間。從一系列選項中選擇，比根據記憶寫出選項容易不少。一個使用常見 icon 的簡單 UI 是基於識別的，一個命令行界面是基於回憶的。信息和功能應該被設計得明顯，符合直覺而且容易使用。java

鉛筆 icon 是一個表示編輯的符號，容易識別，與 app 無關。android

使名稱清晰、易於理解

A 變量名稱應該說明它表明什麼，而不是如何使用： isLoading, animationDurationMs.ios

A 類名稱應該是一個名詞，說明它表明什麼：RoomDatabase, Field.git

A 方法名稱應該是一個動詞，說明它作什麼：query(), runInTransaction().github

7. 使用的靈活性和效率

UI: 你的應用可能被沒有經驗和經驗豐富的用戶同時使用。建立一個 UI使其迎合這兩種用戶的需求，並讓他們習慣經常使用的操做。聽說，20% 的功能被 80% 的用戶使用。你須要在簡潔和功能之間權衡。找出你的 app 中的那 20%，而後把它們變得儘量簡單易用。使用逐步展示原則，讓其餘用戶在次要的頁面使用進階功能。算法

Wi-Fi 設置默認顯示基本選項，但也包含進階選項。它適合用戶的需求。數據庫

寫有彈性的 API

用戶應當可以使用 API 高效地完成任務，所以 API 須要有彈性。好比，在查詢數據庫時，Room 提供不一樣的返回值，容許用戶進行同步查詢，使用LiveData，或者若是他們喜歡的話，使用 RxJava2 中的 API。後端

@Query(「SELECT * FROM Users」)
// synchronous
List<User> getUsers();
// asynchronously
Single<List<User>> getUsers();
Maybe<List<User>> getUsers();
// asynchronously via observable queries
Flowable<List<User>> getUsers();
LiveData<List<User>> getUsers();
複製代碼

把相關的方法放在相關的類中

若是一個類和一個開發者寫出的代碼沒有直接關係，那麼他一般很難找到其中的某個方法。並且，一般包含大量有用方法的 Util 和 Helper 類會很難找到。在使用 Kotlin 時，解決這個問題的方案是使用擴展函數。

8. 美觀和極簡的設計

UI: UI 應當保持簡單，只包含當時和用戶相關的信息。不相關或不多使用的信息應當被刪除或者移到其它屏幕，由於它們的存在使用戶分心，而且減小了相關信息的重要性。

Pocket Casts app 使用極簡設計

這個播客 app 的集列表頁面顯示最少許的，和上下文相關的信息：若是用戶沒有下載某集，這一集的大小和下載頁面是可見的；若是用戶已經下載，就能夠見到時長和播放按鈕。同時，對於那些好奇的用戶而言，詳情頁面包含全部這些信息，而且不止於此。

API: 用戶們有一個目標：用你的 API 更快解決問題。因此把它們的路徑作得儘量短和直接。

不要暴露內部 API 邏輯

API: 沒必要要地暴露 API 內部邏輯會讓你的用戶困惑，並下降你的 API 的可用性。不要暴露沒必要要的方法和類。

不要讓用戶作任何 API 可以作的事情

API: 從 22.1.0 開始，Android Support Library 提供 RecyclerView 相關的一系列對象，使用戶能夠基於頻繁改變的大型數據集建立 UI 元素。當列表改變時，RecyclerView.Adapter 須要被通知哪些數據被更新了。這使得開發者創造他們本身的用於比較列表的方法。在 25.1.0 版本的 Support Library, 這類反覆出現的代碼被 [DiffUtil](https://developer.android.com/reference/android/support/v7/util/DiffUtil.html) 類極大簡化了。並且，DiffUtil 使用通過優化的算法，減小你須要寫的代碼量而且加強性能。

9. 幫助用戶識別、診斷並擺脫錯誤

UI: 向你的用戶提供有助於識別、診斷並擺脫錯誤的錯誤信息。好的錯誤信息明確指出有東西出錯了，使用禮貌而易讀的語言準確描述問題，包含有助於解決問題的建議。避免顯示狀態碼或者異常類名稱，用戶不會知道如何處理這些信息的。

建立事件時的錯誤信息。來源

在輸入區域失去焦點時儘快顯示錯誤信息，不要等到用戶點擊提交表單的按鈕。更不要等到服務端傳來錯誤信息。使用 TextView 的功能來顯示錯誤信息。若是你在建立一個事件表單，你要經過直接給 UI 控件設置限制的方法，防止用戶建立發生在過去的事件。

快速失敗

API: 一個 bug 被報告得越早，它就會形成越少的損失。所以，失敗的最好時機就是在編譯期。例如，Room 會在編譯期報告任何不正確的查詢或者類註解。

若是你不能在編譯期失敗，最好儘快在運行時失敗。

異常應當用於指示異常的狀況

API: 用戶不該當使用在控制流中使用異常。異常應當僅用於例外狀況，或者 API 的不正確使用。儘量使用返回值來指示這些狀況，由於捕獲並處理異常幾乎老是比測試返回值要慢。

例如，試圖把 null 值插入一個有 NON NULL 限制的列中，就是一種異常的狀況，會拋出 SQLiteConstraintException。

拋出具體的異常。儘可能使用已有的異常

API: 開發者知道 IllegalStateException 和 IllegalArgumentException 是什麼意思，哪怕他們不知道你的 API 中發生了什麼。經過拋出已有的異常來幫助你的 API 用戶，使用盡可能具體而不是籠統的異常，並好好填寫錯誤信息。

在經過 [createBitmap](https://developer.android.com/reference/android/graphics/Bitmap.html#createBitmap%28android.graphics.Bitmap,%20int,%20int,%20int,%20int%29) 方法建立 Bitmap 時，你須要提供新 bitmap 的寬高等信息。若是你傳入小於 0 的值做爲參數，這個方法將會拋出 IllegalArgumentException。

錯誤消息應當準確指示問題

API: 爲 UI 寫錯誤信息的指導原則，也適用於 API。提供細緻的錯誤信息，以幫助用戶修復他們的代碼。

好比，在 Room 中，若是一個查找在主線程運行，用戶將會得到 java.lang.IllegalStateException: 不能在主線程訪問數據庫，由於它有可能把 UI 鎖住較長的一段時間。這代表查詢被執行時的狀態（在主線程）是不合法的。

10. 幫助和文檔

UI: 你的用戶應當可以不用文檔使用你的應用。對於很是複雜或者領域專門化的 app，這也許是不可能的。因此，若是須要文檔，確保它易於尋找、易於使用，並解答了常見的問題。

諸如「幫助」或者「發送反饋」之類的元素一般在導航菜單底部

API 應當是自說明的

API: 好的方法、類和成員命名使 API 可以闡明自身的意義。但不管 API 多好，沒有好的文檔就沒法被使用。這就是每一個 public 的元素——方法，類，域，參數——應當用文檔說明的緣由。對於你，一個 API 開發者來講簡單易見的東西，也許對於你的 API 用戶來講就不那麼容易和顯然了。

示例代碼應該是模範代碼

API: 示例代碼有若干用途：他們幫助用戶理解 API 的目的，用途，以及上下文。代碼片斷 用於解釋如何使用基本的 API 功能。教程教用戶關於 API 特定層面的知識。代碼示例 是更加複雜的例子，一般是一整個應用。這三者之中，缺乏代碼示例會引發最嚴重的問題，由於開發者看不到總體圖景——你全部的方法和類是如何協做的，以及它們是如何與系統協做的。

若是你的 API 流行起來了，有可能會有數以千計的開發者使用這些例子。他們將會成爲如何使用你的 API 的例子。所以，你犯的每一個錯誤都會讓你自作自受。

這些年，咱們學習了不少關於 UI 可用性的知識；咱們知道用戶們須要什麼，以及他們在想什麼。他們須要符合直覺、高效、正確的 UI，而且要能幫助他們用合適的方式完成特定任務。這些概念都不止於 UI，還適用於 API，由於開發者也是用戶。因此，讓咱們經過可用的 API 幫助他們（也是幫助咱們本身）吧。

API應當易用且不易濫用——它應該易於作簡單的事，可能作複雜的事，不可能——至少難以——作錯誤的事 Joshua Bloch — source

參考文獻

10 Usability Heuristics for User Interface Design
www.apiusability.org/
Myers, B. A., & Stylos, J. (2016). Improving API usability. Communications of the ACM, 59(6), 62–69. PDF
Bloch, J. (2006). How to design a good API and why it matters. Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications. ACM. PDF
Ellis, B., Stylos, J., & Myers, B. (2007). The factory pattern in API design: A usability evaluation. Proceedings of the 29th international conference on Software Engineering. IEEE Computer Society. PDF
Robillard, M. P. (2009). What makes APIs hard to learn? Answers from developers. Software, IEEE, 26(6), 27–34. PDF
Scheller, T., & Kühn, E. (2015). Automated measurement of API usability: The API Concepts Framework. Information and Software Technology, 61, 145–162. PDF
Preventing User Errors: Avoiding Conscious Mistakes
Error Message Guidelines
Material Design Patterns and Guidelines