2005/08/21

網摘工具比較
分類:部落格、網路


最近因為部落格的熱門發展,連帶著網摘工具也隨之重要起來。網摘就是一種公共的Bookmark,以技術角度來講,只是把URL及標題還有意見(評論?)及部分重要內容記錄起來。

雖然以上這個定義非常的容易了解,但是做起來卻是困難,尤其是要配合瀏覽器要操作容易,又要能跟部落格整合,又要能公開API或是RSS規格等,其實,中間的運作是很複雜的。

我試著只選 http://furl.net 及 http://del.icio.us 這兩個網路服務來做比較,先做個比較表,再詳細列出其中的優劣。

***** furl/delicious
操作親和性    ◎
多標籤設定 ◎  ◎
多標籤搜尋    ◎
全文搜尋  ◎  ◎
評比工具  ◎
RSS輸出 ◎  ◎
RSS輸入 ◎
JS 輸出 ◎  ◎
API介面    ◎
每日自動發行   ◎(只有MT)

上上個月我自己開始做網摘以來,del.icio.us 還沒有開放 javascript 含入部落格的工具,當時只能用 RSS輸出的規格再出然後做出 javascipt放在部落格內顯示給其他網友看,資料轉兩手導致有時因為網路連線斷線的不確定因素,不是太慢顯示,就是資料出不來,而且 del.icio.us 的 RSS 輸出有項目的限制,這樣來做網摘並不合適,不知道什麼時候開始delicious 也有了 javascript 輸出服務,http://del.icio.us/feeds/js 顯然比 furl 有彈性的多。

操作親和性來講,其實第一眼會覺得 furl 比較像是一般標準的視窗程式操作,就是上面有一層一層的功能表,然後選好了功能表,後續就會有相對的 UI 介面來操作或者是設定,但是 delicious 比較不一樣,他完全是使用目錄的概念,所以搜尋的時候只要 URL 打對了,其實相對應的網摘就出現,而列在右邊的 tag 也用 client 端 javascript 的模式來選擇,所以剛上手需要點時間來習慣,但是一上手後的操作非常簡便與快速,要網摘一篇文章或是一個 URL 比 furl 的選擇方式要快速的多。

多標籤設定的這項功能來說,雖然兩項服務都有,可是在操作上以 delicious 比較方便,而 furl 雖然有,可是要按住鍵盤的 Crtl 鍵,然後用滑鼠點選,雖然不容易出錯,可是通常我們設定的 topics 很長,很難找到要點選的項目,雖然可以用建入的方式,不同主題用分號(;)隔開即可,但是還是以 delicious 比較方便。想不透為什麼 furl 不做一個 javascript 的點選模式方便操作呢?

至於多標簽搜尋,delicious 可以用加號(+)的方式把搜尋自設的 tag,但是 furl 就不能了,怎樣玩都只是單一的 topic。其他有關比較表中的一些RSS規格輸出輸入等等,我就不再詳述了。

每日自動發行到部落格這個功能我測試過 blogger.com 的平台是不行的,或許我還沒有看清楚規格的說明, 或者是哪裡沒有設定好!希望知道的人能夠教一下我。聽說 MT 的平台是可以的,可是目前好像還沒有人用這種方式來發行網摘。

其實拿這兩個網路服務來做比較並不是很合適,兩種服務都各有定位,以 delicious 來說,如果要查找大家的 tag 然後來搜尋所要的資料,其實是比較方便快速的,但是如果你有自己的部落格,只是要在自己的部落格來做網摘的話,furl 其實是比較活用的,他的評比工具比較齊全,目前,我就是選擇用 furl。

我們是不是經常會陷入一種迷思,功能越多越好,但是其實並不一定是對的?GMail Talk 出來了,大家也都有一堆希望表列,希望跟 blogger.com 整合之類的,但是我覺得目前 Picasa+Hello+Blogger 的整合不錯,再整合其他的系統服務有多少人會用,值不值得花上系統過大,維護不容易的成本?

另外 furl it 的 no-popup 加到我的最愛的版本中文會變成亂碼的問題,雖然MAX 已經發 mail 去跟 furl 的人講,可是我發現都沒有修改好,所以我就自己改了,若是大家有使用 Furl It Complete No-popup 的版本,可以把下面這段碼複製到我的最愛Bookmark的連結內容即可。

javascript:d=document;t=d.selection?(d.selection.type!='None'?d.selection.createRange().text:''):(d.getSelection?d.getSelection():'');d.location.href='http://www.furl.net/storeIt.jsp?p=1&t='+encodeURIComponent(d.title)+'&u='+escape(d.location.href)+'&r='+escape(d.referrer)+'&c='+encodeURIComponent(t);

要感謝在下面迴響留言的人,這篇文章是大家一起完成的。(完)

2005/08/02

網路應用API的下一步?
分類:網路




Google 釋出的 API 並不多,我對 http://maps.google.com 的 Javascript 元件的 API 印象深刻,SUN 的 J2EE 及 MS 的 .NET 可能都即將走入歷史。

這種網路元件的架構並不是很先進,傳統以來很少有系統這樣設計的,一方面是網路的寬頻環境還不是很成熟,另一方面是安全性有很大的漏洞,所以商業軟體不太可能走這種網路元件的合作模式,以商業化來講,不是把常用的 Server 設計成開放性的平台(如SQL Server),或者是做成一些程式庫函式庫(DLL)來包裝核心,多人開發使用。

觀察 google 的 maps,簡單的說,只是在地圖上做一些加值的應用,地圖相關資料的提供加上對地圖的移動縮放的控制都是 google 負責,而地圖的表皮就是合作廠商來進行。雖然不知道這樣的合作模式可以創造多少的市場價值,但這種架構已經出現實際應用,我很樂見這個影響對未來軟體開發,能創造不一樣的架構。

上面這張圖是 http://johnvey.com/features/deliciousdirector/ 開發出來的另一種應用,是利用 http://del.icio.us 所提供開放的 RPC API 來存取資料,但是應用介面的程式則是放在 johnvey.com 網站上面。

當大家還在討論 XML/RPC 規格的時候,網路元件的應用已經在瀏覽器上開花結果,如果到一家公司看看內部的管理系統,大部分已經做成使用 IE 就可以控管到所有的資料,這種網路元件的應用就越來越重要,合作廠商要如何保持自己的核心競爭能力,要如何分工合作,我想這樣的架構應用非常的重要。

今天早上我還跟另一家公司在談如何整合測試,雖然是必要的,但是這種開放性架構,整合測試已經變的非常容易,重點應該是怎樣定義這些網路元件的應用,只要定義的好,大家保有自己的核心能力,可以在各自的領域努力作到最好。