Image Deep Zoom
‧提供巨大圖檔的 seamless viewing 及 zooming
‧當使用者檢視時，先只載入呈現影像的必要資料
‧有效率的將大張圖檔轉成 scaling vector
製作過程
‧前處理工具將影像切割成 256 x 256 tiles
‧然後產生影像金字塔階層中較低解析度的階層
‧加入Deep Zoom物件(MultiScaleImage 或 MultiScaleSubImage)到應用程式
‧前處理工具產出image tiles 及 XML description file
<MultiScaleImage x:Name="deepZoomObject" Source="source/items.dzi" />
如何運作
當影像呈現在Client端時，先載入較低解析度的tiles，等高解析度的影像下載完成，再平順地融入較高解析度的tiles
→
→
網站實例：
http://memorabilia.hardrock.com/
參考來源:
Silverlight應用程式初探/陳晴◎著
‧採用開發/任務為主導的頁面UI 設計, 而不是美工主導的UI 設計。
‧現在的網頁風格趨向是簡單，而KISS(Keep It Simple, Stupid) 一直是設計界的最高境界。
‧美工主導的設計的弊病：
美工人員對代碼和程序不夠了解，而開發人員由於不需要對最終美化負責而 被“慣”壞了變得越來越不重視樣式風格。
‧目前流行的web2.0風格的網頁設計元素
1.Simple layout 簡單頁面結構
大部分採用css來控制的簡單2欄或3欄結構，甚至是1欄的。 没有人再用table來控制layout.
2.3D effects, used sparingly 3D效果，但保守地使用（不是太繁重和累贅）
淡淡的倒影，幾乎是web 2.0網站的流行裝飾
醒目的爆炸形logo...甚至有篇文章說，網站上要没有這個爆炸型logo就不算web 2.0 :)
這裡並提供一個web2.0logo自動產生器的服務：LogoCreator，這個網站提供了五種Web2.0的風格讓使用者選擇，只需要輸入文字和圖片尺寸，再做一些字體、位置、圖案、倒影比例、背景顏色和透明度等相關的設定，就可以立刻製作一張別具Web2.0風格的Logo。
非常容易就可以製作出一個和filckr風格相同的weco.net logo :) 當然還可以自己做其他的設定修改
3.Soft, neutral background colours 淡背景色
4.Strong colour, used sparingly 强色調
看到odeo的时候這種紅色沖擊非常明顯
5.Cute icons, used sparingly 很cool的圖標， 往往很吸引人，但不能濫用
6.Plenty of whitespace 頁面比較鬆散，很多空隙。
用戶的螢幕分別率越来越大， 太緊湊給人壓迫感。所以最新的這些網站往往空白很大：
7.Nice big text 大字體
可惜中文字體大一些後會有些難看，在英文網站裡，大字体體漂亮而且醒目，是不錯的設計。 這也是因為用戶的螢幕分別率越来越大而帶來的必然趨勢。
參考文章網址:
http://www.uuzone.com/blog/mao/96927.htm
http://ithelp.ithome.com.tw/question/10008487?tag=rt.rq
JSON(JavaScript Object Natation)
可以用JavaScript表示的資料結構(可以以物件來表示,也可以以文字表示)
‧XML和JSON比較
XML：是重量極的格式
太複雜
JSON：a light weight data-interchange format,simple format
沒有樹狀type,相較於XML較簡單
‧為什麼要用JSON
1.比XML快
2.typed(XML是typeless)
JSON types:string,number,array,boolean
XML types：都是string
*XML在schema裡可以定義格式,但較複雜,周邊技術計較多
‧cross-domain request using XHR(XML Http Request)
(XHR是瀏覽器支援的一個物件，它可以check client端狀態以及server端傳輸狀態，client端丟request過去，可以繼續做自己的事)
‧run script
script應該要從server端過來
有限制，mashup有安全性問題
‧eval() method
把物件的字串變成JavaScript物件
當來源可以被信任的時候就用eval()
好處：可以用裡面的data,data可以從不同來源來，使用上較方便
壞處：可能是惡意程式
解決方法：用JSON Parser
通過parseJSON()讀取JSON數據，驗證是否為真的JSON代碼，安全性較高
當來源不能完全被信任的時候就用JSON Parser
RSS/Atom/AtomPub
‧用來分發和匯集網頁內容的XML格式
‧跨平台的互應
‧和應用能夠分開(它是data)
RSS和Atom的比較
1.Atom可以處理比較複雜的data，可以處理不同的格式
RSS只能處理HTML
2.Atom在對內容方面的限制較小
Atom可以描述內容是"partial"或是"full"(如果內容很少的時候，可以把內容擺在bit裡，丟給所需要的程式)
而RSS不行
3.Atom彈性較大，內容較豐富
AtomPub(Atom Publishing Protocol)
‧HTTP based protocol,XML格式
‧可以不只訂閱，還可以新增、刪除、查詢、修改
‧App request type
1.Post─新增
2.Delete─刪除
3.Put─修改
4.Get─read(讀網頁進來)
‧GData有在使用AtomPub
GData(Google Data API)
‧有標準的介面去作新增、刪除、查詢、修改
‧基本的RSS和Atom只能作訂閱，要作應用的話還是要用GData
‧認證方面
1.Installed Application
_輸入帳密，這個Session輸入一次後，GData會幫你包裝，不用一直重複輸入。
_Use ClientLogin interface
認證成功後，Google會return一個token，Application在每次登入都會確認它，但這個token有時效性。
2.Web application
_兩種情況:
(1)OAuth:如果跨好多網站時，如果到不同網站都要再重新註冊，會很麻煩。因此如果要用到Google以外的網站，就用OAuth(但其他網站也必須要提供Oauth)
(2)AuthSub:如果是用Google的服務(Ex:Google Map,YouTube)則使用AuthSub，AuthSub允許有註冊過或沒註冊過的access
其實之前回家都有好好的再看一次老師影片還有再做一次筆記
不過是記在筆記本上而沒有上傳到部落格
所以不是臨時硬湊出來的啦
現在就把我之前做的筆記整理到這裡 先po上一小部份
GAE(Google App Engine)
‧提供給程式發展者一個發展的平台。
‧優點：可以用它的硬體、CPU、頻寬，不用maintain。
‧缺點：限制較多，只支援Python。
只能用Google帳戶，因此在設計程式時要考慮如何把程式和Google帳戶作結合。
‧限制：
1.不能直接寫入file system，只能read，但也只能read with application code的檔案。
2.應用程式只能透過提供的URL、E-mail Service、API來瀏覽其他的電腦
而其他電腦只能透過提供的HTTP或HTTPs的請求來連接應用程式
3.應用程式只能在有網路請求時運行
‧特色
1.程式發展者可以不用管load balancing
(用戶增加時，load balancing很重要)
2.都是使用Google帳戶，所以帳號管理也不需要管
3.是要寫程式的，不像Yahoo Pipes等是在線上發展，在下載SDK時，它會提供local development environment，讓開發者測試完 成再上載。
GAE使用的Data Store
‧程式上載後採取分散式儲存
‧需要query engine
‧使用Big Table(和一般的Table不同)
採用物件導向的概念 Data object = entities
在搜尋時是用"kind"和"properties"找
‧優點：可以彈性擺放
GAE 和 Google Apps的差別
Google Apps
‧管理demain(管理者角度)，是Google所提供的平台
‧例如把e-mail system丟給Google去管理，可以提供附加功能，在上面建立 internet system，讓e-mail system變成web base。
蔡忠潔 494512085 jeffean
沈馥安 494512475 miniann423
賀毓軒 494512293 bossho
使用技術:
Ajax
jQuery
Ruby on Rails
Silverlight
Flex
實作內容會在Demo時再作詳細說明
蔡忠潔 494512085 jeffean
沈馥安 494512475 miniann423
賀毓軒 494512293 bossho
使用技術:4種(Jaiku /twitter/Google Map/Google Calendar API)
並整合成一項服務
http://jeffean.webhop.net/lab3/
主題:魔人啾揪團網
內容:讓活動發起人在網路上發起召集，公布活動訊息包括活動主旨、活動內容、活動時間及地點。在發布的同時新增到Google calendar上，讓各項活動時間可以一覽無遺並避免時間上的衝突。並在Google Map上標示出活動地點，同時可以發布訊息到Jaiku及twitter通知大家，達到活動宣傳的效果。
在這個資訊爆炸的時代，網路成為了人們獲取資訊的重要媒介，key入一個關鍵字，所得到可選擇的資訊的驚人數量，恐怕是從前還在靠著圖書館、百科全書在找答案的人們所無法想像到的。我們key入關鍵字的行為就是為了要搜尋到我們想要的資訊，對於搜尋的人來說，要如何搜尋才能得到可信任、可依賴的資訊，對於被搜尋的一方來說，要如何才容易被使用者搜尋到...。看完這本《隨意搜尋》才發現，「搜尋」，好像在不知不覺中已經變成了一個最重要的課題。
關於搜尋的人，也就是使用者、消費者的角度來看，在這個資訊來源暴增的時代，資訊辨識能力也越來越重要。過多的不必要的資訊總是會干擾到我們作出好的選擇，身為一個顧客，我想如果有好的資訊辨識能力，網際網路絕對可以節省我們的時間和金錢。
在開始閱讀這本書的時候，就有一個字眼開始不斷的出現，並貫穿了整本書：「可尋性」，在閱讀完之後，我也終於明白它有多重要。可尋性的意思就是容易被接觸、容易被發現、容易被定位的程度。它是一項特質，隨著獲取資訊的便利性日益提高，可尋性的重要也讓我們不得不忽視。書中提到，我們正朝著「環境可尋性」這個方向前進，意思是未來我們可能在任何時候，從任何地方、找尋任何人或物。資訊變得無所不在，這改變了人們的心智。可尋性賦予了個人「自由」，我們可以自己選擇消息和資料的來源。
而在數位的領域，可尋性依賴的就是「關鍵字」，它是搜尋成功的關鍵。這部份恐怕也是商業份子或是未來的我們所要極力探討的，因為關鍵字搜尋的威力，已經和WWW的豐富內容結合，且激發了商業行為的革命。所謂的商業革命，並非只是簡單的把購物過程變成線上進行，而是因為資訊和選擇，賦予消費者更大的能力。以前的消費者不可能在購物前找到這麼豐富的產品資訊，也不會有這麼多選項，權力已經移轉到消費者的身上。當從賣方市場轉變到買方市場的時候，可尋性就變得格外重要。
除了影響到web設計之外，可尋性也改變了商業行為的模式，長尾理論就是一個最佳的證明。網際網路的普及，使得具有長尾特性的商品具有增長企業營利空間的價值，而且規模還大得驚人，其產品總值可以和暢銷產品相抗衡甚至超越。這真的改變了我以前刻板的觀念，看來網路提供給消費者的選擇真的比以前多太多了。
而要如何設計出可尋性高的網站，很重要的就是我們必須要站在使用者的角度，想像使用者在搜尋相關資訊的時候，會輸入什麼關鍵字，進而找到我們的網站，如何使我們網站的被搜尋到的機率提高到最高。對於搜尋活動的生產者來說也是一樣，如果無法判斷搜尋活動消費者所處的情境，又怎能提供令人滿意的搜尋結果。其實不只是在可尋性，梅老師上課也提到，UI(使用者介面)一直都是服務、網站設計的一個重要課題，UI不等於美工，而是我們是不是能夠讓使用者容易找到他想要的，無論何時，我想站在使用者角度，以及先當一個好的使用者，都是一件重要的事。這本書讓我了解了現在web世界重要的驅勢以及當一個設計者應該要具備的觀念，尤其在對於資料檢索的概念上更是有非常深入的探討，我想我可以了解老師推薦我們看這本書的原因 :)
蔡忠潔 494512085 jeffean(組長)
沈馥安 494512475 miniann423
賀毓軒 494512293 bossho
我們目前有兩個方案,可能還會看實作的情況來決定要用哪一種
那現在還是先把我們的想法提出來
投影片: http://www.rumor.tw/~jefftsai/web20.ppt
Date:1/7
方案一
主題名稱:正妹推推王
說明:由於ptt表特板在瀏覽正妹的時候,很容易被推文數欺騙或踩到地雷,而且要一個一個開網頁連結去看正妹相片也頗為麻煩,因此我們想要做一個正妹推推王的服務,可以讓使用者自由上傳正妹照片,並可讓網友推薦留言,讓使用者可以馬上瀏覽到推薦人數最高,人氣最旺的正妹。
使用技術:Google App Engine
因為是沒有使用過的技術,Python和Django的熟悉也是需要時間,怕趕不上Demo,因此我們也擬了第二個方案
方案二
主題名稱:SongOH Radio強化版
說明:SongOH Radio是小胖之前做的網路電台,可以線上點歌並收聽.想要加入會員功能,結合一些服務API的應用(twitter,Facebook...),例如會員點歌通知功能等等,並結合Google Maps,可以看到目前在地球(台灣)哪些角落有人正在收聽SongOH Radio,然後加入一些AJAX特效等等。
使用技術:Google Maps,twitter APIs,Facebook APIs....,AJAX
| 蔡忠潔 | 494512085 | jeffean |
| 沈馥安 | 494512475 | miniann423 |
| 賀毓軒 | 494512293 | bossho |
