環狀使用者介面之我見

這篇文章純粹是要講我個人對 Circle UI 的偏好。所以如果你不欣賞 Path UI 的話記得別看下去噢 XDD 

大約將近一年前我有幸在某家公司參與全新版本功能的討論，又很幸運的我剛好是可以提供一些新 idea 出來被打槍的人，所以我就理所當然地提出了我『愛』的 Circle UI，我還寫 Code 去 demo 了。那天 demo 前我很興奮，我自己覺得這個 UI 好酷，然後到了會議室之後剛好大頭(CEO之類的)有來耶！ 於是我很興奮的展示了我的提案，然後大頭說：『這好奇怪噢！』，然後我在等著下一句為什麼奇怪，然後然後就沒有了耶。於是這個提案就這樣被幹掉了（我就很落寞的離開了這公司會議室）。其實當初是說要做一個類似 iOS 上的 App 資料夾在桌面上，於是我想說以資料夾為圓心然後把 app icon 散開成環狀，這樣不就是可以讓滑鼠移動距離最小，理論上操作上很順手啊（沒有理論根據，只是我自己分析）。當然後續可能會有些問題，比如說 apps 太多，會把半徑撐太大然後距離又變遠之類。但是我覺得這是小問題，只要固定半徑，然後滾輪或是觸控旋轉 circle 就可以了。硬要抄 apple 總是讓人覺得很反感。更何況用 apple 方式展開 folder 在 24" 螢幕上的話，我要把滑鼠移動多遠才能按到右下角的那個 app 呢？總之，被打槍了，一直到現在我還是不太了解大頭覺得奇怪的點到底是什麼。

剛好那時候 Google+ 推出，Google 把 Circle 的概念實現的很棒，只是可惜 G+ 已經快變鬼城，但這不影響我對 circle UI 的欣賞 :)

到了去年底，Path 2.0 推出，我真的是太欣賞了：

Path 介面上左下角的 circle menu 我真的超愛的，單純是環狀就已經讓我很欣賞了，再加上一些 UI 的理論分析，比如說一般人左手拿手機右手單指操作，那麼觸碰區域的方便性界定大概是這樣：

在 easy 區域裡面是最方便的範圍，所以使用環形剛好可以讓選項都落在 easy 區域中。同時因為選項要第二步才會出現又可以避免為人詬病的 Tab bar 吃掉太多 iPhone 螢幕範圍的問題。不過有利有弊啦，就變成要多一步才可以叫出選項。但是如果以最重要的拍照功能而言，大部份的拍照 App 都是 透過 action sheet ：

一樣是要按下 tab 中間的按鈕，然後再從 action sheet 選擇動作，所以就這點看來是還好。 另外有一個問題是有人認為 Path 環狀 menu 太小不好按，這可能就見仁見智了 :)

另外一點很值得提的是， menu 的 animation 實在是做得很好，所以開始出現一堆 open source 來實作這個 menu：

Web 版：http://sparanoid.com/lab/path-menu/#

Native Objective-C 版：https://github.com/levey/AwesomeMenu

雖然我還沒能成功地在任何線上產品裡面放進 circle UI ，但我相信有一天我可以實現這個夢，在被認同的情況下實現這個夢(比如做一個圓形螢幕的 Smart Phone 之類的)。

image sources: 

http://www.zurb.com/article/264/outside-in-product-development

http://www.twylah.com/quytennis/tweets/144711624480141312

iScroll.js的scroll不順怎麼辦？

如果有寫WebApp的人一定會遇到要對content做scroll的需求。這時候你通常有幾種選擇：

1. 把不需要scroll的DOM元件的CSS position屬性設定為fixed，然後依靠device上預設的web browser的scroll功能。這個功能絕對行得通，但是如果是在iOS上的話，你一定會覺得為什麼這個scroll特別黏？就是一做fling的動作，就是沒有其他原生App的scroll的流暢。其實你試試iOS上的Safari，的確就是這個行為沒錯，感覺是特別設計有什麼特殊用意並不清楚。但是很明顯的這個方法對於要求原生App的UI體驗是不夠的。
2. iOS5之後的WebBrower有支援一個特別的overflow值，也就是 overflow:scroll 。設定這個之後，超過容器空間的iOS會自動套用原生的scroll功能。也行得通，如果你不打算支援iOS4的話。
3. 為了克服以上兩個問題，我的選擇是使用iScroll.js，一個Open Source的JavaScript library。很強大，把scroll模擬的很好，而且也會自動產生捲軸。大致上的原理是使用Timer(window.setTimeout)來模擬scroll，也有支援momentum。但是我一直很疑惑的是怎麼在實際的iOS裝置上的scroll animation的frame rate 竟然或是這麼低呢？好吧，重點就在他用了setTimeout! setTimeout! setTimeout! 所以frame rate低是很正常的啊，大概連15fps都不到吧。這時候想說如果用CSS transition(感謝我曾經在之前的公司present過CSS3)的話應該會順暢很多吧。畢竟transition是native code在做animation，而且適當的trick(就是設定一個完全沒作用的3D Transform)還可以啓動硬體加速，FPS一定可以提升到30以上。於是我打開iScroll的source code：

    // Constructor
    iScroll = function (el, options) {
     var that = this,
      doc = document,
      i;
   
     that.wrapper = typeof el == 'object' ? el : doc.getElementById(el);
     that.wrapper.style.overflow = 'hidden';
     that.scroller = that.wrapper.children[0];
   
     // Default options
     that.options = {
      hScroll: true,
      vScroll: true,
      x: 0,
      y: 0,
      bounce: true,
      bounceLock: false,
      momentum: true,
      lockDirection: true,
      useTransform: true,
      useTransition: false,
      topOffset: 0,
      checkDOMChanges: false,  // Experimental
   
      // Scrollbar
      hScrollbar: true,
      vScrollbar: true,
      fixedScrollbar: isAndroid,
      hideScrollbar: isIDevice,
      fadeScrollbar: isIDevice && has3d,
      scrollbarClass: '',
   
      // Zoom
      zoom: false,
      zoomMin: 1,
      zoomMax: 4,
      doubleTapZoom: 2,
      wheelAction: 'scroll',
   
      // Snap
      snap: false,
      snapThreshold: 1,
   
      // Events
      onRefresh: null,
               onBeforeScrollStart: function (e) { e.preventDefault(); },
      onScrollStart: null,
      onBeforeScrollMove: null,
      onScrollMove: null,
      onBeforeScrollEnd: null,
      onScrollEnd: null,
      onTouchEnd: null,
      onDestroy: null,
      onZoomStart: null,
      onZoom: null,
      onZoomEnd: null
     };
   

   你看到第22行了嗎？useTransition: false，哇，太令人欣慰了。我什麼都不用改耶。只要把它改成 useTransition: true 就好了耶(但還是要記得把要scroll的DOM加上null 3D transform)。果然一改完就很順。省了我很多時間:)