2012 年 03 月 22 日 3:28 
網站開發人員每天需要周旋於 PHP (或其他伺服器端編程語言)、SQL、JavaScript、HTML、CSS、數據庫預存程序及一些不同用途的開發架構之間，總會有「執筆忘字」的時候，這時你可能會向 Google 或編程書籍求教。不過，網上不少好心人替我們便製了一些「速記片」(cheat sheet)，方便我們隨時查閱，Anson Cheung 在他的網誌蒐羅了 20 張網站開發人員必備的速記片。 繼續閱讀 »
| ||||
 人人都知道上網的人對於網站的速度耐性有限，所以你的網站的效能和顯示速度，是網站的可用性，甚至成功與否的關鍵。Jacob Gube 在他的網誌分享了 20 個線上測試網站速度的工具，可以用來測試網站的速度，和找出哪裡是效能的瓶頸，他建議你同時運用其中數個工具 (沒有一個工具具備所有功能)，作為恆常性的測試手段。 繼續閱讀 » 對優化網頁效能有研究的人都知道，首要的任務是盡量減少 HTTP 請求 (http request) 的次數，例如把多個 JavaScript 檔案合併，把多個 CSS 檔案合併，利用 CSS 精靈和合併的小圖示等等，但是很多人都不知道還有一個 data URL 的密技，讓我們直接把圖像的內容崁入網頁裡面，這個密技的官方名稱是 data URI scheme。 甚麼是 favicon？ Favicon 是 favorite icon 的簡稱，幾乎所有專業網站都有 favicon，它是一個由不同解像度的圖標結合成的檔案，例如它可能結合了一個 16×16 和一個 32×32 的 .bmp 檔案於一身，Favicon 的檔案延伸名稱是 .ico。在大部分的瀏覽器，這個圖標會在網址旁邊或者在書籤頁裡面顯示。通常 favicon 反映了該網站的設計或者有關機構的商標。 甚麼是 .ico 檔案？ Favicon 是一個由不同解像度的圖標結合成的檔案，內含的圖標有些是 16×16，有些是 32×32，有些只有 16 種顏色，有些有 256 種顏色，瀏覽器或其他使用 favicon 的系統會根據當前的需要，選擇最適合的解像度和顏色數量的版本來顯示，倘若沒有完全吻合要求的版本，它們可能要把圖表拉大、縮小、降低顏色的數量等等，這 些操作可能會使圖標的素質變得不理想。
這款字體最理想是大小是 9 或 10 points，並使用激光打印機列印。Sprang 說儘管把它用在正式的文件中可能略嫌不夠清晰，但它頗適合用在辦公室內的備忘錄、員工手冊、內部文件、以及個人用途。 這款字體是以開放原碼許可證在網上免費提供，並鼓勵外部人員參予開發，現時阿拉伯文和希伯來文版本的 EcoFont 正在以相同的節約油墨原則開發中。 最近幾天接二連三有知名網站遭黑客入侵，包括討論區系統 phpBB 的官方網站（phpBB 仍然是安全的，漏洞出在網站上另一個應用系統）及網上書籤網站 Ma.gnolia，網站被入侵已經不是新聞，很多被入侵的系統內的用戶資料被盜取，例如網上求職者網站 Monster.com 上星期被入侵後，數以十萬計的求職者個人資料被盜；有些網站的資料被抹去而無法復原，例如 Ma.gnolia 便承認他們無法復原用戶的書籤，唯有透過網上其他資源盡力恢復用戶的公開資料，其中包括 Google 搜尋器的緩存影像。數據丟失固然嚴重，對網站聲譽和用戶信心的打擊更是無法彌補。 我們在設計用戶介面時經常會遇到一些細小、對易用程度未必有很大影響的問題，其中一個就是對話框中的按鈕次序：應該「確定／取消」還是「取消／確定」？用戶介面專家 Jakob Nielsen 分析了這個問題，他的建議是：跟隨平台的一般做法，比優化介面更重要。 Jakob Nielsen 認為兩者都是合理的選擇，兩者都有支持者： 「確定」先行符合語文的自然閱讀方向，中文、英文和很多語言都是從左到右閱讀，很多按鈕組合例如「是／否」、「前一頁／下一頁」都是按一個從左到右 的自然進程，所以我們應該按照閱讀的邏輯順序排列成「確定／取消」。此外，假設用戶選擇「確定」的機率比「取消」高，把「確定」放在前面可以讓那些主要用 鍵盤瀏覽的用戶少按一下 TAB 鍵便到達他們的首選按鈕。 把「確定」放在後面可以改善流程，因為這是對話框的自然結束。此外，正如「前一頁／下一頁」的情況，「確定」是讓用戶繼續下一步，「取消」是退回一步，所以「確定」應該放在「下一頁」同一個位置，即是在右邊。 網頁的導航菜單 (navigation menu) 的設計有甚麼要訣？有名的網頁介面顧問 Jakob Nielsen 的研究發現，文字靠右對齊的菜單令用戶讀起來更容易，除此以外，他還有幾項有關導航菜單的設計指引，見解獨到精闢，值得我們參考。 Jakob 表示，從「眼睛追蹤」的研究知道，用戶的眼睛往往迅速地沿著菜單的左手邊向下移動，只有當最左邊的一個或兩個字詞吸引了他們的注意，他們才會閱讀菜單項目的其餘部分。 因此，我們有以下的菜單設計指引，這至少對於垂直設計的菜單是有效的： 菜單項目應該靠左對齊，使用戶的眼睛可以沿著一條直線移動，無須在每一個項目尋找新的起始點。 每一個菜單項目都由包含最多訊息的一個或兩個字詞開始。 避免使用相同的幾個字詞作為菜單項目的開頭，因為這樣做使它們更難被掃瞄。 Yahoo! 的首席網站優化工程師 Steve Souders 從去年三月至九月發表了一系列優化網站的 14 項原則性建議，他和他的團隊研究後發現，下載一頁網頁的時間，80% 是花在瀏覽器的工作上，這些工作其實可以透過簡單的優化來刪除掉，從而大幅提高網站的效率，我們不妨看一看這位專家給我什麼建議。 儘量減少發出 HTTP 請求：網頁上各式各樣的 JavaScript、CSS、圖像、Flash 等佔去了瀏覽器大部分的工作，所以減少網頁中需要下載的元件，從而減少發出 HTTP 請求，是優化網站的最重要一步。方法是合拼多個 JavaScript 和 CSS 檔案，利用「CSS 精靈」技術等。 把內容分散到不同的伺服器：把所有內容從一個伺服器送出，顯然會做成瓶頸效應，既加重伺服器的負擔，也增加伺服 器周邊網絡的負擔，對於大型的網站最理想的作法是在世界各地設立區域性的伺服器，減少網絡擠塞現象，至於較小型的公司則可以光顧商業性的「內容傳送網絡」 服務供應商。更小型甚至個人網站又如何呢？可以嘗試把靜態的內容分離出來，從應用伺服器移到另一台伺服器。 每一項內容都註明到期日期：為了避免訪客經常重複下載網站內不常改動的內容，我們應該為每一項內容註明到期日期，瀏覽器會把未過期的內容放在緩存區，節省了不必要的 HTTP 請求。圖像是最值得使用這個技巧的內容，不過其他內容包括 JavaScript、CSS、Flash 等在可能的情況下也應該盡量使用。 繼續閱讀 » 曾經管理網站，特別是論壇、網誌之類容許訪客寫文章的網站，一定見識過濫發文章／濫發電郵的威力，所以很多網站管理員都會安裝／啟動一個稱為 Captcha 的驗證系統，當訪客貼文章的時候，要從一個圖像中辨認出其中的文字然後連同文章一拼呈交，這些圖像都是隨機產生、充滿訊燥、字體故意被扭曲的圖像，只有人 類才有能力正確辨識，這樣便可以杜絕網絡上的壞蛋使用機器人大量貼出文章。 Captcha 是一個很成功的技術，很多內容管理系統都內建了 Captcha，或者透過安裝附加模塊來實現 Captcha，根據統計，互聯網上每天有六千萬個 Captcha 被解答，每一個花大約十秒鐘，十秒鐘對一個人來說不算得什麼，但六千萬個十秒鐘加起來便很可觀了，我們可以善加利用這龐大的腦力資源嗎？ reCaptcha 正好解答這個問題，它除了有助杜絕濫發文章，也藉著人類「閱讀」圖像的能力把掃描的文字數碼化。 Jakob Nielsen 有一篇文章討論下拉選單作為用戶介面應注意的地方，文章寫於 2000 年，最近他針對滾輪滑鼠對下拉選單使用性的影響，補強了這一篇文章，對用戶介面有興趣的朋友，這是一篇不可多得的好文。 Jakob Nielsen 認同下拉選單是網頁設計中一個很有用的工具，可是由於設計人員對它的濫用和誤用，它有限的互動性經常引起使用性的問題，有時甚至對用戶做成混亂。以下是下拉選單經常出現的地方： 命令菜單──執行用戶所選的命令 導航菜單──帶領用戶到其他頁面 填寫表格──填寫表格時從多個選項中選擇一項 選擇特性──在一個包含多個選項的菜單中選擇一項 Mark W. Lewis 在 Painter Creativity 發表十個年輕天真的設計師最經常聽到的謊言，看來還真有點依據！ 「這次你平宜一點（或者免費）替我們工作，下次一定補償給你。」 「在見到最後的作品前我們分文不付。」 「幫我們工作的話你會得到很大的暴光率，工作便會陸續找上門。」 Jack Pickard 在 Accessites.org 發表了一篇文章，建議大家以後在 HTML 中放棄使用 Transitional DOCTYPES。 HTML 的第一行是用來表示所使用的 HTML 版本，使用 Strict DTD 表示檔案中沒有「不建議使用」的 element 和 attribute，使用 Transitional DTD 表示裡面含有這些 element 或 attribute。對於一直有人倡議推廣 Strict DTD，部分人的回應是：「這是我的網站，我喜歡怎樣便怎樣。」 Jack 告訴我們不再使用 Transitional DTD 的理由： 首先，W3C 的 Transitional DOCTYPE 中是如此建議的。你或者沒有閱讀過這份官方文件（恐怕世上沒有多少人真的讀過 DOCTYPE 文件），但可以告訴你，Transitional DOCTYPE 正是建議我們儘可能不要使用 Transitional DTD，應該使用 Strict DTD。 此外，Strict DTD 把內容和表達明確分開。以下是 Strict DOCTYPE 禁止使用的 element： basefont font center applet dir 及 menu isindex s 及 strike u 透過其他 element 或者使用 CSS 都可以達到以上elements 的效果，至於被禁止的 attribute 例如 align、bgcolor、border、clear 等，亦可以透過 CSS 來達到，既然我們可以用 Strict DTD 來達到 Transitional DTD 的效果，同時又可以把內容和表達分開，為何還需要 Transitional DTD？ 網上有很多圖像處理、相簿管理的網上應用系統，容許我們把大圖像裁剪為較小的圖像，但是用戶必須輸入裁剪框的座標和大小，對一般人來說顯然十分困 難，Dave Dash 在 Spindrop 發表了一篇教學文件，指導我們怎樣利用 DHTML（JavaScript + CSS + HTML）來製作一個靈活易用的圖像裁剪介面。 在學習前不防先看看 Dave 的示範。
Dave 這個示範的靈感其實來自蘋果電腦中地址簿的一項功能，Dave 認為這是他見過最簡潔易用的圖像裁剪介面，所以利用它作為設計藍本製做了這個 DHTML 教學文件。這個示範用 PHP 在 Symfony（一個 PHP 開發架構）上開發，不過你們即使沒有安裝 Symfony 也一樣可以學習其中的技巧，唯一必需的是 PHP。 這個介面把收集到的座標送回伺服器，然後利用 GD 函式庫進行真正的裁剪工作，這部份工作 Dave 也做了詳細解釋，並且列出了全部原始碼。 在網站設計者的社區，Flash 一直是一個很具爭議性的話題，有些人認為 Flash 補充了 HTML 在互動方面的不足，使網頁更生動，提高了上網的趣味，但是有些人卻認為 Flash 屬於可有可無的花招，在某些情況下它反而成為使用者的障礙。 Peter Seebach 在 IBM developerWorks 上發表了他對網頁上使用 Flash 的意見，Peter 在肯定 Flash 的價值之餘，也指出在大多數的情況下 Flash 都被用在不恰當的場合，他還提供了一些使用 Flash 的大原則給讀者參考。 Peter 首先指出，Flash 是否在所有平台都得到良好的支援？儘管不同的調查有不同的結果，但無可否認 Flash 在各個平台的支援和接受程度都很高，主要的瀏覽器都可以觀賞 Flash 的動畫，我們的問題不再是用戶是否可以瀏覽 Flash 的網頁，而是我們為甚麼非要用戶使用 Flash 看動畫不可？真的有這個需要嗎？ Flash 的濫觴 Peter 說有太多設計師認為使用 JavaScript 和 Flash 堆砌出來的動態網頁才算是生動和互動，可惜大部分情況係都不是如此。 首先絕大部分的用戶都已經習慣了網頁的連結是一個藍色有底線的文字，探訪過的連結則會變成紫色，總之連結都是有底線的，新的和探訪過的連結可以用顏色來區分，偶然使用 image map 是可接受的，雖然有時它帶給某些用戶一些困惑。 當這些聯結用動畫的形式表達出來，情況便變得很有「挑戰性」，用戶們突然間找不到他們那些習慣了的知名而可靠視覺提示，他們需要花時間和精力來理解 眼前的網頁究竟如何運作，雖然有時這是有趣的，但通常功能性都不大，尤其是當用戶發覺他必須把滑鼠移到指定的區域才能看到他尋找已久的關鍵詞，情況特別使 人煩惱。 Peter 繼續指出，網頁設計上加入太多的創意未必是好事，網上的用戶不會只瀏覽你的網頁，所以可靠而一致的用戶介面是十分重要的。而且，即使你的設計真的比傳統的 方法優勝，若果它的使用方法與其他網頁差別太大，到頭來用戶仍是覺得它混亂而難於使用，何況，你的設計未必真的比人家的好。 Flash 是可有可無的嗎？ Peter 認為純粹為了炫燿而加插的 Flash 動畫，都是不美觀、難於接受和不明智的，一個用戶來到一個產品的網頁，發覺需要另外一些技術才能看到有關的資料，一定會感到很沮喪，這時即使這件插件很容易安裝，他也不會願意多走一步安裝這個插件。 很多網站設計者總是以為他們是網上很有代表性的一群，他們擁有高速的網絡，最新版本的軟件和插件，於是很容易為他們的網頁定下過高的要求，其實他們應該在一些舊版本和較不普遍的瀏覽器，尤其是一些沒有安裝任何插件的瀏覽器上測試他們的網頁，然後才決定怎樣設計。 除了舊版本的瀏覽器外，他們也應該在設計時考慮到流動電話和手帳上的瀏覽器。另一個設計者經常忽略的東西就是搜尋器優化，搜尋器不會把圖像中的文字編制索引，若果你希望別人在搜尋器上找到你的網頁，最好還是使用搜尋器看得懂的文字。 聰明的設計者會把網頁設計成即使 Flash 無法運作也不會妨礙瀏覽，重要的資料都用率直簡樸的文字表達。 設計得好的網頁會使用動畫和動態的內容來吸引訪客，而不是把訪客驅走，互動的元素應該把瀏覽的過程簡化而不是複雜化，但不論任何一種互動技術都不能 代替簡樸的文字內容。不論你使用任何互動技術，千萬不要在插件上有太多要求，我們可以假設大部分的訪客都可以觀看 Flash 的內容，但是那一小部分看不到 Flash 的用戶怎麼辦呢？世界上沒有一個老闆會聘請一個人站在店舖的門口每一百個客人便驅走一兩個，為何網站設計師要這樣做呢？ Jakob Nielsen 是網上知名的網頁設計權威，他主持的 useit.com 被視為其中一個對網站／網頁設計理念影響最大的網站，這個網站在 Google 的頁面排名更是同類網站的表表者，網站內有關網頁設計的文章，全世界的網站開發者都視為金科玉律。 我偶然翻閱了 Jakob 在 2002 年寫的一篇文章「把文字大小的控制權還給用戶吧」，雖然是四年前的作品，裡面對瀏覽器的描述可能已經過時，但是對設計師有關網頁字體的忠告，卻歷久彌新。 Jakob 在文章的開始這樣說： 有時科技的進步會產生反效果，「比較好」的科技到頭來反而害苦了用戶，網際網絡也有這種情況，不少新點子例如頁框、改變捲棒的顏色、捲動文字等，到頭來最好還是不要使用。 另一個被視為有害的網頁技術，就是 style sheet 中讓網頁設計人員以象素的精確度來定義文字大小的技術，這種技術令越來越多網站的可閱讀性變得越來越低。 是甚麼令到網站的可閱讀性降低呢？Jakob 說在大部分的情況下都是因為文字太小了，但是為甚麼這種現象那麼普遍呢？對此 Jakob 有兩個解釋： 網頁設計師大多是年輕人，擁有較好的視力，他們對細小文字的容忍力比那些 40 歲以上的用戶高。加上網頁設計師大多擁有昂貴而高性能的顯示器，這些都能舒緩眼睛的不適。 設計師在編寫網頁的時候大多不會 閱讀 網頁的內容，他們大都只是促略瞄一下，確保頁面上的文字看來不錯，事實上有些設計師只是以一段重複使用的無意義文字來測試字體、字型、排版等效果，既然他們根本沒有閱讀那些文字，文字的大小對他們自然無關痛癢。 我認為 Jokob 遺漏了一個很重要的因素：絕大部分的網站開發人員和站長都沒有受過設計訓練，他們純粹靠個人的直觀和使用習慣來設計頁面。 不同的用戶對文字大小有不同的要求，為了提高網頁的可閱讀性，Jakob 給予開發人員六點忠告： 不要使用絕對值來定義文字的大小：在 style sheet 中使用相對的數值，例如較大的字體使用 120%，較小的字體使用 90%。 預設的文字大小必須足夠大：最小 10pt，這樣只有很少用戶需要在瀏覽器調整文字大小。 以長者為主要對象的網站字體應該加大：最小 12pt。 在可能的情況下不要在圖像內加入文字：因為 style sheet 和瀏覽器都不能改變圖像內的文字大小，若果非在圖像內加入文字不可，必須確保文字足夠大（最小 12pt），而且要使用高反差的顏色。 不妨加入一個讓用戶更改 style sheet 的按鈕：若果你的訪客大部分是長者或弱視人士，這張替換的 style sheet 可以用來顯示特大的字體。有很多用戶根本不知道怎樣在瀏覽器上更改文字的大小，這一個按鈕正好方便他們。 儘量增大顏色的反差：文字和底色的顏色反差應該儘量增大，不要在背景使用水印的效果，儘管很多人都知道低反差的顏色增加閱讀的困難，但卻越來越多網站使用灰色的字體。 在現今的瀏覽器和網頁技術比 2002 年有了長足的進步，當年只有 IE 和 Netscape，現在有了 Firefox，Opera 和 Safari 也開始為人所認識，W3C 的技術規範也越來越受到重視。總之，這四年來網站的設計概念和技術都有不少改變，你對 Jakob 當年的建議有甚麼意見？ 在 IBM developWork 有一連兩篇的文章介紹如何編寫動態網頁，內文舉出了幾個常見的例子，包含詳細的說明和原始碼，對於希望令自己編寫的網頁有更多互動效果、更多姿多采，卻對於 JavaScript、CSS 等不甚了了的人來說，這是一份不錯的教學文件。 這份文件介紹以下六種動態網頁效果：矩形彈出視窗、tooltip、隱形／顯示段落、分頁、統計圖表等。 矩形彈出視窗
tooltip
隱藏／顯示段落
分頁
統計圖表
網站的開發人員，特別是商業網站，對於如何針對搜尋引擎進行優化，使自己的網頁能夠在搜尋的結果中排得較為前列的位置，都進行過不少研究，也有無數 針對「搜尋引擎優化（Search Engine Optimization, SEO）」的文章發表過，指導大家如何令搜尋引擎重視自己的網頁。 不過一直以來似乎還沒有人研究過搜尋引擎是否保證把頁面上所有文字編列索引？曾經有人懷疑，搜尋引擎視太短的頁面為沒有實質內容而予以忽略，但是太 長的頁面則只會截取一部份編列索引，其餘的部分會是為內容重複和關鍵字重疊而予以忽略。即是說頁面太短固然不行，根本進入不了搜尋器的數據庫，太長則屬浪 費，若果你有一些很精闢的關鍵字在頁面的後半部才出現，即使有用戶用這個關鍵字進行搜索也不會找到你的頁面。 Serge Bondar 針對這個問題進行了一個實驗，目的就是要解答： 各大搜尋引擎讀入多長的頁面來編列索引？ 實驗設定 Bondar 預備了 25 個檔案，容量從 45KB 到 4151KB，在這些檔案中每隔 10KB 的距離插入一個全宇宙獨一無二的關鍵字，這些獨一無二的關鍵字用程序生成，Bondar 稱之為索引深度標籤，完成後他便把這 25 個檔案放上網頁，隔了一段時間後使用三大引擎：Yahoo!、Google、MSN 搜索這些索引深度標籤。 實驗結果 Yahoo! 編列索引的深度：
Google 編列索引的深度：
MSN 編列索引的深度：
分析 三大搜尋引擎果然對頁面的長度設有上限，超越上限的部分任何文字都不會被編索引，這個上限大概是： 搜尋引擎 頁面的長度上限 Yahoo! 210KB Google 520KB MSN 1020KB 對於長度比這些上限短的頁面，當然可以讓它們快樂地活下去，但是過長的頁面是否需要截短呢？Bondar 相信多出來的部分不會拖低整個頁面的評價（Page Ranking），若果有編排和表達方式上的需要，這些頁面亦無需蓄意修改。 Dean Edwards 研究 document.onload 的缺點與及解決方法已經一段時間，現在他終於提出了一個跨瀏覽器而又簡潔的終極解決方案。 事情的原委是這樣的：很多開發人員使用 document.onload 來啟動 JavaScript 進行一些網頁效果的初始化工作，例如動畫菜單、Ajax 應用程式等，但是 document.onload 只有當網頁的所有內容，包括圖像、JavaScript、動畫、影音檔等全部下載後才會被觸發，倘若這些檔案容量很大，或者儲存在一個不受你操控的伺服器 上，網頁上的效果很可能被延遲啟動，甚至完全不能啟動。 這就是 Dean Edwards 希望解決的問題。 他早在 2005 年 9 月已經基本上找到了 Mozilla 和 IE6 上的解決方法，Mozilla 的解決方法是使用一個即使在 Mozilla 網站亦沒有詳細解說的 DOMContentLoaded 事件，IE6 則需要使用兩個 Miscrosoft 的自訂規格 defer 和 conditional comment，可惜這個方案有兩個缺點： 在 IE6 它必須使用外部 JavaScript 檔 它沒有解決 Opera 和 Safari 的問題 現在 Dean Edwards 終於為 Opera 和 Safari 找到了解決方案，而且在 IE6 也有了無需使用外部 JavaScript 檔的方法，所有問題正式畫上句號。 「很多機構的網頁都有太多令人煩擾的東西，而且可用性很低，這等於給競爭對手讓路。」InfoWorld 一篇有關網頁設計的文章這樣說。 這篇文章引述顧問服務公司 iFocu 的高級可用性顧問 Theresa Cunnington 的話，用戶瀏覽網頁時一般的耐性都很低，Cunnington 說：「不論你的網頁設計得有多炫目，只要用戶認為沒有用，他們就會轉向你的競爭對手，而這只不過是用滑鼠按一下那麼簡單。」 Cunnington 說 Flash 就是一個經典的例子，設計師總是愛用 Flash 來炫耀他們什麼可以做，而不是做他們應該做的事。 iFocus 列出幾項用戶最討厭的網頁花招： 入侵性的廣告：用戶最討厭那些遮擋網頁內容、瘋狂閃動、及吞食網絡頻寬的廣告。 重新發明車輪：用戶不喜歡在使用一個網站之前，必需閱讀一大堆說明文件指示他們如何瀏覽。 分散注意的東西：用戶特別討厭那些閃動的橫額、圖示等會分散注意力的東西，因為這些東西會吸引眼睛離開重要的內容，從而阻礙閱讀進度。 長篇大論的文章：一個常犯的錯誤是把宣傳手冊裡面的內容「傾倒」到網頁上，作為一個不同的媒體，網頁應該有它獨特的表達方式，例如一般人閱讀網頁的速度比閱讀紙張慢 25%，而且選擇更少的內容來閱讀，不喜歡長篇大論的文章，也不喜歡需要向下捲動的頁面。 | ||||
Copyright © 2012 香港網頁開發網誌 - All Rights Reserved | ||||
