2014年1月3日 星期五

2014/01/03 人機介面設計 JS照相機與local storage 技術應用討論


localstorage
本機儲存
和 JS的照相機
該用在我們系統的何處
照相機的部分
我覺得要運用在新的功能
例如 在瀏覽綠建築網站的時候
使用者觀看台灣的綠建築
然後透過我們網站開起照相機
15 分鐘前
   在 HTML5 相關技術中,web storage 提供開發者可以將一些資料,以 key-value 的形式儲存在用戶端(也就是瀏覽器啦),相較於 cookie 而言,cookie 只有 4kb 的容量,而且多數網站已經會預先塞一些資料在裡面,能利用的空間不大(而且在 JavaScript 端操作不易),所以有 5MB 容量的 web storage 當然要好好利用啦!
Web storage 與 cookie 有一樣類似的特性,就是它是跟著 domain name 而存在的,所以不必擔心儲存的資料被其它網站讀取走(當然,如果還是 XSS 那一樣會中招)
Kun-Ru
 • 
14 分鐘前
上傳非官方的綠建築照片
我目前想到的 照相機部分
當然不只侷限在台灣的綠建築
或者 多開一個叫做 綠建築分享
讓有到不同綠建築以及有使用我們網站的使用者
12 分鐘前
使用 localstorage 可以應用在儲存一些小文字小圖片之類的
Kun-Ru
 • 
12 分鐘前
分享這個很像不錯 可以同時運用照相機根本機儲存
Sharon
 • 
12 分鐘前
透過我們網站的功能來拍照跟分享
localstorage的話
我想一下 在我們網站要運用在哪個地方
會得到最大的效益
我覺得
localstorage 可以結合照相分享的部分  
將使用者輸入過的資料
運用local的方式儲存
因為 在儲存的時間以及生命週期 相較於 session,local的方式會比較長
而且連萬惡的ie8都支援了
ie6 7 就算了吧
6 分鐘前
這裡的win8超難用 
Sharon
 • 
6 分鐘前
會LAG....
Kun-Ru
 • 
6 分鐘前
哈哈
我想到的 local storage 部分  
5 分鐘前
p5 2k7
子涵
 • 
5 分鐘前
只有儲存使用者資料
5 分鐘前
真的一直當機...
不錯的提議
子涵
 • 
4 分鐘前
I7....
Kun-Ru
 • 
4 分鐘前

所以結論就是
將照相機功能新增至我們網頁使用者可以透過我們網站來開起照相機拍照以及上傳綠建築照片
在local storage的部分 使用者在新增過後自己的資料 便會記錄起來 在下次使用後便可直接上傳綠建築照片
1 分鐘前

2013年12月27日 星期五

2012新人王前三名得獎網站分析

我們認為前三名網站都做得不錯,因此在這邊為各位呈現我們小組討論後,所得出各個作品的優點及缺點,以下分別為各個網站的連結及優缺點分析。

第一名:訪台北


優點


該網站的互動性、圖片、色系都使用了較溫和軟性的配色,以及在互動式按鈕的部分使用單頁呈現視窗的提醒,以及內容文字的部分也經過考量設計後呈現,整體網站使用者介面很值觀,在操作及整體觀感也達到了簡易操作及了解的成效。


缺點


  1. 在網站瀏覽的時候,例如:在聞香頁面時,menu部分沒有明確告訴使用者該頁面是停留在哪一頁對於一進入網站的時候會產生了一種不明確的感覺
  2. 在首頁到最後一頁的快速換頁的卷軸動畫,因為速度較快切換多次容易讓視覺產生錯亂及不舒服的感覺
  3. 在針對使用者互動及動畫部分製作較少


第二名:Listen TO Taiwan


優點


該網站運用了聽覺感官的方式讓使用者進入聽覺回憶台灣的各個特色,以及提供使用者自行控制播放、暫停、停止和換曲的各種行為,讓使用者可以達到最佳化的聽覺互動效果,且網站使用了懷舊的風格與唱盤對應,讓人有種坐上時光機回到過去的錯覺。


缺點


在整體網站設計的內容太過簡單,以整體來說顯得較單調,因此在使用者瀏覽停留的部分,可能因為只有聲音,所以以使用者的角度來說缺乏了互動性,因此讓使用者停留的意願較低。

第三名:來去北港


優點


該網站使用圖片佐文字加上插畫Q版的設計,很引人入勝,以及利用了Q版的人物改變使用者對於北港傳統文化的感官,在操作部分的運用了簡單的menu控制來達到預達成的效果。


缺點


  1. 在網站入口的選擇中,提供了學生、商人、夫妻、單身男女、一家人...等不同的身分選擇,但在入口的時候選擇了不同的身分進入就應該有不同的建議進入點,而不是同樣的連結,這樣每個分類的內容大同小異,沒有實質作用失去了分類的意義。
  2. 在各面不同的畫面,可以增加不同的互動式動畫或效果,讓整體頁面達到更好對於使用者的互動行為,以達到讓使用者停留更久的效果。

2013年12月19日 星期四

RequireJS介紹

RequireJS是什麼?!
RequireJS是一個JavaScript文件和模組加載器,根據需要來加載JS文件的JavaScript框架,可避免不必要的js文件加載,優化瀏覽器以提升網頁瀏覽速度,提高程式碼的速度和質量。
範例1:
假定你把你所有的JavaScript文件在“腳本”目錄中的項目。例如:你有一個project.html頁面,用一些scripts,目錄可能看起來像這樣:

添加require.js到scripts目錄,所以它變成像這樣:




Backbone.js介紹

Backbone.js 提供了非常簡單的方式創建模型 (model) 和視圖 (view) 幫助開發者可以很自然而然的明確區隔使用者操作介面 (view) 的行為及背後資料處理 (model) 的邏輯,讓程式碼井然有序。

事實上,Backbone.js 並不是真正的 MVC framework,她並沒有 controller,但這卻不構成問題。通常 controller 比較適合於 client-server 的架構,controller 會攔截需求 (request) 以決定要調用哪個model。以Javascript這種所有事情都跑在 client 端的情況來說,view 可以直接和 model 溝通而無需再透過 controller 。

Backbone.js 的 model 是透過 observer pattern 的方式,讓 view 可以直接監聽 model 上的任何 event ,並且立刻更新 view 本身。Backbone.js 也直接內建支援 jQuery 或 Zepto 操作 DOM。除此之外還提供了 collections (相當於 model 的 array),並提供支援 RESTful JSON interface 的 API。

構成 Backbone.js 的基本元素有底下四種類別:
  1. Model
  2. View  
  3. Router  
  4. Collection
 

2013年12月12日 星期四

Search、Sort、Filter 舉例及解釋

Search 搜尋:

1.      Explicit Search 外顯搜尋
解釋:由輸入框及搜尋按鈕組合而成,在輸入完畢所需要搜尋的內容後,點擊搜尋才開始啟動搜尋動作
範例:

圖1-1 輸入搜尋關鍵字
圖1-2 搜尋結果

範例說明:以Sony Xperia Z Ultra手機內建的月曆程式作範例,在搜尋框內輸入關鍵字”聖誕”,輸入完成後點擊搜尋,產生搜尋的結果。



2.       Auto-Complete 自動完成搜尋
解釋:由輸入框、顯示頁面、搜尋按鈕組合而成,在輸入過程中會自動進行搜尋,若使用者尚未搜尋完畢,即產生了使用者所需要的結果,使用者便可以直接點選所需要之搜尋,達到節省時間之效果。
範例:


圖2-1 輸入過程-1個關鍵字
圖2-2 輸入過程-2個關鍵字

範例說明:以Facebook提供之內建應用程式中的好友搜尋作範例,在搜尋區域輸入關鍵字”許”,便開始產生與關鍵字相關的搜尋結果,在輸入完整搜尋關鍵字”許桔”後,便產生與關鍵字相關之搜尋結果。



3.       Dynamic Search 動態搜尋
解釋:由輸入框、顯示頁面、搜尋按鈕組合而成,在輸入過程中會搜尋資料庫或裝置內擁有的資料,適用於資料量較少資訊,若關鍵字搜尋與資料符合,則會產生符合關鍵字的搜尋結果。
範例:

圖3-1 輸入過程-3個關鍵字
圖3-2 輸入過程-8個關鍵字

範例說明:以ES檔案瀏覽器的檔案搜尋功能作範例,在搜尋區域輸入關鍵字”goo”,便產生與關鍵字符合的搜尋結果,在關鍵字”google.”輸入完畢後,便產生與關鍵字完全符合的搜尋結果。




4.       Scoped Search 分類搜尋
解釋:由輸入框、顯示頁面、分類區、搜尋按鈕組合而成,在輸入過程中可選擇需要之分類進行搜尋,將關鍵字輸入完畢及類別選擇完畢後點選搜尋,便會產生設定之搜尋條件。
範例:


圖4-1 輸入過程-網頁搜尋
圖4-2 輸入過程-圖片搜尋

範例說明:以行動裝置內的Chrome瀏覽器作範例,在搜尋區域輸入關鍵字”facebook”,選擇分類”網站”進行搜尋,便產生與關鍵字以及所設定之類別相關的搜尋結果,另以關鍵字”facebook”進行搜尋,選擇分類”圖片”進行搜尋,便產生與關鍵字以及所設定之類別相關的搜尋結果。




5.       Saved and Recent Searches自動儲存最新的搜尋紀錄
解釋:由輸入框、顯示頁面、搜尋按鈕組合而成,在輸入過程中會把曾經輸入過的關鍵字提示在下方可以選擇。
範例:

圖5-1 iOS系統搜尋畫面

範例說明:以iOS系統下瀏覽器,曾經輸入過相關的關鍵字都會在下方提示。




6.       Search Form 搜尋表單
解釋:由輸入框、顯示頁面、搜尋按鈕組合而成,在輸入過程中會把曾經輸入過的關鍵字提示在下方可以選擇。
                範例:

圖6-1 台灣高鐵iOS版搜尋畫面

範例說明:以台灣高鐵iOS版舉例,乘客可以利用搜尋表單可以快速訂到票,及所要搭乘的時間、班次及特殊條件選擇。




7.       Search Results/View Results 搜尋與顯示結果
解釋:由輸入框、顯示頁面、搜尋按鈕組合而成,輸入後底下會以不同的方式呈現,如以清單、圖片、地圖來呈現。
範例:

圖7-1 Google瀏覽器iOS版搜尋畫面

範例說明:用Google瀏覽器iOS版輸入搜尋關鍵字,會以列表旁邊還會有圖片一起呈現。


Sort 排序:
1.    Onscreen Sort 直接出現
描述:
畫面上的排序可以提供簡單的單擊方案,把排序項目放在畫面的上方或下方取決於其它畫面元素。
清楚顯示哪個項目在選取中或「開啓中」,如果項目標籤不適合放在雙態觸變按鈕列裡,則使用 Sort Order Selector 模式。
範例



2.    Sort Order Selector 選擇器
描述:
以下拉式選單或是對話框的方式來選擇排序方法。
有很多用來選取不同介面控制項。
範例


3.    Sort Form排序表單(排序Refine)
描述:
將排序和篩選的項目合併在同一個畫面。
使用此模式前,要考慮有效率的排序項目雙態觸變,或排序選擇器模式。
範例




Filter 篩選:
1.    Onscreen Filter直接篩選:頁面上直接選擇篩選條件,將結果直接顯示於頁面上。
範例:台灣高鐵APP,在訂票紀錄中,可以選擇觀看已訂票卻未付款或未取票的票。


2.    Filter Drawer抽屜:利用抽屜的形式,將其他功能隱藏在旁邊,以節省螢幕空間。
範例:iTunes上的Exxon Mobil Fuel Finder,在抽屜裡可以選擇要在地圖上尋找的地點。


3.    Filter Dialog對話方塊:利用對話方塊,進行更進一步的選擇。
範例:台灣高鐵APP,在訂票時選擇出發日期與出發時間。

4.    Filter Form 過濾表單:利用條件,一步步過濾出符合使用者需求的結果。

範例:Hotels in New York,可以利用價錢、星等、位置等條件搜尋符合需求的飯店。