Feature Label Area

2015年11月17日 星期二

Tagged under: , , , ,

Mac OS X 10.10 Yosemite 上建立 Ruby On Rails 環境

之前 Mac 還沒更新到 Yosemite 時,已經建立過一次 ROR 的環境,但不知怎麼搞的,這陣子要重拾 Ruby On Rails  卻一直無法建立新專案 ,頻頻出現錯誤,brew doctor 也一堆 warring,搞了一整天,好不容易在 http://localhost:3000/ 看見畫面了,寫下來紀錄一下。

起因: 無法建立 ROR 專案:
Rails is not currently installed on this system. To get the latestversion, simply type: 
$ sudo gem install rails 
You can then rerun your "rails" command.
照著指示執行:
$ sudo gem install rails
也是錯誤百出:
ERROR: '/bin' is not writable - it is required for Homebrew, try 'brew doctor' to fix it!
Warning .... 
Warning ....
瘋狂鬼擋牆,一怒之下決定直接砍掉 user/include 整個資料夾,一切重頭開始(淚)

TIP:
user/include 在 mac 裡是隱藏檔,要說密語下指令才能看見: mac 下顯示隱藏檔:
$ defaults write com.apple.finder AppleShowAllFiles TRUE && killall Finder
恢復原狀,mac 下不顯示隱藏檔:
$ defaults write com.apple.finder AppleShowAllFiles FALSE && killall Finder

開始囉!
決定要重頭開始時,先看看自己有的版本是什麼,畢竟電腦被我用得一團亂

$ gcc --version
$ brew -v
$ git --version
$ ruby -v
$ rails -v
$ rvm -v

1. 安裝 Homebrew
目前網路上找到的教學頁面,Homebrew 連結大部分都已經不存在,建議直接到官網去抓:http://brew.sh/
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
安裝完後跑 brew doctor,應該會得到 Your system is ready to brew 的系統回復,就代表成功了。
$ brew doctor

2. 安裝  rbenv
我原本是裝 rvm,這次換到 rbenv,沒有好或不好,很容易被洗腦,跟我一樣情況的,可參考這篇文章:從 rvm 轉換到 rbenv

新的使用者,可以直接安裝 rbenv
$ brew update 
$ brew install rbenv ruby-build 
$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile 
$ echo 'export PATH="$HOME/.rbenv/shims:$PATH"' >> ~/.bash_profile$ source ~/.bash_profile

3. 用 rbenv 安裝 Ruby
$ rbenv install 2.2.3    # 安裝 Ruby
$ rbenv global 2.2.3     # 預設使用新的 Ruby
$ ruby -v                # 確認目前本版是否正確安裝

4. 安裝 Rails
$ gem install rails -v 4.2.4    
$ rbenv rehash     
$ rails -v       

5. 建立 Rails 專案
$ rails new myapp       # 建立 myapp 專案
$ cd myapp              # 開啟 myapp 專案資料夾 
$ rake db:create        # 建立 database
$ rails server          # 開始跑拉!

好了,可以從 http://localhost:3000/  檢視網頁了。



參考資料:

1.  Gorails  ***** (大推薦,要建立 git 或 mysql 都可以看這篇)
https://gorails.com/setup/osx/10.10-yosemite
2. vinn's  (新手推薦)
https://vinn.tw/blog/install_ruby_on_rails_yosemite.html

2015年1月17日 星期六

Tagged under: , ,

[ 色彩 ] 不要在你的畫面中使用純黑色 #000000

色彩技巧其中最重要的一項就是避免使用純黑色,第一次聽到是從童年的美術老師,更多次是來自 RISD 學院(羅德島設計學院),不要使用黑色?聽起來很奇怪,但他是一個很好的建議。

想想看,有時候我們看到黑色的東西,有時候並不是純黑色,也就是,我們很難找到純黑色的東西,例如:道路不是純黑色、辦公椅子不是純黑色,網頁不是純黑色⋯⋯

陰影不是黑色
普普藝術畫家 Wayne Thiebaud ,他的畫是陰影不是黑色的完美典範

Wayne Thiebaud 的陰影是一些畫中最飽和的部分,在螢幕上顯示也是一樣,在紙上也非常完美。
你可能會覺得「但這些都是畫,他們不是真的,真實的狀態下陰影就是黑色的

有個燈泡的例子,一個藍色的燈泡裝在一個白色的燈罩上面,打開燈光時,燈泡亮起了藍色的光,而他的陰影卻是一個橙色的色調,不是黑色。


這實驗令人吃驚。

而現在,我喜歡走在街上尋找最飽合的陰影


該圖片最深的顏色不是000000,而是#130f30(這是 19% 的亮度和 69% 的飽和度)

黑色摧毀了一切
試試看,當你把任何 icon 或圖像放在純黑色的色塊旁邊,純黑色完完全全壓倒性勝利,完全脫穎而出你的畫面,意味著他不自然。

日常生活中,所有你周遭的 “黑色” 日常物品,如果有光線反射,代表他們不是純黑色,他們是深灰色(dark gray),而這道燈光有可能是一個色彩,所以他們甚至不是深灰色(dark gray),而是色暗灰色(colored-dark gray)




而在視覺畫面上,你可以從 Dribbble 搜尋更能明白「純黑色」與「黑色」哪個看起來比較好?

純黑色
黑色

飽和度也很重要
除了遠離 #000000 之外,使用灰色時你還可以給他一點色彩,讓他們看起來不會太沉燜。
以這個網站為例https://segment.com/
灰底的部分,文字跟背景都添加了少量的黃橙

再來來看看Facebook,
為什麼 Facebook 的 App 感覺這麼協調?


因為所有這些灰色都充滿了Facebook 的藍色。

結論
當你發現 #000000 在你的畫面中時,
你要問問自己,真的需要純黑色嗎?
如果你需要黑色,你必須設法讓他在畫面中看起來更自然。


via 
http://ianstormtaylor.com/design-tip-never-use-black/



2014年10月22日 星期三

Tagged under:

[ UI ] 穿戴式技術對介面設計帶來的影響

SmartWatch 僅僅只是個開始,隨著問世的 Android WearGoogle Class、和未來的 Apple iWatch ,世界正慢慢的開始轉變成“穿戴”舒服的科技產品,取代“攜帶”。

以後「帶著一台電腦坐在咖啡廳的現象」漸漸的會轉移成用戶與互聯網的交互設計


到底什麼是可穿戴技術?


可穿戴技術可以是衣服、或是配飾,目前大多穿戴技術設計帶於手腕或眼鏡的形狀,輕量。已健身工具為例,目前普遍使用和方便的可穿戴技術 Fitbit 、 smartwatches 和 pebble。

大家熟知的 Google Class ,雖然現在的成本讓大多人望之卻步,但就如一般科技產品,最終激烈的市場將會推動價格合理的成本,而當這時代來臨時,你將要準備好面對一切。

為什麼網頁設計師需要關注可穿戴式產品?


83% 專家認為可穿戴技術會在未來的 10 年大幅度成長,到 2025 年將會完全沈浸在物聯網( IOT ) 。這意味著用戶將來自不同平台觀看網站,而不僅僅只是筆電或其他移動式設備。

隨著穿戴式技術的擴大和更多用戶的接受度,更多使用者會希望他們訪問的網站有提供此技術功能,如果屆時你沒有準備這樣的技術,客戶將會另尋其他網站來滿足他們的需求。

雖然可穿戴式技術正處於起步階段,但他目前快速成長,所有的可穿戴技術基本功能都已到位,例如瀏覽、社交媒體、即時聊天、攝影鏡頭、視頻。可穿戴技術的未來,將包括創建一個美麗而實用的網站,讓使用者能夠有效的訪問他們所關心的訊息。

如何將穿戴技術結合你的網頁設計


之前“可移動裝置”挑戰了網頁設計的設計方向與思考邏輯,現在,毫無疑問的,可穿戴技術將會再次影響你的網頁設計,問題是該怎麼做?

1.  響應式設計


響應式設計應該要被重視,統計到 2014 年,目前只有 3% 的網站是符合響應式設計且敏感又快速。

2. 訊息是即時的


及時的訊息是穿戴式技術的重點,這意味著如果你的網站無法提供此訊息,將會減低用戶的造訪率。為什麼訪問者要在你的網站?必須先搞清楚你的網站對使用者來說什麼訊息才是最重要的,其餘的元素就可以斟酌顯示或隱藏,讓網站思路變得更清楚。

3. 互動就是一切


一個網站不應該只是靜態,就像是一只漂亮的花瓶。

4. 極簡設計


極簡設計的趨勢已經存在一陣子了,期望這坡趨勢會走得更久,因為極簡設計比起其他設計更能被穿戴式科技產品所接受,因為界面不會被一些漂亮而無用的 icon 所淹沒。很多時候,網頁設計師對於作品過度風格化,希望讓使用者留下深刻的印象,但其實,最難的設計其實是創造一個安靜的設計,顯山露水,這才是一個成熟的設計師。

5. 文字越來越大


以前的網站字級越大,就會被歸類為“俗”那類,所以即使看到眼睛瞎掉,網間還是充斥著 12px 的文章,甚至是 10px  ⋯。行動裝置漸漸取代電腦,穿戴式技術的興起,小文字終於不再被使用者接受,也不再為主流。

6. 不要再有彈跳視窗了!


無論彈跳視窗設計多麼漂亮,一直都不喜歡他出現在我的網頁中。但這可能會有一點爭議,無論如何,至少目前為止,穿戴式科技沒有足夠的空間供彈跳視窗出現的位置。
如果您的設計必須有一個彈跳視窗,那請設計一個巨大的關閉按鈕。

7. 網頁設計必須是直覺的


想想,為什麼會有訪客透過穿戴式技術連結到你的網站,無論是尋找資訊或是任何指示,甚至是優惠卷等等,無論是什麼需求,你的網站必須了解並引導使用快速找到他們想找的資訊。
所以直覺的網站設計無論在任何時候都是重要的,因為用戶沒有耐心...。



via http://webdesignledger.com/trends-2/how-wearable-technology-will-impact-web-design




2014年5月24日 星期六

Tagged under: , ,

[ UX ] “ OK 按鈕 ” 與 “ Cancel 按鈕 ” 擺放位置順序的微妙關係

當設計師設計對畫框畫面時,常常思考「確定」與「取消」按鈕的放置位置。根據他們的功能或使用者習慣,什麼是最好的?哪個又該放在前面?






平台的一致性?

許多人面對這個問題時,最常看見的解決辦法就是「 跟別人一樣就對了」,例如 windows 把 「確定按鈕」放置第一,我們就應該遵循這個原則。雖然這看起來像是一個解決問題的方法,但實際上它不是。設計師應該要去思考放置這兩個按鈕位置的背後原因和用戶體驗。

「一致性」是設計師常常說的話,也是一個受歡迎的藉口。但若不深思熟慮用戶所面臨的問題,一昧的追尋所謂的“設計法則”對用後又有什麼益處?如果設計師根本不知道某設計為何存在。又或者,某些“設計法則”其實是對用戶不友善的方式,但設計師只為了借助平台的「一致性」,以為就能解決所有的問題?

其實平台設計的一致性不應該只是為了滿足設計師,一個真正的設計師是需要了解問題的根本或這更深的層次,並了解為什麼應該這樣設計。


為什麼「確定」按鈕放在畫面右側比較好

當設計師開始思考按鈕的放置位置, 可能會覺得唯一的辦法就是要讓用戶測試。如果是一個資歷較淺的設計師,還不太相信自己的判斷時,這可能會你唯一的方法;但如果是一個經驗豐富的設計師,他們可以從用戶的角度來看這項產品或頁面時,那麼就可以通過設計分析來解決這個問題。

從「使用者眼球流程」來判斷

有些設計師認為,把「確定」按鈕放置在左側對用戶是最好的,因為這樣就更接近使用者的眼球瀏覽順序,聽起來是有道理,但你不能忽略使用者習慣,使用者不會貿然決定點擊任何一個按鈕,當他們還沒看到所有的選擇之前。這意味著,大多數的用戶不會盲目地點擊他們眼球看到的第一個選項。

 當「ok」按鈕放置在左側時:
使用者眼球必須看完所有可以選擇的按鈕,才會返回來點擊
當「ok」按鈕放置在右側時:
當使用者確認看完所有的按鈕,眼球也朝一個方向流動,
順著進行點擊的動作。

以上兩張圖明顯表示,下圖帶給用戶更快的視覺流程,用戶在每個按鈕上注視的次數只有一次,所以以速度或是用戶使用上的流程來說,「確定」按鈕放置於右側是好的。

從「按鈕功能」來判斷

按鈕功能?簡單來說就是當用戶點擊「確認」或「取消」按鈕時,他希望應用程式給他什麼 feedback?

「確定」按鈕是當他們完成該頁 閱讀/填表 完後點擊的按鈕,並把它們推進到下一個頁面。「取消」按鈕是讓用戶回到原始狀態,回到上一個動作,例如清空所有已填寫的欄位。

這樣的判斷類似分頁按鈕的位置,以使用者到「下一個」的按鈕放至右側,而需要使用者返回到「前一頁」的按鈕位置放在左側。這樣也反射到使用者的閱讀和導覽方向,「右進、左退」,這樣直覺的思考也便於用戶理解。


為什麼按鈕不能分別放在 左下角 及 右下角 呢?

是啊,就上面理解來說,那為什麼不能直接把「取消」「確定」按鈕各放置於左下角,這樣不是更能直覺思考導覽模式嗎?
OH~NO NO NO,因為「取消」「確定」按鈕不是完全屬於 “分頁”按鈕,所以就方向性嚴格的區分其實是不必要的,這樣反而弊大於利。



除了按鍵之間巨大的視覺分離使得操作變得困難之外,在功能上,使用者如果不能直接看到該程序有“撤回”的關鍵動作,反而會覺得不安。(就像 Ctrl+ Z 功能,在軟體操作上來說很重要一樣)。

所以讓使用者可以看到「取消」按鈕隨著「確定」按鈕放置在旁是很重要的,因為取消按鈕對於使用者來說,也是一個安全按鈕,以防有任何想要“撤回”的步驟,而且放置一起,也讓使用者能更高效率地去二選一中採取最佳的下一步行動。


為什麼按鈕要放在頁面的最右下角?

放置於右下角是為了讓用戶更方便點擊,它遵循了 Gutenberg diagram (古騰堡圖表) 的瀏覽模式:


右下角的位置剛好是使用者瀏覽順序的最後一個區塊,把按鈕放在右下角的位置剛好可以讓用戶閱讀完文章後決定所要採取的行動按鈕,順勢進行點擊的動作。

結論

當真的了解為什麼“確認按鈕”要在畫面的右下角時,同樣的觀念就可以用在更多設計思考層面上。
當然,除了按鈕的位置很重要之外,要注意的還有按鈕視覺比重與文案撰寫。



via 

2014年5月23日 星期五

Tagged under: , , ,

[ UX ] 為什麼使用者不會點擊首頁輪播圖片


Erik Runyon 網站研究首頁輪播圖片點擊率發現300萬的主頁訪問量僅約1%的人會點擊輪播圖片。下面的研究結果是從2013年01月01日 至 2013年6月30日,長期觀察五個網站的首頁輪播點擊效果:

網站 1:
首頁訪問量:3,755,297
點擊每個輪播位置的百分比:
第 1 張:89.1%
第 2 張:3.1%
第 3 張:2.4%
第 4 張:2.8%
第 5 張:2.6%


網站 2:
首頁訪問量:37,688
點擊每個輪播位置的百分比:
第 1 張:71.07%
第 2 張:7.13%
第 3 張:6.71%
第 4 張:8.18%
第 5 張:6.92%


網站 3:
首頁訪問量:43,724
點擊每個輪播位置的百分比:
第 1 張:54.57%
第 2 張:17.87%
第 3 張:10.84%
第 4 張:8.75%
第 5 張:7.97%


網站 4:
首頁訪問量:8,210
點擊每個輪播位置的百分比:
第 1 張:62.1%
第 2 張:15.32%
第 3 張:12.1%
第 4 張:10.48%


網站 5:
首頁訪問量:26,900
點擊每個輪播位置的百分比:
第 1 張:84.81%
第 2 張:4.48%
第 3 張:10.71%


輪播圖片的點擊效果差到令人吃驚。

大多數的輪播區塊都有兩張以上的圖片,第一張圖片都嘗都得到最多的點擊,但第二張之後的點擊率都急劇下降,這樣的點擊效果通常問題都不是出現在圖片身上,而是輪播ux設計,例如輪播區塊的導航列。



以左圖來說:
單以箭頭圖 icon 顯示,沒有任何的導航訊息,也沒有描述任何訊息讓使用者清楚知道若他點擊 icon 時會得到什麼樣的 feedback ,簡單來說箭頭 icon 就是告訴使用者「這裡有很多圖片,但不知道有沒有重要的圖片」,這樣的結果通常是使用者不會看過第一張以外的圖片,因為最後使用者會忽略它,把注意力放在其他更豐富的訊息上。
另外就 ui 層面來說,單以箭頭圖示,如此不顯眼的 icon,放在最邊緣,有時候有些網站還會做成半透明,也難怪用戶點擊率不高。

以右圖來說:
使用者需要的是一個明確、醒目的標籤導航。而標籤內容是豐富、有意義、精確描述使用者想要要什麼的訊息。這樣會刺激使用者的點擊率,因為導航明顯告訴他們,若他們點擊什麼,他們便會得到什麼。
另外就 ui 層面來說,一個含有文字的導航列也較大,並放置在一個明顯的位置,而不是以icon 顯示,這更讓使用者容易看到。 

2014年5月7日 星期三

Tagged under: , ,

[ 設計好幫手 ] 推薦給設計師的 Photoshop 自動切圖軟體 Slicy(Layer Cake)

根據 想提升工作生產力,就別再做這七件事 一文中,提到一項是 停止作重複的事情,並使它自動化。

對於設計師來說,切板這件事常常會覺得浪費時間,但卻又不得不做好,這時找出一些有用的小工具,讓例行工作“切圖”這件事變得非常輕鬆,意外的還會讓你養成良好的工作習慣。

App Store:https://itunes.apple.com/tw/app/slicy/id512533449?l=zh&mt=12

這項軟體操作簡單,唯一的必備條件是使用 Slicy 前需要一個架構乾淨清楚的 photoshop 結構與命名。

後續只要將 PSD 拖進去 Slicy 的 APP 視窗內,就能自動生成切圖元件,事後只要一變更 PSD 內容,切圖元件則會自動更新,省掉非常多的工作量,聽起來是不是很神奇~~




當然,前提是必須先養好良好的PSD圖層管理習慣及命名。

命名規則

基本標簽
圖層或群組名稱的字尾打上.png 或 .jpg。
沒有打上副檔名的圖層資料夾則不會生成元件。

設定切圖尺寸

有時製作APP時,照文件規則會需要固定的尺寸,例如 64 x 64, 48 x 48, 24 x 24.。


方法有兩種:
  1. 將欲呈現的尺寸,使用形狀圖層畫出,命名為 @bounds 。生成圖片時,系統不會生成@bounds圖片。(如圖 red.png)
  2. 在資料夾上使用向量遮色片 (如圖 yellow.png) ps. 若在圖層上使用向量遮色片則會出面錯誤 (如圖 green.png)
製作 Mac Icon 

方法:
只要把副檔名改成.icns

製作兩倍尺寸或1/2尺寸的圖層

方法(寫法):
1. 放大2倍:圖檔名稱@2x.png
2. 縮小1/2倍:圖檔名稱.png+@2x
ps . 記得做向量圖檔,不然放大會糊掉哦

另外這裡有一個貼心的小功能,原PSD檔的星星尺寸為基數(85x81),Slicy 會自動把尺寸各加上1px的空白,讓數字變成偶數時,再放大or縮小。

最後,最厲害的就是當你按上方的  save 存檔時,Slicy 會詢問是否要自動更新元件,這時候選擇右邊 Automatically,當你事後更改PSD時,就不用每次修改一次 PSD 還當個傻子慢慢存檔了!




是不是方便極了~~~~~~~~!
官網可以先下載試用哦  http://macrabbit.com/slicy/


2014年4月27日 星期日

Tagged under: ,

HTML5 sectioning 元素, 標題 及文件大綱(Outline )

開發 HTML5 網站時,有時只注重視覺的呈現或寫 code 的技巧,而忘了 HTML5 很重要的 Outline (大綱)。

Outline 是什麼?
以 yahoo 為例,Outline 為右邊的形式


為什麼開發網頁時要注重 Outline 呢?
除了讓瀏覽器快速解析網頁的主要架構,有助於 SEO 之外,讀取的速度還可以加快,所以開發 HTNL5 網頁時,了解並製作正確的 Outline 為首要且重要的一個課題。

如何得到解某網站的 Outliner ?
實用的小工具網站(HTML 5 Outliner)http://gsnedders.html5.org/outliner/

如何編寫正確的Outline?(以下正文開始)

Sectioning

使用新的 sectioning 元素時(article,section,nav,aside),更需要小心 outline 的結構算法
為了方便理解,先看html4的結構

uThe HTML 4.01 outline

<body>
    <header>Site title etc.</header>
    <nav>
        <ul>
            <li><a href="/">Nav item</a></li>
        </ul>
    </nav>
    <article id="main">
        <h1>Article title</h1>
        <p>Article content.</p>
        <h2>Article sub-heading</h2>
        <p>More content.</p>
        <h3>Article sub-sub-heading</h3>
        <p>More content.</p>
    </article>
    <aside>
        <h2>Sidebar heading</h2>
        <h3>Sidebar sub-heading</h3>
    </aside>
    <footer>
        <h2>Footer heading</h2>
        <p>Footer content.</p>
    </footer>
</body>

會得到這樣的 outline
  1. Article title
    1. Article sub-heading
      1. Article sub-sub-heading
    2. Sidebar heading
      1. Sidebar sub-heading
    3. Footer heading
再來用相同架構(只是換了 tag 寫法)來看看 html5 出現的 outline 結果

The HTML5 outline

<body>
    <header>Site title etc.</header>
    <nav>
        <ul>
            <li><a href="/">Nav item</a></li>
        </ul>
    </nav>
    <article id="main">
        <h1>Article title</h1>
        <p>Article content.</p>
        <h2>Article sub-heading</h2>
        <p>More content.</p>
        <h3>Article sub-sub-heading</h3>
        <p>More content.</p>
    </article>
    <aside>
        <h2>Sidebar heading</h2>
        <h3>Sidebar sub-heading</h3>
    </aside>
    <footer>
        <h2>Footer heading</h2>
        <p>Footer content.</p>
    </footer>
</body>

得到以下 Outline
  1. Footer heading
    1. Untitled NAV
    2. Article title
      1. Article sub-heading
        1. Article sub-sub-heading
    3. Sidebar heading
      1. Sidebar sub-heading
此時會發現原本應該在底下的 Footering header 跑到 top-level ?!  而且顯示 “Untited NAV” (未命名)?!!

為何現在 footer 變成了 header?

原因如下:

首先,footer 元素不是 sectioning ccontent ,所以 footer 沒有辦法創造新的 section,而以層級來說,<h2> Footer heading </h2>是唯一在 body 以下的 heading,所以瀏覽器直接讀取 heading 來當 top-level 。

如何避免 footer headering 變成 page heading ?

我們可以把 footer 元素內容包在 section 元素內,如下:

<footer>
     <section>
          <h2>Footer heading</h2>
          <p>Footer content.</p>
     </section>
</footer>

演算結果 ( Outline ):

  1. Untitled BODY
    1. Untitled NAV
    2. Article title
      1. Article sub-heading
        1. Article sub-sub-heading
    3. Sidebar heading
      1. Sidebar sub-heading
    4. Footer heading

雖然感覺有點投機取巧,但輸出的結果的確把 footer heading 放置該有的位置,但現在的問題是 body 沒有 heading 了 ?!

NAV sectioning

現在我們有兩個未命名的 sections,先說明一下,為何 nav 有 “未命名” 的問題?
因為nav 是一個 sections 元素 ,所以依照 outlines 演算法來說,sections 會創造出自己新的 section 區塊。而依照 sections 元素預設應有 heading 的規則來說,nav 沒有輸入 heading 內容 ),所以這裡即顯示 “Untitled NAV” (未命名的標題)。

題外話:
不確定為什麼 nav 被歸列為 sectioning 元素。
導航列中的每個選單 li 都可以有一個標題來標簽他們,但因為這裡是一個 sectioning 元素,所以必須有一個 heading 放置在 nav 元素中去避免 “Untitled NAV” 的問題。

所以我們這麼做:
<nav>
     <h2>Main navigation</h2>
     <ul>
          <li><a href="/">Nav item</a></li>
     </ul>
</nav>

演算結果 ( Outline ):

  1. Untitled Section
    1. Main navigation
    2. Article title
      1. Article sub-heading
        1. Article sub-sub-heading
    3. Sidebar heading
      1. Sidebar sub-heading
    4. Footer heading


避免未命名的 BODY

為了避免 body 元素也成為 “未命名” 區塊,必須放置 heading 在其他 section 區塊外。
但這樣做的問題是,他阻止你放置的實際文件內容在 article 元素裡,而同時他也必須成為此文件階層最高的 heading。

解釋一下:
這裡的意思應該是希望 article title 成為 body heading ,但該如何做才能不影響實際顯示的內容而又成為 body heading,使 outline 演算後變成以下結構:

  1. Article title
    1. Main navigation
    2. Article sub-heading
      1. Article sub-sub-heading
    3. Sidebar heading
      1. Sidebar sub-heading
    4. Footer heading

但因為 article 只有在當你有多個 article 在同一頁面共享一個 heading 才有作用,而以這個例子來說,它可以是一個主頁或 blog 的頁面,所以一個頁面只放一個 article 是不合理的。

這裡想到幾種不同的解決方式:

a)  避免使用 sectioning 元素。

忘掉 section 元素移除的問題, 因為這樣 outlines 會變成跟原本的一樣,最明顯的缺點就是將會錯過任何使用 html5 元素的優勢,不理想。

b)  在任何 sectioning 元素外去重複的 article 標題。

重複的 article 標題,你有可能必須撰寫 css 去隱藏他們,只是為了它擺在 outline 正確的地方,可能不是一個好主意,無論視覺上或 SEO 優化上。

c)  把網站標題(site title)放置在階層最高的 heading。

有些人認為,網站名稱/Logo/組織 名稱的 heading 應該放在最高階層,但我不同意這個看法,我覺得這是文件標題是最重要的,當你拜訪這個網站的時候。

d)  避免使用 article 元素在單一個 article 頁面上。

要如何使用 sectioning 元素,但不換行的把單一文章頁的 article 元素

操作如下:
<body>
    <header>
        Site title etc.
        <nav>
            <h2>Main navigation</h2>
            <ul>
                <li><a href="/">Nav item</a></li>
            </ul>
        </nav>
    </header>
    <div id="main">
        <h1>Article title</h1>
        <p>Article content.</p>
        <h2>Article sub-heading</h2>
        <p>More content.</p>
        <h3>Article sub-sub-heading</h3>
        <p>More content.</p>
    </div>
    <aside>
        <h2>Sidebar heading</h2>
        <h3>Sidebar sub-heading</h3>
    </aside>
    <footer>
        <h2>Footer heading</h2>
        <p>Footer content.</p>
    </footer>
</body>

演算結果 ( Outline ):

  1. Article title
    1. Main navigation
    2. Article sub-heading
      1. Article sub-sub-heading
    3. Sidebar heading
      1. Sidebar sub-heading
    4. Footer heading

到這裡,已經越來越完整了,現在唯一的問題是到這裡, nav 沒有他適合的欄位區域(因為他並不屬於 Article title ) ,這裡很有可能會讓一些使用者感到困惑,解決辦法如下:

<header>
    <h1>Site title etc.</h1>
    <nav>
        <h2>Main navigation</h2>
        <ul>
            <li><a href="/">Nav item</a></li>
        </ul>
    </nav>
</header>

演算結果 ( Outline ):
  1. Site title etc.
    1. Main navigation
  2. Article title
    1. Article sub-heading
      1. Article sub-sub-heading
    2. Sidebar heading
      1. Sidebar sub-heading
    3. Footer heading

大概就這樣了,但我還是覺得 outline 沒有 site title 在裡面將無法更明白地表示出這是什麼網站,噗


via HTML5 sectioning elements, headings, and document outlines