今天和同事突然談到在我們身後那片大窗框住的建築物（我們面向著紐約近日狀況不怎摸好的 Financial District)，
其中有一棟建築十分突兀的佔據畫面，我就有點批評：這棟建築太摩登了！於是同事給我一個有趣的演說video來看關於你怎摸欣賞藝術和現代藝術，很有笑點。（分享分享）

Tidying up art

Adobe announced a new application called Catalyst, which is a Flex based IDE that allows designer to design or modify UI (user interface) easily. Basically, it’s birth is for designers and developers to work together efficiently. (We all know that Flex is not easy to modify UI.) This application could create MXML for designers.

I think Adobe is a bit like Apple now that it’s killing it’s own products! My thought is Catalyst will kill Flex eventually in a good way. Wondering if this kind of revolution will affect Flash. Flash is still good for delicate animation and better user experiences.

讓塑膠貴到像黃金的KAWS在紐約要展覽了!

KAWS 據說基地位於Brooklyn, 也是SVA畢業的, 有興趣的人趕快去看看!

KAWS

November 6 - December 23, 2008

730 Fifth Avenue
Between 56th and 57th Streets
New York, NY 10019

網址

自從好幾年前湯哥的一部電影”關鍵任務”之後,許多從事互動的好手,都把實現電影中的互動展示界面當作使命,這個 Video 也不例外.

雖然當初(幾年前）,許多人提出互動概念的原型,那或許是從創意的角度提出來的一個可能性,然而後來大家紛紛把可能性變成可能之後,反而應該反思一下, 究竟這樣的界面真的有比較好嗎?

以下我的淺見:

如果直接用手操作比較好的話, 那為何我們現在寫字需要用筆,而不是在指尖上套個能有墨水的東西呢?

藉助器物當然是有道理的,手握鉛筆, 能讓人控制更微小的動作,用滑鼠也是一樣的道理.

用手套操作,萬一想要抓頭怎麼辦?

直覺的反應或許很好,但是這樣一來無心的動作可能造成決策的錯亂, 就像試想歸想,做歸做,如果想的事情直接就會發生,那麼沮喪的人可能全自殺光了. 藉助器物(起碼也要個觸摸面),可以有思考跟行動的分野,我想也可以用這種角度來看吧.

和josh貼的猜歌大王同時發表的Loopt是個可以把地圖當界面,即時顯現自己和朋友的位置,直接點選進行語音,訊息,圖片,事件分享的social application.
這種location-based的點子在許多新一代的手持裝置的概念產品中都有提到過. 不過這個Loopt到好像是第一個正式發表,而且還站上iPhone這個大平台的作品. 手上有iPhone的裝來玩玩看吧,分享一下效果如何?…:)

這個iPhone的免費下載軟體Shazam好厲害阿，聽到喜歡的歌，只要在這軟體裡按一下Tag Now, 幾秒之後他就會根據軟體聽到的片段，分析出確切的專輯與歌名。不過目前「似乎是」只有美國iTunes上買的到的歌才解析的出來。還有，自己唱好像沒用哪～^>^!
影片連結
Shazam

介紹

瘋了1

瘋了2

DEBUTS TODAY TRY YOUR LUCK (img source from H&M)

宅男們！看過電影少女漫畫吧～這個會蹦出來,不過還是在螢幕裡

很有趣的 CV Pattern recognition 的作品, 有點宅,有點變態.

(這讓我想起 JOSH 哥的 Thesis)

最近玩了 Wii music,裡面用到 balance board (from Wii Fit )的鼓, 蠻有意思的.

說是創新其實也沒有,因為他就像真的在打鼓一樣, 尤其是那個手腳不能分開運作的挫折感.
不過對以往的音樂遊戲來說,是一項突破. 以前對著迎面而來的音符match按鈕的音樂遊戲,好像有點讓不會樂器的人藉由遊戲來乾過癮,不過玩過 Wii Music Drum後我感覺好像不只是乾隱,全部破玩後,有個真的鼓,我想應該是可以上手的. 而且在過程,不是學的心態,而是在玩的感覺.大家有 Wii Music的話一定要玩玩看.

我想一陣子後應該會有些 Gamer 用 Wii Music Drum 打出很離譜的節奏, 拭目以待….

我們小組 (R/GA) 做的耐吉史巴克又跌破眼鏡得到今年2008倫敦國際獎銀獎

看這邊有我名字… 送!

high-res and the making of can be found here:

http://www.flickr.com/photos/18697966@N00/2982281565/sizes/o/in/set-72157608377333404/

http://www.flickr.com/photos/18697966@N00/sets/72157608377333404/detail/

Silk Route 升級 2.6.3

在 Ajax 的強力壓陣下, Flash 在許多功能像是 SEO / Direct Link 方面遠遠比不上傳統直接暴露原始黨讓 browser / robots 讀取的 html 頁面.

許多案子紛紛的靠往 Ajax 網站而捨棄 flash, 為求生存, Flash based website 除了要提供更複雜的設計需求, 還必須要解決本身在 SEO / Diret Link 不如 html 的缺失, 所以就出現了熱門的 DeepLinking (DL) 的機制, 以 SWFAddress 為大宗.

如此一來解決了所有內容包含在 Flash 內的困擾, 讓 URL 上的網址可以對應到相關的 Flash 頁面.

相信有做過 DL 的人都知道, 要完全的雙向 DL, 是寫 AS3 的一大挑戰,除了要儘可能的做到絢麗的互動設計之外,還要兼顧到 DL 的機制, 更進一步如果要有SEO的能視度, 相對應的資料處理變得相當複雜.

其實利用 MVC Pattern, 整個分工可以變得比較清楚,尤其最近跟康貓兄搞了一點 CakePHP, 其用 Controller 與 View 配對的機制, 打通了不少之前在 Flash 上, View 與 Control 之間糾纏的問題.

以下是小弟我的心得怕忘記,寫下來,並跟大家分享:

基本上, 在製作 DL 的時候,如果從最基本的觀念出發,就是一切由URL控制,最理想的狀況就是,所有Flash內部的任何動作,都只是改變網址,經由網址的變化 Event, 觸發頁面的改變.

概念有了,就比較簡單一點點了,再來就是實作上的訣竅.

一般而言網站的目的就是包裝資訊,然而這整個資訊的結構可能相當龐大,因此我們要根據一些分類法把網站加以分類,讓人方便並且容易了解,分類之後在依據策略做互動界面的安排.(這些類工作就是所謂 information architect / interaction design 的責任, 很多人都把 interaction design,誤認為製作好玩的互動界面,其實共做內容大多是在設計流程圖)

經過以上動作之後,網站會有幕後看不道的整筆 1.data, 在實體上就會形成兩樣重要的視覺元素, 2.navigation system and 3.content.

我們可以用 MVC 的方式來讓這三個元素既達到視覺設計上的突破,也能完成DL/SEO功能上的要求. 並且至做出來的模組,也可以重複使用,減低每次重做的痛苦.

“->”資料流向
“>>”動作順序

Model
1.data: 資料分割,並且提供統一的資訊回應 API, 資訊包裝回應,避免耦合. (data -> relationship logic -> information),幫裝不一過多或過少,這也同時會影響 SEO,搜尋的結果.

Controller
接受 SWFAddress 的網址改變 Event,觸發:

(0).拿資料 : M->C: 先把View要的資料蒐集完畢,然後發出事件改變 View.(蒐集資料也可以發生在 View,視情況而定)
翻譯網址改成 Model API 需要的語法, 索取Model裡面分割好的information,簡單來說,一個網址就是配一個包裝過的資訊單位,也就是 transition -> 最後完畢提供資訊的界面所需要的, 基本上網址對應的內容可以後來再讀,但是 navigation / 互動元素, 要用到的必須先準備好.

1.做改變 : C>>V: 跟據網址發出事件給 V
需要過濾網址格式是否正確,否則會造成混淆與錯誤.

2.給資料 : 提供API,反應 V 要改變的資料

View
content: 消失上一筆內容, 接收網址顯示內容.
navigation: 接收網址改變, 或是改變網址.

在處理 navigation 必須要能直接跳頁, 而並非依序漸進, 像是 start >> 1 >> 1-3 （這種依序漸進的方式不宜採用),必須要有 start at 2-3 >> 3-2 >> 2-1.

DL通常用在一開始就有網址進來,可以把 audience,直接帶到該頁內容,這種狀況要擋住一開始近來的事件,先把所有的 Menu 內容準備好,在去觸發,不然會造成 Menu 無法應變.
Menu 內容已知,數量不多的時候, 可以一次把所有的 Menu 建出來,但是不要秀出來, 已備跳頁的狀況

最後的挑戰就是必需要考慮到循序見儘可能產生的transition,與跳頁的時候,要如何安排可能產生的問題.