支援多種裝置的內容

為各種使用者和裝置建構應用程式時,請同時考量內容、版面配置和圖像設計。

使用者在網路上閱讀內容的方式

美國政府撰寫指南摘要說明瞭使用者對網路內容的期望:

研究顯示,使用者不會閱讀網頁,而是瀏覽。平均而言,使用者只會閱讀 20% 至 28% 的網頁內容。從螢幕上閱讀的速度遠比從紙上閱讀慢。如果資訊難以存取和理解,使用者就會放棄並離開網站。

如何撰寫適合行動裝置的內容

請專注於當下主題,並在開頭就說明故事。為確保內容在各種裝置和可視區域都能正常顯示,請務必在開頭點出重點:一般來說,最好在開頭四段中,以約 70 字呈現。

請思考使用者想在你的網站上獲得什麼。他們是否想找出什麼?如果使用者是為了取得資訊而造訪您的網站,請確保所有文字內容都能協助他們達成目標。使用主動語氣撰寫,並提供行動和解決方案。

只發布訪客想看的內容,不要發布其他內容。

英國政府研究也顯示:

換句話說,即使是針對有讀寫能力且具備技術知識的對象,也請使用平實的語言、簡短的字詞和簡單的句子結構。除非有充分理由,否則請盡量使用對話語氣。新聞業有一項舊規則,就是撰寫時要想像自己正在與聰明的 11 歲兒童對話。

下十億使用者

簡潔的寫作方式對行動裝置讀者來說尤其重要,如果內容是針對螢幕較小、需要捲動更多內容、螢幕品質較差且觸控反應較慢的低價手機,就更需要簡潔的寫作方式。

接下來上網的十億使用者大多會使用平價裝置。他們不希望花費資料預算瀏覽冗長的內容,而且可能不是以母語閱讀。精簡文字:使用簡短句子、盡量減少標點符號、段落最多五行,以及單行標題。建議使用回應式文字 (例如針對較小的可視區域使用較短的標題),但請留意缺點

文字越簡潔,內容就越容易本地化和國際化,也越有可能在社群媒體上被引用。

簡而言之:

  • 保持簡單
  • 減少雜亂
  • 切中要點

刪除不必要的內容

就位元組大小而言,網頁很大,而且越來越大

回應式設計技術可針對較小的檢視區塊提供不同內容,但一開始先簡化文字、圖片和其他內容,始終是明智之舉。

網路使用者通常會採取行動,積極尋找當前問題的解答,而不是放鬆心情閱讀好書。

Jakob Nielsen

請自問:使用者瀏覽我的網站時,想達成什麼目標?

每個網頁元件是否都能協助使用者達成目標?

移除多餘的網頁元素

根據 HTTP 封存檔,平均每個網頁的 HTML 檔案約有 7 萬個,要求超過 9 個。

許多熱門網站的每個網頁都使用數千個 HTML 元素和數千行程式碼,即使是行動版網頁也不例外。HTML 檔案過大可能不會導致網頁載入速度變慢,但 HTML 酬載過大可能表示內容過於龐大:.html 檔案越大,表示元素越多、文字內容越多,或兩者皆是。

降低 HTML 複雜度也能減少網頁大小、啟用本地化和國際化功能,並簡化回應式設計的規劃和偵錯作業。如要瞭解如何編寫更有效率的 HTML,請參閱「高效能 HTML」。

使用者在從應用程式獲得價值前執行的每個步驟,都會導致 20% 的使用者流失

Gabor Cselle,Twitter

內容也是如此,請盡可能協助使用者快速找到所需資訊。

請勿只對行動裝置使用者隱藏內容,請盡量提供相同內容,因為您無法準確判斷行動版使用者不會錯過哪些功能。如果資源充足,請為不同可視區域大小建立相同內容的替代版本,即使只針對優先順序高的網頁元素也無妨。

考量內容管理和工作流程:舊版系統是否會產生舊版內容?

簡化文字

隨著網路行動化,您必須改變寫作方式。簡潔明瞭,減少雜亂,直指重點。

移除多餘圖片

HTTP Archive 顯示圖片傳輸大小和圖片要求數量不斷增加
根據 HTTP 封存資料,平均每個網頁會發出 54 個圖片要求。

圖片可以美觀、有趣且提供資訊,但也會佔用網頁空間、增加網頁權重,以及增加檔案要求數量。連線品質越差,延遲情形就越嚴重,這表示隨著網路行動化,圖片檔案要求過多會造成的問題也日益嚴重。

HTTP 封存圓餅圖,顯示各內容類型的平均網頁位元組數,其中約 60% 是圖片。
圖片占網頁權重超過 60%。

圖片也會消耗電量。螢幕是手機最耗電的元件,其次是無線電。圖片要求越多、無線電使用量越大,電池就越容易沒電。光是算繪圖片就需要耗電,而且耗電量與圖片大小和數量成正比。請參閱史丹佛大學的報告「Who Killed My Battery?」(誰耗盡我的電池電量?)。

如果可以,請移除圖片!

請參考以下建議:

  • 建議採用完全不使用圖片的設計,或僅使用少量圖片。純文字也能很美!請自問:「網站訪客想達成什麼目標?圖片是否能協助完成這項程序?
  • 過去,儲存標題和其他文字時,通常會以圖片形式儲存。這種做法無法因應可視區域大小變化,還會增加網頁大小和延遲時間。如果使用文字做為圖片,搜尋引擎就無法找到文字,螢幕閱讀器和其他輔助技術也無法存取文字。盡可能使用「實際」文字,網站字型和 CSS 可啟用美觀的排版。
  • 使用 CSS 而非圖片來製作漸層、陰影、圓角和背景紋理,這些功能所有新式瀏覽器都支援。不過請注意,CSS 可能比圖片好,但仍可能造成處理和算繪負擔,尤其是在行動裝置上。
  • 背景圖片在行動裝置上很少能正常運作。您可以使用媒體查詢,避免在小型檢視區塊顯示背景圖片。
  • 請勿使用啟動畫面圖片。
  • 使用 CSS 製作 UI 動畫
  • 認識字形;使用 Unicode 符號和圖示 (而非圖片),必要時使用網路字型。
  • 建議使用圖示字型,這類字型是可無限縮放的向量圖形,而且只要下載一個字型,就能取得整組圖片。(但請注意這些疑慮)。
  • <canvas> 元素可用於在 JavaScript 中,從線條、曲線、文字和其他圖片建構圖片。
  • 內嵌 SVG 或資料 URI 圖片不會減少網頁權重,但可以減少資源要求數量,進而縮短延遲時間。內嵌 SVG 在行動版和電腦版瀏覽器上都獲得廣泛支援,且最佳化工具可大幅縮減 SVG 大小。同樣地,系統完全支援資料 URI。兩者都可內嵌在 CSS 中。
  • 建議改用 <video>,而非 GIF 動畫。行動裝置上的所有瀏覽器都支援影片元素 (Opera Mini 除外)。

詳情請參閱「圖片最佳化」和「移除及替換圖片」。

設計內容,確保在不同可視區域大小都能正常運作

「打造產品,而非為小螢幕重新構思產品。優質的行動產品是從無到有,而非移植而來。」

行動設計與開發,Brian Fling

優秀的設計師不會「針對行動裝置進行最佳化」,而是以回應式設計為考量,建構適用於各種裝置的網站。文字和其他網頁內容的結構,是跨裝置成功的關鍵。

接下來上網的十億使用者中,有許多人會使用螢幕較小的低價裝置。在 3.5 吋或 4 吋的低解析度螢幕上閱讀內容可能很吃力。

以下是兩人合照:

相片:比較高階和低價智慧型手機上顯示的網誌文章

在大螢幕上,文字會縮小但仍可閱讀。

在較小的螢幕上,瀏覽器會正確算繪版面配置,但即使放大,文字仍難以閱讀。螢幕顯示模糊不清,且有「色偏」問題 (白色看起來不像白色),導致內容難以辨識。

設計行動版內容

為一系列的可視區域建構時,請考慮內容、版面配置和圖像設計,使用實際文字和圖片設計,而非預留位置內容

「內容先於設計。沒有內容的設計不是設計,只是裝飾。」

Jeffrey Zeldman
  • 將最重要的內容放在最上方,因為使用者通常會以 F 形模式閱讀網頁
  • 使用者造訪您的網站是為了達成目標,請思考他們需要哪些資訊才能達成目標,並刪除其他內容。嚴格審查視覺和文字裝飾、舊內容、過多連結和其他雜亂元素。
  • 請謹慎使用社群媒體分享圖示,因為這可能會使版面配置雜亂,且相關程式碼可能會拖慢網頁載入速度。
  • 為內容設計回應式版面配置,而非固定裝置大小。

測試內容

  • 使用 Chrome 開發人員工具和其他模擬工具,在較小的檢視區塊中檢查可讀性。
  • 在低頻寬和高延遲的條件下測試內容;在各種連線情境中試用內容。
  • 嘗試在低價手機上閱讀內容並與之互動。
  • 請親友和同事試用您的應用程式或網站。
  • 建立簡單的裝置測試實驗室。Google Mini Mobile Device Lab 的 GitHub 存放區提供自建裝置的說明。OpenSTF 是一個簡單的網頁應用程式,可供您在多部 Android 裝置上測試網站。

以下是 OpenSTF 的實際運作情況:

OpenSTF 介面。

行動裝置不僅是通訊、遊戲和媒體裝置,也越來越常被用來消費內容和取得資訊。

因此,規劃內容時,請務必確保內容在各種檢視區塊中都能正常運作,並在考慮跨裝置版面配置、介面和互動設計時,優先處理內容。

瞭解資料費用

網頁越來越大。

根據 HTTP 封存資料,前一百萬個網站的平均網頁權重已超過 2 MB。

使用者會避開速度緩慢或費用高昂的網站或應用程式,因此瞭解網頁和應用程式元件的載入成本至關重要。

減少網頁大小也能帶來利潤。YouTube 的 Chris Zacharias 發現,將觀看頁面大小從 1.2 MB 縮減至 250 KB 後,出現了以下情況:

換句話說,減少網頁權重可開拓全新的市場

計算網頁權重

計算網頁權重的工具有很多。Chrome 開發人員工具的「網路」面板會顯示所有資源的總位元組大小,可用於判斷個別資產類型的權重。你也可以查看從瀏覽器快取擷取的項目。

Chrome 開發人員工具的「網路」面板,顯示資源大小。

Firefox 和其他瀏覽器也提供類似工具。

WebPagetest 可測試網頁的首次和後續載入情形。您可以使用指令碼 (例如登入網站) 或 RESTful API,自動執行測試。以下範例 (載入 developers.google.com/web) 顯示快取成功,後續網頁載入不需要額外資源。

WebPagetest 也會依 MIME 類型提供大小和要求細目。

WebPagetest 圓餅圖,顯示依 MIME 類型分類的要求和位元組

計算網頁費用

對許多使用者而言,資料不僅會耗用位元組和效能,還會耗用金錢。

您可以使用「我的網站費用是多少?」網站,估算載入網站的實際財務成本。下方的直方圖顯示載入 amazon.com 的費用 (使用預付型數據方案)。

載入 amazon.com 首頁的預估資料費用 (12 個國家/地區)。

請注意,這項指標並未考量相對於收入的負擔能力。blog.jana.com 的資料顯示資料費用。

500MB 數據方案
費用 (美元)
每小時最低
薪資 (美元)
支付 500 MB 數據方案所需的工作時數
印度 $3.38 $0.20 美元 17 小時
印尼 $2.39 $0.43 美元 6 小時
巴西 $13.77 $1.04 美元 13 小時

網頁權重不僅是新興市場的問題,在許多國家/地區,使用者會採用資料用量有限的行動資費方案,如果他們認為您的網站或應用程式耗用大量資料且費用高昂,就會避開使用。即使是「無限」行動數據和 Wi-Fi 數據方案,通常也有數據用量上限,超過上限就會遭到封鎖或限制。因此,請盡可能清楚說明網頁耗用的資料量。如需具體最佳做法,請參閱這篇網誌文章:透過費用透明度培養信任感

總而言之,網頁大小會影響效能,並造成費用。提高內容效率一文說明如何降低這項成本。