此文檔是編寫成為W3C品質保證興趣小組工作的部份。請把有關之可公開意見傳送到公開檔案郵寄清單public-evangelist@w3.org或把私人意見郵給Karl Dubost karl@w3.org。
作者特此鳴謝各位曾經參與回顧及提供意見的人士。
不論您是經理、網絡開發者、市場或傳訊部門組員,或獨立網頁主持人,您也從不同途徑看過有關網絡標準的好處。 您明白這些標準是有利於為您節省成本,簡易管理及賺取利潤,而您亦因此決定轉換 - 把標準放上您的網站內。
可惜,您找不到一份可以指示您該從哪裡開始及怎樣安排這個把網站轉換成為符合標準的過程的指引。可能您會以為在一個大的網站內實行這目標是遙不可及的。若您不肯定什麼是網絡標準,我們建議您可先閱讀什麼是網絡標準真義[WEB-QUALITY],怎樣選購及開發一個有質素的網站[REQ-WEBAGENCY],及為什麼一個具可讀性的網站[WAI-PROFIT]能帶來利潤。
我們在此推介的方法是適用於任何大小的網站的;它適合您所需,不論您在管理的是一個私人,小型公司或大企業的網站。
我們會引導您於所有不同的步驟當中 - 所有您也能夠獨力完成 - 從分析您現有的網站到組織您的新網站。每一個當中的步驟也是分開來設計的,並且是可以在不同時間,不同程度,由不同人士,不管他們的技術水平,而是依據工作程序來進行的。
不論大小,您必須先依標準來評審;當中大概會有許多網頁是不能符合您設定為您網站標準的要求。
把您們的傳訊部、技術部,市場部及管理層的人員召集一起來建立一個您們希望評核您的網站的清單。在這階段,是沒有需要排分那項是您希望修正的先後程序,但我們建議您最少也先行測試您網站的有效性(HTML 和 CSS)、可讀性及國際化水平。您會於以下內容中找到一些技術解釋。
這篇文章概述出依據W3C標準來改良您的網站的方法,但您也可以利用這策略來處理其他為您網站所需而設定的要求。我們建議以下有一份不盡齊全定的清單:
有時候,您或您的組員可能沒有相關的技術或未能理解有關您網站內的問題;若是這樣 - 請尋求協助。邀請在可讀性或國際化方面有相當認識的專家來參與。例如,關於可讀性的問題(殘障人士瀏覽您的網頁時的簡易度),您可請求一個相關的協會來協助您,一般情況下,如盲人協會,他們會十分樂意協助。若您是一家大企業的一員,也可能當中已有一些有殘障的職員在內。向您的人力資源部查詢及提議安排這些人士加入您們的工作。
現在您清楚您的測試要求,您要決定在您的網站內現有的問題。一個好的處理方法是列出全部在您網站內屬於您自己的所有URIs。這工作只是很簡單的程序--一個簡單的追查網頁連結的工具,再把它們加入一個純文字檔(如:一行列出一個URI)已足夠。
可能您的網站不能使用追尋連結的工具;這可能是一個檢察您的網站內有哪些網頁的連結不能被連接的。基本上,這程序可以顯示出哪些網頁是不能被搜尋器檢查出來的。亦意味著您正有效地防止外間進入您的網站。
當您完成這個清單時,您可以使用LogValidator [LOG-VALIDATOR],一個特別為幫助您檢驗網站而設的程式。LogValidator把一系列的URI依據您開始測試時所選的模式來進行分析。(這會是您的技術組員的其中一部份工作,請與他們相討怎樣配合您的網站結構來執行。)它會在每一個URI施行一系列的測試然後提供相關的測試結果。
經過這首回分析後,您會有一個關於您的網站健全性的概念,因此您便可以設定有關整頓您網站內的問題網頁所需的工作安排。或許您會有許多不合乎您要求的網頁,例如:您所有的HTML或XHTML網頁都是不能符合有效規格的。但您亦毋需擔心 -- 這事實上是一個好消息! 為什麼? 因為若您是使用一些範本工具或一些內容管理系統來製作您的網頁,這便表示您的範本內有一些錯誤的地方了。
解決方法很簡單;只需把範本修正及再一次進行測試;您可能發現較以前減少了出錯的地方,什至完全沒有錯誤。若您並非範本工具的開發者,向為您的網站製作CMS的人或有關人等查詢及作出相應的修正。將來,當您的網站要再設計時,請依照在Buy standards compliant Web sites [REQ-WEBAGENCY]內的建議。
若在第一個關口後您仍然在網頁內發現有錯誤,您也毋需擔心 -- 這指引會教您怎樣把它們修正。
這一步另外一個好處是它能帶給您對網站內的所有網頁一個具體的概念,這意味著當您要移動一個網頁,或刪除您網頁內的一個章節,您會有一個更清晰的意識來決定怎樣引領您網頁的訪客到來您的新網站,亦等於您不會因為經其他途徑來連接您網站(如其他網站提供的連結或搜查器)的失誤而損失訪客。緊記,好的URI是不會連接不通的。
現在您有一列詳細的所有不符合有效規格或有其他問題或錯誤的網頁的清單。它的長短不是問題,因為它不會改變我們在此作出的解釋。首先要清楚的原則是很簡單的: "不要修正! 改善 - 組織您的工作"
並不是完全有需要於一時間把所有問題修正,事緣兩個主要原因:
此外,請勿嘗試個別處理一個問題,而完全不顧及其他問題至完成。例如:您打算令您的html網頁合乎有效規格,和令它具可讀性 - 您應一併同時處理。假若您完成一個後再處理另一個,在後些的修正循環內,您可能會帶來另一些問題和影響您之前所做的一些良好效果。
所以:勿致力要於一次修正程序中把全部錯誤改正,亦不要以循環形式解決問題 - 應該要改良您的工作步驟。
這方法的成功因素是要於面對選擇時保留對事情的現實性,而且要確保這些選擇可以提供有效的成果。如果您想改良您的網頁,您便要決定您要解決所有發現有問題的網頁上所需要付出的時間。嘗試以在您網站內的一個問題網頁作例子,考慮在工作流程中以最合適的技術人員和資源來解決問題。
當您決定要運用多少時間在數個網頁上時,您將可以更準確地預計出需要的資源及人員在完成整項工作上,以及更實際地計算出每一天可以完成的網頁。
我們鼓勵您每一天處理一次會比每週/每月處理一次較佳。因為這樣可以讓負責執行職務的人士更容易安排時間,而且因為一天處理一次的時間必定較累積一週才處理所需的時間少。一天處理5頁比一週內利用一天時間來處理25頁,自然是來得較輕易及簡單。
與負責這些職務的組員定期舉行會議;以收集他們的觀點,執拗及經驗。這樣可以幫助您明白問題是源於CMS,或在編輯網頁的程序上。您會可以同時改善編寫程序及所使用工具的質素。
此後,從實踐這方法時所得的經驗,您會能夠設定里程標。例如: 50%瀏覽您網頁的人士能接觸由您所訂定的品質要求。當達至目標時,您可以提高水準至60%及以上。任何您希望測試或達成的目標,盡量保持它們在合理及細小的規模;這樣可以保持延續性,但卻是可達成目標及有進步的。
要達成一個真正成功的計劃,您要讓每一個有份參與出版的人員也包括在程序內。了解所使用的工具和方法,可以幫助您知道問題的起因 - 這是有關工具或使用者帶來的問題呢?若問題是由編輯工具帶來的,這樣便可以幫助您收集意見,而且還可以跟工具的製作人相討怎樣可以改良他們的軟件。這個在大規模機構的環境裡,尤其有大量使用者的情況下更是有效;正是一個聰明的進步方法。
把改良了的網頁出版 - 即使在非公開的情況下,最少也在組員之間發佈。這樣可以顯出當中的進程及鼓勵各人繼續參與。若您已經於發佈系統中找到問題所在,您只能在此加以改善。
在這文件前部份已提及的LogValidator [LOG-VALIDATOR],是可以幫助您點出網站內出錯的地方從而讓您可以作出改善。在預設的模式下,這工具是可以測驗出HTML文件的有效性。這基本原則實際上是很直接的:從網頁伺服器的一個log文件,裡面包含有每日被讀取最多次數網頁的結果,並取出最初n頁數的結果排序(n是一個您指定的數值),然後把它們傳送到W3C Markup Validator。完成後,它會把評核結果送回給您。
此舉有什麼好處呢?因為這樣您可以先修正最多人瀏覽的網頁,這是您評審您網站品質的角度 - 而非在於實際上有多少頁數。
LogValidator具有一個以Perl編制的開放及模件建設,您可以開發適合加入來配合您要求所需的模組。例如:您可以加入拼字檢查工具,或一個可以檢查在網頁頁內的商標和頁尾的信息是否正確的模組,又或是一個可以檢查網站連結是否有問題的模組。這是一個安裝十分簡易的工具,並且是CPAN存檔的部份。
處理這些事務的方法有許多,所以您應該依循所定目標方向作出實際性的行動。
使用LogValidator後,有許多方法可以使用來實行或分析由LogValidator檢出的結果。例如:您可以建立一個內部使用的郵寄清單,讓負責管理新網頁品質的組員每天早上也收到一列需要留意的URI。那麼,他們便可以安排除錯,或匯報產生問題的有關部門跟進。
這個按步驟進行的方法幫助您去維持網站的品質,但當問題繼續發生時,您仍需要定期進行跟進。
間歇地(如每三個月),請重頭把整個分析程序進行一次,這樣您便可以了解到您的網站在整體質素上是否有進步,而且還可以了解您的範本工具是否出現問題。同時也可以幫助您達成起初您所訂定的目標。若您網站的質素沒有改善,那麼您的步驟當中可能有些東西要修正了。
最後,負責執行這計劃的人員,在見到整個過程所得的結果,也會感到他們所付出的努力終於得到回報。漸漸地,您會得到一些有利於機構的珍貴經驗。同時,當您進行這回顧時,請編制一份紀錄了整個程序的事項,將來這紀錄便可以成為一份有關您的網站質素的手冊。
通常您的機構也會有其關於使用公司顏色及公司商標的守則。當發現問題時,把有關的簡單技巧加入,便可以改良您網站的質素。
在這裡所提供的方法是很具靈活性的;您要顧及您所需要的事項。若您的一些出版要求已有增減,您必須更新您的出版程序,亦即您的品質保證程序。
這裡建議用作評核及改良品質的方案是分別設計的部份,因此互相之間是沒有影響的。所以,您是可以因應您的需要而作出加減的。
您可能有機會面對一些由於不可能自己解決的問題,致使沒法子即時把問題解決。例如:您斤所使用的出版或編輯工具是無法編出有效的編碼的。雖然您已嘗試不同的方法,但無一可行。這情況下,您必須把意見收集,並以公司機構的名義反映有關之意見。由於這樣可代表整個市場一部份的意見,所以這些編輯工具公司會聽取您的意見。
要保持良好網站質素,您要對帑內部優秀的編寫員作出獎勵,並對有較多問題的提供協助。假若您的用戶不能領略您所選用的方法所帶來的好處,這就等如不能達到成功一樣。所以,您應該邀請他們加入,鼓勵他們匯報過程中,或使用工具時所面對的疑難等。這樣,對整間企業也會帶來得益。
這方法在W3C內已沿用多年在HTML部份上,它幫助我們保持所有網頁的有效性。 這亦是一個可用於您公司內或團隊內的一個十分有效的方法。
鳴謝所有參與複核本文章的人士: Olivier Théreaux, Stephanie Troeth, Denis Boudreau 以及所有在public-evangelist mailing-list內的人士。
