Pages

Monday, December 26, 2011

App Store Review Guidelines 送審前十項常犯必檢查項目表

App Store Review Guidelines
一個 iOS App 在送審過程會經歷的階段有:
  • Waiting for upload
  • Upload received
  • Waiting for review
  • In review
  • Ready for sale.

這是一個順利的轉換過程,但是如果不幸的審核沒過,就得再來一次。在 Apple Developer Center 裡面有一分相當重要的文件叫做 App Store Review Guidelines。不知道身為時常送審的  iOS App developer 您閱讀過這份文件了嗎?
以下為我們和其他同樣開發 iOS App 送審經驗朋友們,收集過去送審前一定要檢查的十大重要項目,根據過往經驗ㄧ犯規就是會被退審的項目,而這些項目在這份文件裡面都有清楚重要聲明:
  1. Apps 如果在審核過程操作上會 Crash,是會被退審的。
  2. Apps 如果有功能是非文件上記錄,或是 App 描述上沒有寫出來出現的隱藏功能,是會被退審的。
  3. Apps 如果用了非 Apple 公開的 APIs 也就是 private APIs,是會被退審的。
  4. Apps 如果單純是市場調查工具或是純廣告的,會被退審。
  5. Apps 如果單純只是歌曲或是電影,請送到 iTunes store,Apps 如果單純只是書籍,請送到 iBookstore。
  6. Apps 分類項目如果跟 App 本身內容呈現不符合,會被退審。
  7. Apps 如果只呈現空白的廣告區塊,卻沒有廣告,是會被退審。
  8. Apps 如果引用了第三方的內容 (版權、商標等) ,必須要檢查是否有符合使用規定。
  9. Apps 如果用了 Google Map, Google Earth 圖片,卻擅自隱藏或是修改 Google 的 logo 或是版權所有標誌,是會被退審的。
  10. Apps 如果設計上用了跟 iOS Human Interface Guidelines 規範相反或是錯誤行為,是會被退審的。
這禮拜日子很特別,有中國人的冬至,有西方人的聖誕佳節,尤其 Apple 要過年放假,所以在一個月前就寄信出來給所有 iOS 開發人員:
iTunes Connect will be temporarily shut down from Thursday, December 22 to Thursday, December 29 for the winter holidays. During this shutdown, the following functionality will be unavailable:
  • Access to iTunes Connect
  • The delivery of any apps or updates.

意思是在美國時間 12/22~12/29 這段時間,iTunes Connect 會關閉,任何跟 App 更新送審都會不受理。對於 Polydice Inc. 的 iOS Team 過去這週也在這波趕開發送審的時程下,搶灘拼送審。您是否也跟我們一樣在這聖誕佳節的氛圍下搏命一擊呢!

本篇最原始由 Edward 發表於 thepolydice.com 的部落格文章 App Store Review Guidelines 送審前十項常犯必檢查項目表

Tuesday, December 20, 2011

Share Archives to Teammates in Organizer

Share from been archive
每當我們將 Xcode 專案寫好想要 Archive 起來作為後續釋出的流程,都可以成功的包裝即顯示在 Organizer 裡面,Xcode 會幫我們自動導引到 Organizer 的 Archives 區域,看到過去所有的紀錄。在 Xcode > Window > Organizer - Archives 區域,時常可以做事情有:
  • 在該建立的記錄按下 Comment 區塊,記錄些重要事情,為何這份 Archive 有它不同處,跟過去歷史記錄作區別。
  • 如果要送審會選擇右上方的主要按鈕:Validate 和 Submit。
  • 如果要分享出去,匯出成某種形式,則選擇 Share。
在 Share 裡面,關於匯出的內容本身 (Contents) 可以分為 iOS App Store Package (.ipa)、Application、Archive。在 .ipa 對於我們用 Ad Hoc 方式來發佈是最常用的。

這邊想要特別記錄 Archive 幫助了我怎麼樣的突破難關。過去因為在開發上想要體驗最新最酷的功能,所以也安裝 Apple 在 Developer Center 釋出的 beta 版本 Xcode,而也安裝了該開發工具,但是當最後專案完成,準備要提交給 Apple 送審時候,才發現不管怎麼弄,在第一關驗證 (validate) 就是無法過關,看了關鍵字句,才發現真正的原因。
Xcode 4.3 Developer Preview 2 cannot be used to submit apps to the iOS or Mac App Store. Continue to use the publicly released version of Xcode to compile and submit apps to the App Stores.
也就是在 Apple 網站上有特別聲明了,用該最新 Xcode 來開發測試是沒問題,但是目前不允許透過這版來提交 Apps 給 App Store,還沒開放問市的意思,請多多配合。

慶幸的是我們的夥伴是有安裝正式版的開發環境,馬上請他幫忙將要送審的專案 Archive,再透過 Share Archive 將該專案包裝起來匯出來給我這台卡住不能送審的環境。因為可能環境上我才有送審所需要的各種資源,包含密碼、private key、certificate、provisioning profile 等種種,需要從一台沒法送審的 Xcode 來提交送審。

於是透過這樣的步驟,解決了無法送審的方式:
  1. 用 Share Archive 方式將專案程式匯出。
  2. 將 Archive 點選兩下,即可匯入想要匯入的 Xcode > Organizer - Archives 裡頭。
  3. 這時候就可以繼續後續動作,不論是 Validate、加上 Code sign、Submit 提交給 Apple 等流程。
藉由我們少用的 Archive 步驟,來完成某時候緊急所需要的解決方法。

當問題出現、時間緊急不是 Xcode 重新下載重新安裝所可以接受的情境下,透過對於專案匯出送審有更明確瞭解,即能協助我們自己度過緊張時刻,另外當然有些重要規範平常也是要多多注意來避免狀況發生。

Sunday, December 11, 2011

改造優惠類型 iPhone App 藉由資訊整理做起

改造優惠 For iPhone App
我想做個挑戰,我不相信做優惠做促銷的 iPhone App 一定要搞的花俏無比,資訊多到很雜亂、功能多到不知道提供了哪些功能,讓人們不覺得這是它們所要的 App。

讓我們回到為使用者設計。

以下列出設計上常犯的盲點:
  • 資訊充足,但是卻提供太多動線選項讓使用者選,就會讓使用者覺得資料很雜亂,沒有整理過的反效果。
  • 首頁提供太多動線給使用者,讓使用者無從著手哪個是起點。
  • 資訊因為五花八門,而必須提供篩選功能給使用者篩選,造成反效果。
  • 因為廣告就一定要花俏,要花俏就必須要很多動畫與誇張特效

讓我們回到使用者想要的是什麼,這邊列出根據過去接觸過手持 iPhone 臺灣朋友特性條列:
  • 他們希望乾淨、有質感的 App,也許他們說不出原因,但是他們比較得出來 5 顆星和 3 顆星的差別。
  • 他們希望這個 App 是有個人化的,不論是資料分析、個人喜好等等。
  • 他們希望動線越少越好,好用比較重要。
  • 他們希望每天打開來可以有驚喜。

於是開始做了規劃,App 名稱叫做改造優惠 for iPhone App,描述:提供一個根據您所需要各種優惠訊息,讓繁忙的你、每天外出想要找尋新消息的 iPhone APP。功能特色支援使用者位置定位、透過個人化習慣傳遞優惠訊息、收藏優惠訊息和優惠券等等功能。

Wednesday, December 7, 2011

Opened pull request on GitHub

點圖放大
本篇最原始由 Edward 發表於 thepolydice.com 的部落格文章 Opened pull request on GitHub
 
GitHub 首頁上有個很顯目的 Banner,它告訴我們 Developers 如何參與 GitHub,簡單四步驟:
  1. 建置開發 Git 環境。
  2. 建立一個 Repository 作為程式碼控管儲存的地方。
  3. 從某個 Repository 建立分支 Fork,可以視複製或者是建立全新的。
  4. 多點社交,可以從追蹤朋友和監看關心某個 Project。
我們在 GitHub 上面最大的驚喜不外乎是我們挖到寶了,所謂挖到寶是找到很酷炫的某個元件功能、可能是某個已經整合好的套件、可能是已經完成自己即將開發功能。接下來將該 Repository 引用回來,並且透過 Sample code 做火力展示,這種喜悅我們很常發生。但是是否發現專案需求改變,新功能不但要達成,可能甚至要擴充,那麼我們原來下載回來的或是引用回來的 Project 該怎麼使上力呢?甚至未來如果我自己改了 Code,但是原出處有更新版,想要享用,有什麼配套措施可以用呢?

Saturday, November 19, 2011

使用 SenTestCase 為後續整合更快速

繼上篇 使用 SenTestCase 為 Continuous Integration 之路更踏實 ,對應到 iPhone App Project 開發,以 Model-View-Control 架構來看,Model 是最可以撰寫的地方。而根據過去經驗,這邊是最少修改被挑剔批評,同時也是邏輯重要陣地。

再來進一步談談對於 TestCase 撰寫對於後續開發不同程式介接而言的收獲,是可以讓整合測試進行相當的快速。

速度一、增加 Code base 幫自己留意,也讓夥伴有個參考。
現在很多 iPhone App 都是希望跟 Web Service 做介接,而 iPhone app 與 Web service 的溝通良好關鍵在 API 設計 ,所以當 Model 部份的程式都對應寫了 XXModelTests,裡面針對各種呼叫 API 行為都敲定好,也都測試完畢,那麼當開發人員轉移到 View 和 Controller 開發時候就不會有後顧之憂,甚至在接的時候,都已經擁有使用 Model 的測試 Code base,看一下馬上就接上手。甚至不論今天是自己接自己寫的程式碼順手,當夥伴們要接的時候,可以很有信心跟他說,參考我的 Test Case 即可。

速度二、犯過的錯誤要累積下來。
我們在經驗不是很豐富情況下,在開發設想角度不足情況下,我們的程式功能和測試情境是不夠的。不要忘記,開發人員自己的邏輯 思考錯誤,測試又將錯誤程式測試成對的,這樣荒謬的情況是真的會發生的。所以事後的矯正 Test Case,或者回來不充測試案例是要一直進行的。當曾經粗心的錯寫下來到 Test Case,這樣到後面開發過程,Test Suite 整個包裝下去測試,都是可以涵蓋進去不會忘的。

速度三、為跨系統整合把關。
iPhone App 在整個產品服務下的角色扮演是 Client 最終端的部份,所以也不要忘記了後面支撐我們的 Server side。Server side 也是會變動的,不論是功能新增、條款異動、情境改變等等因素,進行呼叫的參數值、回傳值都會跟著改變。而作為 iPhone App 的開發人員,如果平日都有寫好 Test Case,每天執行很多次都沒有問題,突然在某一次原本對的測試情境突然出錯了,那麼就能進一步分析問題出在原因,如果是 Server side 沒有講好的默契,這時候趕緊跟 Server side 的開發人員做個溝通協調,也能為這道溝通的關卡把關。 

使用 SenTestCase 帶給 iPhone App 開發人員最大的收獲就是,今日的你會謝謝昨天的你,程式不如預期就發生警訊,儘快處理;如果如預期都過關,就讓我們就可以把更多心力放在 User Interface 的設計上。

剛剛跑了一個開發中的 iPhone App 專案,結果得到:
Executed 41 tests, with 0 failures (0 unexpected) in 54.148 (54.166) seconds
Test Suite 'All tests' finished at 2011-11-18 16:43:52 +0000.

您的測試程式有在更新、維護和累進嗎!

Sunday, November 13, 2011

使用 SenTestCase 為 Continuous Integration 之路更踏實

"Testing is not closely integrated with development. This prevents you from measuring the progress of development- you can't tell when something starts working or when something stops working. Using JUnit you can cheaply and incrementally build a test suite that will help you measure your progress, spot unintended side effects, and focus your development efforts." -  Test Infected:Programmers Love Writing Tests. by Kent Beck, Erich Gamma.
 
導入 Unit Test 開發可以用最便宜又累積性的建置測試套件,如此一來可以幫忙幫助評估進度,未發掘的潛在 side effects,改此程式動到另外邊功能的狀況,而且可以用對力氣更專注在開發。
 

在上篇 天使與魔鬼對於 Unit Test 的影響 有對單元測試做了些看法分類,而當最近選擇導入 Test Driven Development 測試導向開發,再次找到了投資的好處了。要投資在很怕會異動的程式、最底層不希望會出錯的程式、每天測試保持在最佳狀態。換言之,使用者介面 User Interface 以外,都是很好的投資點。對應到 iPhone App Project 開發,以 Model-View-Control 架構來看,Model 是最可以撰寫的地方。而根據過去經驗,這邊是最少修改被挑剔批評,同時也是邏輯重要陣地。

SenTestingKit framework,是 Objective-C testing framework 建立在 SUnit 之上,Kent Beck 的 Smallltalk unit testing framework。同時在 Java 的 JUnit 也看得到,而且這是發佈出來 Open Source 的。對應到 Apple 在 XCode 2.1 之後都已經有包含這個套件可以使用。

Saturday, November 12, 2011

用 iCarousel 在 iPhone App 上做出旋轉木馬效果的顯示

iCarousel 是一套在 GitHub 上 Open Source Project,它是一個 class 設計來簡單套用即可呈現多種樣貌的類似旋轉木馬效果的在 iPhone 或者 iPad App 上面呈現。

想要看效果可以參考 forked 來自 nicklockwood/iCarouselpolydice/iCarousel ,下載回去打開 iCarousel iOS Demo 就可以看到這種效果展示了。iCarousel 是用 type 來設定要顯示的樣式,目前分為 Linear, Rotary, Inverted Rotary, Cylinder, Inverted Cylinder, Cover Flow, Cover Flow 2, Custom。

在使用上很簡單不過,除了規劃好基本的 type 和要顯示的 frame 之外,透過兩個 protocol 來做所有的設定和參考互動。

Tuesday, October 18, 2011

Version control challenge: 請提供過去問市測試、正式版本的應用程式

*.ipa file
『請提供過去問市測試、正式版本的應用程式給測試人員或是相關人員測試』,根據如此的考題,請問會怎麼做才能做得漂亮,可能需要耗費了點功,但是不置於弄不出來呢,或者是否有問過自己是哪些原因讓身為開發人員的你會使用版本控管來管理程式碼?

以上面的考題用 iOS App 為例,如何取得過去在 App Store 上面的版本,而且可能會有製作方式不同,需要重新的製作出來,例如有切分 Production 或者 Testing 環境的串接。也就是說重新建置 version 1.0 (test / production) 版本、version 1.1 (test/ production)、version 1.2 (test/production) 依此類推可能四到六個不同版本的 App。

如果沒有做版本控管或者說有用版本控管但是沒有用好的方法來管理的話,那麼可能面臨今天這樣考題會做不到了。很慶幸的是,感謝過去這陣子都有養成良好的習慣,加上一些線索推敲,可以讓這個考題解的漂亮。

1. 打開 Xcode 的 Organizer 的 Archives 頁面,這邊詳細記載著過去 Archives 記錄。其中以 Status 欄位為例,Xcode 在交付給 Apple 審核,都會標上 Submitted 記錄,所以整張列表我們可以知道我們曾經給 Apple 送審的記錄。

Organizer - Archives

2. 搭配 Creation Date 我們可以以當天即是重要日,因此帶著時間我們回到版本控管工具上,找出當天大事記的標籤 Tag,可能是 v1.0.11 的紀錄。於是我們找到了時間點與版本記錄。

3. 因為是要時間追逤,所以強烈建議請一定要開新的資料夾,將程式碼可以放到新的環境,不要和原來開發中的資料夾放在一起。以 Git 為例就是到新的資料夾下面再 git clone your-repository

4. 如果 iOS App 有用 Git submodule approach 來做外部 Open Source project 管理,那麼先下 git check 到該 Tag 再來產生 submodule 的建立。原因有一個可能那個時期的 submodule 記錄點跟後來的記錄點不同,所以從那時在建立來還原。如果運氣差一點,submodule 的 URL 已經被取消掉或是不存在,所以意味著一定 Build 不起來了,可能就得找替代方案,所以需要再搭配開設新的 Git Branch 來做找尋新的 submodule 來源調整與記錄修正。如此才能做 git submodule init 與 update。

5. 打開該 Xcode project,進入該版本進行 Build & Run,照道理是要能跑的。開始調整設定檔,因為需要針對該版本製作 (test/production) 等設定後的 *.ipa 檔案。當選擇新的 iOS provisioning profile 再次做好新的 code sign 後,即可 Archive。於是我們在同樣的 Organizer 就可以看到最新一份的 Archive 出爐了。馬上在 Organizer > Archive 針對該紀錄下 Comment 類似 App v1.0.0, Git tag v1.0.11 (test env.) 這樣記錄。

6. 剩下的各種版本設定建置依此程序類推,讓它們一一完成。

以上即可提供過去問市測試、正式版本的應用程式了。過程不是那麼容易,可見平日的各種重要大事紀錄累積是如此的重要。也才能交付這些各種組合版本的熱騰騰的 *.ipa 出去給予安裝。

當我接觸版本控管這幾年開發經驗,從 CVS, Subversion 到今日的 Git 使用經驗,我第一次在心中有如此震撼,碰到如此的挑戰而最終能克服,再回來省思版本控管用好的方法實踐對我們開發人員而言是真的如此的重要。

Sunday, October 16, 2011

TestFlight SDK: Quick, painless integration Instant insight.

https://testflightappcom/sdk/
當我們在 iPhone App 開發之路 一定會有測試階段,不論是功能開發完畢的釋出測試、或者想要搭配使用者測試,如何讓這個過程順利是個很重要一環的活動。在 TestFlight magically distribute iOS Beta testing for your team 說明了讓釋出測試變得如此順利,現在 TestFlight 更進一步推出 SDK 讓我們可以整合到專案裡頭,如果說原來的 Testflight 幫我們做到發佈,現在加入 SDK 可以讓使用者在整個測試過程收集更完整的資料。

一個理想的使用者或者測試人員在使用 TestFlight App 安裝下來的測試版 App,會有哪些情形發生呢?

  • 我們會想要關心使用者測試了多久,有多頻繁地使用。 
  • 我們會想要知道測試過程中有沒有發生 Crash ,這是很嚴重的狀況,一定要能收集到第一手錯誤訊息。 
  • 我們會想要知道不同的測試人員在使用該 App,有通過哪些檢核點,透過群體資料來分析哪些地方還有那些動向測試到呢? 
  • 我們會想知道如果有任何的問題,是否可以透過本身的 App 就提供意見回饋呢?這樣不用另外拿紙筆或者需要額外寫封信,第一時間印象打出資訊送出即可。

Wednesday, October 12, 2011

*.DSYM File Extension

Xcode build setting
這份 Debugging information 檔案是由 Apple 的 Xcode 開發軟體產生的。如果在建置 App 過程當中在 Debugging 階段有選擇 Debug Information Format 設定為 "DWARF with dSYM",這份檔案就會跟包裝檔案裡面。所以如果要找出該放檔案,在 Build 好的 *.xcarchive 檔案,按下右鍵 Show package contents,即可找到 dSYMs 資料夾,裡面就會有 .dSYM 這樣附檔名的檔案。
DWARF 全名是 "Debugging with Attributed Record Formats." 它是由 Xcode 產生出來的 debug 符號,在發佈以前過程中抽離出來,它會儲存了所有 Debug 資訊和產生一份 Debug map。

像我們在 App 發佈測試發生了 Crash 狀況,希望可以解析回來詳細狀況的話,即需要此份檔案。"You can upload a zipped .dSYM for this build to symbolicate your crash reports. " 當類似 TestFlight: iOS beta testing platform 瀏覽詳細狀況時候,會需要開發人員來提供這份檔案。 

Monday, October 10, 2011

TestFlight magically distribute iOS Beta testing for your team

My TestFlight T-Shirt
當我們在 iPhone App 開發之路 一定會有測試階段,不論是功能開發完畢的釋出測試、或者想要搭配使用者測試,如何讓這個過程順利是個很重要一環的活動。很感激的是 TestFlight https://testflightapp.com 讓這一切變得如此簡單和魔術般的神奇。TestFlight 是 Apple 認可 iOS 開發人員可以註冊他們的服務、建立團隊、邀請成員和加入成員們的 iOS 裝置,方便將資訊回到 Apple 的 Provisioning Portal 登記重新包裝新的一份 App,回到 TestFlight 上傳,之後的發佈釋出就是如此的讓整個團隊都能安裝使用,如此的簡單。

對於開發人員 Developer 可以怎麼做?
  1. 從註冊自己帳號,建立自己的團隊。
  2. 開始邀請自己的成員們加入,以方便取得 UDIDs (Unique Device IDentifier)。
  3. 回到 Apple Provisioning Portal 登記,重新建立新的一份 Provisioning Profile 檔案。
  4. 將最新一份 Provisioning Profile 拿來 Code Sign 在該新的 iPhone APplication (.IPA) 檔案。
  5. 回到 TestFlight 上傳該 IPA 檔案之外,填寫 Release Note。
  6. 接著所有需要測試的成員都可以收到通知信,一一安裝在成員的手機裝置上了。

對於測試人員 Tester 可以怎麼做?
  1. 初次使用可能受到邀請函、或者被邀請加入、或者新註冊。
  2. TestFlight 會詢問是否註冊該 iOS 裝置,如此才能讓開發人員取得裝置的 UDID。
  3. 開發人員取得 UDID,重新製作 Provisioning Profile 來包裝建立新的一份 .IPA 檔案。
  4. 等開發人員釋放了,TestFlight 會寄出通知信 email 告知有哪一版可以安裝使用。
  5. 遵循著信件就可以輕鬆安裝該 App。

TestFlight 帶給開發人員的改變是提供了:
  • 完整使用者管理、使用者除了掌握 email 資訊外,也紀錄著裝置的 UDID,方便取得發佈 App 所需要的資訊。
  • 簡單的上傳步驟,方便輸入 Release note,透過 .IPA 檔案解析 Provisioning Profile,讓開發人員可以勾選僅可以發佈的成員名單。這點很重要,因為當開發超過一個 App project,用哪一個 App 可以發佈給那些團隊成員,這邊切割變得要簡單明瞭。
  • 搭配發佈 email 通知到,使用者是否收到信件、開啓信件、點擊信件的 URL link 到最後是否安裝這些的狀態轉換都在平台上有個完善紀錄。

TestFlight 除了完全符合 Apple 開發人員的規範條款之外,又能減少開發人員在測試這個活動上的負擔,讓我們在 App 問市前可以擁有更多機會來測試找出 App 潛在問題。

試著想想看如果今天開發人員和測試人員來自不同公司,而 TestFlight 透過那些功能上的設計,讓跨公司可以合作的如此順利呢?

我們非常感激 TestFlight 這個平台設計的用心與便利性。

Thursday, October 6, 2011

iRate 協助使用者給予我們更多的支持與鼓勵

Rate for Mr. Plurk
iRate 是一套可以協助我們來行銷我們 iPhone, Mac App Store 的 Apps。可以在使用該 App 一陣子後,透過彈出視窗請使用者幫我們評分一下。這樣的提醒可以讓真正有用的使用者來幫我們評分,而且會給予更接近實際的使用心得與推薦。

這套在 GitHub 上面有很多人在維護,而我也先 Fork 一份回來,等未來有時間可以來改善加強它。https://github.com/edwardinubuntu/iRate

不過對於這套的設計,可以幫助我們到什麼樣程度,這是最有興趣的,而在看這套 Library 發現最有趣的是一段 method 叫做 shouldPromptForRating。這也是本套 Library 的核心,該彈出視窗彈出的時機到底為何?透過程式碼可以瞭解到這套彈出時機分為一系列的檢查判斷,並且是有順序性的,分別為:
  1. 是否為 Debug 階段,如果是一定會開啓。
  2. 檢查使用者是否評分過這個版本。
  3. 檢查使用者是否謝絕評分過這個版本。
  4. 檢查使用者是否經過一段時間了,該是請使用者幫忙了。
  5. 檢查使用者開啟關閉該 App 超過幾次,而且使用該 App 有經過些特別的檢核點。
  6. 檢查時間上是否倒了使用者說稍後再提示。
  7. 彈出視窗吧!
所以根據這些條件判斷式,我們可以組合出最適當的設定。彈出的時間點很重要,不要頻繁吵到使用者,也不希望過早還沒摸索清楚就問使用者,又能請使用者給予我們評分提醒,這樣的組合拿捏,確實是一門小小的藝術。

Sunday, September 25, 2011

當 iPhone 轉移到 iPad 該注意的 5 個 User Experience 概念

當我們已經擁有了 iPhone app,應用程式的主要特色和功能與畫面等等都有了,而當我們要開始規劃 iPad app,在這個交替轉換的設計上我們有那些考量要注意呢?

1. 加強互動性,不要只是加入新的功能

一個好的 iPad 應用程式會給人們創新的方式來跟內文互動,不只清晰清楚定義,用有限的功能來完成。一定要抵制住誘惑限制加入新的功能跟應用程式主要任務沒有相關關係。反而要做的是,探索可以讓使用者看到更多和互動更多。通常來說,不應該是把所有在 iPhone 應用程式的所有功能都帶回來。

要讓 iPad 應用程式看起來突出,專注在將使用者體驗放大,而不是帶入太多功能而讓主要任務被稀釋掉了。舉例來說:

閱讀型的應用程式要讓使用者可以閱讀書籍和讓閱讀上可以享受在大螢幕樂趣。減少讓使用者從此螢幕帶到另外一個螢幕來看閱讀清單,而是使用 popover 來讓使用者可以管理閱讀清單和選擇複製喜愛的句子進去。應用程式可以讓使用者可以加入書籤和註解,讓他們可以去跟自己閱讀進度做比較。

螢幕書寫的應用程式可以同時提供主要畫面和輔助工具都在同一個畫面,不會需要切換主要內容,可以在這之間來選擇要做的操作。

2. 減少全螢幕的切換

讓視覺上的切換可以跟內文改變很靠近。取代用滑動整夜切換方式,讓區域只要局部的變更舊好。讓狀態轉換只要局部,讓整頁大幅度轉換是非常不推薦的。當越少全螢幕切換,可以讓使用者保持在他們的操作項目上,可以使用類似 Split view 或是 popover 來減少全螢幕的轉變。

3. 仰制資訊的階層性

在 iPad 會讓使用者有更大的螢幕來看更多資訊,所以希望讓可以使用者可以閱讀大量資料,也方便作切換。所以通常來說會專注在主要的畫面,然後提供 popover 來讓使用者可以操作。在大的 iPad 畫面可以使用 split view 和 popover 來取代本來 iPhone 應用程式的階層切換。所以使用 Navigation bar 在左手邊,讓使用者可以滑下來看想要找的類型分類,然後當點選是最後一層,就將主要的功能配製在右邊的主要畫面中。有階層的效果交給左手邊的 Split view,而內文放置在右手邊。而如果畫面直立因為內文為主要畫面,利用 popover 來提供階層切換。

利用 segmented control 在 toolbar 上來做不同內容的切換,這樣就可以在同一條上來呈現不同的內容,例如 iTunes  裡面作不同內容類別的切換。

利用 tab bar 來提供不同內容,或者進入不同主題的程式功能分類。

4. 考慮在些 Modal 浮出的操作上使用 Popover

Modal 是很像在畫面上浮出來,但是必須要按下關閉才能結束,而 Popover 的介面可以讓使用者同樣的操作但是用起來比較輕量化。使用 Popover 可以讓使用者按下畫面外部任何地方就讓它關閉,而這在 Modal 是不行的,也會讓它看起來是新飛入的畫面。除此之外,Popover 可以擁有一個箭頭指向控制項,相當靠近使用者按的地方。讓使用者可以一直專注在原來的內容,如果用 Modal 會有打斷使用者,有點像是什麼事情要改變了。

如果要操作一個列表超過一個操作,使用 Popover。
如果需要使用者來看階層性的視覺,使用 Popover。
如果使用者在完成主要任務前想要做些事情,可以考慮使用 modal popover。
如果這功能操作會深入多頁操作,而且呈現跟原來畫面功能有關,使用 modal popover。
如果功能只會用到一次或者不常用到,類似設定功能,使用 modal popover。

如果考慮使用 Modal view,確定閱讀關於不同畫面切換的形式,使用適合的成像方式來完成 modal task。

5. 將 Toolbar 上的操作帶到上方

如果說 iPhone 應用程式有一個 toolbar,考慮不要放在下方,而是將他們都移到上方。擁有的加寬型的 iPad 畫面,是可以將所有 toolbar 上的功能帶到上方的。這樣一來可以讓我們擁有更多空間來閱讀內容。像 iPhone 裡面的 Mail 在下方會有重新整理、整理、刪除、和寫新內容,而在 iPad 上會將這些動作放在上方,而重新整理會放在 mailbox list,而當畫面直看的時候,從左上方 Popover 出來使用。

以上整理自 iOS Human Interface Guidelines: User Experience Guidelines。近日朋友問我,為什麼台灣的 App 有些行為看起來很詭異怪怪、甚至煩人;但是又有些台灣做出來的 App 可以厲害到跟國外歐美做出來的 App 不分上下,很有質感。這中間差異有哪些?當我回來詳讀 iOS Human Interface Guidelines,發現到這裡面告訴了我們很多設計上的準則,Apple 在審核上雖然以此篇為標準,但是也不會說一定每一個都要設計百分之百到位,很多我們看到在 App Store 上看起來遜色的,你說他們不符合審核標準嗎?如果標準是 60 分就讓它過關,我想這也只是符合 HIG 的表層而已,當我們深入去閱讀 iOS Human Interface Guidelines,才會瞭解這每項道理背後的用心,Apple 對於我們開發人員的苦口婆心,當真正用心地去規劃與實踐,我們才能距離使用者給予五顆星的評價更靠近了。

Saturday, September 17, 2011

開發 Location based 的 iPhone app , MapKit 知多少

2011 粉樂町 iPhone App
我在之前介紹過多篇部落格跟開發 iPhone app 遇到地圖有關的應用,也曾在 Hackathon in one day 提過平常的技能累積有多重要,這樣上了戰線才能即時反應出個人戰力,如果說開發過跟 Location-based 為主的 iPhone app,對於地圖的應用或多或少都有心得了吧!以下為個人根據實務上會碰到的各種功能特色或是需求,所列出來會碰到的情境,如果一題 10 分,你懂幾分呢?

我曾經跟夥伴開玩笑說,我們應該來做各種技術的 badge,當經過一定程度的試煉,就可以得到該勳章。試著來 Unlock Map-Kit 的勳章吧!

實務題
  1. 在地圖上標示使用者的藍點位置,取得使用者的所在座標位置。
  2. 將眾多座標,從上降下的方式標示在地圖上。
  3. 說明 Design Pattern Flight weight 在 Map 開發上應用到的地方與使用的原因。
  4. 當座標點非常多,透過地圖飛入的方式將所有的坐標以適當的 zoom in 方式出現在畫面上。
  5. 當座標點選下去,會點選 MKAnnotationView,將特定的圖片顯示在左方,點選右邊 Disclosure 可以進入介紹頁面 ViewController。
  6. Designer 畫了一個座標圖示,將之替換原來內建的紅色針頭,將它標示在地圖上。
  7. 計算出使用者手機的位置與座標距離多少公里。
  8. 當地圖以中心為起點,滑動了 10 公里,重新跟 Service side 要新的資訊。
  9. 透過使用者的位置坐標,顯示靠近的道路路名稱。 
  10. 透過手機朝向位置的功能,將地圖可以支援自動旋轉,做出指北針的效果,北方不變,地圖選轉的特效。

進階題
  1. 支援街景
  2. 支援地圖導覽
  3. 透過使用者輸入地址查詢到該地址的座標。
  4. Google 的浮水印沒有出現在地圖顯示上,會造成怎麼樣的後果。

以上這些情境都是在開發實務上會碰到的,有些可以在我先前文章找的到解答。換個身份,甚至身為 iPhone app 使用者的我們,這些功能對我們來說,是不是已經在各個 App 裡面很熟悉的遇見過了呢。

Wednesday, September 14, 2011

在表演型的舞台上說出動人故事

“我們一生總是不停的奮鬥,時而熱情擁抱人生,時而執著於目標,但也曾經因為岔路而佇足,擔心選擇,害怕失敗。但是,一次不同的際遇,往往是一段精采的故事;選擇人較少的路,或許會發現新的方向。”

我最近因緣際會關係,擔任了這次 9/10 TEDxTaipei Salon - The Road LessTraveled 活動的工作人員,這次負責工作是將整個活動的相關投影片、影片等等切換投影做好的控制。從活動前一天的彩排,當天活動前的預演,到當天下午正式開始,如何將所有流程講者要分享的故事協助控制得好,這個經驗是非常難能可貴的。

活動進行中的環境介紹:
  • 舞台上講者的前方地上有兩個小螢幕,一個可以播放講者投影片,另外一個是要播放倒數計時的提示,講者的背後是一大面投影出來正在講的剪報頁面。講者身上只會有麥克風和投影片切換的遙控器。
  • 工作人員的音效、聲光、電腦控制必須在遙遠的二樓控制中心進行協助,電腦必須可以支援影片播放、投影片切換和其他音樂播放等需求。

過去我們做過台前簡報,也有過或多或少的簡報授課的經驗。但是試想今天 TEDx 這樣的舞台,要如何進行呢?又會碰到那些問題?需要志工的我們來克服。
  1. 筆記型電腦 Mac 僅會有一個影像輸出。
  2. 電腦與舞台距離非常遠,而且是不同層樓。
  3. 講者會到當天還在修改自己的檔案。
  4. 講者會給很多個人命名的檔名,包含了影片、投影片、圖片集,甚至會分版本,檔案大小也非常大。
  5. 如果有六個講者,搭配主持人等等不同播放需求,順序而言是要緊密在一起,不會有讓觀眾等待的呆滯時間。

以上你是否覺得已經面臨不曾有過的挑戰與壓力了呢?

彩排與預演階段對於志工我們而言僅是摸索環境與熟悉環境而已,更別說出包不斷、卡住連連等狀況百出。發生了檔案太大 copy 很久等待的窘境、發生了電腦抱來抱去切換螢幕造成當機發生、發生了檔案找不到播放不對的狀況、發生了協助人殺過來電腦控制台詢問某講者檔案準備齊全否實際上檔案是落在另外遙遠工作人員的身上、發生了講者準備在台上練習了卻發生螢幕打出來上下不一致情況、發生了太多慘不忍睹的狀況。

請問如果是工作人員的你我,要如何進行下午觀眾滿席的盛大活動呢?

活動預演結束活動進行前的中間休息時段,我們技術工作人員團隊招開非常重要的檢討會,做出來幾項重大的改變:
  1. 將所有手頭上所有散亂眾多版本檔案點名,抓出要活動所需的檔案。
  2. 根據活動進行的順序將檔名分出順序,何時播放影片、何時緊接投影片都排序清楚。
  3. 兩台以上的電腦都準備一份檔案,但是將各個電腦進行任務分配,哪台串接主螢幕,哪台負責影片哪台負責投影片,如何交互配合切換的分配。

最後上陣了!過程緊張緊湊,分分秒秒計較的準確切換,目標讓整個節目組合到天衣無縫的感覺。也只有在參與的當下,才能親身感受的台上講者說的動人勉勵的故事同時,也能體會到我們自己身在台下堅守崗位的幕後推手責任心與榮譽感。這次協助機會得來不易,讓我們學到志工寶貴的一課,全場的觀眾也被台上的講者感動的全體起來鼓掌最為最後的 Ending,也順利讓活動劃下完美的句點。

Thursday, September 1, 2011

Inception Deck

Created by Sticky Notes for iPad
當我們工作面臨到各式各樣大小專案、也會參與產品的設計,我們有什麼方法可以讓我們的團隊大家是保持在同一個方向同一個陣線上前進呢?團隊合作在於彼此扮演好自己負責的角色。在 Agile Samurai 這本書介紹到 Agile Inception Deck,這是一套有效 Agile 方法讓團隊們可以在最一開始就保持對的方向。

如何運作

Inception Deck 是要告訴我們把對的人拉進來,彼此商量對的問題,把大家對於這個專案擁有的期待收集整理起來。將整個團隊透過幾個步驟與方式把整個概念與想法可以凸顯出來,透過這一連串的方法可以把好的想法激發出來,大家彼此對於這個計劃的樣貌,不該成為的樣子,最終要產生怎麼樣的結果 ship 出去一一成型化。

只要涉及到這專按計劃的成員都要參與,最理想是要包含客戶、負責人、團隊成員、開發人員、測試人員和分析師等等。負責人參與相當的重要,因為我們碰到最艱難做與不做抉擇之間,是需要負責人幫忙判斷做裁示的。

而 Inception Deck 是活躍的,它不是一個拿來做完文件後就不再碰,而是要把它放在團隊某個地方提醒大家該做什麼,為什麼要這麼做。

這是 Inception Deck 的概括,當然 Agile 原作者有提到,這是個起頭點,可以試著靈活運用,做出屬於自己的方法。

1. Ask why we are here.
這是提醒我們自己,為什麼我會在這邊,我們的客戶是誰,為什麼我們會選擇要起始這個專案計畫。

2. Create an elevator pitch.
如果我們僅有一個搭電梯的時間來介紹我們的專案計畫,我們會如何介紹,這個時間長僅有 30~60 秒時間而已。而 Elevator pitch 有個簡單常用的公式:給某某某,需要做怎麼樣的事情,這個計劃產品是個如何的工具,用來滿足怎麼樣的行為。不像於哪些系統工具,我們的工具是建立在什麼什麼理念之上來達到怎麼樣的服務。

3. Design a product box.
如果今天在雜誌上看到咱們的廣告,我們會希望它呈現什麼樣子,最重要的是,人們會什麼要購買它。

4. Create a NOT list.
要做什麼事情很容易,我們可以許願許不完,但是如何清楚定義出我們不要做的是很重要的。

5. Meet your neighbors
我們的計劃社群比我們想像中大很多。為什麼我們不把大家拉進來喝喝咖啡,聊聊與認識彼此呢?

6. Show the solution.
讓我們把計畫藍圖畫下來,打算用什麼技術來解決我們的問題,畫出來讓團隊們可以有共識。

7. Ask what keeps us up at night.
什麼事情發生會讓我們半夜睡不著覺的,這算是風險評估。怎麼情況下會影響我們很深,要把它寫出來,避免這個恐怖錯誤機會發生。

8. Size it up.
將整個計劃要進行多久,多大規劃明確定義出來。

9. Be clear on what's going to give.
專案涉及時間、範圍和金錢。怎麼調配情況下是我們可以接受並且交付出去的。

10. Show what it's going to take.
成本要花多少?時間要多久?我們需要把我們的團隊規模大小定義出來讓我們投資者知道。

在專案裡頭使用 Inception Deck 不是夢幻,他是要讓大家都可以在同一個房間,有如
讓對的人都坐上巴士,問尖銳有效的問題,共同討論,然後再把結果分享給負責人或者資助者。雖然這要花一點功夫和時間,但是這對於專案理想中的期待是可以帶來無價的幫助。也用此來提醒我們和我們的團隊夥伴們該扮演好我們的定位與角色。

以上是 Inception Deck 的概念與概略方法,想要瞭解更多可以參考原文 The Agile Inception Deck.

Sunday, August 28, 2011

社群團隊如何擬定出一個 iPhone App 企劃案

Design iPhone App Project

前言

這是一個真實故事,最近我參加了讀書會社群,一個來自各個領域不同背景的夥伴們,因為有一個共同的目標就是我們想學 iPhone App 相關的企劃、使用者行為研究與技術等知識,所以我們凝聚在一起讀書,為了書讀能學以致用,我們就組成一個社群團隊,目標做出屬於我們的 iPhone App。我們歷經了兩個月閱讀 iPhone User Experience 一本書,也開始討論出我們想要做哪一類型的 iPhone App,現在走到了如何敲定一個 App 企劃案。

我們針對『交友、攝影』這樣的主題來開始進行討論我們的 App 企劃,這過程相當不容易,因為大家背景不同,想法不同,興趣不同,太多原因我們都不如此不同,我們要如何產出單一個心服口服,共同一致的 App 企劃案呢?

社群團隊跟我們平常工作團隊有何不同?社群團隊因為來自各自領域,大家挪出假日時間齊聚在一起,目標為了學習新知識,所以我們首先要找出我們可以運作下去的動力,開始起頭是因為先有個概念說我們要學習參與過程,因為我們彼此可能有新手,這些夥伴可以參與到工作上無法扮演的角色,也有實戰經驗夥伴們。大家可以 Open mind 提出自己的 idea,而且必須從每一位不同的 Idea 去找出個共識,相當不容易。關鍵不外乎還是在溝通,每一個人要講出自己的想法,不論是 good idea, not good enough idea,所有夥伴都要給予熱列掌聲,這樣大家才能會有更強烈參與感與肯定感,最重要我們是來學習的,所以不恥下問,虛心受教是基礎的共識,如此我們才能共事。


一個社群團隊如何擬定出一個 App 企劃概念?

每人一張紙,寫下心目中的 App 企劃案

我們每一位發了一張黃色的橫條紙 (經過証實黃色的紙張書寫起來會更有靈感,激發創意),寫下『情境描述為什麼要有此 App、它能帶來好處與解決怎麼樣的問題』。將此 App『訂定主題』,『找出銷售點』,『列出功能會需要用那哪些』,這過程目的是激發大家心目中最渴望擁有的 App,從渴望程度一直逼到跟大夥講出來,創造出那個 Passion。

輪流講出動人的企劃案

大家圍成ㄇ字型,每一位我們輪流到中間,拿著手上的黃色紀錄紙,跟大家說出動人的故事情境。順便拿起馬克筆,在桌前超級大張的白紙上,用圖形畫下自己的點子,將關鍵字、關鍵流程、關鍵的精髓紀錄下來,最後再將書寫記錄紙貼在旁邊空白處。大家一一輪流跟大家介紹心目中的 『交友、攝影』 App。除了介紹人將之外,大家可以扮演類似老闆、投資人、消費者的立場來跟介紹人請教,題目、銷售點、概念哪方面不清楚,討論到清楚。在這過程大家可以學習到提案的應變能力,以及觀摩大家用心的點在那些地方。如果有用心參與,將會發現每一位認真起來都很優秀、優缺點也都會有,這樣很正常。

當大家的點子都提完,我們該如何篩選出唯一主要企劃案呢?

Idea 過濾檢查表

我們寫下來大家對於一個 App,在給予打分數上會有哪些分析指標。大夥們訂定出了『實用性、技術可行性、趣味性、互動性、誘因性、具黏著性、照像攝影功能、便利性 (簡單 / 快速) 』這幾個評估特色。將每一個企劃案套入這些特色,給予投票裁決說是否有足夠的條件符合該特色,將這些特色對照給與紀錄。另外我們將所有企劃案撇在一邊,大家來投票將這些特色給分,認為這每一個特色在我們心目中的重要性,最後我們就排出了檢查表的權重。

權重統計

點子企劃案有了、對照檢查表也有了、特色權重分數也有了,就是答案揭曉的時候到了。App 企劃案星光大道就這樣全部套用在一起,我們的分數就一一開出,得到冠亞季軍等名次的企劃案。

最後

我們在這過程目的是希望在民主開放式 Open mind 團隊下結合大家不同的意見和點子,最後產生出我們認為最 Powerful 的單一企劃案。但是不要忘記,我們不是要那唯一一個企劃案,要的是所有好的特色,只是以一個為核心,其他未入選企劃案裡面只要是可以抽拉出來的不錯功能特色,何不就將它加入我們的勝出這個企劃案裡面,作為加分的效過呢!

Saturday, August 6, 2011

一個 iPhone App 開發之路要走多久才能結束

開發之路
有衡量過自己從開始一個 iPhone App 開發專案,到最後可以順利上架,中間的路有多長嗎?有試著想過當一個開發計劃進來,到最後預估會何時給 Apple 送審、上架、使用者回饋修正到再改版要多久嗎?這個問題相當的重要,因為我們必須要知道這專案要走多久,當走的時間超出當初預期,開發人員會士氣低落,計劃負責人擔憂與煩惱。如果在預定的時間結束,開發人員會獲得成就感,計劃負責人在對客戶報告時候也才能交出漂亮的成績單。
 
依照我這陣子開發 iPhone App 專案和產品下來,可以漸漸歸納出要走的路有哪些,活動會碰到那些。

1. 專案計畫需求談定

常常會聽到這樣的聲音,『我想要做某某 iPhone App』、『我有個外包案不知道開發商是否有意願接』、『請廠商報價』,這都是在專案計劃起頭時會面臨的難題。身為使命必達、功能不但開發完善、還外加些額外加值服務的開發商而言,只有一個目標,就是結案。把專案 100% 結案,時間不要拖太久為始終目標,在這階段一定要把功能需求條列清楚。哪怕一筆一筆的寫下來會有哪些功能內容,這樣子計畫在協定的時候才能對於整體的範圍才能有個概念。至於之後進行到後面階段,如果要新增任何需求,都要在一開始就把醜話將在前面,會如何處理。很多專案計畫好不好做,在這一開頭就決定勝敗了。有幾個指標可以拿來評估:
  • 對於開發的功能明定了嗎?
    這步如果沒走好,會產生需求蔓延的現象。
     
  • 對於功能之間使用上複雜度高不高?
    如果程式高會深深影響後面開發與測試,因為複雜度高,邏輯上就會難開發,難驗證功能開發正確與否。簡單衡量 iPhone App 程式複雜度可以從 UIViewController 有多少個、程式碼 source code 本身複雜度會不會提高等方向來評估。
  • App 的 UI 上有沒有特殊要求?
    如果參與計劃上有搭配 Designer 負責配色、圖案設計對於 iPhone App 本身而言影響多深。這要用來衡量開發人員和 Designer 合作上會面臨那些合作。
  • 除了 App 本身開發之外,其餘的加值服務會需要哪些?
    在 iPhone App 方面常常被牽扯進來的加值服務是:社群分享、使用者使用 App 行為追蹤、錯誤回報、幫 App 上 App Store 打分數提醒、push notification、支援 In-App purchase 等等。以上這些跟 App 本身要給使用者的服務不是那麼的相關,但是也影響到整體計劃上的策略應用。貪心的人類一定會說這個我要、那個我也要。這邊會深深影響到日後開發上和測試上所需要的時間,所以這部分要謹慎納入考量。

2. 草稿手繪型的 Paper prototyping

在這階段會把收集來的文件、需求列表開始討論、不論是在黑板上畫出個想法、隨便在張紙上畫出想法。當最後都差不多時候,開發團隊可以用清楚的線條來畫出畫面該有的元件、各個頁面之間會長怎麼樣子。Paper prototyping 對於我們的重要性是:要快、要明確定出畫面長相、要明確瞭解到我們要開發怎麼樣的 App。如果在這個階段可以把 Paper prototyping 跟老闆或是客戶報告是最好的。客戶參與設計是 Aglie 敏捷式開發重要一環。在這階段一定要把功能範圍開始敲定,如果不敲定再往下走會逐漸走向功能蔓延開發之路。

3. 可互動的雛型設計 Prototyping

當 Paper prototyping 畫出了,功能範圍也大致敲定了。開發人員可以開始用互動式雛形工具,或者直接打開 Xcode 開始打造整體框架出來,這個範圍會包含畫面上的種種元素、配合些假的資料 (Mock data),讓這階段可以產出可以互動的雛形出來。這個階段的重要性是把原來僅有畫面的紙上雛形,逐漸讓它活起來,不但畫面更細緻更精確了,也讓整體 App 動線上呈現出來。任何只要發現不順、怪怪的在這階段都非常歡迎提出來。而如果互動式的雛形可以放到實體 iPhone 裝置上體驗,那個效果會比在電腦上看來的更精確。如果說所有該有的功能在這階段都做出來,才可以估這個專案計畫完成度 20%。

4. 實作開發

當拿到上個階段的產出 Interactive prototyping,開發人員即可依樣畫葫蘆開始實作起來。在這階段開發人員會作:訂定邏輯處理、設計 Domain object、引用各種 library 和 frameworks,接上真實的 Web Service 去呼叫真實的資料,將 Mock data 卸下,放上真實的資料,講功能一一打造出來。如果說在這階段將所有的功能都做出來,也做好了功能測試、單元測試的話,確定功能穩定度沒問題的話,才可以估計這個專案計劃完成度僅有 60%。

5. 功能釋出開始測試

當功能做出來,除了開發人員本身測試品質之外,也會開始請相關人員參與測試,承辦人、設計師、相關同仁確定這樣設計出來是當初計畫要的,而且開發人員在開發認知上,和專案負責人瞭解上是正確的,在這階段這個專案計劃完成度僅有 70%

6. 使用者測試

如果說開發的 iPhone App 已經可以在裝置上測試,且也讓相關負責人員確認過功能就是要這樣子之後,我們需要的是使用者測試。開發人員不能代表使用者,因為開發人員打從一開始就參與這個案子,很多東西都會當成理所當然,功能就是要如此一般使用。但是真正的 end user 他第一次打開這個 App 就是這樣子使用嗎?他會不會困惑呢?會不會有驚喜呢?會不會有卡住無法走下去的呢?在這個階段不是那麼必要性,但是也不能不做,做使用者測試需要成本,只能說能多做一次,能讓 App 本身更好用,這個投資就是值得了。要探索的是是否娛樂性、好記性、容錯性、簡單上手,開發上不會明確知道這些答案,只有使用者能告訴我們客觀的答案。

7. 反覆式設計

根據功能釋出收到的回餽,不論是 Bugs、Improvement、或者任何建議都是在這階段一一做修正做調整,讓 App 可以越來越上軌道,越來越貼近期盼看到的樣子。每當一個階段結束,我們可以返回前面第 5 和第 6 步重複進行,一直進行到大夥們的理想。那麼完成度就可以對照到 80%、85% 或者 90%。

8. 準備提交送審

能走到這個階段要非常恭喜專案中的每一位成員了,因為產品終於要準備問市了。當最後確認功能都沒有問題、 App 本身的 Icon 和歡迎畫面 Default 圖都準備到位,和 App 本身的各種屬性版本等等設定沒問題,就可以 Archive  準備提交給 Apple 送審了。在送審等待問市中間的這個階段,我們可以為下一版的功能開始開發,回到開發人員實作的部分。

9. 上架後的應對措施

當 iPhone App 上架後才是真正見真章的開始,有多少下載量,有多少人購買,有多少人在上面發表個人使用意見,這一切是如此的逼真,因為 iPhone App 才真正的被市場打分數。

10. 更新版的釋出

iPhone App 的 1.0 版問市一定會搜集到很多的回餽,而這些回餽和原本預計開發的一定會影響著下一版本的開發與提交給 Apple 再次送審上架,這個階段也是從活動 4 實作開始。
 
如果我們不想要讓專案 Delay,甚至希望可以提前問市,那麼就要拿出我們的專業度出來,對於一個 iPhone App 開發之路要走多久,我們心裡一定要有譜,有譜我們才能走的順利,才能開發地安心,開心的結案。

Thursday, July 28, 2011

Google Analytics SDK for iOS version 1.2

先前介紹過兩篇關於 Google Analytics for iOS 介紹,分別為 Google Analytics SDK for iOSGoogle Analytics SDK for iOS Getting Started。那時後官網 Google Analytics for Mobile 推出的是 Version 1.1 ,可以用來記錄追蹤 Page view、custom variables 和 event tracking。但是經過這陣子使用下來,發現在使用上障礙非常的大,問題來自兩大部分:
  1. 當程式在呼叫送出 Custom variables 之後,會出現 EXC_BAD_ACCESS message sent to dealloc instance 的 error,相對的 iPhone app 就直接 crash 掉。
  2. 當程式按下到背景,過一陣子再回來原來的 iPhone app,他也直接 crash 掉。
上網查了些問題發現到 custom variable 問題 google analytics sdk for iOS bug with setCustomVariableAtIndex。各個開發者在使用 track event 和 track page view 都沒有問題,但是在呼叫 custom variable at index 就直接 EXC_BAD_ACCESS。

因次整個 iPhone app 在導入 Google Analytics for iOS 是暫告失敗。

直到最近再次發現到 Google Analytics for Mobile 推出 1.2 版了,這版新增了支援 Ecommerce hits、debug flag、dray run flag 和 SQLite3 使用上錯誤描述更清楚。而改善方面修正了 custom variables crash 和使用 custom variables 的 memory leaks。

於是最大的問題獲得改善了,將 1.2 版重新導回了 iPhone app 專案裡頭,反覆測試與修正,最後讓整個系統不但支援這些數據收集,也讓系統的不 crash 穩定性提升了。

Friday, July 15, 2011

了解使用者從觀察與同理心開始

試著從兩種極端醫生問診病人的情境來思考想想看:

情境一、當醫生在看病的時候,當病人還未開口說到幾句話,醫生就冒然定義病人的症狀,因此做出判定而決定怎麼醫療處置,這樣子的病人是否會傻眼與嚇到呢?

情境二、當醫生在看病的時候,病人不管說怎麼樣哪邊很痛身體哪邊出狀況,就全盤接收就直接判斷該怎麼醫療處置,這樣子的情況病人是否會覺得醫生沒有專業度而恐慌呢?

合理的方法即是中庸之道,從病患的症狀,參考所有的現象症狀搭配之前並立綜合的診斷再開處方,才會是最專業的醫療方式。我們在做自家產品服務的時候,是否也會掉進這樣的陷阱與迷思。未曾足夠瞭解客戶問題與需要就直接動筆開始設計與實作,或者不論客戶說什麼講什麼就全盤接收,最後堆出一個四不像的產品服務而無法讓人使用。

我們想要了解使用者,一切就是要從『人』來說起。我們不是使用者,我們只瞭解自己個人的問題,以自己的遭遇去套用在使用者身上,就會做出自己滿意卻不太被市場使用者們接受。因為這不是我們的世界,也不是你們的世界,也不是他們的世界,這是大家共同的世界。所以我們要以謙卑虛懷若谷的角度做起,唯有放下自己的身段,將自己扮演成旁觀者來看使用者的行為,才能收集到我們所需要的資料與現象。當分析的時候拿出我們的專業能力,才會知道這功能的定義為何,瞭解背後的原因與道理。

觀察 - 將自己歸零,放在使用者的角度來看他們的世界。使用者是如何處理生活周遭的事情,紀錄下來他們的遭遇與解決方法。

同理心 - 試著扮演起對方的角色,來思考他們面臨的問題。『老人家』是如何生活作息、『學生族』是如何求學、運用將心比心『父母姊妹們』是如何抱怨與滿意他們生活上的大小事物。

為什麼我們要了解使用者?因為了解使用者才能做出符合他們真正所需的產品。

我們要如何定義我們做的產品真的符合使用者的需要呢?試著就問問自己最直接跟產品正相關的問題:
  • 如果今天設計『看屋』的網站或是行動手機的服務,是否可以讓使用者成功的找到他夢想小屋。
  • 如果今天設計『社群類型』的網站或是行動手機的服務,是否可以讓使用者和朋友們成功聯繫很順利與愉悅。
  • 如果今天設計『優惠折扣』的網站或是行動手機的服務,是否可以讓想找好康的使用者們真的在同樣商品之下,獲得優惠與折扣省下荷包。
  • 如果今天設計『展覽型活動』的網站或是行動手機的服務,是否可以讓使用者在看展覽同時能有美好的學習與難忘的體驗。

不要擔心做使用者觀察與研究是很辛苦與勞累的,哪怕只是一點點的改善,就能大大影響使用者的體驗與使用性,那麼我們的『微革命』就是成功的,在幫助使用者完成他的夢想之後,我們才算是完成我們設計的夢想。

以上是我參加由 悠識數位 舉辦社群網聚『HP23 - 認識使用者』的心得筆記與個人感想。最後聚會上講者分享裡面,我最喜歡的一句話:"Get out of here, and change the world." 這跟我寫部落格文章以來一直告誡自己的名言相呼應:"Be the change that you want to see in the world. - Mohandas Gandhi"

Sunday, July 10, 2011

Find problems, find solutions

在做 User research 我們可以採取問卷、訪談 (interview) 或是焦點團體 (focus group) 來進行,這幾個做法在互動設計裡面是可以一一學到技巧和優缺點。

Focus Group 這辭彙是在描述一種使用者研究,將品牌、服務或者設計或者相關的產品展示給一個特定使用者小組,透過他們的反應和意見來做紀錄。目標是要使用這些資料來提前預測公眾們對這產品得到的反應。

在看到 Designed for Use: Create Usable Interfaces for Applications and the Web by Lukas Mathis 這本書在開頭介紹使用者研究有提到了兩個案例而學到經驗是,採用調查、訪問是一種方式,但是資料取得後再去分析是更重要的,好的解讀才能做對方向。

我們在練習設計產品,從 User-centered Design 方式進行的話,第一步怎麼找出問題、找解決方案是最根本的問題,這步站穩了,後面再來談設計和實作。

找詢問題
  • 找出使用者現在當下正在做什麼。
  • 找出使用者必須要做但是實際上是不喜歡做的。
  • 找出使用者會喜歡做的事情。
找出解決方法
  • 找出一種方式可以讓使用者做起來更簡單更有效率。
  • 找出一種方式可以讓使用者做起來過時不喜歡的,變成至少有趣。
  • 找出一種方式來讓使用者喜歡做的事情變成真的做的到。
我們不能代表使用者來說使用者就是怎麼樣的行為,而使用者透過言語講出來,也不是真正就是他們需要的,所以我們不能只是問使用者需要什麼,這個任務必須交給我們自己去解出來。

Tuesday, July 5, 2011

Registering for Remote Push Notifications

Local Notifications 和 Push Notifications 是兩種方式讓 iOS Application 在沒有執行的時候可以讓使用者得知訊息。使用情境上這個通知可以是訊息、一個行事曆事件或者遠端伺服器的新資料。而通知可以以 Alert 訊息或者是 Badge 數字來呈現。也可以當在 Alert 或者 badge 數字顯示時候播放聲音。

Push notifications 在  iOS 3.0 即有此功能,而 local notifications 在 iOS 4.0 才有。

先前我紀錄過 Local Notifications let users know it has something for them 如何進行,本篇則是以 iOS push notification 規劃上 client app 開發上步驟與事項為主。

要完成 Push Notifications 必須要三方的合作,分為 Push Provider、Apple push notification service、iPhone app。

iOS app for iPod/ iPhone/ iPad 必須要跟 Apple Push Notification service 註冊,如此 iOS 才能接收到 Application's provider 從遠端發佈訊息。而註冊對於 iOS app 而言分為三個步驟。

1. 呼叫 UIApplication 的 registerForRemoteNotificationTypes: method
2. 在 UIApplicationDelegate 實作 application:didRegisterForRemoteNotificationsWithDeviceToken: 來接收 device token。
3. 把 device token 非物件而是 binary 值這樣資料傳送給 Provider。

這些溝通過程在 Apple 上有個 Token Generation and Dispersal 文件可以參考整個流程。我們要注意的是,iOS application 必須每次在啟動時候要跟 Apple 註冊,取得最新版的 device token 寄給 provider。呼叫 registerForRemoteNotificationTypes: 來取得最新 device token,而這邊的類型接收 UIRemoteNotificationType,透過這邊來決定要索取通知時候支援哪些形式,Alert、badge number、sound。

如果註冊成功,APNs 會回傳 device token 到該台裝置上,透過 application delegate 進入 application:didRegisterForRemoteNotificationsWithDeviceToken:  這 method 裡面。而接下來就把這資料傳給 provider。

如果註冊失敗,APNs 會回傳到該台裝置上 application delegate 的 application:didFailToRegisterForRemoteNotificationsWithError: method ,藉由 NSError 物件來明白說明發生了怎麼樣的狀況。大部份會碰到問題是環境設定有關,所以要參考 “Creating and Installing the Provisioning Profile” 可以取得更多細節。

每次 Application 重新啓動都要將最新版的 device token 傳給 provider 這樣才能協助確保掌握擁有最新該台有效 token。如果今天使用者擁有多台裝置,備份還原,那麼到了新的裝置上也必須執行一次來取得 notification。所以記得不要將 device token cache 起來才交給 provider,記得要取得最新的。

Sunday, June 26, 2011

黑板、筆記本系列 iPad App 展示與觀察紀錄

對於手頭上的 iPad/iPhone App 自己覺得驚豔的,想要介紹給朋友,你的方式是如何?在整個分享過程是如何進行?大家的反應會有哪些?如果在給朋友嘗試摸索過程,你會安靜地觀察嗎?最後如何做好的收尾呢?以上這也可以算為一個簡單快速 Usability Test 的活動。以下為我最近對於不曾用過 iPad 的朋友做在 iPad 2 上面兩個手寫輸入的軟體做展示紀錄。


情境展示一、Chalk Board for iPad by conol, inc

開場白:我這裡有一個軟體很不錯,我介紹給你看看,叫做黑板。顧名思義黑板軟體提供粉筆、黑板、板擦讓我們可以在上面隨意的手寫,寫錯可以擦掉。(此時停頓觀察對方反應,對方可能會有疑惑與好奇,這就是我們進行下去的很大動力。如果沒有興趣,我們可以介紹別的去。)

展示中:打開 App 看到這很大的黑板,在下方選取粉筆我可以在上面任意用白色、黃色、綠色等顏色來寫,例如我來寫『值日生』好了。寫的過程不小心出錯,沒關係可以搭配板擦做修正,繼續寫。(此時對方可能會開始進一步反應例如一些讚歎的回應。)

請使用者體驗看看:好,現在換你來寫寫看,例如寫公佈回家作業。

觀察紀錄:使用者可能會想改題目,不過已經有個概念知道這 App 好玩地方在哪邊了。於是使用者在上面寫 xx 年 xx 月 xx 日,也算進行順利。對於換筆顏色和搭配寫錯用橡皮擦也都可以順利完成。對於寫下去發出的粉筆觸控黑板的實體音效回饋,有真的寫黑板的感覺,整體而言很容易上手與滿意。

心得:要讓使用者上手的 App,概念要越簡單越好,畫面動向要越直覺越佳。如此介紹者講的時候好描述、使用者好想像,對於軟體本身可以針對聲音的回饋、畫面的引導身歷其境,縱使不小心出錯,可以輕鬆的回覆上個動作。這在幫助使用者可否持續對於陌生軟體使用下去,很重要。


情境展示二、Bamboo Paper - Wacom notes for stylusBy Wacom

開場白:我這裡有裝一個很不錯筆記軟體。為何不錯呢?因為它操作起來跟真實在筆記本上書寫感覺很接近。在這裡面可以根據喜好調整紙張的格子和線條,例如我選則的是格子的線條。(此時停頓觀察對方反應,對方可能會有疑惑與好奇否)

展示中:我展示了裡面第一頁是 Demo 版,秀說可以達到什麼程度,比了一下,翻到第二第三頁秀了我用的方式,怎麼使用。開始翻開新的一頁,幫使用者挑選筆,讓使用者試試看。

請使用者體驗看看:使用者想要挑選自己要的顏色,也能分辨出筆的粗細和顏色,但是對於要將選後離開的地方稍微困惑。當開始在畫面寫的時候,會想要以像逛書店試筆方式一樣,在大畫面上開始畫出,對於寫錯的修正就沒有上一個黑板板擦來的容易,但是也很快找到可以清除掉整頁,重頭寫的方式。對於翻到下一頁也可以輕鬆繼續書寫。但是發覺寫起來有澀澀感覺。

觀察紀錄:使用者對於選筆完收起來和寫錯的修飾這邊可以做些調整可以更棒。對於書寫會覺得澀澀是因為使用者的試用 iPad 有貼保護貼,來自於那個觸碰的影響。

心得:最後這些寫完可以匯出當場用 Email 寄給使用者做紀念算是不錯的結尾功能。不過由於是觸控裝置的原因,所以用手指來寫尚不能寫到很細緻的部份,因為用細緻的指尖去測試,會發覺寫不出來。

經過以上兩個 App 的心得是,我們在做互動設計一直強調幾個目標:簡單、易學、容錯、日後容易回憶、快速達到目標等等來看,黑板和筆記本在這方面設計下了很大的用心,將實體的書寫感覺帶到 App 的設計上面來,好上手、出錯也都能讓使用者回到使用步調上。最後也都有符合到娛樂的效果。算是優質推薦的好 App。

Saturday, June 18, 2011

Senior UX Designer 所需要具備的條件

你跟我一樣在追求軟體開發精進同時,也願意花額外心思在使用者體驗和設計嗎?Amazon 現在在尋找 Senior UX Designer,工作地點在美國西雅圖。如果這樣好的工作是我們都嚮往,讓我們來看看需求與條件。以下整理參考自原文 Amazon is Seeking a Senior UX Designer in Seattle, WA

Senior UX Designer (Mobile), Amazon, Seattle, WA

你是一個有才賦和研究型的設計師嗎?花費很多時間研究智慧型手機勝過你的筆記型電腦嗎?你是否會下載研究 Mobile app 只是為了研究新型的 UI 呢?你是否擁有大量好點子,對於現在的 Apps 提出改善計畫呢?加入快速成長的 Amazon 團隊,設計明日電子商務 Mobile application,且看著自己的結果給上萬的人使用呢!

Amazon 專長於通路銷售、技術和電子內容刊物和手機方面服務的開發環境經驗,Amazon 現在要積極的幫助使用者一種新的創新的方法。所以在找尋資深使用者體驗設計師來設計 Amazon.com 的 mobile app。你可以重新到結束設計各種新功能。透過產品經理和開發來設計創意銳利,高品質,好的 mobile 體驗。

工作責任
  1. 負責設計既有的或者新的 mobile apps,使其引人注目、好用、讓人喜愛渴望的使用者體驗和介面。
  2. 能快速解讀商業需求,使用者研究和客戶反應放入 Personas 和使用者情境來導引使用者為中心的設計。
  3. 透過視覺的創意來貢獻產品概念,透過白板、圖表和高維度互動流程圖。要會設計程序包含資訊架構、wireframes,和圖片 mockups 和 GUI 元素,透過反覆式的設計來改善。
  4. 需要和敏捷高紀率的團隊一起設計優等的 UX 。
  5. 開發和維護 mobile 的 design patterns。
  6. 工作上會碰到 Mobile team,使用者體驗團隊和 Amazon.com 高階主管來 Review 和回饋。
特別的技巧
  • 需要有個人線上資歷證明工作過關於建立好的使用者體驗方案和 GUI 設計的應用程式。
  • 需要 5 年以上的使用者設計經驗,互動設計師,產品設計,相關在 Mobile, web 或者其他裝置上面開發經驗。要有和團隊協同合作經驗,和開發人員一起實作設計。
  • 必須是設計或者 HCI 等相關學士學歷。
  • 熟悉設計工具包含 Visio, OmniGraffle, Photoshop, 和 Fireworks 相關製作 IA 文件,互動式流程圖和高解析度螢幕般設計。
以上是 Amazon 在美國西雅圖想要應徵 Senior UX Designer 的徵才資訊整理,可以作為我們未來學習上的方向參考。

Sunday, June 12, 2011

Local Notifications let users know it has something for them

Local notifications 是一種讓該 iPhone APP 沒有正在執行放置在背景時候,而讓使用者可以知道有事情要提醒。這提醒可以是一個訊息提示、可以是行事曆事件、新資料等等。當 iOS 呈現該提示時,顯示訊息可以是 Alert 訊息或者用 Badge 的方式加在 APP 的 icon 上,搭配著聲音提醒。而當使用者看到這樣的提醒,可以選擇關閉或者點選來看,點選看內容則會開啓該 APP,再由 APP 導向訊息位置。

Local Notifications 在 iOS 4.0 之後才支援。

想要讓 iOS 可以在稍候傳遞 local notification 出來,要使用 UILocalNotification,將它登記日期時間,顯示的細節,將它登記 schedules 起來即可。當 iOS 收到這樣訊息,會根據該配製來決定 (alert, icon badge number, sound) 三種組合的形式。而當使用者點選 action button,那麼 APP 會啓動呼叫 UIApplicationDelegate 的 application:didReceiveLocalNotification: 並且將 local notification 物件傳遞進去。所以我們即可從這邊接收到的 local notification 來決定之後的導引處理。

Saturday, June 4, 2011

Google Analytics SDK for iOS Getting Started

Google Analytics for Mobile Apps SDKs 提供了一個簡單的介面讓 Mobile app 可以來追蹤活動與回報這些活動資訊給 Google Analytics。我們可以使用 SDK 來協助計算訪客量、停留時間、使用者分析。追蹤 mobile app 與追蹤 website pages 是不同的。這套 Google Analytics SDK 用傳統 web pages 的概念追蹤使用者和網頁之間互動的模式,再用同樣的概念套用在 mobile 上。可以參考上篇 Google Analytics SDK for iOS

環境準備:為了讓 Google Analytics's 可以追蹤 iOS app,需要 iOS developer SDK (requires Xcode 3.1+ running in Mac OS X 10.5.3+) 和 Google Analytics for Mobile Apps iOS SDK。

設定準備:準備好 iPhone OS 專案,從 SDK library 資料夾拖拉 GANTracker.h 和 libGoogleAnalytics.a 到專案裡面。將專案包含 CFNetwork framework 和 libsqlite3.0.dylib。

在使用 SDK 以前,必須先到 www.google.com/analytics 申請帳號,而且註冊一個 website URL 類似 (e.g. http://mymobileapp.mywebsite.com) 當申請好會取得 Web property ID,這是會用來追蹤的參考。Web property ID 長相 UA 加上數字,格式 UA-xxxxx-yy。在使用以前必須閱讀 Google Analytics Terms of Service 並且遵守規範。

開始使用 Tracker,開始啓動追蹤使用 [GANTracker sharedTracker] 的 startTrackerWithAccountID 這個 method,通常是放在 applicationDidFinishLaunching 裡面,過程都使用 [GANTracker sharedTracker] 來做紀錄的呼叫,最後在 AppDelegate 的 dealloc 再 stopTracker。

Google Analytics SDK for iOS

Google Analytics for Mobile Apps SDKs 提供了一個簡單的介面讓 Mobile app 可以來追蹤活動與回報這些活動資訊給 Google Analytics。我們可以使用 SDK 來協助計算訪客量、停留時間、使用者分析。追蹤 mobile app 與追蹤 website pages 是不同的。這套 Google Analytics SDK 用傳統 web pages 的概念追蹤使用者和網頁之間互動的模式,再用同樣的概念套用在 mobile 上。

使用 mobile tracking SDK 我們可以追蹤 mobile app 上面資訊有:
  1. Pageview Tracking - Pageiew 是個標準定義來評估流量大小,但是因為 mobile apps 沒有包含 HTML 頁面,所以開發者要決定怎麼樣算是一個 pageview。另外也要為 pageview 統計設計個檔案路徑結構,如此才能方便比較資料的層次性。而只要取的名稱實作在 Mobile app 上,送回到 Google Analytics 的報告上也會以這樣結構來做報表。所以我們可以根據 HTML pages 的概念來規劃 mobile app 上的各個頁面。 
  2. Event Tracking - 在分析統計上,事件是設計來追蹤使用者與網頁上各種元件之見互動。我們可以使用 event tracking 這樣的概念應用在 Mobile app 上,只要我們定義出 category 和 action 操作以及操作上的 value 值,如此即可知道哪些事件最常被使用,使用下都給與怎麼樣的值。 
  3. Custom Variables - Custom variables 是 name-value 搭配的 tags 用來另外塞入追蹤 Google Analytics 追蹤。
在使用 Google Analytics 與 Mobile app 設計開發上,我們可以做出怎麼樣的規劃使用呢?以 iPhone app 為例,我們可以在每個頁面 View Controller 當作一個 page,所以在各個頁面出現時,即做紀錄。最後可以得到哪些頁面從取比較高。而在功能動線上可以用 Event Tracking 來做紀錄,來瞭解這樣的 App 設計出來給使用者,哪些功能和按鈕事件等等最常被使用。如果以上兩者還不夠,我們可以使用 Custom variables 來規劃做統計,例如使用者是訪客還是會員,哪些資訊最常出現在畫面上等等。

透過 Google Analytics,我們可以瞭解我們的使用者族群、喜好以及最常使用與最不常使用的功能分別是哪些。想要了解更多可以參考 Google Analytics SDK for iOS

Sunday, May 29, 2011

Prototyping for iPhone apps

之前介紹過 Paper prototyping for iPhone apps,這篇來續談 Prototyping for iPhone apps。

我們在開發 iPhone app ,會有 Prototyping 的階段,這是從開發初期就要投資的活動,這活動會一直伴隨著我們開發過程,只要不知道開發如何下手,就是選擇做 Prototyping 好時機。

有很多種方式可以來做 Prototyping 選擇,從最低精準度的紙上 Prototypes 到真的用 iPhone SDK 來製作都有。除了了解這些方法之外,怎麼把它用在恰當的時機很重要,因為它們有各自的優缺點,根據時機來投入,才能獲得有效的效益。以下整理四種方式:
  1. 紙上繪圖 - 優點是便宜又快速。適合用來定義出概念、流程和文字辭彙的討論。缺點很難顯示出細節的互動,很難模擬資料豐富為主的 Apps。
  2. 靜態圖片裝在裝置上 - 優點是可以展現出視覺效果,包含字體的大小和排版風格。缺點是缺乏使用互動,僅能一個畫面和另外個畫面做切換。
  3. 互動式裝在裝置上 - 優點是模擬出像 iPhone 樣式行為,可以做出些互動操作。缺點是為了達到此目的必須花費出很多的設計時間。
  4. iPhone SDK 開發 - 優點是為了最終 APP 而做些設計與開發是非常有幫助。缺點是這是最昂貴而且對於很難作修改。
以上這幾種方式,我根據自己參與專案和產品開發經驗,這四種都會用到,而且各個時機都會不同,如此才能善用。
  • APP 在概念與些文件準備好之後,在開發非常初期,可以採用紙上繪圖,這對於跟內部同仁做溝通與傳達設計理念最好的方式。 
  • 在講究 Visual Design 的時候,因為要考量到資訊架構、顏色配色、字體等等,UI designer 會善用工具畫出靜態圖片,此非常方便讓團隊知道未來 APP 的長相,也是做為之後開發人員要配合套用的參考方式。 
  • 在互動式裝在裝置上,適用時機當參與討論此 APP 的同仁,可能沒有該 Mobile develop,但是很清楚知道此 APP 整體的邏輯,而且如果是跨公司合作很難可以當面講,設計出互動式裝在裝置上給對方團隊,對方團隊即可參考文件,按照著此來做瞭解其中的邏輯與動線,進而瞭解方便實作。
  • iPhone SDK 直接開啓 Xcode 開始開發,此是當以上概念都非常清楚,而且掌握了些展示資訊 Mock data,即可開始開發整體樣式,套用展示資訊,讓它可以在開發深入前,做個整體 APP 有效的瞭解與開發前的再次確認機會。
    談起 Prototyping,一開始起頭不容易,但是我們發現到,當工具與概念都到位了,直接動手開始做這樣設計,Prototypes 就可以一一成型了,沒錯,一切是從動手開始做才算數。

    Thursday, May 26, 2011

    Developing User Personas

    當我們在設計軟體,最明顯常見問題是,我們的觀眾是誰?要設計一個符合使用者預期,期望可以做出一套貼近滿足使用者的產品,經驗顯示這對一般人而言是不容易的。但是可以從簡單使用者資料做起頭,找出觀眾使用者會是怎麼樣的行為,來設計符合他們的需求。這樣對於設計師而言不但好著手一點,結果出來也會比較符合使用者盼望的。

    User Personas 對於設計初期是一個有用的資源,可以讓設計師透過簡單的方式來瞭解使用者預期和需求,對於後面 Usability testing 也有很大幫助。除此之外,對於設計團隊在溝通上也是一個很有幫助的工具。

    製作 User Personas 使用者資料第一步是要學習瞭解我們的使用者。可以挑選個好地方從一對一訪談開始。盡量和不同類型的使用者談話,這樣才能蒐集比較多元的資料。而每一個訪談我們希望可以找出行為、經驗和能力這些資訊。經過幾場簡單的訪談,覺得資料蒐集差不多了,就可以開始製作 personas。

    例如今天我們想要開發社群交友的平台,我們可以訂定訪談的問題,作為 User personas 資料蒐集所需:
    一、通常用哪些管道如何認識新朋友。
    二、是否嘗試過哪些場合交友,印象深刻的是。
    三、如果網站平台或是智慧型手機軟體,有嘗試過這方面交友工具嗎。
    四、這些工具有怎樣的特色覺得不錯或不好的。
    五、對於熟悉的朋友會想要跟他們保持哪些聯繫方式。
    六、對於陌生的朋友希望有哪些管道可以進一步認識。
    七、在社群交友平台上願意公開自己哪些資料。
    八、在每天哪些時段裡,願意花時間在這方面呢。

    當有了各種資料,可以開始寫下每一位的詳細資訊,資訊可以分類為:
    • 個人檔案 - 名字、年齡、性別和個人特色 (害羞、外向、積極等),居住所在位置、興趣與嗜好
    • 背景 - 對於相關領域是否有經驗、對於這方面的教育瞭解程度。
    • 科技背景經驗 - 是否使用過智慧型手機、是否使用過哪些電子商務網站、計畫開發中的軟體相關所需的使用經驗
    • 使用此軟體或者平台動機

    當資訊收集足夠,進入到產品功能討論時,這些都是非常有利的資訊。我們從 User-centered design 導入到開發週期裡面,研究整理 User Personas 是重要的第一步程序,這也是作為後續用來在開發過程牽扯到 user-centered 活動所需的資訊參考。

    Thursday, May 19, 2011

    The Importance of Visual Design

    Visual Design 對於整體 iPhone user experience 來說是個加分效果,很多 App 會在 Coding 結束才開始做 Visual Design,但是如果在晚期才開始給與的力量有限,也只能幫忙到表層而已,幫忙少數些 icons 替換和配色而已。對於真正的 App design 效果影響,Visual Design 要從早期概念該涉入列為重要階段。有效果的 Visual Design 可以帶來更多的使用者下載、加強 App 的高使用性和吸引使用者目光。

    第一、吸引使用者。當使用者在瀏覽 App Store 考量要買什麼時候,App 的外觀會深深影響他們的選擇。當然 App Reviews 口碑影響和 App 概念敘述文字也是重要一環,如果使用者沒有被吸引或者被驚喜,他們就不會下載 App 了。

    第二、加強 App 使用性。當使用者下載了 App,Visual Design 會變成第一個吸引使用者目光。有效個設計會加強使用者介面的設計,也會加強 App 讓它變簡單使用,可以讓概念呈現清楚、任務操作變有效、可讀性。

    第三、取悅使用者。Visual design 可以加強使用者經驗。當然如果說我們不做這些元素設計,App 相對的就會看起來不吸引人。所以好的設計可以讓使用者更喜歡它。

    何時該開始 Visual Design 呢?Visual Design 該越早越好,當然還是要看是設計怎麼樣的 App。我們的經驗是開發團隊可以使用系統快速建置整個 App 的骨幹和元素,讓 Visual Designer 可以接手來做些技巧調整。在未談美術設計前,可以先做視覺的結構整理。如果沒有清楚的視覺結構,App 會看起來很糟糕,無法讓後面美術設計加入進來,有幾個方法可以加強視覺結構:

    一、Grouping 群組化。將資訊同樣性質的靠攏近一些在同一區塊,將大量的資訊可以分類讓使用者預期在該有的位置,如此可以減少資訊複雜度,也可以幫助使用者知道我們設計想法。群組化可以將畫面同樣呈現這些資訊,但是集中化後使用者在閱讀上視覺不用飛來飛去,減輕使用者的閱讀痛苦。

    二、Hierarchy 階層化。透過階層讓閱讀上增加層次。同樣一大張資訊呈現,位置的擺放可以有很多規劃,在螢幕的畫面上面是最重要最突出的。最下方也是使用最容易找到,所以畫面最上方和最下方都是擺放最重要的資訊或是重要的操作。另外適當使用『Scale』的技巧,將重要資訊可以凸顯出來。用大的圖示加強圖片或是資訊可以讓使用者更快可以找到重要的資訊,在同樣區塊分出重要資訊和次要資訊。

    三、Alignment 校準。文字對齊可以讓視覺更容易閱讀和理解,所以在整個畫面盡量統一標齊顯示。如果是以注重使用者閱讀,盡量都以左邊標齊。

    人們想到 Visual Design 會想到圖片和 Icons 及顏色選用而已,雖然這些也重要,但是 Visual Design 還有更多技巧可以來改善視覺設計,包含幫助加強畫面資訊的結構呈現改良、顏色的控制、字體字型的顯示。當視覺資訊和結構到位,我們再帶入視覺元素像是 Icons 和字體改善。在這過程我們要時常告訴自己:App 的 Visual design 要在早期就列入重要考量,如果當 App 開發完畢再來,能改的會有限。不要讓 App 的視覺元素自己獨立製作,整體畫面、排版和顏色要通通擺放在一起做考量,才能做出重要的取捨。

    設計高優質的 Icons 非常困難和耗費時間。所以考慮僱請一位圖畫設計師或者找尋這方面專家,是個非常棒的投資。

    Saturday, May 14, 2011

    Refine mobile app's user interface 幕後花絮

    簡報 Ideas 擔任起導演與編劇角色
    網站企劃輕鬆聚 從 HP12 開始我一直持續參加到現在,每次都是期待活動前公告,開始搶報名,當天下班趕到現場聽台上講者豐富的工作經驗,從來沒有想過會有站上台分享一天。在三月時候,當活動預告五月有 Mobile design,想到這是個不錯的機會,當時剛好有些東西內容可以分享,於是就跟主辦人 悠識數位首席架構師 Richard Tsai 先預定一個分享名額,於是展開之後緊張準備之旅,準備過程可以分為三個段落紀錄:

    第一、選定分享題目很重要。一開始題目想要講『 iPhone app 開發的 UX 經驗』,但是討論商量之後發現這題目實在太大了,20 分鐘講也講不完,準備上也不好準備,題目一看無法瞭解簡報內容會是哪些,那這樣題目訂定是不佳的。後來反覆的思考,終於敲定一個跟我分享有關,題目又可以鎖定範圍,聽眾也能稍微預測到我想要分享內容『Refine mobile app's user interface』。會選擇 Refine 這個詞是覺得我們都會開發都會寫軟體,但是能做到 Refine 重新再改,能讓它更好,這個勢必有個吸引力在。

    第二、自己開始擔任起導演與編劇角色。用了便利貼把所有要講的內容,先全部寫在便利貼上面,便利貼上方粗筆寫大概念,下方用細筆寫稍微細節項目。於是一張一張便利貼就開始往空白牆上貼上去。開始編排順序性、串起整個簡報會寫的順序,如此一來概念、順序都好了。每隔幾天想到什麼,就貼上去或者挪動位置。當覺得差不多後,開始製作投影片。運用了 大家來看賈伯斯:向蘋果的表演大師學簡報 些技巧,安排三個重要項目將故事切為三個段落、分享熱忱經驗、每張投影片以好表達為主 (圖多字少)、找出敵人製造出英雄形成對立、適當搭配 One more thing... 讓好工作找上你這本書 做 Ending

    第三、充分的反覆練習。投影片在半個月前準備好,之後就是一直練習一直練習一直練習,用了 iPhone app 錄音軟體記錄自己講的內容,用 keynote 簡報啓動 rehearse 模式,一啓動不重來,旁邊搭配時間計時器開始講。最後 20 分鐘結束,回來調整投影片內容順序同時,旁邊的 iPhone 邊撥放著剛剛 20 分鐘自己簡報的內容聆聽。當練習到四、五次之後,最後小祕訣,在投影片附錄處寫下幾分之幾,分子為進行了幾分鐘,分母為總共有幾分鐘,如此一來可以掌握自己簡報搭配時間跟上自己的節奏。
      最後,在 HP19 活動上盡情的發揮與享受簡報的樂趣。還沒講之前的我真的很緊張,現場有兩百多人參加聆聽比往常多出一倍之外,又是新的大型演講場地,大家都超級安靜專心聆聽。最後上台我也因為有緊張而講錯些小事情 (再次強調是分享不是上課、是 Think aloud 不是 Speak aloud),不過簡報過程還能在自己及格的範圍。原來一直以為緊張會將簡報講快所以投影片要準備剛剛好,沒想到我卻因為緊張講更多更慢,導致後面多超出 1~2 分鐘才結束。

      還是要感謝 Polydice Inc.HPX 網站企劃輕鬆聚 讓我有這殊榮站在台上跟熟悉的社群做分享。希望以後我們每位能說出屬於自己更多更棒更好的精彩故事!祝福大家。

      P.S. 那天很緊張,我有帶一杯水上台準備 20 分鐘之戰,結果當我電腦投影準備好,水杯吸管一插上去,轉身之後,我的水杯就被~~拿~~走~~了!邁上了 20 分鐘沒水喝之路,這不輸馬拉松跑兩小時沒喝水的感覺。

      Monday, May 2, 2011

      After action review 讓重複的任務越做越好

      是否發現同樣一件任務事情重複做,有的人會覺得很無趣沒有進步;有的人卻可以越來越上手,甚至得到團隊同袍的欣賞與上級長官的讚美,覺得將此任務給該位是對的選擇。關鍵在於有沒有做事後檢討。我們無法第一次做就到位做的很好,但是如果我們可以從第一次做得到尚可,第二次做開始抓到訣竅,第三次做已經駕輕就手,那麼我們就是有進步了。

      After action review (AAR) 是一個結構化的回顧方式來檢討每次活動程序怎麼發生的,為什麼會這樣發生,如何可以讓它做的更好。而透過參與這個計畫或者活動事件的人們來做紀錄與分析。After action review 最原始是從 U.S. Army 做來針對任務做事後分析用的方式。AAR 發生在需要有領導人來帶領一個週期性的計畫,事先準備和實際進行與事後的研究檢討。

      After action review 可以分為五個流程:
      1. 預設情況會怎麼樣發生?
        活動進行前我們就要訂好目標,沒有目標我們不會知道我們為了什麼而戰。有了明確目標不論是個人或是團體,可以有明確的方向,把力氣放在對的地方。
      2. 實際現場的情況是怎麼樣?
        往往真的有機會親臨現場的都是執行人員,這個需要有賴於執行人員做下好的紀錄,當中發生了哪些事情,造成了阻礙是否可以克服。檢核目標的清單完成了幾項,哪些過關哪些沒有達成。
      3. 為什麼會有這樣的差別?
        執行任務後,一定會發現很多在開始前所猜測推斷的,跟實際真的進行了,卻未必是如此。有些是掌握當中,有些是意料之外,為什麼會有這些發生,都是我們很好的學習方式。
      4. 從此次任務當中學到些什麼可以使下次行動更有效?
        每次任務完成一定會發現有好的地方,也會有要改進的地方,如何去裡面思考與檢討,可以讓改進的地方作為下次不要再犯。
      5. 我們現在要做些什麼?
        根據此次行動檢討,可以列出短期行動、中期行動、長期行動。有些事情是可以快速採行的,有些是要影響到整個政策或是組織行為,有些是更長遠目標有關,這有賴於這時候做個分類。
      我們不論工作上或是業餘活動裡頭,一定會碰到需要反覆進行的活動,也難免會碰到自己初期不上手,或者碰到複雜把握度不夠的時候,After action review 是一套非常好的分析方式,此圖是用 Mindmip 整理出來的流程圖,過去工作上我也用此方式來解決很多有挑戰性的工作。希望 AAR 可以讓我們越來越進入狀況,越來越精進!


      點圖放大瀏覽

      想要了解更多可以閱讀 Wikipedia After action review 或者參考下這份 A leaders guide to after-action reviews

      Sunday, May 1, 2011

      Play sound effect on iPhone app

      在 AudioToolbox 的 framework,我們可以使用 AudioServicesPlaySystemSound 來播放音效。這個 function 可以播放簡短的聲音 (30 秒以內)。因為這個聲音會播放超過幾秒鐘,所以他是非同步的方式。想要知道音樂是否播放完畢,也有另外一個 AudioServicesAddSystemSoundCompletion 透過註冊 callback 的來查看。在使用上要注意有些限制:
      • 播放音效檔案不能超過 30 秒鐘
      • 必須符合 PCM 或者 IMA4 (IMA/ADPCM) 格式
      • 必須包裝成 .caf, .aif, 或者 .wav 檔案
      使用 AudioServicesPlaySystemSound 因為簡單,所以他是使用系統播放音量,不能程式控制聲音大小、馬上播放性質、不能重複播放和跳到特定位置、一次只能播放一個聲音。

      Saturday, April 30, 2011

      Git-flow 讓 Dev Team 步上穩健開發之路

      A successful Git branching model 點圖放大
      從去年開始我認識了 Git 這套新一代版本控管,最大不同是,它採取了分散式的控管,每一個開發人員都可以當作 branch,當然會有中樞在定義 master 或者主要開發幹線,當開發完畢要彙整回主要中樞位置,幾乎採取是 merge 的指令,光談 Git 使用,它已經強化了 merge 的功能,而且因為分散式的管理,每一位開發人員都可以自己做版本控管 (commit, reset 等) 當要跟中樞控管溝通才使用 (push, pull 等) 這些種種新的功能特色,讓 open source project 在開發上可以更為的順利與方便。

      既然 Git 在 branch 開設與事後 merge 這方面強化,在開發上是否有更好的開發模式,來協助我們軟體開發呢?

      Git-flow 是一套成功 Branch model 開發經驗而設計出來的協助工具,當安裝好之後,在 command line 下 git-flow 即可知道它的功能樣貌。

      主要分為幾個主要幹線和分支之間做交互轉換。接下來以開發一個從 0.2 進入 0.3 版本階段為例,這個開發里程碑裡面,需要完成三個主要 features:為軟體的 UI 做動線改善、UI 元素的修正、需要將物件導向的 data model 做翻修調整,套用在此 git-flow 上,作為一個使用 git-flow 生命週期介紹。

      首先準備好 master 和 develop 這兩個主要線,master 是做為最穩定可以交付出去的版本路線,develop 是開發人員的開發路線,這邊是有最新功能的路線。
       
      Day 1~2 將 UI 做動線改善,採用這樣指令 git-flow feature start uiNavigationArrange,於是幫在 feature 類別裡面,開設了 uiNavigationArrange 的 branch,於是任何程式開發都在這裡做 commit,如果需要同仁協助,就 push 到中樞管理位置,讓同仁可以一起開發。當完成後,下達 git-flow feature finish uiNavigationArrange。於是 git-flow 幫忙把此 local branch delete 掉,merge 回 develop 路線,再將 develop 路線 push 到最新位置,讓同仁可以做同步。

      Day 3 將 UI 元素修正,採用 git-flow feature start uiElementsEdit,於是在 feature 開設了新的 branch,將畫面需要各種元素控制項做些調整之後,下達 git-flow feature finish uiElementsEdit,於是 git-flow 幫忙把 local branch 移除掉, merge 回 develop 開發路線。

      Day 4 將 Data model 調整,採用 git-flow feature start refactorDataModel,於是在 feature 開設了新的 branch,將物件彼此間做些調整與擴充之後,修改完成後,下達 git-flow feature finish refactorDataModel,於是 git-flow 幫忙把 local branch 移除掉, merge 回 develop 開發路線。

      Day 5 要做版本 Release,採用 git-flow release start 0.3,於是從原來 0.2 的進展到本次新版本 0.3 的路線,進入測試階段,過程如果發現想要些微調整都在此 commit,完成確定此版沒有問題,採用 git-flow release finish 0.3,這時候就是 git-flow 幫忙,它會砍掉此 release/0.3,幫忙下 tag v0.3 (如果當初開始 git-flow 有為 tag 做 prefix 'v' 命名,這邊會自動加上去),且 merge 到 master 和 develop 路線,於是範例產品 0.3 版誕生了,此版功能有改善 UI 動線、變更 UI 元素控制項、後面 data model 的修正。

      如果上線發現有問題要修,就可以採用 hotfix 的方式來做些調整與修正,回饋到 develop 路線,也作為 master 的修正。

      以上是一個套用在開發專案或者產品所採用的開發範例,git-flow 讓開發過程站對腳步,又能將過程做個完整紀錄,不論開發團隊人數有多少,相信套用此模式開發,能讓 Dev Team 步上穩健的開發之路。最後要感謝 ihower 的部落格文章 Git flow 開發流程 介紹,以及圖片來自 A successful Git branching model 的文章。

      Sunday, April 24, 2011

      Whats the difference between UI Design and UX Design

      From Quora, Dan Saffer, Interaction Designer and Author
      在 Quora 網站上,有個討論主題是 "What's the difference between UI Design and UX Design?",在這篇的下方可以看到相當豐富的回答。

      而從回答來做簡單歸納是:
      UX 設計了整個物件主題的經驗,跟如何來使用這個產品或者服務有非常關聯關係。
      UI 是設計該產品或者服務的使用者介面,UI 可以視為 UX 的一個部份,但是很多好的使用者體驗未必有 UIs。而在設計 UI 時候需要透過 UX 設計來做資料整理和程線,受到影響比較大。而對於 UX 而言不會被 UI 給受限。

      我過去閱讀的互動設計這本書。對照到此圖,是位於整個 User experience design 裡面蠻重要的一環,它牽扯到人類行為,聲音設計、和人機互動設計等。而在互動設計這本書也探討過不同領域的設計概念。

      但是在這個圖裡面還有一部份是在談 Content 和 Information architecture,這部份是在探討資料如何組成有效的資訊呈現給使用者來看與使用,是否快速導到使用者想要的地方,是否可以快速瞭解此產品要傳遞怎麼樣的資訊。這在資訊架構學主要著墨的。

      回到整個 User experience design 來看,我們要設計好一個產品或是服務,有哪些面向我們要注意:
      • 資訊的呈現與動線
      • 內容提供什麼 (文字、影音、聲音、圖片)
      • 視覺設計 - 是否讓產品本身外觀看起來酷炫,有別於一般同類型的產品。
      • 人機介面互動
      • 聲音設計 - 是否在適當的時機提供恰當的音效或是音樂回應得使用者。
      • 工業設計
      • 架構
      下次當我們要分析一個產品的使用者體驗好與壞,我們可以從這些面向來做分析,得到綜合分數就可以拿來衡量此產品跟競爭產品之間,誰的使用者體驗比較優了。

      Sunday, April 17, 2011

      Tells that the region just changed from MapView

      我在開發某 iPhone app project 期間,當時 version 0.5 還沒有實作很多功能,有邀請了年輕的朋友 Bill 來體驗我們的 app,協助 Usability test。我跟 Bill 說明此 app 設計的目的,並且給他我的 iPhone 操作,題目是從手機上瀏覽商品搭配地圖使用與操作。而 Bill 在操作時候,我在旁邊靜靜的觀察。Bill 對於這套 app 很好奇,會切換到地圖上瀏覽,會觸控移動地圖看看效果,並且點選商品進去看詳細資料。

      事後我的紀錄整理,在開發沒做完的功能會誤按到,所以 Usability test 過程會遭遇卡卡的。但是對於已經開發的地方尚可。商品在相簿瀏覽等待網路傳輸 Loading 會很久,造成使用者沒有耐心往下看。另外我在觀察有帶來新的發現:使用者希望移動地圖的同時,可以插入更多針,顯示更多的商品。這功能可以讓我們的 app 帶來很不錯的體驗,是我們在開發時候未曾發現的,這也是我們本次 Usability test 最大的收穫。

      回到 iPhone app project,我開始思索如何來實作這個部份。想當然兒應該會從 MapView 著手研究,我查詢了 iOS Library document 發現有一個 Method 可以幫助我們。

      Sunday, April 10, 2011

      Paper prototyping for iPhone apps

      iPhone apps 的 Paper prototypes 會包含整個裝置、組合的螢幕、重疊浮出視窗、和一些操作控制項目等。要畫一個 Paper prototypes 可以簡單分為三個步驟:
      1. 準備原料和素材:當我們要在腦力激盪討論場合用、當我們要把設計草稿畫出來時候,這些素材項目對於畫 Paper prototype 是很有幫助的。如果可以話也包含重複用的紙卡、可以反覆貼的膠帶、膠水和剪刀等等。
      2. 辨別整體版面形式:有時候可以畫跟真實 iPhone 畫面解析度一樣 320 x 480 pixels (iPhone 4 是 640 x 960),當然 paper prototypes 可以不用那麼確切。如果考量畫比原來更大的表格畫面,可以在跟別人互動設計上更方便。
      3. 開始畫 prototype:Prototype 會包含整個裝置形式、螢幕和使用者介面的控制項目等。可以做出些被選取 highlighted 和沒被選取到 non-highlighted 的版本樣式。如果還沒決定好要放的 icon 也可以先用文字代替。
      點圖放大
      素材方面,使用者介面常用的控制項目可以準備哪些?
      • Keyboard:可以自己手繪鍵盤樣式或者拍照下來。沒有必要一定要把每一個按鈕畫出來,但是把焦點放在特殊鍵和專門給 email 輸入或者純數字輸入的表達地方。 
      • Sliders:可以畫出使用者在操作上選擇到的大約位置。 
      • Text entry:對於文字輸入地方,使用者可以先寫在 Post-its 或者反覆貼上,再將這貼到 Prototype,這樣可以不影響到既有的畫面。 
      • Navigation bar:這在對於使用者現在所在的頁面位置很重要,上一頁到哪,按下另外的按鈕可以有哪些特性,都可以表現出來。
      • Search Bar:對於大量的列表資料可以讓使用者輸入做搜尋與過濾所需。
      • Image View:可以表達出個人的圖像或是應用程式要呈現商品的圖示。
      • Segmented controls:使用者可以點選出幾種選項,做出些切換的效果。 
      • Loading page indicator:當程式在運作會有等待的時候,顯示出等待轉圈圈的 Indicator 讓使用者知道請稍候。 
      • On/off switches:做出類似啓動關閉的按鈕,讓使用者可以做開關的選擇。 
      • Check mark:當使用者做出選擇了,表現出勾選的樣式。
      • ......還有更多控制項元素。

      Paper prototypes 好處只有在快速的畫出與概念表達出來時候,才能達到提升協同討論和降低開發成本。 畫的太細緻是沒有那個必要的,使用者通常知道細節部份,所以我們只要可以表現出使用者看可以想像的出來即可。一樣的如果在準備 prototype 來做研究,不用擔心是否把介面元素畫夠仔細,反而的漂亮的 Paper prototype 是隨意畫出整個樣貌,添加控制項有如像飛的速度般在進行。
      照片上是在 UI Stencils 購買的 iPhone Stencil Kit,仔細的瞧瞧它包含了我們設計上所需要常用的控制項與 icon,甚至它把畫 Prototype 所需要的等距都有明確定位出來。如果有興趣可以參考官網 http://www.uistencils.com/products/iphone-stencil-kit

      Monday, April 4, 2011

      Get distance between two location from CLLocation

      Get distance
      在開發 Location based system 的 iPhone app,我們會想要做出哪些特性。使用者現在所在位置這很重要 (Finding your way with Core Location),透過一些地理服務來描述使用者所在地的資訊 (從 MKReverseGeocoder 解析更多地理資訊),會把使用者附近所要的資訊顯示在地圖上 (Learning Flyweight pattern by using MKAnnotationView),如此一來可以做出很豐富的應用了。

      如果今天我們要做到現在使用者距離這些地標各別距離有多遠,如果可以把這些資訊顯示出來,一定可以帶給使用者很有感覺,對於要找這些地標可以做出更好兩點概念。那麼我們要如何求出座標兩點距離呢?

      這概念要從兩點經緯度來看,而在 Google search 座標距離,網路上也蠻多公式在求計算這些距離位置。回到我們的 iPhone app 上要怎麼求呢?很慶幸的是 Cocoa 已經有內建,從 CLLocation 有提供換算的 method。