Office Add-in 設計規範與最佳實踐

做者：陳希章 發表於 2017年8月6日

引子

離上一篇Office Add-in的文章已通過去了一段時間，期間有去年Office 365 Asia Devday & Hackathon的二等獎得到者閆曉迪寫了Office365開發系列——開發一個全功能的Word Add-In ,另外我也寫了兩篇有關人工智能方面的文章

1. 人工智能背景下的Office 365現狀和發展趨勢
2. Office 365 機器人（Bot）開發入門

我一直在思考怎麼爲你們講解Office Add-in開發，一方面確實須要實例（因此咱們須要更多的閆曉迪站出來），另外一方面來講，我以爲從一開始就講解一些設計規範和最佳實踐可能對你們會有較大幫助。

固然，實際上我也沒有很是豐富的Office Add-in開發經驗，這方面還須要有時間和案例的積累。因此這一篇文章的主要內容都來自於官方的手冊，我稍微作了一些整理，增長了少許我我的的建議。若是但願查看英文的版本，請訪問：https://dev.office.com/docs/add-ins/overview/add-in-development-best-practices。

第一個規範：提供清晰的價值

這個原則之因此放在最前面，是由於它要回答「你爲何須要開發這個Office Add-in」的終極哲學性問題。

下面幾個最佳實踐是比較適合關注的

1. 在不增長中斷的狀況下，幫助用戶更好地基於Office Add-in完成創做。
2. 爲Offie 提供新的應用場景。
3. 爲Offie 嵌入一些輔助服務。
4. 提升Office 的使用體驗達到實現更好的生產力的目的。

我要補充的一兩點個人理解：一個好的Office Add-in由於提供明確，而且儘可能獨特的價值 —— 不要貪大求全，而是由於專一於作好一件事情。同時，用戶不該該被要求離開他當前所在的Office 環境，就能完成一些有意思的工做，而且與他自己在Office裏面作的工做無縫地融合在一塊兒。這個讓我想起在人工智能背景下的Office 365現狀和發展趨勢 中提到的Tap和Rsearcher這兩項功能。

若是你但願將你的Add-in發佈到Office Store，還有兩個文檔可能對你有用

1. 在發佈以前，經過 Office Store validation policies 以及 Office Add-in host and platform availability 來確保你想要提供的Add-in所須要知足的一些策略。
2. 經過了解Create effective Office Store listings的一些細節，提升你的Office Add-in在Office Store能更好地被查找到，甚至被推薦。

第二個規範：打造引人入勝的首次使用體驗

你永遠沒法改變留給別人的第一印象。這句話一樣適合於Office Add-in開發的領域。下面的一些最佳實踐或許能讓你的Office Add-in給人留下深入印象，而且願意長期使用下去。

1. 在首頁上面清晰地告訴（引導）用戶如何使用這個Add-in，不要一上來就要求用戶註冊啦，登陸啦，好好想想你到底能爲他們提供什麼。
2. 若是你的Add-in須要綁定數據，儘量在建立時提供範例數據做爲參考。
3. 提供試用版。做爲SaaS服務的一個基本理念，就是用戶能夠經過試用瞭解你的產品，而且決定是否要購買訂閱。而即使是有接受訂閱的高級版本，也建議保留一個免費的（但依然包含了有限功能的）版本。
4. 若是須要用戶註冊，應該儘量簡單，儘量預先填好一些基本信息，而且避免郵件驗證。
5. 若是有可能，應在應用中實現單點登錄的體驗，尤爲是對於現有Office 365用戶而言，他們自己就是有身份的。
6. 在應用中應該儘可能避免彈出窗口，若是沒法避免，則應該讓用戶決定是否啓用該功能。

雖然寫了這麼多條，但我總結起來可能就是一條：KISS原則用在這裏是恰如其分的 —— Keep it simple, stupid —— 若是你讓用戶思考，你就輸了。

第三個規範：使用Add-in Command

使用Add-in Command是很是常見的作法，它能夠用來在Office 應用程序中添加Ribbon按鈕，也能夠在快捷菜單中增長子菜單。點擊這些按鈕或者子菜單，能夠直接執行一段代碼（一般是Javascript函數），也能夠打開任務面板（Task Pane）以進一步操做。典型的Add-in Command效果圖以下所示：

考慮到對觸摸操做的支持，應該儘可能減小對於快捷菜單的依賴。

下面還有一些具體的建議

1. 儘量將Add-in Command經過添加組的方式合併到現有的Ribbon Tab（例如Insert，Review等）裏面去，固然前提是你的功能，正好跟這些Ribbon Tab的含義是匹配的。
2. 若是不匹配，則儘量放在Home這個Ribbon Tab，這樣能夠減小用戶查找你的Add-in Command的難度。
3. 可是若是你的自定義Add-in Command有超過6個頂級Ribbon Button，那麼就建議單首創建一個Ribbon Tab了。
4. 在命名上面，Ribbon組的名稱應該儘量跟你的Add-in一致。若是有多個組，那麼每一個組都應該有清晰的命名，讓用戶一眼就知道它的用途。
5. 不要添加多餘的按鈕。請考慮奧卡姆的簡單有效原則——「如無必要，勿增實體」。

第四個規範：遵循界面設計原則

值得高興的一件事情是，微軟爲開發人員專門提供了Office UI Fabric這一套UX 框架，你能夠直接使用Fabric Core Style開展工做，它主要提供了CSS的支持（字體，圖標，內置組件等），但也能夠結合你熟悉的UI框架使用，例如React和AngularJS。

Office UI Fabric是一切界面問題的解藥，與此同時下面還有一些能夠參考的最佳實踐

1. 確保你的Add-in的用戶體驗跟Office宿主程序一脈相承。

2. 如無必要，不要添加多餘的元素。

3. 爲1366*768的主流分辨率優化設計，儘可能避免滾動條。

4. 不要使用未經受權的圖像（或其餘素材）。

5. 使用簡單明瞭的語言。

6. 不要在Add-in作廣告。

7. 考慮不一樣平臺的適用性，包括鼠標、鍵盤和觸摸體驗。

   經過Context.touchEnabled 能夠檢測到當前是否運行在觸摸的模式下。若是在觸摸模式下，還有幾條參考的建議

   • 請確保全部的界面元素都擁有合適的尺寸。
   • 不要依賴於右鍵菜單和鼠標懸停等機制進行工做。
   • 確保在橫屏和豎屏的狀況下都能正常工做。
   • 在真實的設備中進行測試（使用Sideloading技術）

8. 增長輔助訪問功能。

第五個規範：將性能始終放在重要位置

之前咱們固然也講性能，但現在Office Web Add-in的話，這個就顯得尤其重要了，你的Add-in可能會被成千上萬的人使用，性能可能成爲你的制勝法寶，反過來也可能葬送你全部的努力。

除了一直要將性能放在重要位置，從思想上很重視它以外，下面也有一些具體的建議

1. 確保Add-in加載時間在主要的網絡環境下的加載時間不該該超過500毫秒。
2. 確保用戶交互操做的時間不超過1秒。
3. 若是是長時間操做，請提供進度提示。
4. 對於公共資源（圖片，CSS文件，腳本等）請考慮使用CDN技術加速，而且儘量在一個位置（儘量利用緩存的好處）。
5. 參考網站設計的一些基本規範。這個能夠參考我幾年前寫的優化網站設計的三十五條建議。