AM HCI Design Process

國科會101年度前瞻概念設計計畫

計畫名稱  橘色科技的使用者經驗創新:運用資工通訊技術協助銀髮族的全人照護

團隊成員  卓思陽、鄭雅方、呂易安、游穎軒、林奕岑、王亦瑀

計畫摘要介紹

本設計專案目的為利用前瞻資通訊技術,開發年長者全人照護的概念設計,製作可能的產品、服務、系統,達成「橘色科技」的目標。

計畫執行以設計思考為典範,透過用戶體驗為中心、跨領域合作、邁向實際原形製作。設計案以實地觀察為起點,透過深入訪談挖掘不同的設計問題。設計方法為使用者導向創新的情境故事法,讓跨領域團隊成員從情境預想到實際觀察,從用戶體驗研究到用戶體驗設計。三個概念分別關注銀髮族的失憶問題、居家溝通問題、及居家安全問題,包含認知、心理、生理等層面。

為求實現最終設計概念,本計劃結合台大資工、台科大資工、宏正科技,進行跨領域合作發展過程。運用的科技包含手機程式技術(mobile technology)、自然介面(natural user interface)、巨量資料(big data)等,目前資通訊產業最熱門的技術。

本計劃已完成銀髮族群之使用者需求與使用者資訊收集,及透過情境故事之使用者導向創新設計,提出三件以高齡者全人照護為主題的概念設計。期望透過本專案中資通訊技術運用與設計力創新,讓橘色科技真正帶給人類健康幸福。

Memoir Monopoly

Display of Will

Loocare

2012.06.17 Active

郭冠宏(資工)說過程
-
我負責的是伺服器的架構,還有手機裡跟伺服器溝通的部分,以及修了1,2個UI的BUG。

我們的伺服器選擇在Google App Engine(後稱GAE)上架設,他是屬於雲端服務裡的Platform as a service (PaaS) 提供一個良好的應用程式架設平台。使用的語言是Python。

伺服器要處理的行為大致上有

1.儲存使用者基本資訊。(我們限定使用Facebook帳號作為登入)
2.回傳有幾個正在使用我們App的使用者
3.儲存使用者上傳的資料,就是使用者寄出的每封信,包含圖片和錄音檔
4.回傳使用者寄出去的信。
5.回傳使用者所收到的信。
6.刪除使用者寄出或收到的信。

伺服器,或者是稱作後端,最重要的一件事情就是做到Robust,也就是說不管我們怎麼操,都不會壞掉,也就是要確保這邊的完整性,負責其他部分的人也可以無後顧之憂的去做他們的開發,譬如做其他做前端UI開發的同組組員,還有負責UI設計的設計系組員們,就是要展現出一種,這沒有問題的爽感,有一種前端在戰場的士兵要知道背後的存糧是十分足夠的感覺。

另外會選擇GAE的原因,也是因為這個平台Robust,當初曾考慮過直接架設在系上的主機,但是拿資訊系和Google的穩定度來比,想必還是差一個很大的層級,不論是台電可能會無預警斷電或是台大供電系統又哪裡過載又或是系上又要更換設備所以要停電,又Demo時間是系上期末考週,很多的期末作業也都會Demo,會造成系上伺服器的使用度大增。所以我們最後選擇了GAE作為我們的後端開發平台。

其中開發的小插曲,就是在伺服器完成之後,剛接上手機的時候,突然發現不一會兒的時間,GAE竟然就已經超過流量(超過免費的流量,要付費不然不能使用),所以趕緊再開一個伺服器(這也是GAE 的一個優點,可以迅速的做發佈的動作)。於是緊急的確認情況,看到底是哪邊寫壞了,就合理的推測應該是不可能在測試的時候就超過流量,所以一定是哪裡寫壞了,可能有一些地方做了無謂的動作,造成伺服器大量的負荷。

於是我們初步判定,可能是找尋朋友名單那邊,因為我們會針對這個人所有的朋友去詢問到底註冊了我們的App沒有,如果這個人有一千個朋友,那麼就資料庫做一千次的詢問,所以這邊的效率不是那麼的好,所以最先修正了這部份的問題。

但是,事情並沒有改善,過了一個小時後,伺服器還是超過流量了,我們又開了一個伺服器,這時候我們覺得,好像一時之內無法解決,所以我們暫時放棄改善這個地方,我們只多開了三個伺服器,已備不時之需。就像這樣:
 

-
又再過了一會兒,阿哲有了一個新的發現,就是手機端的程式碼不小心寫壞了,原本是整點的時候要跟伺服器做拿資料的動作,這個動作包含了拿取朋友名單,收發信件內容等。然後這個原本一小時會做一次的動作,竟然變成了每秒做一次,也就是說變成每秒都有一個使用者在操作我們的APP,於是這件事情我們立馬得到一個結論。
1.平均是每一分鐘都有60位使用者的話,那們我們伺服器大概一小時候就會超過負荷,也就是要開始要付錢。
2.還有詳細的看Log是很重要的,不能只看表面的數據流量,從Log才可以仔細的看到發生什麼事情,因為一開始沒有仔細看Log,不然應該一開始就能夠發現是不正常的使用者端行為。
3.GAE其實收費不便宜,門檻很容易超過。
 
-
因為知道問題的所在,所以我們馬上做了修正。就解決了這個問題。之後在期末展,我們瘋狂的使用我們的App來做Demo後,查看了伺服器的使用量,大概是達9%(100%就是要開始收費),這個流量還算可以接受。

2012.06.16 Active

蘇兆懷(資工)說過程
-
App = Design + Code
toFuture是我的第二隻app,第一隻app是上學期Mike課作出來的XTongue,主打的點是透過語言交換學習,讓不同國家的人做文化交流。期末demo時唐老師也有來,也許還有點印象。提XTongue的原因是,XTongue的團隊三位都是資工背景,因此開發流程與toFuture完全不同,對我來說是一個很特別的經驗 – 與designer合作所帶來的不同。


XTongue的首頁、Logo等為某一位資工同學所設計,另一方面,toFurture為兩位設計師操刀設計。當然直接比較是不公平的,我並不想說哪個設計好壞,有趣的點在於,資工人對於UI的設計,是以UI元件出發,例如”這裡要用Coverflow顯示圖片,那裡用Gridview顯示”,另一方面,”設計人是以真實體驗為出發(仿真),或是以圖像表示(示意),來設計UI”。例如選色紙的設計,toFuture以一疊色紙展開,swipe的方式選擇,而一般來說,最直覺是用一個gridview來表示。(小補充,我們花了很多時間讓色紙排起來美觀)
-

哪種設計比較好? 或者我們該問,哪種設計比較”合適”。現今UI的標準,例如Button長的樣子、tableview的設計,是長期下來為了適應各種需求而發展出的設計,在大部份的情況下,它運作的很好。User被train,designer也被train,看到button就知道要按,看到table就知道可以scroll,這個世界運作的很好。toFuture打破了這個規則,這也是我最滿意的一點。ToFuture看起來美觀、一致且自然,更重要的是,它很有趣,我們盡可能讓UI貼近使用者真實經驗,在真實世界,紙張不會排成格子狀讓你選,而是層層疊在一起,你必需一張一張檢視。收到的信件,我們讓它掛在樹枝上,隨著使用者而搖擺。當你想看信,你必需將它從樹上”摘”下來,之後它會慢慢unfold,最後呈現出精心排版過的內容。我特別寫了一個物理引擎去讓繩子更像繩子,而初次在課堂上demo也著實讓大家驚豔。
 
聽起來好像很棒,以後我寫app一定要找一個designer! 是否經過designer的設計,UI就會更加好用? 基本上我們也是收到了一些意見,認為某幾個部份做的不好。例如首頁的功能圖示會讓人confuse、new的圖示沒有按鈕的樣子、選紙張不知道是選最上面那張、不知道紙飛機能拔下來等。
-

這些情況在XTongue裡幾乎沒有發生,原因很簡單,我們用的都是原生的UI,中規中矩。為什麼到了to:Future,這些問題反而出現了? 我認為原因有兩個,一是designer對affordance的認知,二是創新UI的原罪。我所觀察到的是,designer以圖像思考,對他們而言,對於圖像的sense大於一般人,他們認為”足夠表達”時,一般人可能無法理解。我們很多設計是沒有考慮affordance這件事,例如一個能被按的元件,長的就不像能被按。我不知道這樣設計背後的原因,也許因為美觀,但我想argue的是,很多時候我們不能兼顧,新的東西,很多時候使用者都要花一點代價”學”一下,才會發現它好用,我們不該因為這個設計不夠直覺,要”學”一下,就否定它。

“直到學了Design Thinking,我才知道原來大學4年來的討論方法,都是錯誤的”。也許從寫遺書變成寄信給未來,旁人會覺得怪異、可笑,把我們的發想過程列出來,你會發現一篇精采的故事。這就是Design Thinking。XTongue的設計,完全是run在三個人的腦袋中,從決定要做關於語言交換,到最後UI的流程。大學四年,沒有人教我們該怎麼”討論”,怎麼”發想”,怎麼”收斂”。管理學有帶到一點,但只是書中條列的名詞。KM也許有講到,但也沒有真的去執行。當了openHCI的助教和這學期的AHCI,我自認為了解該怎麼”討論”。管院有多套制式的流程,什麼整體、個體環境分析,5力,SWOT分析,照著做就能寫出一篇還”能看”的報告,其實討論也是,”Design Thinking”有一套流程,不一定全部照著跑,但參考一下,會對整個討論的過程很有幫助,說穿了就是管院那套,但不得不承認,很有幫助。

在與Designer和Programmer合作的方面,我覺得我們算是幸運到不能再幸運。首先我們每個人都有寫app的經驗,還有奧林匹亞國手在其中。一切都是這麼的完美。唯一的缺點是,Designer與Programmer的交流不足,例如我們有關於美工的部份全由designer做,海報、影片他們全攬,程式則是我們全包,唯一的交集是設計、思考的部份,和最後merge的時候,會抱怨一下規格不符要重畫。從某方面來看,專業分工是件好事,但以學習的角度來看,我也很想學習畫點東西呀!!!我有試著讓designer動code,改幾個參數可以改變UI的layout,讓他們照心中想要的去調,我發現效果很好。(正確的作法是,寫一套可以拉UI的工作讓designer去拉,但我們沒有時間)
-

最後談一下我個人寫app的小心得,解答一下老師對於我們怎麼一開始用Windows Phone,後來又改成iOS的疑問。C#語言天生的優勢加上微軟在開發工具上多年的經驗,我覺得WP是三大平台中,開發最快速的一個,也是我最熟悉的一個。有本教WPF的書名叫”Applications = Code + Markup”,markup可以想成是程式的外觀、UI,也就是我們可以用紙板或是模擬表達的部份。我非常喜歡這句話,因為它點出了在程式的設計中,不止有code,markup也是一樣重要。基於這點,WP開發過程中markup的設計工具非常完整,”基本上不用寫一行code就能完成許多事”。所以一些快速的prototyping,我會選用WP。 

2012.06.16 Active

高新綠(資工)說過程
-
這次我主要負責iOS開發,並著重在瀏覽信件這個功能的程式編寫與介面設計實現。瀏覽信件的介面是和使用者互動最久的畫面之一,因不論是寫信,看寄出的信,看收到的信都會接到個畫面。讀取與編寫未來的信件是本app的賣點,而如何讓app上信件的呈現是舒適與愉悅的,並且能處理各種user input data更是重要。
-

首先是拉這個畫面的UI
這個部分需要和設計的同學做溝通,並盡可能用程式實現出介面的細節。為了要求界面美觀,界面各原件的位置都需有嚴謹擺放,在程式方面做了許多細微的數學運算去調整畫面。

介面有許多細節元件,如播放按鈕、圖片影子、郵戳、膠帶、回文針、背景等等。在拉畫面過程,每個元件都要一層一層慢慢往上疊,並要確認每個物件之間的關係。

iOS拉界面的畫面,可從左側看出畫面由許多圖層堆疊而成

-
圖片、影子需隨input照片大小比例動態調整位置
不論是數入橫的或直的圖片,畫面都會動態更動圖片比例,使畫面維持和諧。
圖片的影子外框也會自行調動位置與比例
EX:圖片比例調整公式:  
橫圖:width 固定調整到280pixel
height =280*圖片原始長度 / 圖片原始寬度
直圖:height固定調整到250pixel
width =250*圖片原始寬度 / 圖片原始長度

如是使用者沒有輸入圖片,則會出現一張default圖片
-
待圖片與影子位置確定後,程式需動態調整所有其他元件的位置,故需根據設計同學的設計圖寫入元件之間的相對位置。

例如:
播放按鈕左側離圖片的左側固定11pixel
左上角膠帶上側離圖片上側15 pixel
膠帶左側離圖片左測 17pixel
郵戳上側離圖片下側4pixel
右下角膠帶下側離圖片下側 23pixel
膠帶右側離圖片右側5pixel
等等…
-
 
背景顏色隨使用者選擇的信紙而改變,共有10種色彩供挑選
-

第二部分是實現信件中3種媒體的呈現:
(1)照片:除看縮小的圖片,使用者也可點選圖片作放大的檢視。
(2)錄音:按下錄音鍵使用者可以聽到之前路好的聲音
(3)文字:文字段落長度會隨使用者輸入而動太改變。此時可用scrollbar往下瀏覽文字。簽名會動態出現在信件最下方。
-

這次很感謝每位組員,因之前開發經驗主要在Android,這次是白手起家學iOS,雖然過程要花較多時間去熟悉新語言,但有組員的相伴讓這個過程很豐收且愉快!

謝謝聖哲的iOS熱心教學與耐心解答,以及主動扛下許多辛苦的整合工作,讓app順利完工!謝謝想飛老師!

感謝Domos的討論,實作超可愛動畫,並在最後一晚一起衝刺!

感謝GGM架server,讓我們當天能順利demo!

感謝承宗的介面設計,讓app化腐朽為神奇,並不辭辛勞生出一堆元件並作微調,讓畫面看起來水水!

謝謝0元的各樣設計,耐心的協調與收集訪談素材,並處理大小事情,讓我們能順利呈現! 

2012.06.15 Active

范承宗(設計)說過程
-

UI視覺主題定調

由於我們的app主要功能是訊息的傳遞,決定選用的主題是紙飛機,所以打算整個app的UI都用紙的質感來表現,希望在數位科技的世界中能多一點溫暖平易近人的感覺。



-

偏執與堅持

在UI設計的部分,我們一開始就想堅持不使用任何現有素材,也不拿現有素材來改,希望100%所有視覺看見的每一顆按鈕、每一張背景、每一格動畫都是我們自己親手打造,在這樣的創作過程中,雖然需要耗費的時間比較長,但也因為這樣才讓我們能更自由自在地發揮和嘗試,每完成一顆元件、一個動畫時也非常過癮很有成就感。



-

數位軟體表現紙雕效果
我自己是從小到大都當學藝股長負責做教室裡壁報佈置的人,對於用紙張做紙雕還有一絲絲微薄的記憶,一開始也想過要不要像瘋子一樣UI全都用紙張做成真正的紙雕拍照處理,但想想實在太耗時耗力了,而且以前壁報的經驗是永遠都會不小心手笨剪錯割歪,也永遠都買不到理想顏色的紙張,所以還是用數位軟體來做出那樣的效果吧。



-

傳統紙雕參考資料收集
決定要用紙雕效果來表達之後,我就先去找了一些相關的書來參考,去找了書才發現,「紙雕」這件事還真是專業,有各式各樣的手法和風格跟效果。



-

參考書目:紙雕設計萬象篇 
這本「紙雕設計萬象篇」的風格很討喜可愛,觀察發現在單色紙張周圍會用筆稍微刷上一點點的漸層,增加立體感和豐富感,刷漸層這點在數位軟體中也可以效法。


裡面有許多物件的案例,這些物件的配色很棒,很吸引人目光卻又不會過度鮮豔,我覺得這樣的感覺如果做成UI的按鈕應該會蠻不錯的。



在後面一點的章節開始有完整的構圖案例,這些畫面也給我很多UI元件和背景之間整個配置的啟發,或許也可以在app中做出像這些案例所具有的豐富感和魅力。

在這些案例之外還有製作過程,從中可以學習到在真實紙雕的世界裡是如何分配元件和拆解一張圖的方式,這些也都是能夠用數位化的方式表達,也因為看了幾本書的拆解方式,讓之後在數位軟體中製作的時候省了不少時間更有效率。



-

參考書目:紙雕造形基礎 
這本「紙雕造形基礎」的技術比上一本更豐富更具有難度,以更立體的思維來製作每個元件,上一本比較多都是紙張彎曲,這一本用了許多折曲幾何形的方式構成,不過這個手法要以數位軟體表達複雜度變得更高了,我以數位軟體嘗試過,這本書教的方法在現實中同一片紙做成的,在photoshop得畫4~10個甚至更多圖層才能做得像,所以在UI上我就很少用到這本書的方式了。

這本書還有一個很不賴的地方是有紙雕作的立體字,由於我們的開機畫面等地方也需要作出文字,所以也是很有參考價值,像是立體字的光影效果、投射在背景的影子效果等等,一開始都是參考這本書的案例去模擬出來。

 

-

參考書目:紙雕動物物語 
這本「紙雕動物物語」不同於其他紙雕書,這本有把一隻紙雕動物的每一片元件都拆開的平面線稿圖,數位軟體中要做也是類似這樣子,用貝茲曲線拉線畫出一片一片色塊再進行處理。一方面裡面的動物都長得很傻笨我蠻喜歡的所以就借了。

 

-

參考書目:我的紙雕世界
這本「我的紙雕世界」裡面作品的手法跟前面幾本又不一樣了,前面幾本都是用一張一張堆疊做出層次感,這本有用單一張上面切割做出的特殊效果,像人物衣服的皺褶和馬的身體,這招後來我有用在我們UI的雲朵等東西上。


-

參考書目:周顯宗的摺紙教室 
這本「周顯宗的摺紙教室」裡面都是一個一個步驟的照片,想說紙飛機展開的動畫可以參考,我我有試圖follow他的教學摺恐龍但卡關失敗,我想我們紙飛機動畫得要先摺出來再去想動畫的動作要怎麼拆。



-

參考書目:紙飛機工廠 
我們小組曾經談論到也許之後可以讓使用者選擇紙飛機的樣式,於是我也就好奇地借了這本「紙飛機工廠」,本來想說紙飛機還不橫豎就長差不多,沒想到光是這本書裡面就有n種紙飛機的款式和教學,這本也是後期發展時可以參考的好書。


-

數位軟體模擬紙雕效果
對紙雕的手法和幾種風格有所瞭解之後,開始先以手繪草圖來構思畫面layout、元件設計、元件圖層拆解等等。



最初先不斷嘗試繪製調整出滿意的紙雕雲朵,做過很多嘗試之後終於try出一種滿意的效果,之後繪製其他的部分也就可以follow和複製雲朵上的紙雕效果。



-
結語
其他UI設計和動畫的部分請看之前其他篇的紀錄,這邊就不再重複囉。

這是我第一次參與App設計和UI,也是第一次和資工領域的成員合作,不得不說我們組的資工組員們真的太棒,我們不只是程式寫得差不多之後丟給UI設計去把按鈕美化弄漂亮而已,我們在整個過程中從怎麼操作和互動,到不知道能不能做出來的嘗試,都是設計和資工一起共同討論激盪出來的。

謝謝資工組員們每次當我提出想像中的效果時,第一時間不會用自己以往的經驗去判斷然後拒絕,他們第一時間總不會是拒絕,而是回答說:「這不知道耶我沒做過,好像也沒有印象有App是這樣,不過我們可以想想看怎麼弄,試試看或爬文問人看看能不能做出來。」他們開放而且樂意嘗試的態度讓我們合作得非常愉快和過癮,能和他們一起合作真是非常幸運的事,過程非常開心且充實。

2012.06.09 Active

徐聖哲(資工)說過程
-
這次的APP在題目終於訂定好之後,寫的非常愉快,我主要負責的是(1)先建出ios端的完整架構以及(2)與server端的溝通(3)接上Facebook API(4)一些頁面的小動畫以及參數的傳遞,就在UI Flow終於決定好以後,我就照著刻出一個大概,然後經過了一個禮拜的努力,總算是把整個架構建出來。不過都還沒套上美術的圖所以感覺很簡陋。

建好了以後,接著就是一連串的跟設計系的同學進行溝通與協調。

首先是首頁,設計系的同學們希望首頁的那幾顆按鈕,沒事的時候不要閒著,所以希望按鈕本身有一些小動畫,我覺得這個想法很酷,所以在想了一下大概要怎麼做以後,就二話不說的先做了。最後呈現出來的結果如下,第一個按鈕的筆會一直上下移動,示意要寫信,再來第二個按鈕飛機會一直飛出去,示意是寄出的記錄,第三個收信的按鈕的兩個父子會一直跳舞,示意為用信在做互動的感覺。

選紙張頁,跟domos的選紙動畫合起來後,畫面也變得很酷炫,用手滑一下就可以換紙張顏色。

多媒體頁的畫面呈現也變得很棒,一開始進去三個多媒體資訊會彈出來,然後多媒體資料都填入後,各自會有小小的預覽結果。

收信記錄頁這邊結合了domos的繩子物理動態效果,也變得十分有趣!
扯下紙飛機後,會有開信紙的動畫,打開後就可以看信。

以上就是這次APP的製作流程,然後我真的很慶幸,這學期把其他課都退掉只專心修AHCI這讓我IOS開發功力增強不少,也拓寬了設計的視野。

然後我發現一件事,好的team的成員組成真的能強化夥伴的實力!這次多虧了范承宗的天馬行空,try了好多好玩的東西(會動的按鈕,在table裡加上一些小動畫等等..),超開心的 。

還有0元的影片海報以及諸多的設計巧思, 還有感謝郭冠宏的server讓我們可以毫無後顧之憂的開發前端,還有 Domos 的一堆超Q彈動畫! 

以及新綠不屈不饒的努力學著IOS,並且默默的把顏色對應以及一堆奇怪的影音跟相片處理做完。

我只能說,好險我那時候上課遲到,才能跟你們配到一組。真的是太幸運了,合作的好愉快!雖然最後只得到一頓飯的小獎~但是我覺得整個課程結束之後,我學到的,遠超過那些。
DITL