移動Web設計:Mobile Web設計中的建議和禁忌

來源:互聯網
上載者:User

文章描述:如果你正準備為你的網站製作一個行動裝置版本,那這篇文章將會對你相當有用,在本文中,將探索移動Web網頁編碼設計的各種技巧和注意事項.

如果你正準備為你的網站製作一個行動裝置版本,那這篇文章將會對你相當有用,在本文中,將探索移動Web網頁編碼設計的各種技巧和注意事項:

  • 為了行動裝置上的使用者體驗可以被接受,代碼得怎麼設計。
  • “Mobile Web”與普通網站的不同之處?
  • 可以讓網站成功運行在行動裝置和案頭瀏覽器上的基本技巧
  • 一些Mobile Web設計中的建議和禁忌、以及大量資源

Mobile Web和普通網站到底有何不同呢?

這是個很好的問題 – 首先,也許我們應該從“什麼是Mobile Web”的問題開始。畢竟,使用者用行動裝置訪問的Mobile Web,跟他們在家裡用台式機訪問的網站是獨立的不同的部分。當我說“Mobile Web”時,我指的是“通過行動裝置訪問的網站”。

在Opera,我們全身心投入而創造出的瀏覽器允許你查看整個網路,不管瀏覽裝置是否有這個能力。只要你在建立網站時,付出一點兒細心、尊敬並遵循 Web標準,你就可以為所有人所有裝置建立只有一個版本的網站 – 唯一的一個網站。但是,有一些例外情況 – 在某些情況下,只有分版本的網站才行得通,一會你會看到這一點。

移動領域的競爭環境並不平衡

在案頭領域,對於我們前端開發人員來說,形式正在好轉 – 大多數現代瀏覽器已經對Web標準支援的非常好了,無論是Opera、firefox(以及其他Gecko核心瀏覽器)或者Safari(以及其他 Webkit核心瀏覽器),甚至IE帶給我們的痛苦都比原來少了。雖然IE6的使用者群體數量仍然非常杯具,但這應該歸結於大多數人封閉的使用習慣等因素。 但是,行動裝置領域在這方面卻是不同尋常的:

  • 你擁有能為“Full Web”提供支援的瀏覽器,像iphone上的Opera Mobile和Safari。Opera Mobile使用了與案頭版本相同的渲染引擎,所以對標準的支援相差無幾。
  • 你擁有並不很爽的瀏覽器,例如IE,它們對Web標準僅能提供有限的支援。它們中的一部分只支援WAP(例如WinWap),另一些支援其他像 Chtml或HTML-MP這樣的標準(例如日本NTT DoCoMo的iMode瀏覽器),還有一些只支援Web標準中的有限子集(例如Netfront、Pocket IE、以及Blazer)。
  • 最後,你擁有OperaMini, 以及其他通過代理機制的瀏覽器。它主要只是作為串連使用者和一個大伺服器群的用戶端介面。當使用者提交一個URL時,用戶端會讓服務端尋找這個頁面。然後它會 把頁面轉換成一個輕量級的二進位標記語言,將它格式化成適合行動裝置查看的形式,並發送回用戶端顯示。這種方式的最主要優勢,是可以使頁面體積減少90% 左右,協助使用者節省很多頻寬費用。這種標記語言表明Web標準並不能很好的表現在行動裝置上,因為在這種服務的方式下,OperaMini對 ajax/javascript某些方面將支援的不是很好 – 在這兒有更詳細的解釋。

注意:不要指望你的超級Ajax和DOM指令碼動畫網站在行動裝置上會有良好表現。JavaScript在行動裝置上的支援程度千差萬別。時刻提供優雅降級吧。這種做法有一個例子叫做Hijax。

我們可以看到,在行動裝置的跨瀏覽器安全色方面,你要思考的問題有很多。但是不要怕 – 我隨後的建議會給你指引一個正確的方向;並且隨著時間的推移,行動瀏覽器對標準的支援將會得到改善,屆時我們前端開發人員真的再也不需要為它們操心了。你問 我這一切什麼時候會實現?Who knows!

行動瀏覽器的其它限制還有那些?

當然,在行動裝置上開發網站時,除了瀏覽器對標準的支援外,還會遇到其它更多的限制因素。裝置自身的限制因素,你也不得不考慮。例如:

  • 有限的控制 – 不要只假設你的使用者會使用滑鼠來控制頁面中的一切,你也要提供鍵盤的選擇。一些手機使用者可能沒有類似滑鼠這樣的東東,所以類似這樣的結構 :hover 以及 onClick 對 他們來說是沒有用的(這對可用性方面也是非常重要的 – 一些殘障使用者可能在用手方面會有些缺陷)。為使用者提供的表單設計也同樣重要 – 你可能已經感受到,用手機來填寫那些又臭又長的必填表單有多麼不爽。為瞭解決這個問題,試著去把那一坨內容用下拉式功能表的方式展現出來,這比等著使用者一個字 一個字手動輸入來的更靠譜(譯者註:目前國內有某些山寨機瀏覽器對下拉式功能表的支援可能有不同程度的問題。例如基於MTK系統的聯想i61,預設情況下會顯示所有選項,而在某些情況下會產生變形和“漂移”,使用時需要謹慎些)。另外,給表單設定一個最有可能的初始值,也是一個好主意。
  • 有限的螢幕尺寸 – 想象一下你那美妙的1024×768的設計在240×320螢幕下,或者更小的螢幕下,它的可用性會是什麼樣子……有一些方法可以應對這個情況 – 你可以故意把頁面設計的很簡潔流暢,或者你可以通過採取功能檢測或媒體類型檢測(諸如此類)的手段,為行動裝置提供不同的頁面。另外對於螢幕尺寸,有些手 機可能不需要這麼麻煩,它們可能會提供“縮放模式”這樣的機制,但是你卻不能保證這一點。
  • 有限的記憶體和頻寬 – 行動裝置所提供的可用記憶體明顯比台式機少得多。因此,在你設計網站時,需要特別小心的考慮那些超大容量的相簿圖片,以及互動式流媒體視頻的應用程式。此外,一些行動瀏覽器提供了關閉映像顯示的選項,但是你也同樣不能確定這一點。
  • 有限的排版 – 我靠,你對台式機上那些排版非常癡情?你沒有看到行動裝置上的表現!雖然這條規則有很多例外情況,但大多數行動裝置對字型的選擇非常有限,只有一兩種(like 1 or 2)。這個限制是由系統或瀏覽器決定的。
  • 有限的顏色 – 一些行動裝置在顏色方面的支援也非常有限。考慮你有多少頁面的體驗需要依賴於顏色,並確認那些對比色在行動裝置上仍然支援。

這些限制因素,就是導致Mobile Web的體驗與PC Web的體驗不同之處的真正原因。千萬別欺騙自己,覺得自己的網站在行動裝置上的使用者體驗與台式機上會保持一致 – 這純屬YY。當然,你拋開瀏覽器,千方百計去確認使用者體驗這一點仍然值得肯定。

真正的辦法,去確保你的網站為移動使用者提供一個良好的體驗,是測試,測試,再測試!一些Web設計師們已經認識到,除了他們自己的手機、台式機以及遊戲機瀏覽器外,還需要有一大堆行動裝置需要準備在手頭。

解決問題的不同方法

人們普遍意識到,有三種辦法可以解決移動開發的問題(已經被Cameron Moll證實了 – 找他的書看看)。可能的話,我建議你試試這三種方式 – 如前所述,在Opera,我們堅持相信One Web的理念 – 但是剛才我也說過,有些情況下這是很難實現的,或者也是沒有必要的。下面是這三種方法:

  1. 務必堅持遵循Web標準
  2. 建立一個完全獨立的移動網站
  3. 只建立一個網站(One Web),但是根據瀏覽它的裝置和瀏覽器情況,添加最佳化代碼。

現在,讓我們開始對這些點逐個講解。

堅持遵循Web標準和最佳實務

一個好網站的基礎,是要有一個好的HTML結構,以及美妙的CSS(表現)和JavaScript(行為)。如果你認真地遵循Web標準,大多數行動瀏覽器至少會很好地解析並至少會基本可用,這是非常有可能的。例如:

  • 一個網站,有良好的HTML結構順序並在HTML中沒有裝飾性圖片,在行動瀏覽器的單列模式或移動模式中,會呈現得很有邏輯性。
  • 如果你的表單元素中含有“label”元素,瀏覽器將把它渲染得更有表單區域的感覺。
  • 如果你給CSS和JavaScript使用了優雅降級/漸進增強技術,瀏覽器如果不支援、簡化、忽略某些屬性,這時網站的可用性幾率會大大增加。

如果你花費時間精力去研究的話,在提升移動使用者體驗方面,還有更多事情可以去做。如果你的目標受眾包括大量使用非HTML瀏覽器(例如支援WAP或CHTML的某些日本瀏覽器)使用者,那麼你可能不得不檢測裝置並提供適當的內容。

提供一個完全獨立的移動網站

如前所述,我認為如果可能的話應該盡量避免使用這種方式。你可以做裝置檢測並自動重新導向來避免給使用者使用帶來麻煩,但是這意味著你不得不維護兩套網站。最主要的方法是通過UA嗅探來識別瀏覽器,或在服務端進行裝置功能檢測,然後再給使用者提供相應的網站。在dev.opera.com,有很多優秀的文章來講述如何? – 查看最後的資源部分。

但也有例外,對於完全獨立的網站來講 – 你不得不始終考慮使用者體驗情況。某些類型的瀏覽裝置可能不相容於特定的網站或者特定的功能。例如,有一個大學校園網,帶有部門電話號碼的搜尋功能,但同時 也包含了一大堆校園曆史的網頁。如果你想去與某人會面卻找不到他們部門時,你大概會想在行動裝置上使用搜尋功能,但你在外出的時候也不太可能想坐下來閱讀 那麼多的文字。

在這種情況下,你可以使用下面提到的一些技巧,來為行動裝置提供網站中某個功能的一部分,或者乾脆為行動裝置建立一套完全獨立的網站。你只需檢測用 戶使用的裝置類型並自動提供給他相應的網站,並把這個過程完全公開給使用者,但是很多很多人並不願意這個功能把他們完全限制住,所以如果你要這麼做的話,就 需要給使用者提供一個指向完整網站的連結,使用者可以自行選擇是否用它來訪問完整網站。

一句話警告 – 裝置檢測很容易被濫用。你可能經常看到一個網站的案頭版本非常牛B,而它的移動網站卻非常的垃圾。因為開發人員只是將移動網站放在一個非常低標準的位置上。 事實上,目標受眾的裝置水平並不均衡,現在很多的行動瀏覽器都具有處理完整Web頁面的能力了!你應該儘可能地讓裝置發揮他們最高的處理能力,並且要發揮 行動裝置的特別優勢,比如基於位置的服務(LBS),還有 tel: 協議 – 在超連結點擊時它可以讓裝置撥打一個電話號碼。

只提供一個網站(One Web)

進行到這裡時,就開始變得有趣了。你可以再次依靠服務端功能檢測,但這次是在單一網站的基礎上進行最佳化,而不是重新導向到另一個獨立網站。有一些手機所支援功能的資料庫可以參考,例如WURFL。它是以XML檔案的形式開放的,你可以在設計最佳化內容之前,先通過它來查詢裝置所支援的功能。你還可以查詢行動裝置的UA字串,找出這些裝置的其他細節參數,例如是否有網路攝影機,螢幕尺寸是多少,以及它的語言種類等資訊。

在用戶端,你已經得到了為行動裝置而最佳化內容所需的兩個條件 – 媒體類型(media types)和媒體查詢(media queries)。

媒體類型(media types)

就像你知道的那樣,你可以指定不同的CSS來實現不同的用途,例如:

<link href="main.css" type="text/css" media="screen" rel="stylesheet"><link href="print.css" type="text/css" media="print" rel="stylesheet"><link href="mobile.css" type="text/css" media="handheld" rel="stylesheet">

手持類的媒體類型允許你針對行動裝置使用最佳化版的樣式(例如精簡的布局和排版等)。這是一個被支援得很好的機制,實現起來也很簡單,但它確實有它的 缺陷。就像之前所說,它經常被開發人員濫用,來給網站提供一個蹩腳的最低標準布局。事實上,OperaMini最近改變了預設類型,把預設使用手持型樣式表 (handheld stylesheet)改為螢幕型樣式表(screen stylesheet)。OperaMini可以處理大多數完整網站,因此它並不真正需要使用手持型樣式表(handheld stylesheet)。如果你樂意,你可以在OperaMini的瀏覽器選項中手動設定回行動裝置檢視。

媒體查詢(media queries)

媒體查詢是CSS3的一個構想,它的用途跟條件注釋非常相似 – 你可以把一大堆CSS規則封裝嵌入到一個媒體查詢中,然後把它應用到你的標記結構中,這一切取決於一個條件,類似“螢幕尺寸是否小於480px?”然後把代碼放進去,代碼類似這樣:

img {  margin: 0 0 10px 10px;  float: right;}@media all and (max-width: 480px) {  img {    margin: 10px auto;    float: none;    display: block;  }}

你甚至可以使用多個媒體查詢,像下面這樣:

body {  max-width:800px;  font-family:georgia, serif;}img {  margin:0 0 10px 10px;  float:right;}.info {  position:absolute;  left:8000px;}@media all and (max-width: 480px) {  img {    margin:10px auto;    float:none;    display:block;  }}@media all and (max-width: 240px) {  img {    display:none;  }  .info {    position:static;  }}

OK,在這個例子中(原始碼點擊這裡查看),瀏覽器中的圖片在螢幕大於480px時會向右浮動,文本會環繞圖片並通過外邊距留出一點兒舒服的距離(另有一個資訊隱藏在 p 元素中,並命名了一個 classinfo - 看看HTML代碼)。文字資料流在一些小螢幕中看起來可能會有些蹩腳,因為那裡沒有足夠的空間來讓圖片和定量的文本放置在同一行中,所以當螢幕小於480px時,圖片就需要改變一下,讓文本不再圍繞在它旁邊,而是用 display:block 讓它們顯示在不同行中。等等 – 還有更精彩的!如果螢幕非常小以至於不能有效地展示圖片,那就讓它們消失,然後讓隱藏資訊顯示在圖片那兒,替代那些圖片顯示文本描述 – 這是一種將資訊傳達給讀者的一種另類技巧,利用它也可以為那些使用螢幕助讀程式的盲人使用者提供原始文本,以便他們順利瀏覽網站。圖1展示了三個不同的瀏覽視 圖,這是在那些支援媒體查詢的瀏覽器中(例如Opera 9.5)表現出的不同形式。

圖1:例子中三個不同的瀏覽模式

聽起來挺好,但是有沒有不足呢?好吧,目前瀏覽器對媒體查詢的支援程度非常有限。Opera瀏覽器支援它們,Safari 3也可以(以及其它基於Webkit核心的現代瀏覽器),但是Firefox 3之前的版本並不支援,IE或其他瀏覽器也不支援。解決問題的方法之一,是使用媒體類型和媒體查詢的組合。這種方法在我的這篇文章中做過解釋。這是一種變通方案,但肯定不夠理想。這點在將來應該會有所改善。

摘要總結

目前就是如此而已。我希望我的移動開發世界之旅會對各位有所協助。我在這隻是拋磚引玉,要想深入學習的話,可以查看下面這些資源。

資源

  • Mobile web design book, by Cameron Moll
  • Designing and developing mobile web sites in the real world — 一個執行個體研究 by Brian Suda
  • Server-side capability detection for mobile devices by Brian Suda (包含WURFL, UA字串等資訊)
  • Ajax/JavaScript support in Opera Mini 4, by me
  • Kristian von Streng Hæhre’s Opera Mini request header reference
  • How to serve the right content to mobile browsers, 同樣by牛B的me — 包含媒體類型和媒體查詢
  • Creating safe media queries that work cross browser
  • Web design with Opera Mobile in mind, 再一次 by me
  • The WURFL homepage
  • The Opera Mobile homepage
  • The Opera Mini homepage

英文原文: Coding for the Mobile Web



相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。