Software Cinema

剛剛看到 YouTube 上似乎增加了新的 sorting 方式, 本來是在利用 keywords 進行搜尋過後, 可以有 Relevance, Date Added, View Count, 以及 Rating 的 sorting 方法,


現在多了 Today, This Week, This Month, 以及 All Time 的選項. 但是我實際試了結果好像沒有作用, 還沒有作用的功能會先放上來嗎 ? Anyway, 從選項看起來, 我猜應該是可以進一步對於 sorting 的結果作切割吧, 例如 Date Added 加上 This Week 的話, 就只會看到利用 keywords 找到的 Videos 中, 只列出於本週內加上的 Videos, 依照 Data Added 的新舊順序列出. 雖然不是什麼突破性的 sorting 功能, 但是增加這個利用 Time 來切區塊的參數, 就可以讓 sorting 的效率增加不少.


玩著玩著就想到, 以後不知道會不會出現 Domain-Driven Video Sorting. 顧名思義, Domain-Driven Vedio Sorting 就是會針對你要找的 Videos 所屬的 domain, 有專用的 (specific domain) 最佳化過 ( optimized ) 的 sorting 方法.

講到最佳化好像就會變的很複雜, 要用一堆數學, 其實根本不用啦, 舉例子來說, 我上面的兩張圖片是在找韓國星海職業比賽的影片, 想看 Bisu 對上 Stork 的最近三場比賽 Videos, 而 YouTube 目前只有上面說的兩種 sorting 方法, 這兩種 sorting 方法事實上是普用性的 ( general purpose ), 對於哪個領域都可以適用. 但是在星海職業比賽內事實上有一些領域邏輯 ( Domain Knowledge & Logic ) 在, 例如這是 OSL 或是 MSL 的聯賽, 是單場 (1 set) 或是三連戰 ( 3 set ) 等等. 這些領域邏輯應該可以被用來進一步增加 sorting 的效率.

再舉個例子, 如果今天我是找 NBA 短片 Videos, 我可能可以利用聯盟分組 ( Division ) 與否的方式來為找到的 Videos 切段, 在 NBA 官方網頁上已經有類似的區分方法, 不過是用來看戰績表的.(噗, 不小心把姚明跟 Garnett 剪進去, 沒辦法今天沒馬刺戲份)


換句話說, 當我們在 YouTube 上根據某些關鍵字找到某些影片之後, YouTube 會自動根據你找到的影片之領域特性, 提供你除了普用性的 sorting 方法之外的, 此領域專用性搜尋方法, 因此究竟你每一次的搜尋可以用到哪些 sorting 方法是動態 ( Dynamic ) 決定的. 而至於 sorting 方法的產生就不一定, 要容易作點或許可以利用 Domain Ontology 推演出來, 這樣八成就會是靜態的 ( Static ), 複雜點的話或許 sorting 方法會是 self-evolved, 這方面就超越我所知道的領域了.

不管是哪樣, 可預期的, 服務都是越來越往我們的真實生活在靠攏, 我們需要遷就電腦軟體的地方只會越來越少.

昨天在註冊申請 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

UNITED_BOTTLE 是在 2007 德國紅點設計獎 (International Red Dot Design Award) 的得獎作品之一. 其基本概念是認為產品設計應該考量到預設用途之後的其他用途 ( future design should think beyond the product ), 因此在塑膠水瓶的例子中, 對於水瓶的外部設計, 除了考量到容易拿取不滑落的需求外, 其實水瓶的形狀跟是否能夠裝水的主要功能 (functionality) 是關係不大的.

但是用過的水瓶事實上可以變成是一種一般的容器, 就向有的家庭會把好看的玻璃瓶拿來裝別的東西, 當作花瓶, 或是作為裝飾. 在這裡是考量到可以把用過的水瓶拿來裝沙土, 就有了類似沙磚的效果, 可以用來快速建造臨時性的房屋, 避難所, 甚至可以建造永久性建築, 過可能需要搭配其他的黏性固定材料.


在這樣的應用中, 關鍵在於怎樣的外型設計可以方便裝沙土的水瓶作為磚塊使用, 可以快速地堆疊, 以及搬運. 創作者是以固定數量的水瓶可以組成一個單位的角度來進行設計.

嚴格來說, 雖然水瓶的形狀跟功能性關係不大, 但是卻會跟 marketing 有關係, 因此這樣的想法是否會獲得廠商支持倒是很難說.

在進行 software design 時, 我們也往往需要考量 design for reuse, 然而, 在 software component 身上, 是否也找的到類似水瓶的形狀的特徵 (attributes), 是跟主要的功能關係不大, 但是可以直接被用來橫量此 component 的 reusability 的呢 ? 是否我們可以就此列出一張清單 (checklist), 當我們面對什麼樣的 software components 時, 只要檢查此清單上的項目, 就可以撰寫出一份此 component 的 design for reuse 文件呢 ?

昨天收到 SourceForge.net 的通知信了, SourceForget.net Marketplace 正式開張.

在 Marketplace 上, 可以購買 services, 也可以提供 services.

提供 services 的人不一定要是某 project 的維護者, 舉 XAMPP 為例, 目前提供的一個相關 service 是 XAMPP Instalation, 提供者 (seller) 並非原本在 S.F.net 上, XAMPP project 的維護者之一. 不知道這會不會引發在 S.F.net 上的 SEO 問題 : 我的 services 要怎樣比較容易讓需要的人找到呢 ?


同時從右側的進階資訊 widget, 可以看到此提供者同時提供的其他 services, 以及 profile. 在 profile 內的資訊除了基本資料, 聯絡方式, 以及該 seller 在 S.F.net 上參與維護的 projects 之外,


同時可以察看該 seller 的 reputation 評分, 算是某種 customer feedback 的 service quality 紀錄. 但是此 quality 統計紀錄是針對 seller, 而非針對該 seller 的不同 services. 由於同一個 seller 對於不同的 services 能夠提供的服務品質可能有所不同, 因此我覺得如果可以同時提供該 seller 在不同 services 的表現會更好. 左下角有一個 detail 選項, 或許可以看到各次評分的詳細紀錄, 但是因為沒有找到已經有紀錄的 seller, 不知道下面的資訊會如何出現.


另外在 reputation 評分上, 也只有提供 excellent, good, satisfactory, fair, bad 等等模糊的評分, 而沒有辦法根據不同的 software services 有更細節的描述, 或許可以結合 ontology-based [1] 的方式給予更有意義的評分.

身為 OSS portal 的龍頭, SourceForge.net 的 Marketplace 能夠獲得怎麼樣的成功, 相信全世界都在看吧. 如果 Marketplace 能夠在獲得一定的成功, 很可能給投入 OSS 的力量帶來相當大的影響, 同時在 software company 營運模式也會有所改變也說不定. ( 派遣的品格 !? )


References

[1] M. Sensoy and P. Yolum, "Ontology-Based Service Representation and Selection," IEEE Transactions on Knowledge and Data Engineering, vol.19, no.8, pp.1102-1115, August 2007

今天因為 project 的原因, 想裝起 Joomla ! 來試試看. 但是 Joomla ! 的網站上好像暫時停止 download 以及 demo film 的下載, 原因不明. 想說好吧, 不然就用 Mandriva 內建的 Joomla packages 裝好了. 結果剛勾選完, 驚訝的發現居然相關的需安裝 packages 包含 Joomla 總共高達 36 個 @@


雖然說裡面包含了 Apache 跟 PHP 相關的 packages, 但是重點是我之前系統中並不需要安裝這些, 這些是由於 Joomla ! 的需要才有相依性安裝的.

藉著這個機會剛好想嘗試一下很久以前就發現的問題 : Package Manager 好像都沒在紀錄 package installation dependency 的, 因此想移除某 software 時也一併移除之前因為相關性才裝的 software, 好像無法透過 package manager 的幫助達成.

所以裝完 Joomla ! 後, 又故意把他移除試試看. 果然, Mandriva 內建的 package manager (RPMDrake) 只會偵測到 Joomla ! 相關的兩個 packages.


而在移除過後, 再度選擇裝回去, 就會發現現在只需要裝兩個 packages 了. ( 就是剛剛移除的 Joomla ! 相關 packages. )


這個結果意味著, 在 Joomla ! 被安裝時, 因為相依幸而被安裝的其他 packages ( Package In ), 在 Joomla ! 要被移除時 ( Package Out ), 並不會自動地被移除, 或是詢問使用者是否要一併移除. 然後就這樣留在系統中, 成為不知哪時才會被用到或是被更新的 useless packages ( Packages Left Behind ).

事實上要紀錄 package 被安裝時的 dependency associations 應該不是難事, 甚至當你要移除某個 packages 時, package manager 也會提醒你此 package 目前被哪些 packages 所依賴, 如果移除可能會出現問題. 顯見這些 dependency 資訊應該已經有被紀錄起來, 為何在 remove package 時, 卻不提醒使用者一併移除可能之後不會用到的 packages 呢 ?

我能想到的主要原因只有一個. 因為整個系統嚴格上來說並不受 package manager 管轄, 所以當面臨移除的指令時, package manager 並無從知道是否之前因為 dependency 而安裝的其他 softwares, 在 package manager 管轄之外, 被其他經由使用者自行安裝的 packages 所利用, 這樣的 dependency association 目前是無法經由 package manager 所紀錄的. 因此 package manager 無法在殘缺的 dependency association information 底下, 確保 package 的移除不會出現問題.

然而不用 package manager, 靠管理者更難做到上述的 package dependency analysis. 是否有更好的方法, 可以 statically or dynamically 對於整個 system 內的 package dependency 作分析, 進而蒐集相關資訊, 使得管理者可以在 remove package 時, 很清楚的知道應該把哪些 packages 也一定移除嗎 ?