響應式設計如何讓您抓住用戶體驗?

2016-07-12 1777 1 編輯:Monster 來源:原創文章

最近很多客戶咨詢我們是否可以提供響應式網站建設服務,以及響應式網站的優缺點等等。這里深正互聯想說,深正互聯可以為客戶提供響應式網站建設服務,但前提是您需要知道每一種技術都有其特定的局限,以及其特有的優勢,對于一些客戶認為響應式網站等于一切的客戶,深正互聯特地分享了一篇關于響應式的文章供大家閱覽。

你調整了瀏覽器,笑容攀上臉頰。你感到非常開心,認為自己實現了友好移動的目標。在正式討論前,讓我來預測下未來:你會失掉用戶和經濟效益,如果你把響應式網頁作為唯一目標和唯一的解決辦法。好消息是,你可以行之有效。

在這篇文章中,我們會談到移動互聯網和響應式設計的關系,首先將介紹如何巧妙的運用響應式設計,為什么性能對移動端非常重要,為什么響應式設計不能最為你網站的目標,最后技術的性能問題幫助我們更好的理解這問題。

自2000年開始,設計者和開發者就把移動設備的問題過于簡單化,以至于現在仍然有人認為響應式網頁設計能解決一切問題。

大家必須明白,凌駕于與任何目標,移動網絡體驗必須和閃電一樣快。迅速、實用、兼容的體驗對所有移動設備都是挑戰。當你使用響應式設計時,這些挑戰都存在。從一開始就重視性能會讓過程容易些。

響應式設計是很棒,但不是********。如果你在移動設備上一味堅持,在轉換率后就可能隱藏著性能問題。大約有11%的網站是響應式,這個數字每月都在增長,所以現在是談論這個問題的時機了。

據Guy Podjarny研究,72%的響應式網站不分屏幕大小都提供相同的字節,盡管這會降低移動網絡連接。不是所有用戶都有耐心等著網站加載。

對響應式設計存在的問題有了基本認識,我們就能減低它帶來的損失。

移動網站來自過去

我不是說你不應該采用響應式設計或者去用m.*的子域名。事實上,現在社會分享無處不在,不分設備,分配給給文檔一個URL,這是聰明的做法。但這并不意味著一個單獨URL應該提供相同的文檔或每一個設備都應該下載相同的資源。

援引Ethan Marcotte的話,他創造了“響應式網頁設計”這個術語。

最重要的是,響應式網頁設計的初衷不是要取代移動網頁。——Ethan Marcotte

交互、移動、快速

如果我們能使用一些其他的技術,就可以實現獲得響應式設計好處的同時,不影響移動設備的性能。響應式設計從來不是意味著要解決“性能”,這也是為什么我們不能因此指責它的原因。然而,相信它能解決你所有問題,這大錯特錯。

設計響應式很重要,因為我們需要解決跨桌面和移動端視窗大小范圍的問題。但是只考慮屏幕大小就低估了移動設備。桌面和移動端的界限正在變得模糊,基于不同的設備對我們而言仍然有多種可能性。但是我們還不能通過媒體查詢來決定響應式設計的功能。一些評論家稱之為“可靠的響應式網頁設計”,然而另一些人則認為它是伴隨現代視覺的響應式網頁設計。在沒有了解其基本語義的情況下,我們需要搞清楚這個問題。

雖然沒有可應用于各類文檔的萬全之策,但是能夠運用一些技巧來改善現有響應式的解決辦法,并且力求性能最大化。

· 實現每一個文檔對所有的設備都使用相同的URL和相同的內容,結構不必要相同。

· 當從零開始,遵循“移動先行”的方法。

· 在一個真實設備上測試當資源加載和顯示會發生什么。不要依賴調整你的桌面瀏覽器。

· 使用優化工具測量和提高性能。

· 通過JavaScript傳輸響應圖片,雖然我們更期盼著瀏覽器供應商(例如srcset)能解決這個問題。

· 當你需要當前設備具備加載條件時,只加載JavaScript,這會在onload事件之后發生。

· 對移動設備,內聯文檔的原始視圖,或者發送一屏顯示內容。

· 使用下面一種或幾種技術應用智能響應式的解決方案:條件加載、按組響應、服務器端層(如適應性方法)。

網站框架條件加載

不要總是在CSS中依賴media queries,因為瀏覽器將會為所有設備加載和解析所有選擇器和樣式 (后面詳細討論)。這就意味著手機為了一個大屏要下載和解析CSS。因為CSS塊的呈現,你要浪費一些時間等待聯接成功。

在設備上用JavaScript的matchMedia查詢來代替CSS media queries,你知道這些內容是不會變化的。例如,大家都知道iphone不能動態的轉換成iPad的規格,所以我們只在正在需要CSS時才用。

可以用特征檢測,例如 Modernizr,對UI和功能性做出更明智的決定而不是僅僅根據屏幕尺寸。

按組響應

在處理簡單文檔、為臺式電腦和智能手機提供相同的HTML時,雖然為我們可以讓所有屏幕依賴一個單一的HTML基礎和響應式設計,但這并不總是最好的解決方案。為什么呢?同樣是由于移動設備的性能。

即使我們在服務器端儲存相同的文檔,但是根據設備組別的不同給用戶不同的文檔。舉個例子,為一個6英寸甚至更大的屏幕提供大的浮動菜單,為一個小屏幕提供漢堡菜單。在每個組群里,使用響應時技術以適應不同的場景,例如肖像模式和風景模式的轉換,切換iPhone(320像素寬)、5英寸Android設備(360英寸)和平板(400像素)。

服務器端層

智能響應策略的最后一個選擇是服務器。服務器端功能檢測和決策不是移動網絡的新鮮玩意。類似 WURFL 和Device Atlas的庫在市場上有好多年,響應式設計和服務器組件的混合也眾所周知。有時被稱為是響應式設計和服務器端組件(RESS),有時又叫自適應設計,這提高了響應式設計的速度和可用性,同時每一個服務器端都保持一個代碼庫。很遺憾的是。這些技術這幾年并沒有什么突破性的發展。只能在博客和雜志里看到一些開發者對“RESS”、“響應式”、“自適應”做比較。原因就是:我們是前端專業人士。任何涉及到服務器的事情看起來都是不太愉快的問題。在一些情況下,前端設計師能把握好服務器的腳本,另一些情況是,服務器由遠程開發團隊管理,設計師不想每做一次小的UI改變就要和遠程團隊溝通處理。我能體會這種感覺。

這就是在大型項目中要花時間思考新架構層的原因,這樣前端工程師對服務器做決定時不會影響到后端架構。Node.js是一個極好的備選平臺,是介于當前企業后端基礎和前端之間的服務器端層。

在這個新的端層里,前端的工程師可以根據有現實的決定權,這會使得在不觸及后端架構的情況下,讓所有設備上的體驗更為快速、響應、可用。


本站文章均為深正網站建設摘自權威資料,書籍,或網絡原創文章,如有版權糾紛或者違規問題,請即刻聯系我們刪除,我們歡迎您分享,引用和轉載,但謝絕直接搬磚和抄襲!感謝...
關注深正互聯
我們猜你喜歡
七星彩头尾