Software Cinema

今天看到 Laptop 的這篇文章 : V12 Designs’ Dual-Touchscreen Notebook Coming within Two Years, 裡面提到 V12 Design 的 Dual-Touchscreen Notebook.

這怎麼說呢, 雖然乍看之下就是兩片 LCD 螢幕合在一起, 然後其中一片可以用作鍵盤顯示以及使用, 理想的話還會有 V12 Design 宣稱的感應回饋 ( Haptic Feedback ) 能力, 但是把 Notebook 上鍵盤那側變成 LCD 所帶來的 User Interface 改變還是很巨大的. ( 以下圖片引用修改自 Laptop )


把目前的 Notebook 具有固定式鍵盤, 到 Optimus Maximus 萬鍵之王的想法, ( 以下圖片取用自 Optimus Maximus 網站 )


再到 V12 Dual-Touchscreen, 硬體輸入裝置給了 Software 越來越多的自由. 在萬鍵之王上, Software 可以更加容易的改變按鍵的定義跟配置, 這在之前需要具備一定電腦知識的使用者才能辦得到. 而在 Dual-Touchscreen 上, Software 將甚至可以自行定義輸入用的 "鍵盤" 長甚麼樣 ( 如果他還長得像鍵盤的話 ), 而且不像過去會佔用到 Software 用來呈現 Data 的空間.

Software Usability 與 System Usability 的定義之間或許會更加的模糊, 真難想像這是會帶來無限的可能還是混亂 :p ( 更別提 Multi-Touch Screen 摟 ~~ )

在看 CNN 新聞的時候, 注意到他的 Photo Slideshow.


主畫面是選取的照片, 照片下半部是可收起的半透明照片解說, 下面則是 Slide Bar, 最下方則是其他 Group 的照片. 沒什麼特別的地方, 但是隨處 ( Most News Site, Blog, Company Site ... etc ) 可見是否也意味著這已經變成了某種 Web UI Pattern 了 ?

最近想幫系網頁也加上類似的照片集, 同時改變一下版面配置, 目前的公告區佔得太大了, 應該減少文字的比重. 倒是可以參考參考 CNN 的設計.

今天在 Cool Hunter 看到一個有趣的 Tag Cloud 設計, 在利用同樣 Tag 的文章數量來變化 Tag 大小的功能之外, 這個 Tag Cloud 伴隨著兩個 slide bars, 分別是 Year Slide Bar 以及 Days Slide Bar, 藉由調整這兩個 slide bars 的數值, 可以改變 Tag Cloud 的呈現. Year Slide Bar 用來決定要看哪一段時間之前的文章統計, 而 Days Slide Bar 似乎是決定要有幾天的 contents 被列入 Tag Cloud ( 這裡不是很確定 ).

我覺得這揭示了一個很有趣的點是, 透過部分網頁 visualization, 許多原本無意曝露出來的 information, 是否無意中授予了網頁訪客呢 ?

回頭想想 Tag Cloud 的目的, 其實在於提供一個訪客可以快速了解這個 Blog 內容統計的工具, 可以快速瀏覽整個 Blog 的主要內容傾向, 主要文章類別以及比例, 同時可以直接選取該分類, 在 Tag 及分類眾多時會有較大的幫助, 是一個讓 Blog 變得較為 user-friendly 的功能.

而把 Tag Cloud 變為訪客可以自行調整的模式, 在上述的能力中又做了加強, 同時把 Tag Cloud 由目前時間點的一個網站 Snapshot, 變成接續一個時間軸的眾多 Snapshots, 甚至我們可以從中窺知 Blogger 的興趣之演變, 因而把該 Blog 的更多 information 經由 Tag Cloud 的存取而曝露出來. 但是這對於 Blogger 是好是壞就難說了, 要看 Blogger 是否有意識到此點.

有人寫了利用單純的 JavaScript + HTML 寫了一個 EeePC 的操作介面模擬網頁, 可以簡單嘗試一下 EeePC 的操作, 不過僅僅是有限的更換工作群組以及模擬程式開啟關閉而已.

不知道為什麼 ASUS 怎麼沒想到利用這種方式來行銷呢 ? 應該不是對於 EeePC 的操作介面沒信心才是, 基本上要打破一般使用者對於 NB + Windows 的迷思, 沒有讓他們先行體驗更好的方式了吧.

從這點出發, 是否未來我們在建構軟體系統時, 其實有可能以同樣的方式來蒐集使用者對於操作介面的意見, 甚至直接作為廣告宣傳用呢 ? 從上面的 EeePC 介面模擬可以看出來, 其實這樣的 prototyping 在技術上只需要 Image + JavaScript + HTML 就可以完成, 而整個內容則來自於一個或是數個定好的 scenarios. 其他的元件跟操作都是可以在不同的 projects 中進行 reuse 的. 因此撇開需要創建嶄新效果以滿足顧客需求的 software 不談 (例如 Vista), 建立一個這樣的 interface prototyping framework 滿足大部分的 software 需求顯然是可能的.

昨天在註冊申請 Lijit 的服務時, 在過程中發現一個有意思的 Progress Indicator Pattern [1] 的實現例子. 在說明該例子前, 先簡單回顧一下 Progress Indicator Pattern, 在這裡我採用 Tidwell [1] 的整理.

在 Tidwell 書內主要利用 What, Use When, Why, 以及 How 來描述 UI Patterns 的 Metadata, 對於 Progress Indicator Patterns 而言 , 分別是 (我用中文摘要說明, 詳細內容可以參考 [1] ) :

• What : 當進行一個 time-consuming 的工作時, 讓使用者可以明確地認知目前的工作進度
• Use When : 當 User 在 UI 的操作上, 會因為此 time-consuming 的工作而中斷操作, 或是不影響操作, 但是需要把此工作的進度放在背景讓使用者可以監督時
• Why :
  
1. 在需要 software 進行較長 (使用者會明顯感覺被打擾) 時間運算的工作中, 如果使用者不知道目前的進度, 可能會因為不耐煩, 或是以為 software 不正常運作, 而出現無法預料的行為, 造成其他的錯誤操作
2. 根據實驗統計, 如果使用者能夠被告之進度, 即便進度內容不見得反應真實的情況, 使用者也會比較有耐心等待系統完成任務, 甚至認同系統目前正在 "思考"
• How :
  
1. 利用動態 (animated) 的指示元件 (Indicator) 來讓使用者知道目前的工作進度, 在指示元件的呈現上, 可以選擇使用文字語句型的 ( Verbally ), 或是圖形化的 (Graphically), 或是兩者合用也可, 一搬來說會呈現下面的資訊
• 目前在完成哪個工作
• 目前完成的進度百分比
• 預估還需要多少完成時間
• 是否可以停止此工作, 以及如何停止
  
2. 原則上不需要要求顯示進度與實際進度要達到非常精確的地步
   

一般常見就是 Windows 上的進度對話視窗 (Progress Dialog), 另外書本內也舉了 KDE bootsplash 畫面當例子.

而回頭來看看 Lijit 上的例子, 在填完申請之後, 會進入環境自動建構以及產生搜尋引擎的的過程, 這要花一點時間, 在這裡 Lijit 也應用了 Progress Indicator Pattern,


而 Lijit 的實現中比較特別的地方在於, 他的文字部分並非只是用取代的方式迭代, 而是會有淡出的效果 :

看上面從我的網址資訊變成 Create Search Engine :


另外 Lijit 的實現還有一個有趣的地方, 但是我沒辦法回到前幾個步驟去截圖. 在前幾個步驟, 當某個步驟特別長時, 他會出現不同的說法在描述同一個進度, 像是一開始可能跟你說他在進行 optimization, 然後可能會變成跟你說正在根據你的網站特性進行更好的 optimization 等等, 其實講的是同一件事, 只是他用的語氣偏向比較輕鬆的對話型語氣, 而不是制式的告知你進度, 這跟過往看到一般 software 的 progress indicator 文字部分有很大的差異.

從上述的兩點我不禁聯想到, 在 Design Pattern 與他的 Realization 之間, 究竟存在多少直到 implementation level 才會決定的點 ( Tuning Point ), 而足以影響此 Pattern 最後的結果好壞呢 ? 像是上面的淡出效果, 是不一定要這樣做的, 但是卻更加符合 Progress Indicator Pattern 的動態 ( animation) 要求, 而進度訊息文字的內容顯然也沒有規定應該怎麼寫, 但是如果在這部分填入了一些一般使用者無法看懂的專業術語, 是否就有違 Progress Indicator Pattern 在 Why 上面的要求呢 ? 反過來說, Lijit 的做法就比讓使用者看的懂還要來的更好.

是否我們可以針對各種 Design Patterns, 找出這些點, 變成使用該 Design Pattern 時的注意清單 ( Checklist ), 進而更加補足 Design Pattern 的 Metadata 呢 ?

References

[1] J. Tidwell, "Designing Interfaces : Patterns for Effective Interaction Design," O'Reilly, 2007

在我涉入 Software GUI 的研究領域之初, 我所思考的第一個問題其實是跟 Software User Interface Copy 有關的問題. 當時的觀察對象是 XMMS 跟 Winamp, 以及其他在 Desktop Linux 上跟已經在 Windows 上存在已久的 softwares 之間極為相似的 GUI 設計. 當時的想法是希望探討 GUI 的設計模仿跟 OSS 的成功之間是否存在關係, 以及是否 OSS 可以在發展初期藉由模仿既有的 popular software GUI 設計, 取得較大的成功優勢. 當然這背後還牽涉到怎樣把 functionality 跟 non-functionality 的 GUI 連結起來並從整個 global software 身上分離的問題, 這在目前也還沒有具體的研究成果. 不過這個想法最終是死在對於智慧財產權的考量. 因此雖然我還是在嘗試解決相關的問題, 但是採用的是完全不同的做法.

這幾天看到一個有趣的 Desktop Linux Distro. : Vixta Linux. (以下 screenshots 取自 Vixta@S.F.net)

Vixta 是以 Fedora 8 為基礎作修改的 Desktop Linux Distro. , 從名稱以及外觀不難看出來是 follow Windows Vista 的 style. 雖然模仿 Windows style 這不是第一樁, 但是在隨著 EeePC 使得 Linux 能見度再度提高的同時, 出現了跟 Windows Vista 極為相似的 Linux Desktop, 還是比起之前對於 Windows 2k, XP 的模仿更具意義. 而即便是在一些操作的介面上, 例如 File Manager, 也弄得很接近 Windows 傳統的方式. (不過其實原本 Konqueror 的 side bar 比較 powerful)

這樣的模仿, 目的之一當然是希望能夠混淆視聽, 讓使用者分不出來這是 Linux 還是 Windows Vista, 以達到想要的結果, 也就是寫在 Vixta Goals 裡的 : Spread linux to the "masses", User-Friendly, 以及 Familiar look and Feel.

假設 Vixta 可以達到他想要的效果好了, 這意味著使用者無法在使用 Vixta 時分清楚究竟現在他用的是 Linux 系統還是 Windows 系統, 要達到這個程度, 不是只改改 layout 介面就可以作到的. Software GUI 的真正意涵在於連接 Software 的運作邏輯 (Software Implementation Model) 與 User 的使用邏輯 (User's Conceptual Model) [1][2], 而通常後者的可變動性 (flexibility) 是比較大的, 因此可以說 Software GUI 是決定了怎樣把 Software 的運作邏輯表現給 User, 使得 User 可以在最小修正使用邏輯的前提下, 最有效率地利用該 Software. 而如果今天出現了一個 Software GUI, 可以讓 User 察覺不到背後的系統更換, 那麼被更換的兩個系統, 與 Software GUI 之間必定有相當程度的 decoupling -- 換句話說, 在 Software GUI 與背後的系統之間有相當清楚的 Interface 存在.

D. Collins 在 [1] 中引用了 J. Bennett 的 model [3][4], 訴說 User Interface 中四個不同的主要部分 : (the figure bellow is referenced form [1] )

圖中的 Implementation Model 是同時包含了 hardware 以及 software 的部分. 可以看的出來各部分之間的 coupling 關係, 使得要完成一個完整的 Software User Interface Copy 是很難的事情, 因為多多少少不同的系統在 Implementation Model 上都有差異, 也會影響到 Presentation Language 以及 Action Language 的呈現. 如果為了 Copy 而去改變 Implementation Model 就有點本末倒置了. 我相信 Vixta 總不會為了要讓 User Interface 更像 Vista 一點而去改 Linux 系統本身吧.

但是這是不是意味著 Software User Interface Separation (from Functional Application Part) 是不可能的呢 ? 我覺得倒也未必, 只是可能不會由目前的模仿之路作到, 而是透過 UI Design Patterns 的路作到. 重點還是在於 User 是否需要這樣的東西.

即便在 Windows 上也是有許多嘗試改變 Windows 預設 User Interface 的 softwares 存在, 例如比較有名的可能是仿 Mac 的 FlyakiteOSX, (figure bellow is referred from Screeshots@FlyakiteOSX)

這下好了, 用 Linux 的人在用 Windows 的 Desktop, 用 Windows 的人改用 Mac 的 Desktop, 下一個會是誰用誰的呢 ? 但是可以肯定的是, 只要 User 有這樣需求的一天, User Interface Separation 的可能性就一直存在, 差別可能只在於會在哪出現, 是在 OS 上, 還是會率先在 Web Applications 上出現呢 ?


References
[1] Dave Collins, Designing Object-Oriented User Interfaces, Addison-Wesley, 1995
[2] Theo Mandel, The Elements of User Interface Design, Wiley, 1997.
[3] John Bennett, "User-Oriented Graphics Systems for Decision Support in Unstructured Tasks," ACM SIGGRAPH, 1977
[4] John Bennett, "Analysis and Design of the User Interface for Decision Support Systems," In Building Decision Support Systems, Addison-Wesley, 1983

jlayout 是一個可以把 GUI configuration 與 Java code 分開處理的 tool. 遵從 jlayout 的 annotation 以及 configuration 語法, 可以把原先 Java code 中一大串的 GUI code 部分以少量的 annotation 取代掉, 而在 configuration file 上是以對每個 object 獨立作 configuration 的方式, 指定 object 的 state, 以及 objects 之間的 association. 整體概念可以簡單用下圖說明.


概念上跟 CSS 之類的有點相似, 但是 jlayout 沒有辦法支援長相一樣的 GUI objects 使用同樣的 configuration, 當然就更別說 styles 之間的 inheritance 關係.

從 configuration file 的長相可以看到其實 jlayout 在 code 跟 configuration file 之間還是有蠻強的 coupling. 需要依靠 object name 作為 configuration deployment 的依據, 也幾乎每一個 GUI object 都需要一個獨立的 configuration section.


換句話說, jlayout 提供的好處其實只有可以縮短原先 Java code 內的繁雜長串 GUI 部分, 以及可以透過 text-based configuration 調整 GUI object 的 state, 以及 GUI objects 之間的 associations. 進行調整時, 因為許多 method call 的 code 被省略了, 因此可以用更簡潔一點的方式作調整.

雖然主要編輯軟體改成 OpenOffice.org 有一段時間了, 不過遇到某些狀況還是跟 OOo 白痴沒兩樣, 就跟以前使用 Word 一樣.

雖然說身為唸 software engineering 的人, 覺得責任也不全在我身上, 編輯軟體的 user interface design 應該是很典型的, 遵守 "讓使用者專心在他該花心思的事" 去設計, 而不是當使用者想要什麼效果時, 還需要抱著一兩本厚厚的書在翻找, 或是找有深厚使用經驗的 "高手" 求救 (通常這情形發生的越多, 表示這 software 的 user interface 設計越有改進的空間). 過去 Word / Office 每次出新版, 市面上的相關書籍就琳琅滿目, 該說 M$ 跟這些書的作者也算是某種共犯結構嗎 ?

回到 OOo 的自訂頁碼起始值好了, 如何插入頁碼在 OOo 的基本操作手冊文件裡已經有說明, 但是當我要自訂文件的頁碼起始值, 也就是希望頁碼不見得要從 1 開始, 可以從 15, 43, 或是任何數字開始呢 ?

(以下方法適用於 OOo 2.1, 也就是我現在使用的版本.)

有兩個方法, 第一個是在頁碼上按滑鼠右鍵進入欄位設定,

在欄位設定的格式選項下方, 有一個叫做修改的可修改欄位. 但問題是, "修改" 是什麼意思 ? 要修改什麼 ?

實際試了之後才會發現, 這裡的修改意思是對於目前頁碼的修改, 而且是加減的修改, 而不是直接替換掉原本的頁碼. 舉例來說, 如果把這裡填 10,

確定之後就可以看到原本頁碼是 32, 變成了 42, 同時上下相連的頁面, 其頁碼也會跟著改變. 換句話說, 原本的 32 + 修改的 10 = 最後的 42.

第二種方法就更神奇了, 你必須要把游標移到要改頁碼的該頁, 比如說剛剛的 page 32, 頁面內容的第一段上, 然後右鍵進入段落設定中. 請注意要是第一段, 否則改變的頁碼會從下一頁開始產生影響.

進入段落設定中, 在中間的位置有換行與分頁的設定, 需要把插入以及使用頁面樣式都勾選, 然後才能對右邊的頁碼進行調整, 一樣把他改到 42.

按下確定之後, 一樣可以看到 page 32 變成了 page 42. 但是請注意, 這種方法所造成的頁碼改變, 僅限於 page 32 及其以下的頁面, 換句話說 page 33 會變成 page 42, 但是 page 31 仍舊只會是 page 31, 跟第一種方法的影響不同.

Well, 回過頭來說 user interface design, 像是這種 design, 一來在使用者想要某項功能時, 很難以選擇施行(因為根本不知道可以這樣改阿), 二來對於究竟會造成什麼效果 (post-conditions), 也難以掌握. 今天只是改個頁碼就可能出現兩種不同的結果, 要是改其他的東西, 使用者如何放心文件的其他不相關部分不會被偷偷的進行什麼變動 ? 如果每次作設定的改變都需要使用者重新檢查文件一次, 這未免太累人了 :(

從這個 case 其實可以深入探討三個議題,

1. use case consistency : 如果上述兩個方法其實是同一個 use case, 或是相似的 use cases, 那麼他們的 post-conditions 是否應該保持一致 ?

2. use case understandability : 如何讓使用者事先意識到在他所使用的 use cases 中, 最終會對文件帶來什麼改變, 而不是等到 use cases 執行完了, 才讓使用者去找尋造成了什麼改變. 畢竟 use case 在 forward engineering 中本來就是給 customer 看的東西, 沒道理在真正使用 software 時反而不能從 use case 裡得到應該知道的訊息.

3. document-preserving activity : 這是從 refactoring 的 behavior-preserving 借用過來的, 以編輯軟體來說, 是否部分 activity 應該可以視為對 document 作了 refactoring, 同時這些 activity 也必須具備某種 document-preserving 的特性. 舉例來說, 上述的兩種頁碼變更方式, 第一種會維持頁碼的連續性, 第二種則是會打斷頁碼的連續性, 這可能是兩種不同的編輯功能, 但是顯然地他們造成的效果是不一樣的, 換句話說這兩個 activity 對於 document 的改變事實上就是具有不同的特性.

阿...越扯越遠了, 就此打住, 有機會再深入討論這些想法吧 :)

看到一個好玩的網站 : FloorPlanner , 可以用來幫你規劃家裡的各樓層擺設, 有商業版軟體, 但是也可以註冊他的免費帳號, 可以試用線上版 (使用 Flash 製作). 註冊只要使用 emial 帳號跟設一個自己的密碼, 門檻很低.


進去後可以 create 自己的一個新的 project, 或是開啟別人的來看, 結果我開了其中一個名為 container 的規劃圖, 共兩個樓層 :


而且他也把 tag system 用在分類大家的規劃圖, 所以使用線上系統的人, 就可以共同快速地分享自己不同空間的設計.

使用設計上相當直覺, 以 Drag&Drop 為操作基礎, 分為三個控制 menu, 一個是 (1) 新增房間, 門, 窗, 註解等等 global constructs 的 menu, 一個是 (2) 新增各種家俱的 library menu, 下拉式選單內有各種 library, 另外一個是 (4) navigation menu, 就是左移右移放大縮小啦, 另外 (3) 的編輯部分也是很容易操作, 直接用滑鼠拉空間範圍, 換顏色等等, 搭配 library menu, 很快就能作出很漂亮的設計.

以 Software Product 的角度來看, 真是一個很吸引人使用的 Software :)

看到這三個 YouTube 連結 :

• StarCraft + Touchscreen on linux with wine
• 3D Desktop! TouchScreen and XGL on Linux!
• 3D Desktop! TouchScreen and XGL on Linux (part 2)
  

真是太炫了, 這樣玩星海, APM 只要超過 50 螢幕就要爛了吧 XD, 手指也忙不過來.

XGL 之前利用 LiveCD 玩過, 沒想到搭配 TouchScreen 的能力可以做到這樣, 雖然說實用性還有問題, 但是這跟利用 keyboard & mouse 的 interaction interface 比起來, 已經算是 PC 上的一個 milestone 了 (雖然現在 TabletPC 以及 UltraMobile 也是可以這樣, 但是 PC 還是以 keyboard & mouse 為主).

這也意味著 Softwae GUI 的設計會邁入一個新時代嗎 ? Software Non-GUI part 與 Software GUI part 的分離之議題是否會更加被重視 ?