Creating the new mnjul.net homepage

於是我又~炸掉我的英文個人首頁,然後重做一個了。其實上一版也是一年前才做好( 算是活得最短的一個版本 ),但當時有點是為了找工作,所以急就章搞了一個也不知道到底要放什麼東西、要做什麼功能、要用什麼方式呈現、要怎樣設計的怪東西。前陣子總算有時間想 & 實際操作,就開始動工。

 

英文個人首頁,到底要放什麼東西?

自從六年前的橫向捲動的版本開始,一直以來我都把我的英文個人首頁當做 portal,放入( 幾乎是所有的 )我做的東西的連結,了不起再分門別類一下,最後加個 about me 的小 pop-up 就收工。也就是說,乍聽之下,根本就是作品集--但又是大雜匯的作品集( 姑且稱之為 meta-作品集 ):網站作品、程式碼作品、攝影作品、音樂作品、寫作作品,但又有其他亂七八糟的連結( 連到我的 Twitter 之類 );這樣胡亂攪和起來,要如何簡單扼要地呈現就成為一大難題。如果想再對每個連結都添上文字介紹,就亂糟糟了。下圖是這次被我炸掉的去年的版本:雖然有各種縮圖,但還是眼花撩亂地,沒什麼結構感、層次感。

[ 去年的版本 ]

What I am vs. What I could do vs. What I can do

仔細思考以後,發現我其實希望在個人首頁呈現「我是怎樣的人,我身為人的組成有哪些哪些面象」的概念。這跟「放上自古至今我做的所有東西」的 meta-作品集的構思有點差別--當然,meta-作品集的每個段落,都還是會放上段落介紹,但如果以作品集的角度出發,這些段落介紹卻是配角( 連到作品的連結才是主角 );若以「自我介紹」的角度出發,這些段落介紹則是「述說我這個人的這部份的層面」的主角,而連結只是一些補充內容而已。這樣,段落介紹反而必須著墨更多,而且要能在訪客一捲下來的時候就吸引他們的目光。

另外,放上自古至今我做的所有東西,其實算是展示 what I could do,而並非 what I can do -- coding projects 尤甚。那些三年、五年、十年的古老的 coding projects 所用的技術,現在也沒有太大意義;放上來,反而失了焦。

No “coding projects” section?

那麼,最近的、或是還在進行的 coding projects,到底要不要放?其實想了半天,我發現「coding」並不是我這個人的一部分--從小學學 ETBASIC 到到現在,coding 一直是我很厲害的技能,我也確實把 computational thinking 帶到我生活的很多地方;但 coding 反應在我身為「人」上面,永遠只有一件事--個人網站。從國中以來,我最大的 coding projects 永遠是 Mnjul’s Intimate Home,設計 & 自幹最多 tooling、frameworks/libraries 也一定是在 Mnjul’s Intimate Home 率先套用;每沒幾年就想炸掉 Mnjul’s Intimate Home ,然後重做新設計、用新技術、寫新內容。

那麼,就放 Personal Websites 吧--而且既然不是 portfolio,也就不要放 coding projects 吧!當然,已經選定了軟體工程師的職涯,還是要有一個地方正式放 coding projects,所以在此之前,我也先將我的 CV ( 這邊採取美國學界的用法,是很細節的 curriculum vitae,而不只是「履歷」的意思 )諮詢 Eka 的意見修改排版、美編,並套用 responsive web design。就希望訪客如果要知道我的專業層面,請直接看 CV 。

這麼一想,確實,我其實沒什麼體現到日常生活的 hacker 精神或是 maker 精神喔,怪不得面試某些公司都不會上(?)。

 

到底怎麼設計?設計感要從哪來?

這問題當然就問最近剛拿到 Parsons 設計學院的數位與科技藝術碩士學位的 Eka 啦。不過,其實釐清了網站的目的,其實文字跟區塊排版似乎就不那麼困難了。( 上面的有些想法,也是邊在 Adobe XD 邊設計的時候,邊整理出來的。)

對,Adobe XD--我決定這次不只有在紙上隨便畫畫幾下就直接跳到 HTML + CSS coding,而學著用最近才發表的 Adobe Experience Design。不過,因為這是靜態網站,我大多還是以 wireframing 為主,不太需要 prototyping,所以大概只用了 Adobe XD 的一半功能。說到底,以前我都是用( 已被 Adobe 棄之不顧的 )Fireworks 做這部分的設計,但很少真的認真做( 每次都是有個 fu 就開始 coding 了,但實際上有很多細節沒考慮到 );不過 XD 有一些滿方便的功能,所以用起來還算順利,沒有想要中途放棄的感覺。

不過,沒想要中途放棄,也可能是回答了「設計感要從哪來」的問題:採用了 Eka 的建議,每個段落都放上一張橫幅滿版的背景照片( 只要跟那個段落的主旨有一點點相關就好 );我攝影作品跟經驗也算行,要立即為了特定需求拍一張心想的照片也能勝任,所以一放下去,真的是設計感大升喔,如下:

[ 不管怎樣先放些照片當背景吧 ]

 

Round 1 (Desktop view)

說到底,雖然現在是 2016 年,我也真的要開始做 responsive web design,但我也還是沒有要做 mobile first;再怎麼說,很多我其他的東西也都還沒有 RWD,甚至還有用 Flash 的咧。所以先從 desktop view 開始囉。

Design

如上述,這次逼自己用 Adobe XD 至少把全部的版面都畫出來,圖示/縮圖也都找好、生好、放好,字也都定稿定得差不多了,才算完成設計的階段。比起年代久遠的 Fireworks,XD 有頗聰明的 grid snapping / aligning to other elements,也會提示「目前放的東西跟前一個人的距離」,有沒有跟「前一個人跟前前一個人的距離」一樣。

從上面的那張圖開始,為了讓連結們能更有存在於另一層視覺結構的感覺,又再把連結的圖示/縮圖縮小,並加上 frosted glass,整體感覺就好多了;另外,也去配色網站選好了不用背景照片時的單一色塊的色系們:

[ 大致的版面設計 ]

對我來說,這階段除了視覺設計以外,最重要的部份其實是上面說的「稿都定好了」--也就是文字內容。以往,這階段的文字寫作都是和 HTML / CSS 甚至 JavaScript coding 同步進行;但同一段時間內,要連續切換左右腦,說實在有點困難;再加上有的時候 debug 累了,文字內容就會草草帶過。此外,內容的長短也會影響 CSS 的設計,所以以前在文字方面,有時會得過且過。這次先有了主軸,在設計階段只要負責把字打好打滿,就不用擔心這些事情。

Implementation

因為是相對靜態的網站,以我現在的功力,用 Adobe XD 弄好設計之後,其實沒兩三下就刻出來了。 Adobe XD 提示各個東西和別人的距離的功能,在這時候特別派得上用場。

因為唯一的互動功能就只有「Photography 段落有按一下才展開所有連結」,但這實在太簡單了,所以我直接用 vanillajs 刻,完全省掉 jQuery。不過我為了寫得順手,也就放棄了 IE 9( 用了 Element.classList,也用了 requestAnimationFrame,下述 )便是。

Section Backgrounds

說實在,因為太好刻了,所以也要求自己,能用 CSS 解決的問題就不要寫 JavaScript。當然就也允許自己使用 vw 單位以及 calc()。這邊來說說怎樣用純 CSS 做 desktop view 的每個段落的背景。

Desktop view 每個段落的高度是固定的( 在最小的 desktop view 寬度之下,也不會 overflow 高度 ),寬度則是 100% viewport width;連結的那塊永遠是 40% 寬。視覺上,每個段落是一張背景照片,只是連結那塊有 frosted glass 的模糊特效。這邊 frosted glass 依然由 CSS blur filter 搞定。因為 CSS blur filter 沒辦法 blur 下一層的東西,實際上的操作麻煩許多:必須右邊那塊有自己的背景,然後再只針對背景上 CSS blur( 不然就連文字也一起模糊掉啦 )。但左右兩塊的背景又要能接起來,所以要特別下些功夫。

所有背景照片都比每個段落還不扁( 這邊扁的定義是寬大於高 ),在仔細研究後,發現主要訣竅在左右兩塊都設定 background-size: 100vw auto,左邊那塊的 background-position-x 設定 left ,右邊那塊設定 right,這樣就會好好接起來了!不過,因為我實際上都將拍好的照片不裁切就放上,可能會想要有 y 軸的位移,就得要設 background-position: left 0 bottom -300px 之類的東西( 大多瀏覽器還不支援 x y 分開設 )--然後,不知為何, Chrome 在吃這個 4-value background-position 的時候就完全爛掉了,所以我就只好用 background-position: 0 calc(100% - 300px) 來偷吃步一下啦。

不過這樣單純接起來,發現左右兩塊的接縫的視覺效果不好,會隱約透出 body 的背景色。所以就只好把左右兩塊都再放在一個 container 裡,然後那個 container 再套用背景照片。直接套用左邊那塊的 background CSS 就沒問題了喔!畢竟是寫 background-size 設定的寬度是 100vw。另外,右邊那塊也要設定 overflow: hidden,模糊特效才不會溢出去( 關於 frosted glass 的操作,像是如何使用 pseudo element,要怎麼調整 position 跟設定 z-index 才不會蓋住內文、有正確的大小,網路上的討論已經很多了,這邊就不贅述。)

不過,實際上還是得寫一點 JavaScript:Photography 段落在展開所有連結的時候,就比照片還不扁了:使用 100vw 當做背景照片的寬,背景照片的高度可能不夠蓋滿整個段落。這個時候,並無法使用 background-size: cover,因為瀏覽器算 cover 時,會使用左右兩塊各自的寬度,而非( 上述的 )container 的寬度,就會算出錯誤的大小,照片就接不起來了--只好用 JavaScript 算清楚現在到底要把背景照片設成跟 viewport width 同寬,還是跟段落高度同高,然後再將正確的 CSS class 套用到 Photography 段落。( 用 CSS class就可以搞定囉,不用設 Element.style,因為段落高度是固定的。)

Tooling & Deployment

這次,依然用了各種 font icon。以前我都特別仰賴 FontAwesome 的 icon,不過這次發現 entypo 的一些圖也滿好看的。因為 entypo 現在不直接提供字型檔,所以我就只好找 fontello 來生成字型檔。不過既然都要用 fontello 了,就也順便把 FontAwesome 我要用的 icon 抓進來,最後生成只有我需要的 icon 的字型檔。因為不太會有改 font icon 的需求,這部份就只有靜態地做一次而已。

這次依然使用 LESS,然而跟以往的偷懶作法不一樣,不把 less 檔吐給瀏覽器做 client-side compilation,而在我 deploy 的時候就先 lessc 做掉。講得好像我有用 deployment tool --實際上是沒有。因為我總共也只有一個 less 檔、一個 js 檔,所以所有的 deployment 步驟我都是手動在 terminal 下的。

我曾經有在 Sublime 裝存檔時自動 lessc 的 plugin,但後來發現不盡理想:我有的 sublime project 不想要存檔的時候自動 lessc,然而 Sublime 沒辦法 project-wise enable/disable plugins 。因為我都是同一時間 Sublime 這個 process 開了好多不同的 project( 但也沒關掉,就只是開著,想做哪個 project 或得做哪個project 的時候就去動它 ),頭就大了。啊,如果 Sublime 可以 project-wise enable/disable plugins 的話,我一定會付錢買授權。

 

Round 2 (Tablet / Phone view)

說到要做 responsive design ,有額外的 wireframing 好像顯得更重要了,原因如下:理論上,在寫 RWD 的 CSS 的時候,在 media query 之內,應該只要多寫這個 media query 得蓋掉( 正確來說是「cascade」喔 )的規則。但如果直接去改 CSS,因為要邊想視覺設計,邊跟「cascading」這件事搏鬥,有的時候真的恨不得可以先在 media query 內先狠狠地引入一次 CSS reset 再重頭開始寫--不過這樣當然是多餘得很。所以,先在 Adobe XD 設計好,再直接照著無腦改 CSS,確實輕鬆許多。

Design

實際上,因為我做 tablet / phone view 只是想要能用正確的 viewport & font size 呈現內文給來訪者看( 如前所述,對外連結大多都 mobile unfriendly ),所以也沒有太多花心思在設計小版面。能用的 viewport width 變窄,首先要改掉的就是左右並排的段落介紹文字跟連結區塊--改成上下排列。還是 tablet view 的時候,連結區塊就可以分兩欄,是 phone view 的時候,就分一欄。

因為是靜態網站( 對了,因為介紹跟連結改成上下排列,所以 Photography 段落就直接預設展開了 ),實際上互動的部份並沒有針對「tablet view」或「phone view」有設定什麼區別;這兩個 view 的差別其實只是我 media query breakpoint 隨心所欲設定的,看寬度壓縮到什麼時候才只能顯示一欄,這樣。這麼說來,確實也是覺得 RWD 的 media query breakpoint 不應該設定成特定的 device width & height ( 了不起,device 的差異應該是 touch-enabled or not ),而是要根據內容在遇到哪個 width & height 的轉變時得要有不一樣的呈現方式,來決定。

用 Adobe XD 先做 wireframe,最大的好處是可以快速模擬在每個 breakpoint 前後的內容應該長什麼樣子。例如,我最後決定 breakpoint 是 600px 跟 1024px,用 XD 拉一拉我馬上就可以知道 599px ( 一欄 ) 跟 600px ( 兩欄 )的視覺設計差異;以及,雖然是同一組 media query,但 600px 跟 1023px、599px 跟 320px 的邊界距離要怎麼擺。這也讓實際在寫 CSS 使用 vw 單位跟 calc() 的時候可以更無腦,把數學式算出來,就一定沒問題了。

[ 不同的 viewport 大小所用的各種設計概念 ]

另外,改成上下排列,本來拍成 landscape 向的背景照片就變得不怎麼有意義了,只剩下裝飾用途;Writing 段落跟 Music 段落則可以把背景圖片置中,至少還看得到一些端倪。

Implementation

實作方面,最花時間的自然是把本來的左右並排的段落介紹跟連結改成上下排列。不過在做 desktop view 的時候,心裡已經有個底,所以沒把 HTML 結構弄得太複雜,要拆 CSS 還算簡單。

另外,遇到 Chrome 不知道為什麼明明可以顯示兩欄的時候,卻只顯示單欄,調整 column-fill 也沒用的情況。

CSS 一長大,要在檔案內快速找到想要的東西就變得麻煩了。這時候 Sublime 的 minimap 就很可以派上用場:

[ Sublime 畫面;用的是 Patrick Gillespie 的 Text to ASCII Art Generator ]

Section Backgrounds

現在,最大的問題變成連結區塊的背景如果還要做 frosted glass 的效果,就麻煩些了。問題有二:

  1. 介紹區塊的高度跟連結區塊的高度都是動態的( viewport width 已經決定了文字能有多寬,高度便由瀏覽器自己 reflow 出來的結果才能知道 )。
  2. 整個 container 常常會比照片不扁( tablet view 很寬的時候,整個 container 才有機會比照片扁 )。

1 跟 2 加起來,結論就是要寫 JavaScript 了:每次 resize 的時候,搞清楚現在 viewport 有多寬,上面的介紹區塊跟下面的連結區塊各有多高( 這樣就知道 container 有多高 ),然後決定背景照片應該以 container height 當高度,還是以 viewport width 當寬度,才能正確覆蓋 container--接下來,再搞清楚連結區塊的背景照片要多大,然後放置正確的 background-position,才能好好上 frosted glass 特效。整體來說,最麻煩的部份在於連結區塊的高度必須維持由瀏覽器 reflow 好後用 Element.getBoundingClientRect() 算出來,而不能用 JavaScript 硬設--這樣連結區塊及內文在每次 resize 的時候才會有正確的高度。

這麼一來,要用 JavaScript 操作 DOM 的機會變多了,用 vanillajs 就變得痛苦了些--不過我還是決定一鼓作氣用到底,連 ES6/ES7 shim 也不用。結果連 Object.values() 都自幹出來啦。然後,為了避免每次 resize 事件發出來的時候都做這些複雜( 而且還修改 CSS 並得讓瀏覽器重新套用 blur filter )的事情,另外也用了 requestAnimationFrame 做 throttled resize。實際上在 iPhone 6 跟 iPad Air 還有 Nexus 5 操作起來都還滿順的,也不算真的寫了很多很髒亂的 JavaScript( 能夠只套用 CSS class 的東西,就不操作 Element.style ),棒棒!

 

Final Thoughts

On The Process

綜合起來,標題所說的「Creating」應該是「Designing」+「Implementing」。雖然只是個靜態的個人網站,沒必要用完整套 design process,但這次好好在 Adobe XD 下功夫,感覺成效還不錯。或許之後不管什麼類型、大小的網站,也都可以這樣試試看( 之前在 Coursera 修 HCI 課的時候,沒跟著做完整的 project。)

這算是我第一次好好做 RWD。其實,我不太確定先設計 desktop view,再往 tablet view 跟 phone view 設計的 方向是否正確--但總之,我知道我沒有要 mobile first,以及這相對靜態的網站,在不同的 view 也沒有多少東西是會特別隱藏或顯示的,了不起改改排版位置而已( 疑?不過這樣好像才真的是 「responsive」,而不是規定每個 viewport 要有自己的 template )。

On Browsers

這次的意外發現是,Microsoft Edge 對於標準的相容程度已經非常出色了( 其實 IE 11 也不賴,只是 CSS filter 出不來而已 )。怪不得有自信可以謊稱自己是 Chrome!另外 Edge 更新的速度也快,希望微軟繼續加油。

然後,font icon 顯示在 Firefox 上面的位移,跟顯示在 Chrome 上面的位移有顯著的差異。不知道是否是因為給 fontello 包裝過?還是有其他的原因?總之,我投降了,最後還是以 Chrome 眼見的結果來調整。( 開發的時候都使用 Firefox Developer Edition。)

On Tooling

另外,也不甚確定是否要正式引入一個 deployment process --但我實在覺得 Gulp 跟 Grunt 實在還是…嗯不多說,也讓我想起當時 Gaia 一直卡在使用 GNU Make 的情況。這麼說來,以我目前的需求,就算加上 minification,其實 GNU Make 也還是堪用。畢竟我沒有要拉一沱 dependency 下來啊( 看看隔壁棚的npm )。

以及回到是否要繼續使用 LESS( 而不跳槽到 SASS )的問題:一開始我決定投入使用 LESS,原因之一是噗浪在用,另一個原因是我懶得做 deployment 時的 pre-compilation,就想要直接把 less 檔吐給瀏覽器自己做 client-side compilation--而 SASS 沒提供這個功能。但把 less 檔吐給瀏覽器,畢竟 client-side 要下載的東西變多,而且這樣我沒辦法把 normalize.css 放在同一個檔案減少 network request,也是不太好( 還會增加我 CloudFront 的支出咧 )。這幾年覺得 LESS 的火熱程度還是不如 SASS,如果我決定不需要 client-side compilation 的話,是不是要跳槽到 SASS?

 

總之,謝謝 Eka 的各種設計支援啦!希望這新首頁可以多撐個幾下。

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *