2013-12-28

1227課堂討論,2013第12屆新人王網站設計大賽,【第一名,訪台北】優缺點討論。

2013-第12屆新人王網站設計大賽  http://2013.netking.tw/

【第一名,訪台北】

http://www.funtaipei.tw/

圖1.訪台北主首頁

圖2.各項子頁面,以視角一頁為例。



優點:

1.畫面好看又生動,整體視覺效果不錯。
2.有妥善的運用整個版面,讓每個版面都有發揮到他的功能。
3.功能列以及每頁的大標題都有加入英文的部分,雖然英文部分不多,但若搭配頁面中的圖像,或多或少可以幫助外國人好理解。





缺點:

整體網頁
1.瀏覽器變小 頁面無法跟著縮放
2.如果他可以加入以鍵盤左右換頁功能更好

1227課堂討論,2013第12屆新人王網站設計大賽,【第二名,聽見,福爾摩沙】優缺點討論。

2013-第12屆新人王網站設計大賽  http://2013.netking.tw/

【第二名,聽見,福爾摩沙】

http://listento.tw/


圖1.聽見,福爾摩沙的首頁

圖2.聽見,福爾摩沙的聲音的故事


優點:

1.主題與呈現的方式很有特色,以一張一張CD供使用者自行選擇的想法很棒,這樣的呈現方式與主題相扣。

2.網頁會隨著瀏覽器的頁面大小縮放還不錯。
3.點擊『聲音的故事』按鈕,會用淡出的方式進行轉換頁面,而進入聲音的故事內容後用捲動的方式瀏覽換頁 
4.視覺畫面不錯,素材物件的處理精緻,尤其是黑膠唱片播放器繪製得相當傳神。
5.動畫呈現效果不錯,有與使用者的互動,而且不是使用FLASH製作。

缺點:

整體網頁
1.這個網頁主要呈現的是聲音,若使用者無法接收聲音的話,這個網頁現在幾乎有作用了,或許他可以再多加思考要是聲音無法傳遞出來,是否有其他方式依舊能忠實的呈現。

首頁
2.可能聽不到聲音有影響,直覺不知道該如何操作,或許是撥放音樂的按鈕顏色不夠明亮所至。

3.CD上有標示每一種聲音的來源,但是使用白色為標示文字的顏色,會讓使用者看不清楚,另外,相關資訊呈現較為模糊,需要點擊聲音的故事』按鈕才會知道該項聲音更詳細的介紹,不是使用者直覺聯想到的

4.CD的擺放呈現方式沒有達到效果,CD的意象不夠清楚,如果上方沒有播放機當輔助便會看不出來下方擺放的是CD,而滑鼠滑入時的動畫有些凌亂,無法同時觀看多片CD的封面或名字做挑選。

聲音的故事
5.『聲音的故事應該是搭配每一張專輯,但是他在首頁的標示會讓使用者不清楚他的規則,雖然他在聲音的故事用捲動換頁的方式很棒,但是要捲動得很賣力才可以換到下一個畫面,有時候會捲太快而錯過
6.進入聲音故事後 要返回首頁的返回見圖是不明顯。
7.不清楚『聲音的故事』頁面中 f 按鈕的功能,因為點擊開後,主要的滑動頁面便無法使用。






1227課堂討論,2013第12屆新人王網站設計大賽,【第三名,來去北港】優缺點討論。


2013-第12屆新人王網站設計大賽  http://2013.netking.tw/

【第三名,來去北港】

http://pongkang.idv.tw/

圖1.來去北港導入頁

圖2.來去北港首頁

優點:

1.主要分類依造學生、商人、夫妻這樣的分法還蠻特別的。


 
2.色調、人物設計、版面視覺規劃都很嗚色也相當契合主題,不錯的視覺呈現較果。


缺點:

 【整體網頁
1.網頁不會隨著瀏覽器的頁面大小縮放。
2.導入頁使用FLASH動畫效果,但普遍在MOBILE上會無法顯現,有點可惜。
3.他只有一開的動畫比較炫,進入首頁後只有footer位置的選單列的連結有一點變化而已,頁面比較不生動,較偏向靜態網頁。 

 [首頁
4.點擊進入首頁後,畫面的 head 留空太多,要將slider滑至網頁最下方才看得到主要的選單列;但有時候head『來去北港』的字樣又會被擋住。
 
 【點選選單分類後
5.點擊選單分類的內容有好許多都重複,例如:不論點擊學生、商人、夫妻、單身男女、一家人,每個選項都有『朝天宮拜媽祖』。
6.要回首頁主選單不好使用,滑到頁面最下方後沒有TOP功能可以點擊回到最上方。
 
7.若使用者觀看完『學生』選項後想要改看『一家人』的選項,必須要按回首頁後才能夠再做選擇的動作,或許可以考慮將選單列固定在每一頁的固定地方,方便使用者更直覺化的使用。
 

2013-12-19

1213回家作業,研究BACKBONE與RequireJS的用途為何?


初探 Backbone.js
Backbone.js 是一套前端 Javascript Framework,它提供 MVC 架構,包含了 ModelViewController來讓使者操作。Model提供了key-value 結構,以及可以 binding 大量 event,開發者可以透過 RESTful JSON interface 來跟 Backbone.js Model Collection 搭配。
·  Model:可用來設置和獲取 data (例如:men Model)
·  Collection:某一類型 model 的有序集合 (例如:people Collection,包括 men & momen model )
·  View:操作 Model DOM 的互動與呈現 (例如:men run),可以綁定既有的 DOM 或是自己新增 DOM
·  Controller:負責分派 model view 之間的商業邏輯
Backbone 優點
1.         檔案很小
2.         可以將所有的state model 放在同一個地方
3.         model 的任何調整,可以自動同步到UI (不管有幾個地方需要同步)
4.         較好維護的程式碼結構
5.         較少的 “耦合程式碼”
6.         龐大的社群以及文件可參考

----------------------------------------------------------------------------------------------------
初探 RequireJS
一直以來,我們都習慣使用 script 這個 HTML 標籤來載入 JavaScript 檔案。這種方式有兩種缺點:
1. 無法在 JavaScript 程式中直接管理相依性,必須在 HTML 中處理。
2. 雖然目前新式瀏覽器已經能夠以非同步的方式來載入 js 檔案,但是舊型瀏覽器還是會有阻塞 (blocking) 問題。
終於 CommonJS 提出了 AMD 這個 API 規範,用以讓我們的 JavaScript 程式可以模組化,並同時解決 js 檔案載入時的阻塞問題。目前已經有許多實作 AMD 規範的 JavaScript Library 了,而 RequireJS 則是目前討論最多,應用最廣的其中一個實作。
什麼是AMD?
AMD 提出了一種基於模組的非同步載入 JavaScript 代碼的機制,它推薦開發人員將 JavaScript 代碼封裝進一個個模組,對全域物件的依賴變成了對其他模組的依賴,無須再聲明一大堆的全域變數。通過延遲和按需載入來解決各個模組的依賴關係。模組化的 JavaScript 代碼好處很明顯,各個功能元件的松耦合性可以極大的提升代碼的複用性、可維護性。這種非阻塞式的並髮式快速載入 JavaScript 代碼,使 Web 頁面上其他不依賴 JavaScript 代碼的 UI 元素,如圖片、CSS 以及其他 DOM 節點得以先載入完畢,Web 頁面載入速度更快,使用者也得到更好的體驗。
傳統 JavaScript 代碼的問題
讓我們來看看一般情況下 JavaScript 代碼是如何開發的:通過 <script> 標籤來載入 JavaScript 檔,用全域變數來區分不同的功能代碼,全域變數之間的依賴關係需要顯式的通過指定其載入順序來解決,發佈應用時要通過工具來壓縮所有的 JavaScript 代碼到一個檔。當 Web 專案變得非常龐大,前端模組非常多的時候,手動管理這些全域變數間的依賴關係就變得很困難,這種做法顯得非常的低效。

簡單來說(範例一)
最早的時候,所有Javascript代碼都寫在一個文件裡面,只要加載這一個文件就夠了。後來,代碼越來越多,一個文件不夠了,必須分成多個文件,依次加載
假設網頁原本執行main.js前,需要讀取 a.js,b.js,c.js,d.js,原始碼如下:
--main.js--


這樣的寫法有很大的缺點
首先,加載的時候,瀏覽器會停止網頁渲染,加載文件越多,網頁失去響應的時間就會越長;
其次,由於js文件之間存在依賴關係,因此必須嚴格保證加載順序,比如上例的a.js要在b.js的前面,依賴性最大的模塊一定要放到最後加載,當依賴關係很複雜的時候,代碼的編寫和維護都會變得困難。
利用requireJS的情況下,可以將程式碼修改成如下:
--require.js—


這指令除了會協助載入require.js 以外,還會自動幫讀取main.js。只要修改data-main="檔名.js"就可以讀取其他任意JS,例如:data-main="my",便會自動讀取my.js
將著我們需要對main.js做以下修改,在main.js裡引用a,b,c,d,如下圖:
--main.js—


透過這樣的方式可以由系統幫你載入 a.js,b.js,c.js,d.js 4 JS 檔,
require.js的誕生,就是為了解決這兩個問題:
1)實現js檔的非同步載入,避免網頁失去回應;
2)管理模組之間的依賴性,便於代碼的編寫和維護。



模組化(範例二)
當把所有的程式邏輯都寫在 js/main.js callback 裡面是沒問題的,但那就沒辦法達到我們想要的模組化了。
RequireJS 也實作 AMD 所定義的 define API 方法,所以我們就可以用它來實現程式的模組化。 define API 如下:
其中 id 格式為字串,代表模組的名稱,可以不寫。如果要寫的話,就必須是相對於 js/main.js 的檔案路徑,但不用加上 js 副檔名,例如 ../lib/foo ./js/bar
dependencies 格式為陣列,作用與 require 中的 dependencies 相同。一般來說如果我們在 js/main.js 中定義好相依性後,這裡可以不需要特別指定。
最後的 factory 則為一個工廠方法,它必須回傳一個物件,也就是我們的模組。
接著我們把原來 require API 中的 callback 改成模組,並將它放到 js/app.js 中:
--js/app.js--


js/app.js 會回傳一個包含 initialize 方法的物件模組,而這個方法就是我們前面的 callback 。注意這個例子裡並沒有設定模組的 id
接下來我們把 js/app.js 加到 require 的第一個參數中,特別注意這裡的 app 是指 js/app.js ,而不是模組名稱。
--js/main.js--


callback 的第一個參數 App 會對應到 js/app.js 中所回傳的物件,這意謂著我們可以為該物件指定新的 namespace
到這裡其實可以應付很多基本的應用了,不過如果當 library 間有相依性問題時,這樣的寫法就可能會出錯了。
心得
以往在寫 JavaScript 時,雖然都會儘可能模組化,但變數的管理還有程式拆解不易的狀況,都是自己在維護 JavaScript 程式時很大的痛處。

在瞭解 RequireJS 的強大後,我相信以這樣的模組化方式再搭配 Backbone.js 的架構,一定可以讓系統在開發與維護上更為有組織性。

2013-12-13

1206 回家作業,UI Patterns For Mobile Apps: Search, Sort And Filter

Explicit Search 外顯查詢
Explicit Search外顯查詢,會有明確的操作執行,舉凡搜尋列後的搜尋按鈕或是輸入鍵盤上的Enter鍵。

範例一:Google Play上輸入搜尋條件,接著點選Search Bar後的放大鏡圖示按鈕開始搜尋。
範例二:在yahoo奇摩首頁輸入搜尋條件後,點選鍵盤上的Enter鍵。


 







Search with Auto-Complete 自動完成搜尋
Search with Auto-Complete,能夠邊搜尋邊顯示結果,輸入搜尋字串後就會立刻在Search Bar下拉浮現出可能的結果供使用者直接選擇,使用者也可以繼續輸入自己完整的搜尋條件,輸入完畢後再點選明確的操作執行按鈕即可。

範例一:使用facebook搜尋功能,輸入『nutc』後,就會自動顯示可能符合的搜尋結果。
範例二:Google搜尋列,輸入『台中市北區』,就會自動顯示可能符合的搜尋結果。


 


Dynamic Search 動態搜尋
Dynamic Search 動態搜尋,也被稱為動態篩選,只要符合輸入的搜尋條件,便會將相符合的值都顯示出來。適合用於地址簿或個人媒體庫中,但若使用在搜尋多源大型資料可能就不那麼適合了,因為從大量的資料中做搜尋會到誌顯示結果壟長,增加搜尋時間。

範例一:Line好友,搜尋英文字母『o』,即可找到所有名稱內含『o』的朋友並顯示出來。範例二:搜尋連絡人『白』,即可找到所有名稱內含『白』的朋友並顯示出來。





Scoped Search 分類搜尋
Scoped Search 分類搜尋,可以在執行前先選擇分類,縮小搜尋範圍,以便得到更精準的搜尋結果。

範例一:以名片全能王為例,使用者搜尋名片時,可以選擇要以哪一種資料搜尋。
 




Saved and Recent Searches 儲存最近期的搜尋
Saved and Recent Searches 儲存最近期的搜尋,尊重使用者的努力,讓使用者可以從先前輸入的搜尋條件中做選擇,替代重複輸入同樣的關鍵字和搜尋條件的麻煩。

範例一:以YouTube為例,點選Youtube搜尋列,會自動跳出使用者蒐尋過的搜尋條件。
範例二:點選Googleplay搜尋app,會自動跳出使用者蒐尋過的搜尋條件。




Search Form 搜尋表單
一表單上面有多種欄位可供使用者輸入需要的情況,當使用者輸入好後就以這些規則來尋找相關資訊。

如下圖,火車時刻表,可選擇起迄站、車種、日期以及時間後,再按查詢按鈕依這些條件來做查詢。













Search Results/View Results
在歷史紀錄裡面搜尋想要的資料,意即之前必須要先搜尋過後才可以在這邊找到。

如下圖,這是一個英文字典查詢過的歷史紀錄,所以當還想要再次找出那個單字時,便可以此搜尋來查,優點是可以更快找到。














Onscreen Sort 直接排序
排序的模式已在同畫面上或下整排列出,只要使用者點選或滑過去便可看到以此排序出來的結果。


如下圖,Play商店可依最熱門付費項目、最熱門免費項目、最高營收...等等不同種類來做排序。



















Sort Order Selector 選擇器排序
擁有跳出的視窗,可以提供使用者非常多樣的排序方式,當使用者點選其中一樣時,就以被選擇的那項來做排序。


如下圖左,HTC手機的應用程式可依使用者喜歡的方式做排序,像是最新、英文字母、或是自訂等等方式。下圖右則是信箱裡有非常多的mail,所以系統提供給使用者有多種樣式排序,以利使用者用最快的方式找出想要看的那封mail

 


Sort Form
結合了搜尋和篩選,名為Refine,優點為在資料數量非常大量的時候,可以先透過篩選後,再進行排序,便可幫使用者先進一步篩掉不需要的資料。

如下圖,Yahoo拍賣,排序及篩選放在一起,可讓使用者同時做篩選及排序,讓使用者更快搜尋到自己想要的結果。













Onscreen Filter
讓使用者可以直接在頁面上,選擇欲搜尋的資料類別,並且顯示出符合該類別的資料,過濾掉大量非使用者所需要的資訊。

591租屋app搜尋頁面上方,有租屋、中古屋、頂讓、新房屋四種類別供使用者選擇,如下圖所示:




















Filter Drawer
使用者可以利用手指滑動拉出新的區塊,此區塊內可以提供使用者選擇欲搜尋的資料類別,系統會顯示出符合該類別的資料,過濾掉大量非使用者所需要的資訊。

如下圖所示,將高級篩選由下而上拖曳,即可出現篩選項目供使用者選擇。

 

Filter Dialog
點擊按鈕會跳出一個視窗,此視窗有提供使用者選擇欲搜尋的資料類別,當使用者點選後,看到的結果便只有此一類別的資料。

如下圖點擊下拉式選單,出現一個視窗,供使用者選擇並點選。

 


Filter Form
漸進式的篩選,使用者可先從大方向去做篩選,篩選完後若還可以再詳細細分,系統就會提供使用者在篩選一次的頁面。

如下圖,可以選擇某地區的中古屋,地區可以先選擇縣市再選擇鄉鎮,一步步地縮小搜尋的範圍。