帝國反抗君之古戰場。PowerOp請您速至 blog.yam.com/ystuan 支援前線！

[徵求意見]一篇文章的草稿

（題目暫訂，因為我覺得自己這個題目訂的很爛）
無差別瀏覽 -- 一個網路使用者的努力

寫在前頭：
關於這篇文章，我本來想要「快轉」，跳過瀏覽器戰爭，跳過W3C規範，跳過
Netscape釋出原始碼成立Mozilla.org，跳過目前IE的病毒問題，
直接來談如何填寫bugzilla回報有問題的站台，如何利用Mozilla@Taiwan來集合眾人之力。

「但是，這樣子讀者看的懂嗎？」

我沒有辦法回答NewZilla編輯部這樣的質疑。因為我（一直很固執的堅持）不知道讀者是誰。
身為一個使用自由軟體多年的人，為了寫這篇文章，突然要解釋一些思維中已經覺得「理
所當然」的道理；突然要「倒帶」、「歸零」，解釋我們為什麼要依循W3C網頁設計規範，
為什麼要遊說不依循標準的網站站方，為什麼這個，為什麼那個‧‧‧

好吧，我還是跳過了很多，因此我決定先放在這裡，希望大家提供意見。
請注意，我會保留上述文字和大家的意見，但是最終的稿子可能會登在http://www.newzilla.org，如果順利的話:)

（文章開始）
從唸書的時候開始接觸網路到現在，算算也超過十年了。一開始的時候是在學校／系上，
使用Sun的工作站（作業系統應該是SunOS 4.x）連上BBS，後來則是使用Mosaic這個瀏覽器
瀏覽網頁。學校宿舍有了網路之後，雖然自己的電腦有安裝Microsoft Windows 95，多半的
時間都是使用Linux(Red Hat 3.0.3)，瀏覽網頁則用當時最熱門的Netscape。

現在回想起來，所謂的「舊日的美好時光」似乎還真的存在過；當時微軟的
Internet Explorer才剛問世，功能還比不上Netscape；IE的普及率也還沒有飆升。那時候作
為一個Linux使用者，用Netscape瀏覽網頁，幾乎不會遇到IE only的網站設計。

接下來的故事大家應該都知道了，瀏覽器市佔率戰爭，網景(Netscape)輸給了微軟。原因
當然很多，不過我相信Internet Explorer是因為跟作業系統免費綁兜在一起，才稱霸瀏覽
器市場的。（一句牢騷，有時候我懷疑現在不曉得有幾個人知道作業系統不是只有微軟，
IE只是瀏覽器的一種？）

我可以同意，微軟的作業系統和瀏覽器讓更多人接觸到Internet。但是，微軟對於網頁設
計相關規格的污染，讓網站設計者使用非標準的、只有IE才能執行的語法，導致其他的瀏
覽器就算符合W3C組織所訂定的標準，依然在瀏覽網站的時候處處碰壁。有的網友會用一種
「成王敗寇」「少數服從多數」的論點，來看待這件事。我要提醒大家，「封閉」、「寡
佔」常常隱藏了很大的風險。W3C開放的規格表示任何軟體開發者都可以准此來設計瀏覽器
，原始碼開不開放，程式收不收費都可以。相反的，封閉規格就是做獨門生意，使用者只
有被牽著走，沒有其他選擇。

我也要提醒大家，數位落差(Digital Divide)的情形已經存
在，網站設計者不應該再雪上加霜，限定只有特定的作業系統／瀏覽器才能使用該網站。
不幸的，這才是我們每天面對的現實；不管是私人機構或是公家單位的網站，有的在首頁
直接註明只能用IE，有的甚至會檢查妳使用的瀏覽器，如果不是IE就不讓妳看到內容！在
tw.bbs.comp.linux上面，這種抱怨一陣子就會出現一次。如果這個網站非上不可，
例如大學生使用的選課系統，一般民眾使用的電子監理系統，這樣的抱怨聲浪就更大了。
在這樣的抱怨聲中，也會有網友提到說願意連署來表達意見。我當時認為，一定需要一個
(虛擬)的壓力團體，針對[無障礙網頁]的目標來努力。這個理想中的網站能匯集人氣,收集
大家的經驗談。也許學生關心選課系統，上班族關心政府的報稅系統、電子監理系統、各
家銀行的網路銀行‧‧‧

後來發現，原來我是井底之蛙，其實Mozilla@Taiwan的討論區
http://forum.moztw.org/
已經存在多時了。除了一般關於「Mozilla使用/安裝上的技巧與問題解決」這類的討論區
，Mozilla@Taiwan也開設了「問題網頁與技術傳教(Tech Evangelism)討論區」
http://forum.moztw.org/viewforum.php?f=13
，用來討論 Mozilla 顯示/瀏覽/登入等有問題的網頁，與網路標準的推廣。
身為一個自由軟體的使用者，我期待Mozilla@Taiwan能夠匯集眾人的力量，讓力量累積之
後再適時彰顯。我覺得現階段要先做打底的工作。一個建議：利用上述的討論區，大家來
交換「跟網站站方交涉」的心得、經驗、甘苦談。以及運用接下來要介紹的Bugzilla來提
報用Mozilla瀏覽有問題的網站。

這篇文章接下來想要做一些工具性的努力，目標放在讓使用者能夠很容易的使用Bugzilla
回報有問題的網頁。其實這個架構早就存在了，也針對不同語系的使用者做區隔。底下的
資料基本上是翻譯"Mozilla Site Evangelism Procedures"
http://www.mozilla.org/projects/tech-evangelism/site/procedures.html
，希望讓使用繁體中文的朋友們也能夠運用這個工具。

（先提醒大家，我們討論的主體是Mozilla。請不要把Netscape 6 or 7, 
Netscape Navigator, Netscape Communicator, 或 Debian相關的問題提交給
http://bugzilla.mozilla.org）

Mozilla社群使用Bugzilla這個工具來回報各種問題，主要是程式臭蟲（bug）。另外，
http://bugzilla.mozilla.org/也用來回報設計上有問題的網頁。Mozilla社群把這個
類別稱為Tech Evangelism（技術傳教）。接著讓我來介紹如何填寫。
首先，妳要註冊一個帳號。請到http://bugzilla.mozilla.org/createaccount.cgi
填寫一個電郵，以及姓名。妳會收到一封電子郵件，請用內附的密碼登入。（當然，
妳稍後可以更改這個密碼）
登入之後，哇，好多欄位要勾選，可別這麼快打退堂鼓，要不妳可以點選最上面的
Give me some help
http://bugzilla.mozilla.org/query.cgi?help=1，如此一來
只要將滑鼠移到各個欄位，就可以看到說明。
不過，我們並不是要回報程式臭蟲（雖然這是Bugzilla的主要目的），而是要回報問題
網頁，所以只要依照Mozilla Site Evangelism Procedures
http://www.mozilla.org/projects/tech-evangelism/site/procedures.html
的步驟來做就可以了。
1.不過，冤有頭債有主，Mozilla社群建議大家，第一步先寫信給網站站方，抱怨她們把網頁
設計成不支援Mozilla。如果對方沒有回應，再繼續下面的步驟：
2.確認這個問題屬於技術傳教類別
3.在Bugzilla開一個Bug call，在Product項目選擇Tech Evangelism。
4.選擇適當的Component，請依照網頁使用的語言分類，例如選擇Chinese-Traditional。
5.選擇硬體平台和作業系統。如果妳確定問題和特定平台／作業系統無關，請選All。
6.選擇這個Bug的初始狀態(Initial State)：如果妳確定這是一個bug的話，請選擇NEW （新的）；
不太確定的話，選擇UNCONFIRMED（待確認），Mozilla社群會去確認。
7.選擇嚴重程度：請在major，normal或minor中擇一，其他的選項對技術傳教類的bug來說
沒有意義。至於到底多嚴重？相信妳可以做出最佳的判斷。
8.選擇此問題的負責人(Assign to)：如果妳要負責追蹤這個問題的話，可以填入自己的
電郵位址。不然就把這個欄位空白，讓Component Owner去處理。
9.輸入網址(URL)：妳可以輸入用Mozilla瀏覽有問題的特定頁面。要注意的是，通常來說
如果網站的特定頁面有問題。可能網站有很多頁面都有同樣的問題。如果真的是這樣的話，
妳可以輸入網站的首頁來代表。
10.輸入摘要：請輸入URL的"主要部分"，後面加上 - 以及簡短描述。描述不需要很技術導向。請參照底下的三個範例：

    bar.com.tw - Displays differently than IE5
    netscape.com - Does not allow Mozilla
    fubar.co.uk - Does not support secure connections in Mozilla

舉例來說如果妳要回報http://www.foo.bar.com.tw/help/support/，那麼bar.com.tw就是URL的主要部分。
如此一來，大家可以用摘要的文字來對bug做分類，也可以把同一個公司的bug歸類在一起。

請大家留意的是，摘要應該是一個普通的使用者也可以填寫和理解的。更多有關
技術細節的部分稍後可以加在Status Whiteboard等到這個bug被歸類、指派之後。
11.輸入描述：請針對妳瀏覽該網址所遇到的問題，填寫足夠的細節描述。Bugzilla系統中
有很多欄位是要在bug送出之後才能繼續填寫的。所以在此請填寫簡明的描述。在送出這份
臭蟲報告後，妳可以加入更多的細節資訊。接著是一件很重要的事，請盡量把當初跟站方
接洽的訊息附上來。請記住，客戶的抱怨比不知名的Mozilla技術傳教者寄去的電郵有用多
了。如果妳希望站方能夠支援Mozilla妳一定要填寫客戶抱怨！
12.送出臭蟲報告：如果妳不做這個動作，前面的辛苦都白費了！
13.修改剛剛送出的臭蟲報告：如果妳回報的是跟網頁顯示有問題，可以附上screen shot。
夾檔的時候請選擇正確的MIME type。請盡量縮小檔案的大小。妳可以減低color depth，
並且擷取比較小的畫面。只要能夠說明妳的問題就夠了。
如果問題網頁有invalid HTML或JavaScript，請先存檔到妳的硬碟，然後在夾檔的時候
MIME type選擇text/plain。這麼做可以留下一份原始資料，讓我們可以跟後來的版本
（如果有的話）比對。

聯絡網站站方
1.重新檢視臭蟲報告，如果有需要，執行QA流程
2.設法用網站上的資訊找出站方的聯絡人。如果找不到的話，可以試著用Internic的Whois
http://www.internic.com/whois.html來找。
3.寄送Evangelism Letter
請到http://www.mozilla.org/projects/tech-evangelism/site/letters.html挑選，
除了英文，繁體中文，還有其他語言版本。
英文版http://www.mozilla.org/projects/tech-evangelism/site/tech-letter-en.html
中文版http://www.mozilla.org/projects/tech-evangelism/site/tech-letter-zh.html
以這封信件為本，妳可以跟站方描述她們網頁的問題，甚至建議如何修改。
在跟站方溝通的時候，請牢記"禮貌"和"專業"兩個原則。這封信件是從妳個人的電子郵件
帳號寄出的，妳必須替自己的言論負責。
4.紀錄
在臭蟲報告中，註記你已經寄送Evangelism Letter，以及信件中妳加入的自訂項目。
不過不要把整封電郵貼上來。
設定里程碑為初次聯絡後的一個月（至少）。之後你可以按月查詢、追蹤、重新測試這些站
台。
把這個臭蟲報告指派給妳自己，然後標記為ASSIGNED（已指派）。
5.如果Evangelism Letter被退信‧‧‧
在臭蟲報告中註記無法聯絡站方。
可能的話，試著找出其他的聯絡電郵，再重新寄送Evangelism Letter。如果找不到，
在報告中註記，然後把這個bug的里程碑標記為Future。
6.如果站方做出負面回應‧‧‧
在這份臭蟲報告的status whiteboard中標記為non-responsive，然後再出發。我們還有
很多站台可以去聯繫；以後也還可以回頭檢視這個當初拒絕我們的站台。
Quality Assurance（品質管制）
妳必須要先擁有對bug做Confirm的權限，才可以對bug做QA。在執行（此任務）之前，妳必
須對Evangelism程序非常熟悉，並且和下列人士討論過流程：
Zach Lipton(irc: zach), Asa Dotzler (irc: asa) 或者Evangelism社群的其他活躍成員
。
UNCONFIRMED / NEW （待確認 / 新的）
1.在Bugzilla搜尋是否為重複
如果這個站台已經被提報過了，而且還沒進入 VERIFIED 的狀態，那麼就把新的這個標示為 DUPLICATE ，並且輸入它和哪個號碼的bug重複。
如果有任何新的，有關這個站台的資訊，請確認之後，加註在原來的bug的comments。
2.親自瀏覽站台
確認這個站台是否仍然不支援Mozilla。如果站台用Mozilla觀看沒有任何問題，把這個bug標示為 WORKSFORME 。

如果這個bug原本被標示為 UNCONFIRMED（待確認） 而站台的確有問題，請把狀態改為 NEW （新的）來確認這個bug的存在。
3.分析站台

確認原來的bug report各方面敘述是否明確、精準。有需要的話，可以加上另外的註解。

ASSIGNED（已指派）
重新檢視那些已指派，但是里程碑已經過期（上個月）的臭蟲報告
http://bugzilla.mozilla.org/buglist.cgi?bug_status=ASSIGNED&product=Tech%20Evangelism
再連上那個網站，看看問題是否依然存在。多點選幾個該網站的頁面來確認站方已將問題完全修正。
如果這個站的問題依然存在，把狀態設為 REOPENED （重新開啟）。如果用Mozilla瀏覽這個站
已經沒有問題，就可以把狀態設為 FIXED （修復）。

RESOLVED（已解決）
重新檢視已解決的臭蟲報告
http://bugzilla.mozilla.org/buglist.cgi?bug_status=RESOLVED&product=Tech%20Evangelism
如果 RESOLUTION 是 FIXED （已修復）或 WORKS FOR ME （我個人可以瀏覽）

再連上那個網站，看看問題是否依然存在。多點選幾個該網站的頁面來確認站方已將問題完全修正。
如果這個站的問題依然存在，把狀態設為 REOPENED （重新開啟）。如果用Mozilla瀏覽這個站
已經沒有問題，就可以把狀態設為 VERIFIED （已確認）。

如果 RESOLTION 是 DUPLICATE（重複提報）

再連上那個網站，確認被標示為duplicate（重複提報）的臭蟲報告，真的跟原來那份臭蟲報告一樣
，提報了同一個網站。確認重複的臭蟲報告中提到的所有訊息，都包含在原來的臭蟲報告中了。如果
沒有的話，請加在原來的臭蟲報告中。

技術傳教的Bugzilla欄位

各個Bugzilla欄位在Mozilla Site Evangelism的意義

欄位	選項	定義
Product（產品）	Tech Evangelism（技術傳教）	所有技術傳教的臭蟲報告都應該在Bugzilla的Product欄位勾選 Tech Evangelism
Component	Language-based	技術傳教依照語系分成許多 components. 請依照網站使用的語系來選擇最適當的component。
Priority（順位）	P1	重要網站，重要問題 - 請優先處理這一類。 每位component owner有責任維護一份重要網站清單 ，並且把關於這些站台的臭蟲報告用關鍵字evang500標明。
Priority（順位）	P2	重要網站，次要問題 - 可能的話，處理P1臭蟲時一併處理這一類； 尤其當這問題很容易處理的時候。
Priority（順位）	P3	次要網站，重要問題 - 有多餘時間的情況下才處理這些網站。 因為要發揮最大效益，我們必須考量時間成本。但是如果處理這個網站 有助於產生有用的文件，能運用於幫助其他的網站，那麼就算有 更高順位的問題，我們可以讓這個插隊。
Priority（順位）	P4	次要網站，次要問題 - 很不幸地我們現在沒有時間處理這一類。 將來我們必須要來處理它們。
Keywords（關鍵字）	evang500	用 evang500 這個關鍵字來凸顯重要的、要優先並小心處理的網站。 可以查詢各個component的重要網站清單來確定是否要加這個關鍵字。
Severity（嚴重程度）	Major
Severity（嚴重程度）	Normal
Severity（嚴重程度）	Minor
Status（狀態）	UNCONFIRMED（待確認）	社群的新成員還需要時間證明她能夠提交正確、明確的臭蟲報告。因此，當 她提交臭蟲報告時，會標示為 UNCONFIRMED（待確認）。 對這類報告，要按照這份文件提的一些建議來做 QA （品質控管）。
Status（狀態）	NEW（新的）	這一類臭蟲報告有兩個來源，一種是品質控管，確認了原本待確認的報告之後； 一種是Bugzilla系統中權限較高（有自動確認權限）的成員提交的。
Status（狀態）	ASSIGNED（已指派）	只有在你完成了對網站的分析，並且寄出Evangelism Letter給站方之後， 才能把Evangelism bug的狀態改為 Assigned （已指派）。 當妳首次分析一個網站時，除了檢視報告中原本提到的網頁，請多檢視幾個 網頁，找出這個網站整體的問題根源，並且寄出 Evangelism Letter，信中除了原本被點名的URL，再加上之前妳檢視的 那些網頁；針對這些逐頁提出站方可改善事項，以及整體可改善方向。 使用本文稍後提到的Status Whiteboard qualifiers來更新bug，並且 在bug description中註記這個網站的問題的明確描述： using LAYER tags, LAYER API, IE4 only API, Incorrectly Nested Tags,... 請牢記，我們的要求會給站方帶來額外的工作量。一定要注意禮節、專業 、尊重。把別人惹毛是沒有助益的。
Target Milestones（目標里程碑）	Month for follow-ups / Future	使用目標里程碑來決定何時應該追蹤evangelism bug。Tech Evangelism 里程碑目前是以月為單位。Revisit bugs that have been evangelized [status == ASSIGNED]. Do not set a Target Milestone unless you have Accepted and Evangelized the site. 當站方收到兩封Evangelism Letters卻既不回應，也不 改正她們的網頁，那麼把目標里程碑設為FUTURE.
Resolution（判定）	WORKSFORME（我可以正常瀏覽）	當妳無法用自己的電腦重現這個問題的時候，判定為此類別。
Resolution（判定）	DUPLICATE（重複）	這個網站有類似問題已經被人提報過了。
Resolution（判定）	FIXED（修復）	站方已將問題修復
Resolution（判定）	WONTFIX	在Bugzilla的技術傳教類別裡，請不要使用WONTFIX。 那些告訴我們，她們不打算修改她們的網頁的站方，請在status whiteboard 裡面，標記為not-responsive（不願處理）
Resolution（判定）	INVALID（沒有根據的）	一般來說，在Bugzilla的技術傳教類別裡，不要使用INVALID。 不過component owner有自行決斷的自由，將某些bug判定為INVALID。
Summary（摘要）	網域 - 從使用者角度，簡短明確敘述網站的問題。	在填寫摘要的時候請使用底下的格式： 例如，如果 http://mail.netscape.com/ 的問題在於JavaScript 使用到Layer，那麼摘要可以寫成： netscape.com - mail 使用 document.layers
Status Whiteboard（狀態白板）	not-responsive（不願處理）	在狀態白板中用 not-responsive 來標明那些表明不願處理的站方。
Status Whiteboard（狀態白板）	technote-needed（需要技術文件）	如果一個問題普遍到應該寫份教學文件，將這個問題在狀態白板標記為 technote-needed。等到有人寫出這份教學文件之後， 再移除technote-needed的標記。
Status Whiteboard（狀態白板）	plugin（外掛模組）	在狀態白板使用plugin來標記那些跟外掛模組有關的問題， 後續需要聯絡或協助該廠商處理。
Status Whiteboard（狀態白板）	author（作者）	如果問題需要聯絡／協助網頁製作工具的開發廠商／程式撰寫者， 在狀態白板使用author來標記。

有用鏈結：
Dive Into Accessibility - 在 30 天內打造更具親和力的網站
http://dia.z6i.org/
->一邊看故事，一邊學習。
網絡標準轉換(或怎樣輕易地改進您的網站)
http://www.w3.org/QA/2003/03/web-kit.html.zh-hk
->概念性的文件
無障礙全球資訊網建置準則1.0版教學課程
http://www2.csj.ks.edu.tw/~tch023/accessibility/index.html
->教學課程囉
行政院研考會的"無障礙網路空間服務網"
http://enable.nat.gov.tw/
->政府也不是完全沒注意到這個題目啦。"無障礙"其實比我談的更廣,還考慮了視障聽障等等的朋友。

Posted by ystuan at September 22, 2004 01:35 AM