目標
我們需要的是一個活生生的網站；而不是「只有」一堆連結與一成不變寫死的內容。
方案
類似「Tumblr」的微型部落格概念，管理人在「dashboard」發表內容，一般人會在「blog」看到呈現的內容。
網站中的結點係由每一個相關的人負責，這些人擁有自己的「dashboard」，他們的「blog」是被串在「root blog（也就是網站首頁）」下；同樣的概念，管理人可以在「dashboard」看到每個負責人發表的內容，匯整以後安排到更適合的位置（或不用動）。
這樣可以使的網站內容更豐富，也容易更新和維護。
技術層
概念
- 整個網站可以由中剖開為「dashboard」和「presentation」。
- 使用者的權限可以分為「管理者」與「作者」。
- 不同的使用者分別屬於網站中的某一個節點。
- 所有人每一個 post 都是一個 building block。
- 每個 post 可以由「test, audio, photo, video」當成主類型，分別有相關的輔助工具可用。
- 基本上，網站的內容都是由這些 post 構成。
Use Case - 發表公告
- 資工一姊上班時，接到下禮拜不用 seminar 的通知，便在 dashboard 中發表了一個「類別為公告」的 post。
- 這個 post 會自動呈現在網站中屬於公告的位置。
Use Case - 老師更新研究成果
- 吳老師的研究有新成果，便登入 dashboard 中發表了一個 video post，內嵌了 youtube 的影片，並放了一些說明。
- 一般人透過「http://xxxx/研究成果/xxxproject」可以以適合呈現的方式看到這些內容。
- 吳老師覺得同一個研究較早發表的 post 不需要了，便刪除之前的內容。
- 資工一姊上班了，登入 dashboard，在他的 dashboard 中看到了吳老師發表的文章，覺得不錯，便使用了「re-blog」，並且選好適當的位置，讓吳老師的文章，直接也出現在系上的影音專訪頁面中。
PMS (Bug-Traq) Add-on
- PMS 的 bug traq 功能，是由一堆的 ticket 組成，這些 ticket 會被指派給相關人士，由相關人士負責解決。
- 由這樣的概念為底，以 Timeline 的方式顯示，如同一個資工系的 plurk 帳號一般。
- 任何「非 reblog」的 posts，都會自動出現在 Timeline 中。
- 一般人可以透過這個在網頁上顯示的 Timeline 發表意見、問題討論、報修、聊天。
- 這些問題可以是 private、public、或是回應後才顯示。
- 帳號可以是「系所成員（sitemap 中的那頁）」所有人，也可以直接和 401 連線。
Use Case - 獲獎通知
- 吳老師這項研究獲獎，直接在他負責的節點中更新 post，一姊在 dashboard 中看到了，直接 reblog 並且放在獲獎通知中。
- 黃老師確定要發表一個獲獎通知，他將這個 post 的類型設定在「獲獎通知」，這個 post 便神奇的出現在整個網站中該出現的地方。（一姊不用另外安排位置）
- GAIS Lab 學生比賽得獎，直接使用 Timeline 回報一姊，一姊就發了一個「獲獎通知」的 post。
Use Case - 聊天
- 很多學生 seminar 很無聊，便在系上的網頁聊天與討論 seminar 內容。
- 一姊可以在 dashboard 的 timeline-view 看到這些聊天和討論，她覺得有些很有價值，便直接「quote」放到網站應該出現的地方。
- 這些聊天基本上不會也不應該 assign 給任何人。
Use Case - 報修
- Lab 的電燈壞了，上去發一個訊息。
- 一姊看到 timeline 上的這個 message 會直接 assign 給特定的人，相關人士便會收到通知。
線上服務
- 報修系統 - 可以由 Timeline 取代。
- 設備/教室借用 - 可以用 Google Docs 套上用（excel, form）。
- SA區 - 我寫。
靜態內容（從 sitemap 那裡看）
靜態內容諸如：系所概況、位置圖（Google Map）、設備資源、修業與招生資訊、獎學金、表單下載。都可以直接在 dashboard 裡面由管理者「設定」，如同設定 meta info 一般。
當然，其中修業、招生資訊、獎學金，也可以先 post 以後，再移到特定的位置，因為這些東西還是會隨著時間變化。
其它
當然，RSS 在重要地方是要有的。
當然，要放 sitemap.xml。
要不要考慮在即時互動的部份也引入 Google Wave。
網頁的設計要另外考慮到 mobile device。
