px、pt、dp、sp 大混戰
px、pt、dp、sp 大混戰

dpi、ppi、px、pt、dp、sp 之類的名詞釋義網路文章已經有很多,但全部混在一起運用到 Mockup 上時該怎麼處理?

這個問題其實我也爬了滿久的文,沒翻到有比較完整的說法,所以自己整理了一篇。

形色 - 会上瘾的识花神器
形色 - 会上瘾的识花神器

這篇是意外插隊。在網路上亂逛爬資料時無意發現這款 App,評價還很高。第一代 iPad 剛出的時候,我做過寶石、甲蟲的標本箱 App,也做過從外觀、聲音、棲地辨認鳥類的科學型 App,看到能辨識花朵的 App 覺得好親切啊~

iOS、Android 字級單位

「這是靠我自己摸索出來的喔!是拿 App 截圖進 Photoshop 辛辛苦苦比對所量出來的尺寸。」這位 UI 先生/小姐,你知道世界上有 Guideline 這種文件嗎?「比起問別人,自己摸索出來的才記得深刻嘛!」你知道世界上有工程師這號人物嗎?浪費一堆時間在 PS 量半天為了什麼?文件上寫得一清二楚。字級要用是 pt 或是 px 轉頭問問 RD 立刻就有答案了。

反應與提示

8.jpg
在易用性原則裡,系統狀態的能見度、辨識而非記憶這兩點與「反應」有關。在操作 App 時,「反應」扮演著重要角色,它有著引導使用者至下一步的功能,幫助使用者理解目前狀況、繼續操作。在 iOS 上,常見的反應有數種:視覺、聽覺、觸覺。點擊某個按鈕,按鈕會變成被擊中凹下去的樣子,輸入正確會聽到叮叮的成功提示音,操作錯誤或失敗手機會震動並聽到嘟嘟的錯誤提示音等等。如果對於 App 的「反應」置之不理,使用者就無法知道自己操作的結果,對於自己的操作產生疑慮、逐漸失去對這個 App 的信賴度。

各種狀態與突發狀況

即使畫了非常精細的 UI FLOW、每一頁 Wireframe 旁也寫上詳盡的註解,但在專案後期 RD 仍是發現許多在前期規畫階段沒有被考慮進去的情況,這是為什麼呢?有一種可能性是漏了思考「各種狀態」和使用者的「突發狀況」。這會導致開發時程延後,因為訂定的規則不夠準確而再次召開討論會議確認細節。甚至發現此路不通但該功能已經做下去了無法修改進退兩難的情況。

十大易用性原則

身為 RD 的你受過太多 UI 的氣嗎?老是發現邏輯不通需要打掉重練被延誤時程嗎?常被 UI 嫌念理工的沒有美感都不懂嗎?報仇的時間到了。這篇文雖然說是「十大易用性原則」,也可以說得上是:「教你如何捅 UI 」。RD 最擅長講理,就來跟 UI 講理!從易用性下手找 UI 麻煩,沒有幾位 UI 不中刀的…