July 12th, 2009 iPhone 的 Tab bar 與 Toolbar

嗯哼…。1

通常在 iPhone 軟體下方,你會看到兩種不同的按鈕列,且兩者無法共存:

  • 黑底白 icon:可以在 iPod.app 和 Phone.app 上看到。
  • 藍底白 icon:可以在 Mail.app 和 Safari.app 上看到。

這兩種按鈕列上面的圖案都是單純的符號,但是代表的意義不同。黑底的是 tab bar,用來切換軟體的不同畫面;藍底的是 toolbar,用來當按鈕發出指令。

Justin Wiliams 在 Die You Damn, Dirty Tab Bar 這篇文章裡提到:

Rather than taking the easy way and slapping a tab bar at the bottom of your UI, put the extra effort into the design process to see if it is possible to do the application using a single navigation stack. In most cases, I think the answer is yes. It may be a bit more work up front, but as your application matures (if it matures), you’ll find that the extra usable space along the bottom of your view will be much appreciated.

由於(標準的) tab bar 會永遠佔掉螢幕下方的空間,所以他認為開發者如果能不用到 tab bar,就盡量不用,未來要新增功能時,可以輕易在軟體下方添加新按鈕。

他以 App Store 為例(iTunes Store 亦同):

App Store 裡的各種 tab 如 Featured, Categories, Top 25 都是針對商店內容的不同瀏覽方式,也就是當做 filter 來使用。同樣的商店內容,也可以擠在一起,變成像 iPod 階層式的瀏覽方式,這樣的作法在使用上也不會有任何問題。

階層式的安排,雖然在切換到不同瀏覽方式時,需要多點一下,但會釋出下方螢幕空間供更多功能使用;使用 tab bar,雖可以在各個模式間快速切換,但螢幕下方永遠都不能再放別的東西。

對照一下兩個 Twitter client:Tweetie2 和 Birdfeed3 更可以理解這兩種設計邏輯的差異。

左為 Tweetie,右為 Birdfeed。

Tweetie 有黑色 tab bar,可以在各種頁面間切換。但是基本上這些不同頁面只是相同資料以不同 filter 呈現的結果而已,所以同樣的內容呈現也可以設計成 Birdfeed 這種形式:完全的階層式設計。

接下來,我隨便點一則訊息進入詳細畫面。

嗯…,你注意到以上兩個畫面奇妙的違和感了嗎?

Tweetie 下方的黑色 tab bar,竟然直接變成藍色工具列。

照理採用了 tab bar,應該要在任何畫面都顯示 tab bar,他提供的「快速切換」功能才有意義,但 Tweetie 這裡卻讓 tab bar 消失,以普通工具列取代。

再來看右方的 Birdfeed,點進 tweet 訊息的詳細畫面後,竟然沒有 toolbar 按鈕可用,設計者反而將按鈕變成內文的一個「欄位」:看起來是可以點進去下一層的「Reply, Favorite, Forward, Delete」等字樣,事實上被當成按鈕來用。

合理的設計方式應該是將兩個軟體的畫面互換,也就是說:

  • Tweetie 的訊息畫面應該是採用右圖的方式,將按鈕安排成普通欄位的樣式,並且保留下方的黑色 tab bar。
  • Birdfeed 則應該使用左圖的藍色工具列,把按鈕擺在 toolbar 上。

這樣一換,操作的感覺就會自然許多。

互換後才是對的?

為什麼這兩個很棒的 Twitter client 各自採用不合理的設計方式?為何兩者會形成「互換畫面才正確」的現象?

以我自己的經驗,也許可以稍稍回答這個問題。

在設計 UI 時,最困難(同時也最有趣)的是,設計者如何將各種抽象的行為具體化:即是將「行為」化為實際的「操作流程」。

當軟體的 UI 完成時,代表所有操作流程形成一個系統,在這個系統裡,在哪一個畫面可以做哪些事,是固定而且合乎邏輯的,只要達到這個目標,這個 UI 就幾乎算完工了。

仔細觀察 Tweetie 和 Birdfeed 的畫面,你會發現兩者在該畫面可以使用的功能其實是一模一樣的,只不過呈現方式不同。

對使用者來說,他們在這個畫面可以做哪些事非常清楚,所以功能不管是安排在 toolbar 或是跟內文放在一起,對使用者不太會造成影響。

回到之前的問題,Tweetie 為何會將本該永遠存在 tab bar 換成 toolbar?

只是單純沒有想到按鈕還可以用「內文欄位」的樣子呈現吧。他們發現空間不夠用了,但是又非要這些按鈕不可,只好把佔空間的 tab bar 換掉。這算是 Tweetie 的一個小瑕疵。

至於 Birdfeed,為什麼不在下面的空間裡放一個 toolbar?除了「設計者的堅持」外,我找不出別的理由,也許跟設計者個人美感有關。

結論

Justin 在文章中建議的:「不使用 tab bar,將下方空間留給未來利用」,正是現在 Birdfeed 採用的方式。

假設明天 Twitter API 多了一個可利用的功能,Birdfeed 也許只要加一個按鈕就能辦到,但 Tweetie (在不偷換工具列的前提下)就要多花點功夫。


  1. 這麼久沒寫文章的理由是 Leica,以後有機會再聊。 

  2. Apple Design Award 2009 

  3. Leo’s Favorite Twitter Client Award 2009 

2 Responses to “iPhone 的 Tab bar 與 Toolbar”

  1. July 13th, 2009 at 10:03 am

    Justin Williams Says:

    Upfront: apologies if I misread anything. Google Translate, etc.

    You do raise a good point about being able to hide the tab bar in subsequent views, which I in fact use in my application. Tweetie, Clock and iPod are the three apps that I think excel at using the tab bar more than anything.

    The main point I was trying to make was that the tab bar is fine in certain circumstances, but developers/designers should take the extra time to try and find a way to structure their application’s design without it because it can offer a better user experience.

  2. July 16th, 2009 at 1:29 pm

    Leo Says:

    Hi Justin,

    (I used Google Translate to translate my own article into English, and I have no idea what I was talking about. Terrible translation!)

    What I was trying to say is that, you made a good point about designing without tab bar, and only use it when necessary so the app has more room to grow in the future.

    This I totally agreed. In fact, after reading your article, I redesigned my app mockup without tab bar, and that solved lots of problems. The flow is smoother, and everything seems logical. I was surprised how much difference it made!

    I also suggest that Tweetie use inline text buttons like those in Birdfeed, so it doesn’t need to “swap” the tab bar into toolbar — The tab bar should be there all the time.