August F.Y. Chao

Archive for 2011|Yearly archive page

手持設備上的 App 設計

In 01 論 on 十月 14, 2011 at 2:02 上午

下面是我寫給朋友(Gates)有關設計手機 App 應留意的事項:

1) 手機服務設計不是單純的軟體設計,而是「服務設計」。
以目前 Software as a Service 的觀點來看,任何你所設計的軟體都該是貴單位服務的延伸。
所以你不能只單純以設計軟體的角度出發,像北捷之前開發的 App 都是不好的例子。
我會建議你可以先看一下目前 App Store 裡的分類,並把 Top 25 (Paid and Free) 裡的軟體先做個功能分析表,協助你思考有什麼服務可以與北捷結合。

2) App 設計不能只思考單機運作。
目前的 App 一定都是有帶網路的(就算沒有 3G 上網也會接 Wifi),因此在思考軟體架構時,就不能單純以單機(程式+資料庫)都綁在一起,讓使用者下載後使用。
這樣的設計方式最大的問題就是 App 的延伸性。因為全都在一個 App 裡,你沒辨法與其它的服務結合(FB, Search),而且使用者個人資料也會因為軟體刪掉(更新)之後就可能面對要重建(或更新)的問題。
我會覺得,最快速能開始手機服務,且能在不同手持設備上使用的最好方案是「建立手持設備專用的網頁」。
也就是說,無論下載 App 與否,使用者都能連上"適合"在手機上瀏灠的"網頁界面中使用所提供的服務。
就開發的角度來說,系統其實是網頁系統,透過手機App 取得使用者資訊(也非必需),開發上就不必為了不同的手持設備而開發新的軟體(如目前許多網路書店希望直接使用 HTML5 做電子書的平台,而跳過 Apple 公司的獨佔)。
如果非要透過 App 的方式傳遞服務的話,那就要思考需要取得那些使用者資訊(如地理位置、手持設備的唯一值、個人資訊等等)會與服務有緊密關聯的。

上述最重要的心法就是,捷運站裡一定有網路,所有的資訊最好都透過網路請求/送達。

3) 整合整合再整合
所有的網路服務在開發的階段一定是以單一功能開發(如 tweeter 就是發短訊、找路徑就是找路徑)。
但當設計到 App 裡,一定是將所有用得到的功能整合起來,如找到路徑之後如果傳送給自己、朋友或tweeter 出去。
因此程式語言變成不會重點了! 而是你能將多少單一服務功能整合到單一的 App 之中,而且使用者會覺得有用的整合。
目前很多網路服務公司都會提供 API 給你去串聯,而這些 API 很多都是透過上述的 http or https fetch 來呼叫使用。
更明確的說就是 Web Services,這裡包括了 XML-RCP, HTTP POST/GET, JSON Request 等等。
雖然名詞很多,但其實說白一點就是你丟一個 http 的網頁GET/POST呼叫出去,它回傳你要的資料給你。
所以你的任務就是 a. 去了解怎麼丟變數給不同的網路服務吃 b. 試著去拆解傳回的網路資料。
就 a. 的部份來說,就是去看它的規格,如 facebook 的 mobile API https://developers.facebook.com/docs/guides/mobile/

而就 b. 的部分來說,基本上分2大派:JSON 與 XML ,這些也都有現有的object C 函式可以處理。
但回到前一點 2) 來說,其實也要思考這此串聯要做在手持設備這邊,還是網頁功能這邊。
最後,服務整合的用意是希望讓使用者覺得方便,所以千萬不要整合一大堆有的沒的功能,如此只會讓 App 變很大,而使用者都用不上所有的功能。

4) 賦權
這點是最難的。當手持設備已經這麼方便,且在系統仔細設計之後,是否有些功能可以賦權使用者使用呢?
如:使用者可否透過 App 了解目前捷運上的人潮擁擠程度,而避免人擠人的車輀? 週邊停車的可停車數量的統計?
將行程設計好之後,只需要透過 App 產生 QR Code 讓各站台的服務人員掃瞄,就可以一次購買所有需要的交通票卡。
我想表達的是,如果一個App 只是提供一般資訊的話,那這個服務是沒必要存在的,因為這些資訊 google 都找得到了,何必還要你們來提供。
這此資訊包括捷運地圖、轉程資訊、旅遊資訊、停車資訊等等。使用者會希望從 App 裡得到更多"深入"的資訊,而這些資訊並不是 google 可以 search 得到的。
以上面的兩個問題來說,其實需要的都不僅僅只是 app 的設計,而是整個服務鏈的改變。

以上談的四點其實與程式本身沒有多大的關係,與系統架構、服務設計的關聯較大。
我會覺得,寫 App 只要是資訊提供類,那就是寫一個 browser 去讀網頁資訊;如果是有決策問題的,就多一些 check box 讓使用者點選後,再送到網頁去取資訊。
基本上 App 的設計還滿單純的,因為不外乎是與網頁設計相關。
最笨的設計原則就是把一大堆的資訊 compile 到 App 中,讓使用者下載一個肥得要死的 app,而且裡面包了一些 google 得到的資訊。
而 app 的設計,最難的還是服務設計。如果不能提供更多的賦權、深入的資訊,那為什麼要留下這個 app 呢?

福星機車行 真貴!!

In 99 呼朋引伴 on 四月 14, 2011 at 7:46 上午

福星機車行, 台北市文山區木新路2段123號, (02)2939-2485. 順利機車行, 台北市文山區木新路2段285號

昨天去換了火星塞。
原本只要80塊的東西,這間居然跟我收400堆!

真是…我最近就是這麼容易被打臉嗎?

自然語言處理相關

In 02 備忘錄 on 一月 24, 2011 at 10:19 下午

會議

  1. Association for Computational Linguistics, ACL (有年会论文集)
  2. European Association for Computational Linguistics, EACL (有年会论文集)
  3. International Conference on Computational Linguistics, COLING (两年一次)
  4. Applied Natural Language Processing, ANLP (两年一次)
  5. Empirical Methods in Natural Language Processing, EMNLaP

期刊

  1. ??

人員

  1. 張俊盛 教授 (Jason S. Chang, Professor) 台灣清大
Follow

Get every new post delivered to your Inbox.