程式員養成架構

整理了一下自己對於一位程式員該如何經歷哪些過程以進行養成的心得，繪製成圖表如下：



這個將成為自己安排教育訓練的架構。

逆讀 iOS7 HIG - iOS technologies： iCloud

依據 “iOS technologies - iCloud” 這一節的建議，歸結出以下的設計反模式：

1. iCloud 的啟動方式不容易、不明顯或預設不啟用。

2. 浪費使用者的 iCloud 空間。

iCloud 空間的使用原則是：應該用來存放使用者透過 app 所產出的文件或記錄。例如：使用者編輯/下載、而且需要跨平台共享的文件檔案、照片。而且即使滿足這項原則，應用設計者也應該再進一步地不斷審視實際需求、挑剔地刪減必要存放的產出物。

3. 要求使用者選擇：哪些文件要儲存在 iCloud 中、哪些要儲存在 local。

4. 在 iCloud 關閉或無法工作時，app 的運作有問題。

iCloud 是個選擇性的功能，請別讓 app 和它同生共死。

5. 文件無法自動/無感更新。

6. 對於容量較大、無法在短短數秒同步完成的檔案，沒有提供反饋。

7. 刪除檔案時沒有告警及詳細的描述。

由於刪除存放在 iCloud 中的檔案，意味著所有使用同一個 iCloud 帳號的裝置裡都將無法再次存取該檔，所以妥善地提示使用者並且進一步地確認其決定是必要的。

8. 進行搜索時，找不到 app 裡存放於 iCloud 的檔案。

例如：透過 iPhone 的「搜尋 iPhone」功能 (於主畫面執行 “往下撥” 的手勢) 可以搜尋到備忘錄、郵件等 app 中的內容。不過 iOS 版的 Keynote 似乎就不支援。

9. 同步發生衝突時，不會告知使用者。

Modelio 試用

Modelio 是一套 Open Source 的建模工具。除了可用於繪製 UML 或 BPMN 圖表外，也具備產生不同程式語言程式碼及文件的能力。

它本身看起來應該是由 Eclipse 延伸開發出來的，我試用的版本是 v3.1.0，需要 Java 7 以上版本才能運作。在等級不差、近年購置的 Mac Book Pro 上運作的感覺是…還算順暢，但是有時切換 view 的時候還是會「多一拍」的感覺。

功能挺多、介面也算是不錯看，對筆者而言，比較可惜的是它不符自己的使用習慣。而且我相信，可能也不符合很多人的習慣。關鍵的其中一點是：每個元件 (element) 之間的關係 (它統稱為 link)，必須在既有元件之間拉線來建立。反過來說，和直接從某一既有元件拉出一條線後自動產生新元件的方式不同。

換句話說，在繪圖者當下的思維邏輯為：(以下假設使用類別圖描述書店的 model)

．邏輯1：有兩個 entity，一者為 Book，另一者為 Author；兩者之間有多對多的關係。

而不是：

．邏輯2：有 Book 這個 entity，首先它有一個關係連向 Author 這個 entity，兩者之間為多對多。

若是以一般人可能使用的陳述方式來說的話，可能是：

．每本書有它的作者，作者可能不只一位；每位作者也可能撰寫不只一本書。


由於人的思考比較習於演譯，所以在心智圖 (Mind Map)的繪製習慣中，也是從一個觀點延伸(拉線)出其它觀點。從這個角度來看，邏輯2可能比較接近人的思考習慣。

反過來說，如果在需求文件中已經歷經多次討論、收斂過字彙後產出 model 了，應該也不需要以帶動思考的方式進行繪圖了吧？從這個說法來看，可能就會覺得邏輯1和邏輯2應該只是在習慣上有所有差異。筆者覺得：這樣的模式最好有些個美麗的前提是「需求不會再變」，或是「不需要於製作文件時再進行一次審視」。

嗯…這個部分…大概做過的人比較有感覺。

--

回到 Modelio ，筆者會想試用的原因是它有支援 HTML 匯出。不過筆者還有一個想法：我希望能透過在高層次的圖表中的元素連結到次一級圖表。若是以 HTML 方式匯出時，就必須能在高層次圖表中提供連結，然後使用者點擊後可以看到次一級圖表的頁面。

使用心得是：Modelio 中沒有複合/複雜元件的概念，它提供了 Releated diagram link 這個 common 元素來將元素與其他圖表連結。嗯…畫面上會醜一點，不過還可以用。不過等到一匯出成 HTML 後，該連結的功能就消失了。(而且那個 Releated diagram link 元素還看得到，但是不能點擊)只能說遺憾…。

--

此外，每個元素的編輯要透過 Element view 的表示來設定，不能以 in-line 或 pop 視窗的方式進行，所以使用者的手得用滑鼠或觸碰板多多在畫面中旅行了…這樣也會降低繪圖的速度。

除此之外，像要在類別上加上 attribute/operation 也得從元件庫裡拖點、元素庫沒辦法搜尋、元件沒有 alias 的設定、attribute 沒有 property 的選項…這些都是很可惜的點…。不論是單純繪圖或是產生程式碼，用這套工具的速度我想和 Sparx 的 EA 還是很有差。

不論如何，既然標榜是商業等級的解決方案，我想 Modelio 的產品還可以再為使用者加些油。

逆讀 iOS7 HIG：Integrating with iOS

1. 混用不同版本的 iOS 風格。

2. 重複開發與標準元件相同的元件。

3. 使用的 icon 其意義與預期不符。

例如：把「齒輪」做為「連動」來解釋。齒輪在一般的行動裝置上的意義是「設定」。

4. 裝置在垂直或水平擺放時的顯示方式未被定義。

5. 裝置在垂直或水平擺放時的顯示方式一樣。

6. app 沒有隨時保持使用者的輸入資訊。

7. 要求使用者到「設定」頁進行設定。

除非真的必要，不然不要那麼做。就連要使用者在 app 內設定都要謹慎。

逆讀 iOS7 HIG：Terminology and Wording

依據 “Terminology and Wording” 這一節的建議，歸結出以下的設計反模式：

1. 使用專業術語。

也就是說，使用者可能看不懂。

2. 敘述累綴。

把自己當成為新聞下標題的新聞主編。

3. 敘述會冒犯到人。

4. 用字不精確、可能造成誤會。

5. 有錯字。

6. 標示時間日期時，未考慮不同時區。

逆讀 iOS7 HIG：Icons and Graphics

依據 “Icons and Graphics” 這一節的建議，歸結出以下的設計反模式：

1. icon 的意義讓人看不懂。

使用系統預設提供的 icon 將對使用者快速掌握 icon 意義有很直接的幫助。
若是有另創 icon 的需求時，也盡可能參考預設 icon 的表示方式，除非找不到對應的表示圖示時，才另外找尋溝通力可能最好的設計。必要時，使用文字表達。

2. 未同時支援不同規格的螢幕顯示。

3. 在自己的 app 裡使用 Apple 的專屬圖像。

逆讀 iOS7 HIG：Color and Typography

依據 “Color and Typography” 這一節的建議，歸結出以下的設計反模式：

1. 配色及對比未考慮到使用者的現下環境。

相信大家看過邊走路邊把玩手機的人，但是應該很少看到邊走路邊使用筆電的。這也是行動裝置和電影絕對不同、需要另外考量的點。假設使用者在陽光普照的室外、或是燈光昏暗、浪漫有餘的包廂內啟動您的 app，要讓使用者在兩種環境下都能清楚辨識出 app 提供的內容，這就是為 app 進行配色時所需要的進一步考量。

2. 沒有考慮到色盲。大多數有色盲的人較難從綠色區分紅色。

3. 顏色的象徵不單一。和無邊框的按鈕一樣都以藍色呈現文字的標籤(label)，將造成使用上的混亂：到底哪裡是可以點選的？

4. 配色方式和使用者文化衝突。不同文化中，對於顏色會有不同的定義。

5. 色彩過於斑駁。簡單講，就是「看得很花，又找不到重點」。

6. 辦識力不佳的配色或字體。

逆讀 iOS7 HIG：UI Design Basics - Branding

依據 “Branding” 這一節的建議，歸結出以下的設計反模式：

1. 使用者使用 app 時，有被強迫看廣告的感覺。

HIG 文件中，其認為品牌印象的重要性即使不言而喻，但是尊重使用者、重視內容的大原則不能改。所以品牌的表達應該更高明的融入 app 的整體設計中，而不是把原本該放置重要內容的位置讓給宣告性大於實用性的設計，那樣使用者會覺得在看 DM、在看廣告。

2. 在 app 中到處都可以看見 logo。

行動裝置上的介面就是和網頁上不同，前者的螢幕小得多。在那麼有限的可視範圍下，應該把空間讓給使用者預期需求的內容。但是，難道 logo 就沒有曝光的機會嗎？當然不是。使用者可能在上網瀏覽時偶然進入某個網頁，而且也有可能沒留意到該網頁是屬於那個組織的；但是使用者啟動 app 時，他總是知道他啟動的是某一個 app！這點來看，app 和網頁絕對不同。所以 app 的 icon 就能是 logo 最好的曝光點，就算真的需要在 app 裡加入 logo，相信在「啟動圖片」、「關於我們」之類的 view 裡呈現已經足夠了。

逆讀 iOS7 HIG：UI Design Basics - Interactivity and Feedback

依據 “Interactivity and Feedback” 這一節的建議，歸結出以下的設計反模式：

1. 使用獨特但是不直覺的手勢操作。

2. 使用過於複雜的手勢操作。

3. 沒有顯眼的關鍵色彩來指引使用者。

4. 按鈕和文字框，其矩形框線沒有一定得存在的理由。

iOS7 的介面風格中，按鈕的邊框消失了。邊框消失後，按鈕上的文字就被突顯，該文字的顏色是按鈕的關鍵色/主題色：藍色，這個變得很像網頁上的連結 (anchor)！所以呢？是的，讓人很直覺得想到它可以點選。當整個 view 上有多個按鈕時，邊框的消失也會讓使用 view 看起來更輕、更不複雜一些。在排版整齊的原則下，眼睛掃視畫面元件時，按鈕並不會因為框線的消失而顯得零亂。這一切都與大原則：「以內容為主」是一貫相符的。

5. 使用者不知道操作後的結果，或是沒有能夠指導操作的必要資訊。

簡單講就是資訊提供不足。以「郵件」這個 app 舉例，假設 app 沒有提供還有幾封未讀信件的訊息，使用者就不能輕鬆得知他是不是需要捲動郵件清單找漏看的信件了。

6. 輸入不易。例如：需要輸入地點時，如果能以「項目選擇」代替「文字輸入」就最好那麼做。

因為對於通勤中、只用一根姆指的使用者而言，後著的設計就是在徒增他的困擾。

7. app 沒有提供進度的顯示。簡單講，要讓使用者知道：雖然 app 很忙，但是它有留意到：使用者正在等。

逆讀 iOS7 HIG：UI Design Basics - Modal Context

依據 “Modal Context” 這一節的建議，歸結出以下的設計反模式：

1. 即使沒有必要，還是使用 Alert View 或其他類似機制打斷使用者操作 app。

1. app 含有使用者可能感到被打擾、不被尊重的訊息或中斷機制。

1. 使用者不能選擇性的拒絕、延緩回應提示。

詳細介紹 iBeacon

iBeacon (beacon 有燈塔之意) 是由蘋果公司 (Apple Inc.) 所制定的一項室內定位(indoor positioning)技術，已於 2013年6月公佈 iOS7 內搭載這項技術。

想要認識這項技術，可以從以下幾個方面來說明：

一、應用實例

直接看影片能最快理解這項技術。

1. Macy’s (美國的大型百貨公司)的 ShopKick。

http://www.theverge.com/2013/11/21/5129336/macys-apple-ibeacon-support-herald-union-square-stores-shopkick

2. 美國職棒大聯盟 (MLB) 也跟上這項技術應用了

http://mashable.com/2013/09/26/mlb-at-the-ballpark-app/

3. 美國的 Apple Store

http://www.inside.com.tw/2013/12/07/apple-guides-shoppers-inside-stores-with-ibeacon

4. 日本的 株式會社tab

http://prtimes.jp/main/html/rd/p/000000005.000006482.html

二、技術概要

簡單講就是：

iBeacon 應用 = BLE (Bluetooth Low Energy，低公率藍芽技術) + iBeacon 定位技術

BLE 是一種傳送、收發訊號的技術；至於 iBeacon 則負責定位相關的技術。

以上面提到 Macy’s 百貨公司的例子來說，影片中的女性顧客持有 iPhone，而 iPhone 安裝了 Macy’s 提供的 ShopKick 這支 App，這個 App 就是負責接受訊號的 iBeacon 訊號接收端。在 Macy’s 百貨公司裡，安裝了能發送訊號的 iBeacon 燈塔。

所以從該女性顧客一進門就能收到最新的銷售訊息(打折資訊或限量商品資訊？)，然後她一走近手提包的賣場區塊時，該 App 就能接收到就近燈塔送來的資訊，然後呈現出來讓顧客知道她可以看到哪些包包、以及每個包包的相關資訊。

說到這裡，我想到的是：這樣，以後還需要介紹商品的店員嗎？

總之，燈塔會感應到 App 和它的距離，並且在到達某個設定好的距離後，決定傳送什麼訊號/資訊給 App。像美國職棒大聯盟 (MLB) 的例子也差不多，其中一項就是：走進球場就把今日先發名單發送到 App。

從上面的例子來看，似乎就是燈塔到App的單向訊息傳送嗎？其實也不是。因為 beacon (燈塔)本身也能蒐集資訊、並且進行統計。例如：記錄並統計出哪一個商品區客戶最多？或是客戶的滯留時間最久？行人走進店內的比例？客戶們的動線統計為何？以上可以說是客戶的分析，也可以說是商品的分析。

特別值得一提的，在 iBeacon 的規範下，beacon 本身是不儲存各別客戶的地理位置的。這個說法來自 http://www.inside.com.tw/2013/12/07/apple-guides-shoppers-inside-stores-with-ibeacon。若要追蹤客戶的動線，勢必燈塔之間要存在一個識別碼來代表一個裝有 App 的裝置，同時記錄下該裝置走近自己的時間點。這個識別應該只能在一段時間內有效(例如：客戶走出店外之前)，不可以做為該裝置的永久識別，這樣就沒有會針對性地取得個人資訊的問題。實際上怎麼做的？我還沒去找相關資訊就是了。

三、比較

iBeacon 的出現會讓人聯想到 NFC，會想比較兩者的差異。

一般來說，第一個被討論的觀點是感應/偵測的距離。基於 BLE 的 iBeacon 在這點是比較遠的。

第二，NFC 是點對點技術，而 BLE 是廣播型的，所以可以”散播訊息”。廣播聽起來比較不安全嗎？iBeacon 是以 UUID 作為識別進行配對的，而且俱備 128bits 的加密技術，在一般應用上所需要的安全程度和 WIFI 差不多，若嫌不安全，那大概 WIFI 也不敢用了。

第三要來談的是建置成本。因為 BLE 的感應距離比較寬展，同一空間內所需要佈署的燈塔數量會比佈署搭載 NFC 晶片的硬體要來得少得多，所以 iBeacon 的建置成本會比較低。而且很多人的行動裝置上都有藍芽晶片，但是有 NFC 晶片的裝置就少得多。所以從成本來看，NFC 比較高。

四、廠商

不是想幫廠商打廣告，只是列出來大家有得比較、容易聯想。

http://estimote.com

https://www.sticknfind.com

http://www.aplix.co.jp/?page_id=7593

http://www.sensorberg.com

五、參考

http://en.wikipedia.org/wiki/Bluetooth_low_energy

http://digi.tech.qq.com/a/20130915/001341.htm

http://www.digitimes.com.tw/tw/rpt/rpt_show.asp?cnlid=3&v=20140115-023&n=1

http://d.hatena.ne.jp/samril/20131211/1386816475

http://zh.wikipedia.org/wiki/近場通訊

逆讀 iOS7 HIG：UI Design Basics - Layout

依據 “Layout” 這一節的建議，歸結出以下的設計反模式：

1. 互動元件的矩形大小，小於 44x44。

這個算是老生長談了，不過還是很多違反的例子。多半會發生在原本有 Web Page 設計經驗，或是對 App 設計經驗一直抓不到正確感覺的設計師身上。這個原則很的背後有一個很簡單的原因：「手機是以手指進行操作的，不是滑鼠。」(至少 Apple 並沒有「筆」較厲害的論調…)

2. 內容的呈現，把較不重要的內容放在重要內容的上方、左方。

(多半的西文以及現在我們習慣看的横寫中文也都是這個順利) 這個原則背後的原因：大多數人的閱讀習慣是由左至右、由上而下。其實筆者有另一個想法，那是：可能也是右撇子的人比較多一些的原因。試想，在單手持握手機時，假設我們在捷運上閱讀 iPhone 上呈現的資訊，由於手是有厚度的，所以左撇子的姆指的部分還是有稍微擋到一點點螢幕的可能性吧？

3. 排版不整齊。排版不整齊會造成視線零亂，操作的順序也可能會讓人困惑。

這裡講的不整齊，應該不包括亂中有序的設計。不過，即使亂得很有風格，但是若違害到使用上的直覺性、簡便性，還是得盡可能避免。
使用者需要放大、湊近看才看得清楚；或是需要縮小才看得到完整的內容。

4. 文字大小無法依使用者要求做改變。

iOS 7 新增了「較大文字」的設定，讓使用者能視其需求調整文字的大小。不過，這個需要 app 的配合，為了維護排版的美觀及一致性，這個部分需要進一步的定義及取捨。

5. 類似的元件卻得到出乎意料的/不直覺的結果。

筆者遇到過的例子是：使用 tab 作為 step 的表示法。一般而言，tab 上的各個元素是彼此獨立的。這裡的獨立可能是完全不相關的意思，也可能是邏輯上的不同。例如：音樂和照片就是不相關的，而分類清單與名稱列表就是資料相同、但是呈現邏輯相異的例子。筆者看過的誤用是：把 tab 1當成一個設定的步驟，完成後產生出 tab2 來進行下一個設定。由於 tab 是可以任意切換檢視目標的，所以用來作為 step 的表示(有連續意味、非離散的)，其實真的不算正確。

逆讀 iOS7 HIG：UI Design Basics - Starting and Stopping

依據 “Starting and Stopping” 這一節的建議，歸結出以下的設計反模式：

1. app 啟動後沒有直接進入程式主畫面。

例如：沒有具體理由的放上一顆「Start」按鈕、要求使用者輸入非必要的資訊…這些在「使用者會在開始使用某 app 後的1~2分鐘內決定要不要留下這支 app 」的前提下，都是應該避免的。比較好的作法是：盡可能讓使用者馬上可以使用 app；如果 app 需要的資訊可以從他處取得就那麼做吧！例如 iOS 的本身的設定、iOS 整合好的社群帳號…；假設真的需要使用者來提供資訊，則應該把該時機放在不得不提供之前一刻/前一個畫面。

2. app 啟動後未能直接轉向符合該 app 使用的方向。

例如：需要使用者水平持握裝置來用的 app 就該在 app 啟動後直接轉向成水平畫面。

3. 沒有提供啟動圖片。

這是因為有啟動圖片的話，能讓 app 看起來反應速度更快。啟動圖片很常只是給予一個印象，若是其近似程式主畫面或提供有用的資訊，可能讓使用者有更好的體驗。

4. 讓使用者在 app 啟動時閱讀版權宣告或免責條款。

那會增加使用者的不耐：他們想的是馬上使用 app。比較理想的時機是在 app 裡提供能檢視相關資訊之外，在 App Store 裡就可以附上該資訊，讓使用者能在下載之前就有機會閱讀到。

5. 使用者進入 app 時，並非回到他上次使用的狀態。

只要使用者曾經使用過 app，即使 app 曾經從背景被移除，使用者再次啟動 app 時恢復上一次最後使用後的狀態都是有意義的。這一點即使並不適用於所有類型的 app，但是仍值得被放在清單中進行檢視及取捨。

6. 使用者進入 app 時，假若當下 app 無法取得必要資源，例如：無法存取網路，app 沒有告知相關資訊給使用者。

技術上當然可以使用快取的機制讓使用者在 app 無法取得資源時，以過去曾經得到過的資訊進行 app 的操作；即使做不到這一點 (例如：這是使用者第一次啟動程式)或是根本沒必要做到時，至少要能呈現簡要資訊給使用者，讓使用者知道 app 停下來無法再繼續進行的原因。

逆讀 iOS7 HIG：UI Design Basics - Designing for iOS 7

大多數的 app 開發者會認同，Apple 所提供的 HIG (Human Interface Guidelines) 這件文件是很好、很重要的設計參考。大多數的時候可能會這麼提問：「我們的設計有沒有遵守 HIG 的規範？」，又或者更有效率地(但是也感覺比較消極地)的提問是：「我們的設計有沒有違反 HIG ？」

針對第二個問題，如果有一個檢測清單，列出「不該那樣做的反模式」，那麼在審核設計時，會更科學、更好控制一點。

為了能列出那樣的清單，筆著認為：HIG 也該「逆著讀」。也就是說，看到 "該怎麼做” 是不夠的，而是該去找出 “不該怎麼做”。

以下「逆讀 HIG 」的相關文章便是由此而生。

iOS 7 的設計，有三項主要精神，分別是 deference, clarity 及 depth。這三個字筆者就不翻譯了，因為…英翻中之後也不容易看懂。想徹底理解的話，還是建議除了大略看過這篇文章外，也多少看看 HIG 了解關鍵字的上下文比較好。

綜合來說：要讓 app 專注於其內容本身對使用者的傳達。那內容該是易於理解、操作簡單的。讓清晰的呈現方式來維持使用者的專注力，並使用視覺上的層次感強化使用者的美好體驗。

反過來說，使用任何讓內容本身的表達淪為次要的繁複設計都是應該避免的。要求過度逼真的呈現、或是雕琢與內容較無關的細節，可能造成其與內容本身爭奪使用者的專注力。不論是讓使用者的專注力造成不必要的拉距，或是根本就讓內容從主角變配角的設計都該重新考慮再三。

要讓使用者了解他們處在使用 app 的何種階段、又是從哪而來、接著該完成些什麼。換句話說，app 的導航要明確。

iOS 7採取的手段之一是讓介面元素外觀上看起來”重點很明確”，例如：

1. 使用主題色 (tint color) 加上一個深色、一個淺色的搭配來。我們可以參考「備忘錄」這個內建 app 看看：白底色、深灰字體，以及黃色用於標示互動機能元件。
2. 使用多層次、 blur (半透明、使背景呈現模糊狀) 及部分露出的方式來"保有使用者的方向感”。

靜態外觀變簡潔了，但是 iOS 7 也同時強調使用層次以及能表示該層次的操作動線/動畫。這裡可以用來舉例的是內建的「行事曆」：它使用了 zoom in/out 的動畫呈現了年檢視、月檢視、日檢視三種層次的轉移。其實在主畫面中，當點選/啟動某個 app 時，iOS 7 的呈現也是使用 zoom-in 效果，而非展開，便是依據這個原則。

反過來說就是：使用者在使用 app 的某一時刻，他可能忘了自己目前處於哪個階段而且得不到任何提示。原因可能是在設計上使用了縱深度較高的導覽結構，或甚至因為結合了過多/不合適/不一致的轉場效果而弄得使用者頭昏眼花。

在 HIG 裡還有其他的例子，這裡只擷取容易收斂出重點的部分。