很久沒有寫關於排版的文章,恰巧最近同事間討論到關於畫面資料流( Content Flow )的問題,所以把這個老話題在拿出來嘴一下,順便填充一下部落格的內容。

但,太久沒有寫文章實在是過於生疏。


WD-40

WD-40 超棒噠~

這個比較跟本文無關,只是為了 WD 的埂而已。


RWD

全名叫做 Responsive web design,從被提出來,距今大概已經 10 年過去了。但是對於這件事情的話題性還是不少,諸多網頁(網站)設計都會提到這個東西。然後就像是戰南北一樣,這件事情也時常拿來跟 AWD 做比較。關於這些事情我們後面再來聊。

關於響應式的設計,我們最主要的目的在於:

  1. 針對不同裝置,只需要維護一份資料就可以了。
  2. 在不同裝置,有比較相近的畫面操作邏輯與畫面編排。
  3. 在不同裝置(不同螢幕解析度)下,保有一定的使用者友善介面。
  4. 對於 SEO 來說,不同裝置保有同一個版本的畫面,可保持對 SEO 策略的一致性。
  5. 可以同時面對不同裝置,而不需要網站重新導向。

然後針對上述 5 點,我們繼續思考關於反面的事情:

  1. 維護的那「一份」資料,多數情況下會很大一包。
  2. 為了追求操作邏輯統一性,必須額外付出製作成本。
  3. 這個世界上有千千萬萬種解析度的手機、平板與電腦螢幕,最近有 8K。
  4. Google 一邊告訴你說手機與桌機要有相同結構,一邊告訴你說我有 AMP Page 好蚌蚌。
  5. 因為不同裝置都在同一份的關係,結果每個人手上都好大一包。

好,講到這邊先別急著放棄,後面會讓人放棄的事情還多著呢(欸。


AWD

全名叫做 Adaptive web design,這裡不是四輪傳動全時四驅的那個。這個字很常拿來跟 RWD 擺在一起。翻成中文呢,有的人叫做自適式,有的人叫自適應,我是覺得怎麼叫都很饒口,所以還是說英文就好了,中文要表達起來真的有點容易搞混。至於說為何會有 AWD 的出現,主要是因為 Mobile first 這件事情,所以衍生出了行動裝置優先的網頁設計。

說個豆知識,AWD 的年紀比 RWD 要老的多。大概是行動裝置剛剛起步的時候(大概是黑梅機時代),為了給這些小型裝置能有簡易的網頁可以瀏覽,所以經由伺服器端來產出一個給行動裝置瀏覽的畫面,就是現在俗稱的「手機版」跟「桌機版」的差別。但,後來不被廣泛使用的原因,也是因為整體設計模式並不如 RWD 那樣來的流暢,所以這兩者的界線就變得很曖昧。

自適應式的設計,最主要的方向在於:

  1. 針對不同裝置,由伺服器端判斷 user-agent 來給出不同的資料。
  2. 在不同的裝置尺寸下,設計師可以設計專用的操作邏輯與畫面。
  3. 對於每種裝置都能做到最佳化(設計、介面、資料流)。
  4. Mobile first 所以強化(應用)在行動裝置支援的功能( feature )。
  5. 不同裝置不同檔案,可以完全分離而不受影響。

然後針對上述 5 點,要打臉的地方也是啪啪啪:

  1. 打開 Sketch 起手式就會有三個 Page,分別叫 手機版平板電腦版
  2. 通常叫平板的,都是去依親手機版,或者投靠電腦版,然後變成 奇怪的形狀
  3. 有幾個裝置就要維護幾種 Content flow, UI/UX 跟資料流邏輯。
  4. 有一種行動裝置瀏覽器,叫做 InAppBrowser 或俗稱 IAB
  5. 你有多少版本,就要對應有多少 SEO 的策略(別忘了你有好多網站)。

簡單的舉幾個點,讓大家知道一下,其實各有各的難處。RWD 與 AWD 對我來說,從來就不是什麼二選一的事情。如果你真的需要針對特別的裝置來製作,那麼選 AWD 就沒毛病,如果不是,那麼選 AWD 還是 RWD 根本就不那麼重要。最主要的,還是依據內容來決定,擷一段 Wiki 的總結,

There is certainly more than one way to skin the cat of dynamic web development.

如果真的要區分,那麼我會這麼說:

  1. RWD 就是 one-size-fits-to-all
  2. AWD 就是 one-size-stretches-to-all

至於是 fitsstretches 其實就不是那麼重要。


響應式什麼?適應什麼?

這邊比較工程一點,不過我想先撇除 viewport 的部分,單純的以「螢幕解析度」這件事情來講,應該會比較容易理解。所謂的 響應 或者有的地方會說 自適應 的網頁設計,單就字面上來看,就是在各種螢幕解析度下,都能保有畫面的操作邏輯、頁面結構與相似的使用者體驗(指 RWD 來說)。

所以,在這個所謂響應的著墨點,在於:

  1. 流體佈局( Fluid Layout )。
  2. 有限制的元件尺寸(文字、區塊、圖片)。
  3. 內容資料流的斷點設計( Breakpoints )。
  4. 結構化的區塊(避免內容破碎)。

要列出來的東西很多,主要就以以上四個方向來說明,理論上應該比較容易理解。

流體佈局的部分,這件事情在當年 Bootstrap 推出之後,貌似大家對於 排版 這件事情好像就沒有那麼排斥(真的嗎?),然後對於眾多工程師來說,也提供了不少的救贖。雖然在當初那個年代,大家都還是 floatfloat 去的,但是大抵上還是解決了不少問題。

所以,當我們查看當年 Bootstrap 的 col-sm-4 的設定時,你可以看到 CSS 當中是這樣寫的 width: 33.33%,這樣的設定基本上就符合流體佈局的設計。之所以使用百分比,實際上是為了要在 大容器 當中,保有對於寬度的彈性設置。基於 12 個欄位的預設值,當我們寫了 3 個 col-sm-4 時,就相當於填滿了整個容器。

而,當容器的尺寸發生了變化,依據每一種 Media Query 的設定(設計),無論我們的容器在什麼階段被換成了哪一種尺寸,在容器當中的區塊依舊會保持 3 個子區塊的排列方式。亦即,你的 大容器 即便永遠都是 100% 的寬度,那麼在任何尺寸的可顯示裝置上,都會維持 3 個子區塊的排列。

接著,我們的子區塊 width: 33.33% 相較於容器來說,並不能稱得上是 有限制的 元件尺寸,舉例來說,我們有一張圖片,他的最佳尺寸是 300px,那麼,我們在 1080px 寬的螢幕下,你的子區塊會得到 360px 的寬度,你的圖片若使用了 100% 寬,那麼他就會被拉伸到 360px 的寬度。

圖片被拉伸本身並不是問題,問題在於 圖片 這樣的元素,應該要擁有一個 最大靜態尺寸,以避免在不同的流體佈局當中,尺寸的改變而造成內容資料流的變化。所以說,我們可以將圖片設計為 max-width: 300px; 用以避免他超過 300px 而發生不可預期的事情。換句話說,我們可以透過這種方式,將變化的變因侷限在 300px 以下的變化。

當然,上述的 有限制 的元件尺寸,並非一定是圖片,內容資料的區塊、影片、表單欄位甚至按鈕,都可以依照這樣的方式來實作。為什麼會需要這樣的元件?當我們在流體佈局當中使用相對單位時,你會因為寬度的改變,進而影響到元件高度跟著改變,諸如等比的圖片、影片,文字內容區塊等。所以,當這些區塊在製作或是設計時,必須考慮到因為 寬度 的變化,對於資料流所造成的影響。

資料流的影響,就是在內容為王( Content is king )的結構當中,需要納入考量的部分。舉個簡單的例子,在新聞網站,或是報紙(這年頭應該很少人看報紙了),多數以 為單位來切分內容,重要的標題也有機會採用跨欄的方式來達到醒目的效果。另外一個例子,在 Microsoft Word 編輯文件中,有個功能叫做「文繞圖」,在既定的格線系統當中,我們確實可以很巧妙的安排這些內容,讓他變得易於呈現,且容易閱讀。

但,在面對這麼多裝置的網路環境當中,並沒有一個很固定的格線系統,即便有,在 使用者產生 的內容裡面,你很難侷限(或強迫)使用者能按照規則來走。以「文繞圖」為例子,當文字的長度恰巧高於圖片高度的一個行高,那麼,那一段文字就會被折向圖片的 底部,雖然我們確實可以稱之為「文繞圖」,不過,對於閱讀者而言,這樣個 斷點 就不算是友善(或容易閱讀)的結果。

那麼,應該考慮什麼方式來製作需要的 斷點 呢?

  1. 將你的圖片比例縮小。
  2. 結構化你的文字區塊。

將你的圖片縮小是一種方式,但這樣所產生的效益並不高。由於你無法確切掌控文字內容的長度,所以這邊的斷點製作,會比較傾向於將文字包裝成 結構化的區塊。無論是 Bootstrap 或諸如此類的工具,最起先的用意即是提供 格線系統 ,用以統一(或標準化)你可以操作的格線,讓網頁排版在某種程度上有高度共通性。所以,當我們在規劃排版這件事情的時候,所需要決定的斷點( Breakpoints )就是一個讓人比較難捉摸的地方。例如,瀑布流(他沒有斷點,或者說,每個區塊都是一個斷點)。


Content is king

內容為王的意思就是,內容為王。我們關注的地方有:

  1. 資料流( Content flow
  2. 斷點( Breakpoints

這兩件事情跟 RWD 還是 AWD 一點關係也沒有 ,請記好這件事情,這裡跟內容有關,跟你要怎麼去實現 響應 還是 自適應 的事情沒有關係。資料流因為斷點的設計而產生走向,這些走向最終會被我們封裝成區塊,這些區塊才會跟 RWD/AWD 產生關連。我們回文到前兩段,AWD 可以 直接決定內容呈現方式 然後輸出到裝置,RWD 則可以依據裝置來 動態調整資料流與斷點 ,所以現在可以知道是 了吧。

因為我不是設計師,所以我沒辦法給出什麼資料流的設計建議,或是斷點的設計方向。但,依照 區塊 的結構化,我們可以用來編排我們的版型、用來決定是否採用哪一些格線系統。對於資料流的呈現,我們必須依賴網格系統來當作排版的標準(如果全部用 position: absolute 來做,我也是覺得很神)。我們包裝成區塊之後,設計師決定了資料流的順序、樣貌以及操作邏輯,所以,對於前端工程師來說,依循這樣的規則來做絕對不會錯。

網格系統最經典的應該就是 Microsoft Excel(是嗎?),當中的欄與列的呈現方式,其實跟前端工程師切版有 87 分像。諸如時下最潮的 Grid Layout ,或者是 flexbox(目前 Bootstrap4 就是採用 flexbox)。然後,我們又再次回到 10 年前,甚至 20 年前在用 Table 切版的年代。

有沒有聽過「跨欄置中」?

為什麼會提到這件事情,因為在網格系統中,我們將文字簡化為 區塊 的用意,在於簡化(這不是廢話),我是說,利用巢狀結構來降低畫面複雜度。這個是我們在規劃區塊時,需要留意的事情。我在前文所提到的 內容破碎 所指的,即是一種過度區塊化,或是過度扁平導致資訊破碎。舉個例子來說,

請給我一張名片

我先給你我的名字這個區塊
然後這一片是我的職稱
接著這個長方形方塊是我的電話
最後這個方塊是我公司名稱跟 Logo

重點是 請給我一張名片 ,所謂的 一張 就是區塊,裡面的名字、職稱、電話、公司名稱與 Logo 就屬於巢狀結構,他們是 一定且必要 存在於一張名片當中所需要的元素,這種時候若沒有 一張 這個動作來包裝,那麼這些資訊就會流於破碎。

至於在不同尺寸下,我的名片可能 長得不一樣 這件事,就屬於設計師的範疇,對於前端工程師而言,就是把區塊重新排列組合,請記得,就是 排列組合 這件事情而已。在這邊不需要糾結在 RWD 還是 AWD 還是 WD-40 這些事情,因為根本就不干他們的事情。因為不管你是前端重新排列組合,還是後端排列組合後輸出,最終都只是 重新排列組合 而已。

重點在於,你是否如實呈現了設計師的資料流、斷點與介面邏輯。


小結

我還是想說一下,好看的介面設計不代表好的使用者體驗,難看也不一定代表肯定不好。這種事情不是一個硬幣正反兩面的事,讓資料與介面邏輯說話,剩下的就只是輔助而已。

套一句 Amos 說的,能收到款的管你什麼 WD 都切給你。

好 WD-40 不來一罐嗎?