今天就讓我們諷刺一把,去毒害移動端用戶。聽上去如何?只要照着我的指示做就行。讓我們做一個緩慢的網站,禁用縮放,隱藏導航,並且在頁面里填滿固定位置的元素。我打賭這會讓那些可憐的移動端用戶活不下去。

在捷克,最受歡迎的兒童電視英雄是小鼴鼠(The Little Mole),它是一隻天真的、不說話的、快樂的小動物,常常幫助森林里的其他動物。

電視英雄經常跟那些破壞自然環境的人類作鬥爭。當我陪着孩子們看小鼴鼠時,我有時會把它想象成一個移動網站用戶。你想知道為什麼嗎?

作為網頁設計師,我們經常像“壞人們”對待小鼴鼠一樣,對待我們的用戶,尤其在移動網站上。

這個節目里有一集非常戲劇性。一個老人用盡各種方法想擺脫花園裡的小鼴鼠,最後試圖毒死它。當設計師們把移動版的網站做得很難用時,他們其實幹的是一樣的事,他們要“毒死”用戶,最終迫使用戶離開。

今天就讓我們諷刺一把,去毒害移動端用戶。聽上去如何?只要照着我的指示做就行。

讓我們做一個緩慢的網站,禁用縮放,隱藏導航,並且在頁面里填滿固定位置的元素。我打賭這會讓那些可憐的移動端用戶活不下去。

1. 讓網站緩慢地加載

讓網站緩慢地加載是對付移動端用戶的最佳武器。你要是能讓網站慢到加載所用的時間足夠訪問者往返一趟郵局,那就太棒了!你正在有效地對移動端用戶們下毒。

現在,讓我們認真點。移動網絡的傳輸速度較為緩慢,即便速度增加到3G和4G,也不是哪裡都有網絡,它們無法與有線網絡競爭。

各項測試和調查表明,網站的速度對於用戶的轉化及網站的整體有效性有重大影響力。就算用戶用的是EDGE連接,他們也沒必要為網站內容的呈現而等上好幾秒鐘。

此外,別忘了網站速度是Google考慮搜索結果和AdWords廣告的選擇標準之一。因此,它不單單影響着用戶轉化,還會影響到用戶一開始是否會登陸你的網站。

解決方案很簡單:在開發網站概念的時候就考慮到訪問速度的問題。從性能預算展開工作。

優化訪問速度沒有那麼複雜。讓我來分享一些來自Google的最佳實踐

讓數據傳輸最小化

不要阻礙頁面呈現

優化後端

現在沒時間讀這些?完全理解。留着這些文字以後讀好了。幸運的是,有些工具能告訴你,你的網站有什麼問題。首先,用PageSpeed Insights測試你的網站,接着用WebPagetest

2. 把輪播圖設計的很糟糕

這樣用戶再也不會回來了。

確實,對於輪播圖的各類研究中並沒有明確表示它們是不合適的。然而,輪播圖在實現和用戶體驗方面都是較為複雜的。所用,使用輪播圖有一定的風險。

耐克的輪播圖(左圖)沒有清晰地表達出右方還有內容。百思買(右圖)做的更好:後續項目是可見的,因而很明顯你可以向右滾動。

使用輪播圖時,你極有可能隱藏一些內容,而非推廣它們。根據一些調查,絕大多數用戶只會看到第一張圖片,由於“橫幅盲點”,基於橫幅的輪播圖通常都會被忽略掉。

如果你準備採用移動端輪播圖,請確保它符合以下條件:

  • 不要只為了養眼或是為了隱藏不必要的內容而使用輪播圖。對於宣傳和主要內容相關的次要內容,輪播圖是極好的工具。
  • 用第一張圖片預告後面幾張的內容。第一張圖的主要功能在於誘導用戶去看第二張和第三張。
  • 讓導航能用於小型手機上。用在桌面界面上的那些小點對於手機而且可算不上是“能用”的!
  • 確保自定義手勢不會和默認的瀏覽器手勢相衝突。你要用滑動手勢嗎?確保它不會和瀏覽器內置的手勢相衝突。
  • 不要拖慢網站速度。這主要涉及輪播圖的數據需求和實現方式。

Newegg的輪播圖(左圖)代表一種常規的做法。B&H的(右圖)是一個很好的例子,節省了縱向空間,利用下一個內容的显示,誘使用戶瀏覽額外的圖片。

3. 把菜單藏在漢堡包圖標下面

你要把導航做的容易訪問?拜託,認真點!你這樣會有上千的用戶的。

當你在一個網站上隱藏了菜單,人們會不再使用它。在最近發表的一項研究中,Nielsen Norman Group發現,在手機界面上隱藏導航,對內容的可發現性、任務完成度及花費在任務上的時間有負面的影響。

如果在導航里有一些重要的項目,而你能夠展示它,那就把它展示出來吧。如果你無法展示整個菜單,那麼將它簡化,或者至少显示出菜單里重要的部分。因此,我傾向於推薦“優先+”的導航模式

如果導航還帶有內容,始終显示若干個項目。

如果你無法显示重要的項目怎麼辦?那好吧,把菜單隱藏在漢堡包圖標下面,標籤里寫上“菜單”,並且確保用戶在沒有菜單的情況下也能使用這個網站。

4. 始終依賴滑動手勢

用滑動手勢劃去所有用戶。

我認為,對於移動端UI,不常見的手勢有一定風險,原因有二

(1)自定義手勢可能會和瀏覽器的默認手勢衝突。例如,如果你的輪播圖支持滑動手勢,那麼用戶可能會意外地操作了“邊緣滑動”(和普通滑動非常接近的一個手勢),這個動作會被一些移動端瀏覽器解讀為導航至瀏覽歷史的一個命令。

(2)許多用戶不會用那些不常見的手勢。因此,你必須教會用戶使用這些手勢。如果我們討論的是日常應用,這是合理的,但是對於網站這並不合理。

使用輪播圖也許不一定是個問題。然而,我見過有些新聞網站支持滑動手勢來切換文章。對於用戶而言,這樣的手勢不常用並且難以理解。

滑動手勢不是唯一的問題。點擊Sarafri瀏覽器的底部會显示被隱藏的菜單。因此,如果你把導航元素粘在底部位置,用戶可能要被迫點擊兩次

在使用任何不常見手勢之前,要測試它不會和瀏覽器的內置手勢相衝突。

5. 把所有的點擊目標都做的細緻小巧

一毫米就夠了。

好吧,讓我們認真點。你的點擊目標是否足夠大,能讓一個籃球運動員用拇指輕鬆地擊中他們?

Josh Clark在《Designing for Touch》一書中提到了Steven Hoober和Patti Shank的一項研究。研究者們發現,如果放置在手機屏幕的中心,點擊的目標可以小至7平方毫米;然而,如果放置在頂端或者底部,則至少為11平方毫米。

不過對於網頁,毫米是不切實際的。我們使用像素單位,對吧?那麼,我們該如何處理移動設備上的各種DPI?也許會讓大部分讀者感到驚訝,Josh Clark在書中這樣寫道:

如今,幾乎所有的移動端瀏覽器在宣告設備寬度的時候,基本上都使用相同的像素密度:160DPI是觸屏網頁像素的實際標準。

同樣,你需要做的就是正確地設置viewport的元標籤:

<meta name=”viewport” content=”width=device-width, initial-scale=1″>

還有一個步驟:使用最適用於響應式設計的em或rem單位。大部分瀏覽器的默認字體大小為16像素,因此我們可以使用以下轉換:

/
7mm = 44px = 2.75rem /

.touch { height: 2.75rem; }

/ 11mm = 69px = 4.3125rem /

.touch-big { height: 4.3125rem; }

這樣就好了。別忘了為舊瀏覽器提供一個fallback。如果你想查看細節,建議你購買Josh的書

6. 讓網站可響應,但是僅針對特定的分辨率

迫使用戶離開你的網站。逼着他們去買一個分辨率“正確”的手機。

我們在移動設備上正面臨着各式各樣的屏幕分辨率。以前,只有Android平台受到影響,如今蘋果設備也是。

即便你的網站不是為了移動設備而準備的,也沒有理由一眼都不讓移動用戶看。有一些網站在特定的視窗尺寸下無法使用。真是遺憾!

我們不能想當然地認為智能手機的屏幕大約為320像素,平板電腦大約768像素,桌面屏幕就是超過1024像素。頁面需要在768以及更小的像素尺寸下無縫調整。

那麼,我們應該為哪些分辨率做考慮呢?朋友們,所有的都需要。

在我的開發生涯中,我測過從240到約2600像素寬的各種響應式網站。我承認,讓頁面在所有的尺寸下看起來都很完美,是幾乎不可能的事情,但底線是網站布局不應該分崩離析——除非你的意圖是嚇跑移動端用戶。

和你們大多數人一樣,我所做的就是把瀏覽器窗口從最小調整到最寬的尺寸(或是使用開發者工具的響應式模式)。這跟Brad Frost的測試工具裏面提及的“Hay!模式”差不多。

另外,不要在切換手機的豎橫屏模式時,更換設計。

我認為,用戶不論用哪個方向使用手機, 都會希望瀏覽網站時看到的是一個相同、或者至少是非常相似的界面。我記得有一個講座的參加者告訴我這樣一個故事。當他的公司重新設計網站之後,很多人開始撥打支持電話。他們抱怨的都是一個特定的錯誤:網站的菜單不見了。過了一陣子,他們發現這些都是平板電腦的用戶。當他們在橫屏視圖訪問網站的時候,菜單是在的。當豎屏使用平板的時候,菜單就被隱藏在一個“漢堡包”圖標下面了。

7. 不要讓電話號碼可點擊

要惹惱用戶。不要讓他們直接從網站撥打電話。

對於移動端用戶而言,聯繫是件很簡單的事。只要把電話號碼做成鏈接,點擊進入撥打。這類似於在蘋果手機上激活FaceTimes,短信和Skype。

但是我們有一個問題。人們通常無法從桌面瀏覽器撥打電話。然而,桌面瀏覽器不會忽略這些電話鏈接,而是打開一個令人無法理解的對話框,讓用戶去選擇一個應用來撥打電話。而大部分情況下,桌面上並沒有可以撥電話的應用。

親愛的朋友們,我也不想去毒害桌面端用戶。因此,在這種罕見的情況下,我建議採用設備檢查功能,僅為移動端用戶插入可撥打電話的鏈接。

在HTML中,電話號碼是未激活的。我們只需要用一個span tag包住它,之後再使用Javascript:

Phone: <span class=”phone-number”>123456789</span>

使用jQuery和isMobile的檢測庫,我們會用phone-number類和一個鏈接替換元素:

if(isMobile.phone) {

$(‘.phone-number’).each(function() {

$(this).replaceWith(

$(‘<a href=”tel:’ + this.innerHTML + ‘”>’ + this.innerHTML + ‘</a>’)

);

});

}

在智能手機上,標記如下所示:

Phone: <a href=”tel:123456789″ class=”phone-number”>123456789</a>

8. 禁用縮放功能

如果你真心想要保持用戶的視圖大小,禁用縮放功能吧。這是不人道的——而且非常有效。

但是說真的,禁用縮放功能不僅僅會讓那些視力不佳的用戶難受。出於種種原因,連視力良好的用戶也會在移動設備上使用縮放功能:

  • 為了近距離查看圖片
  • 為了更易選擇文本;
  • 為了在對比較弱的情況下放大內容

實際上,大量移動網站都禁用了縮放功能。即便對於在線商店這種很需要查看圖片細節的網站也是如此。根據Baymard Institute的測試結果,40%的电子商務網站禁用了縮放功能。令人難以置信,對嗎?

正如桌面端用戶不可以沒有後退按鈕和滾動條一樣,移動端用戶也需要縮放功能。

WCAG的易用性原則告訴我們,用戶必須要能夠將文本放大到200%

當然,有些情況下你必須禁用縮放——例如為了固定元素。但有時候縮放功能是不小心被禁用的,例如是因為插入了錯誤的meta viewport標籤。下面的示例是唯一正確的用法,而錯誤的標籤則包含了諸如maximum-scale=1和user-scalable=no這樣的參數。

<meta name=”viewport” content=”width=device-width, initial-scale=1″>

9. 設置 * { user-select: none },然後就天下太平了

有些用戶會訪問你心愛的網站並且複製走所有的文本。這樣的行為是令人震驚的,必須被阻止。

親愛的朋友們,將user-select的屬性設為none有時候是有用的,不過僅限於那些你希望用戶會與之交互的部分,而且在這些部分選擇文本也沒有什麼用處。

因此,我建議僅對以下元素使用user-select: none:

  • 圖標導航;
  • 疊加文字的輪播圖;
  • 控制元素,例如下拉列表、導航

請永遠不要禁用靜態文本和圖片的選擇。

10. 用錯誤的方式加載網頁字體

如果用戶活着看到網頁加載,用閃爍的字體或者完全隱藏內容,來殺死他們。

使用網頁字體並沒有錯,但我們必須確保它們是網站第一個要加載的元素。有些瀏覽器在显示內容前,會等待網頁字體的加載。這被稱為不可見文本的閃爍(FOIT: flash of invisible text). 其他瀏覽器(Edge和Explorer)會显示你最不想要的那個系統字體,這被稱為無樣式文本的閃爍(FOUT: flash of unstyled text )。

有第三種可能性,人造文本的閃爍(FOFT: flash of faux text)。這時候,頁面內容會被渲染成網頁字體的一種規律性的剪切,緊接着就會出現粗體和斜體的剪切樣式。

FOUT實踐:加載網頁字體的時候,显示系統字體好過空白的屏幕。

我的項目通常是基於內容的網站,所以我更喜歡使用系統字體(FOUT)儘快地展示出內容。這就是為什麼我喜歡微軟的瀏覽器。我還會使用一個叫做Font Face Observer的小庫。讓我們看看代碼。首先,JavaScript:

var font = new FontFaceObserver(‘Webfont family’);

font.load().then(function () {

document.documentElement.className += ‘ webfont-loaded’;

});

然後是CSS:

body { font-family: sans-serif;

}

.webfont-loaded body {

font-family: Webfont Family;

}

每個網站的需求都不一樣。可參考Zach Leatherman的“字體加載策略綜合指南”

11. 用社交媒體按鈕胡亂地塞滿頁面

如果用你自己的混合毒藥還不夠毒死他們,那就把鄰居的也用上。

Facebook,Twitter和Google的按鈕會讓移動用戶感到不舒服,原因有二:

(1)它們會下載大量數據,導致網站的加載和頁面呈現緩慢。測試結果显示,當使用官方的社交分享按鈕時,訪問者將下載比20次請求還多300KB的數據。

(2)它們通常是無用的。社交分享功能通常會被集成在操作系統里。在Moovweb所做的一項歷時一年,超過六千一百多萬個移動進程的研究結果中显示,僅有0.2%的移動用戶用過社交分享功能。

大多數的社交按鈕都是無用的,即便在桌面上也是如此。尤其對於在線商店,分享沒有什麼用處,因為低分享数字會讓購買者喪失購買動力。不過我們別去那兒。我們是要去毒死這隻移動野獸。

如果你不想毒死移動用戶,但又需要社交分享按鈕,可以試着使用社交分享鏈接,或者類似Social Likes的插件,使用這些方法對加載速度的影響較小。

12. 桌面到移動端的重定向錯誤

擁有m-dot版本網站的“殺手”開發者會多一樣毒害用戶的方法。萬歲!

我們在幾乎每一個有m-dot版本的網站上都見到過錯誤的重定向

正確的實現看起來是這樣的:

  1. 如果移動端的訪問者訪問了www.example.com/example,服務器會檢測到他們的設備,並且將他們重定向到m.example.com/example(不是去m.example.com)。從桌面端訪問移動版本也是如此。
  2. 如果該URL不存在,那麼讓用戶留在桌面版本,好過將他們重定向到m-dot的主頁。
  3. 通過用<link rel=“alternate”>,或是指明在sitemap.xml文件里,讓搜索引擎知道網站有兩個版本。Google的網站管理員幫助文檔里提供了詳細的指南

理想的方案是做一個響應式網站,在所有的設備都使用同一個URL。網站的m-dot版本增加了開發和維護成本。此外,它不是唯一一個需要為更強大的智能手機體驗或移動網絡速度而做出優化的網站類型。

讀一下Karen McGrane在《Going Responsive》一書中所寫的,參考自Doug Sillars(AT&T開發者項目性能方面的技術帶頭人)的一項研究:

m-dot是唯一一個能做出快速加載的網站的方法,這樣的說法是不實的。良好的編碼及決策實踐可以使響應式與其他方法一樣快。

現在,剩下唯一要做的事就是隱藏不必要的東西——例如網站內容。

13. 藏好內容

把內容藏起來。反正移動端用戶也不想看。

不管你喜歡與否,人們訪問網站是來查看內容的。是的,我們被迫和這些惡意的生物一起生活。

用戶會尋找內容。要儘快地把內容提供給他們。接着,你就可以強迫他們下載應用或者提交詳細的聯繫方式。

不幸的是,很多網站把內容隱藏起來了,原因我不明白。也許它們的內容沒有價值,但是我很難相信這一點。許多元素會導致內容被隱藏:

Cookie欄

有些歐洲網站不得不显示一項不幸的cookie許可通知。我們沒法改變這個規定。但是,這並不意味着cookie欄就該被固定在頁面上,而且佔據一半的屏幕。

在線聊天窗口或新聞訂閱廣告

在移動設備上放置固定的元素是一件很不幸的事情。你隱藏了用戶想看的內容,卻显示了他們根本不感興趣的東西。使用這些元素是可以的,但要避免在移動設備上固定住它們的位置。

下載應用的插播式廣告

這些廣告令人痛苦。有些網站邀請你去下載它們隨附的應用,卻不向你展示網站內容。可是用戶是來看網站內容的!相反的,可以用iOS的smart app banners或Android的native app install banners來宣傳你的原生應用。

Google已經決定自2017年1月起,將處罰移動網站上的重疊內容:

[被插播式廣告遮擋而看不清的內容]會使用戶沮喪,因為他們沒法輕鬆地訪問那些想要看的搜索結果的內容。

相比那些內容可以立即訪問的網站,显示了干擾的插播式廣告的頁面對用戶體驗的損害更大。

為準確起見,Google不會懲罰一些显示插播式廣告的網站,例如cookie欄或者成人網站上的年齡確認。

今天你毒害了多少移動端用戶?

差不多就是這樣了。現在,讓我們嚴肅點。上面沒提到什麼“新的”東西,對嗎?

令人格外抱歉的是絕大多數的響應式網站都在毒害移動端用戶。

讓我們用一個簡短的清單來總結下關鍵信息:

你的網站在移動端呈現的足夠快嗎?

是否不太重要的元素阻擋了那些更重要的呢?你是否選擇了最佳策略來显示網頁字體?那些第三方插件(例如社交媒體)有沒有拖慢網站速度?

你把內容隱藏起來了嗎?

固定的元素是否阻擋了內容?你有沒有在特定分辨率或者橫屏、豎屏模式下隱藏內容?

UI是否移動友好?

點擊目標是否夠大?複雜的UI元素,例如輪播圖,是否在移動端採用了正確的實現方式?電話號碼是否可點擊?內容選擇是否一直都是可用的?你是否讓導航盡量在任何地方都可見?

你是否考慮到了原生瀏覽器?

你有沒有不小心禁用了縮放功能?你是否支持和瀏覽器默認操作相衝突的手勢?

你的重定向是否採用了正確的實現方式(如果你使用的是m-dot版本)?

要善待移動端用戶。別成為那個想要擺脫小鼴鼠的邪惡老人。你想知道這個童話的結局是什麼嗎?小鼴鼠活下來了,嘲笑着那個老人,然後跑去了另一個花園。

 

原文作者:Martin Michálek

原文地址:https://www.smashingmagazine.com/2016/10/how-to-poison-the-mobile-user/

翻譯:ZoeYin

譯文地址:http://www.jianshu.com/p/1478f82565f1

本文由 @ZoeYin 授權發佈於人人都是產品經理,未經作者許可,禁止轉載。