Pages

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,記得要取得最新的。