《iOS應用軟體設計之道》—— 2.5 何時畫草圖

本節書摘來自華章出版社《ios應用軟體設計之道》一 書中的第2章，第2.5節，作者：（美）william van hecke ，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

在若幹情況下，畫草圖是很有必要的。

描述架構提綱。最初，你要仔細檢查整個架構提綱，畫出每一幅畫面的内容。每個功能都要能看到，每步流向都要明确，架構提綱裡的每個條目都要以某種形式在草圖中展現出來。一時間，你的各個想法和注解組成了可供檢查和發展的基礎。這些草圖和提綱一起呈現出了對應用軟體應該如何表現的高層次了解。

直接畫架構草圖。倘若應用軟體規模較小，其功能可以通過所提供的畫面顯示來定義，就可以跳過架構提綱，直接從架構草圖開始。對小不點型的應用軟體（如内置的stocks或notes），這是最簡單的辦法。它們隻有幾個畫面，界面大都是靜态的，沒有太多的流向。

混合方法。有些時候，甚至在早期，你已經對應用軟體主界面有相當好的直覺了解。這些情況下，如果相信直覺，你可以從畫出螢幕開始：在熟悉的應用軟體裡編輯典型的文檔，在資訊型的應用軟體裡檢視典型的狀态畫面；在教育型的應用軟體裡開始一節典型的課程等。先做這個草圖，可能讓你有足夠材料來思考架構提綱。一旦你知道主界面的外觀該是怎樣的，就很容易列出所需做的其他事情。

除此之外，你還可以随時畫草圖。對于項目過程中冒出的大多數問題，畫點草圖都會有好處。草圖可以是含糊的，也可以是完整的，因情況而異。兩個人站在白闆前談論某個界面的細節，交談過程中可能會想出多個大緻可行的方案。而其他人随後看到這個白闆上的内容，也許搞不清楚它畫的是什麼。草圖隻是一種短暫的溝通輔助手段罷了。相比之下，架構草圖應當足夠清晰，你和别人可以參考這些草圖，無需太多解釋就能了解每個畫面的思路。

設計從來不會遵循一條事先能預見的路徑，原始提綱中描述的産品也不會恰好如你設想的那樣變成現實。那是正常的。持續不斷修改正是設計過程的一部分。在你不可避免地決定要添加或改變一項功能時，就要把它實作并畫出草圖，就像它一開始就在規劃中那樣。

一般來說，幾乎每樣東西都至少要畫一次草圖，也許畫好多次草圖才能定案。倘若你儲存了先前的草圖，則日後回顧這些草圖，就會驚奇于哪些部分沒有改變，回憶起那些可能還有些價值的過時想法，還會對你過去那些瘋狂無知的主意感到好笑。

時刻記住這是ios平台

如果你還沒讀過蘋果開發者網站上的《ios人機界面指導原則》（ios human interface guidelines），那麼現在是該讀這本書了。要想大體了解在這個平台上可做什麼、能做什麼，你要把這部書牢記于心。即使你已經用ios的應用軟體好幾年了，并對其深有體會，也肯定有些你不知道的地方。例如，你知道模态視圖的四種風格嗎？每種風格适用于什麼情況？

花時間熟悉你在ios上可做什麼的基礎知識，這是很值得的：表格視圖、導航控制器、分割視圖、浮動框等。如果想了解更深入，可以參看本書第3章對《ios人機界面指導原則》做的延伸和評述。

當然，在給iphone或ipad畫草圖時，記住比例系數（即硬體螢幕的尺寸）是很關鍵的。記住在ipad上，所有草圖要既能适用豎向放置（垂直），又能适用橫向放置（水準）；而在iphone上，可以容易地隻用一種放置模式。同樣，所有要輸入文本的畫面都應該容納鍵盤，在某些語言中還要容納出現在鍵盤上方的完成欄。

沒有必要為每個想法畫若幹個草圖，每個草圖都包含放置模式和鍵盤的狀态，但不要創作任何依賴某種放置模式而鍵盤一旦出現就會破壞整個效果的草圖。現在就記住這些要考慮的因素，在第3章中會正式地探究它們。