新しいUIパターン：サイドナヴィゲーション

自然言語 言語：Java フレームワーク：Android 翻訳

FacebookアプリlikeなUI（画面にかぶさるようにしてメニューが出せるやつ）についての記事を見つけたので訳しました．執筆者の承諾を得ています． Thank you for your kindness, @lehtimaeki!!

（こちらの記事の翻訳です）

Juhani Lehtimaeki （ @lehtimaeki ）さんの記事．文中「私」とあるのは @lehtimaeki さんのことです．

記事のコメント欄も興味深いです．

本文

　AndroidのUIは去年，すごいスピードで発達した（特に私のお気に入りのものについては， *こちら1* にまとめてある ）．ほとんどの変化はたいしたものではなかった（4.0から採用されたholoテーマ，Robotoフォントなど）．登場したときUI界を大きく変えたと言えるのがあるとすれば，今回紹介するSide Navigationかもしれない．
　FaceBookのSide Navigationは，最近いくつかのアプリにほとんど同時に採用された．最初はSpotify，直後にEvernoteが続いた．Google+もだ．
　それぞれ実装はかなり異なるし，ルック＆フィールも異なるが，背後にあるアプローチは同じだ．ユーザに提供すべきなのは，いまいるスクリーンから離れないままで，アプリの最重要部分にアクセスできるショートカットだ，ということだ．
　見た目の違いはかなりはっきりしている．Google+アプリは上からナビゲーションが降りてくるが，ほかは横から出てくる．また，Google+だけは「上へ」アイコン（up caret）もアクションバーも出しているが，他のアプリは出していない．
　このパターンについてのおもしろい議論は *こちら2* で見られる．

Dashboardパターンは用済み（っぽい）

　Side Navigationパターンは，批判を受けてきたDashboardパターンにとってかわる．Dashboardパターンへの主な批判は，ユーザがアプリの中身にたどり着く速度を落としてしまう，というものだ．アプリを起動するたびに，何をしたいかに応じてアイコンをタップしなくてはいけない．
　さらにDashboardパターンだと，他のことをしたくなったらまたアプリのホーム画面に戻ってこないといけない．Dashboardがあって，項目のリストがあって，項目をタップするとその詳細が見られる，という一般的なAndroidアプリのワイヤフレームを軽く描いておいた（モバイルアプリだとよくある構造だ）．この例では，ユーザは最初にダッシュボードから項目をタップして，リストの項目を1つ選んでタップして，詳細画面から別の項目へ移る．これでは，アプリの別のセクションに誘導するのは難しい．

　Side Navigationパターンは，これらの問題を両方とも取り除く．アプリのメイン部分であればどこへでも，ユーザは直にアクセスできる．したがって，アプリは起動時から，前回起動時の画面を表示することができる．Dashboardはいらない．中身に直接つなげるのだ．
　先ほどのアプリを，Side Navigationパターンに変えたもののワイヤフレームを置いておく．第1に，アプリのランディング画面でもう中身を見ることができ，アプリの他の部分にも，ユーザはアクセスできる（しかも，どの画面からでも）．

　これはSide NavigationパターンがDashboardパターンに勝っている部分だろう．Dashboardパターンを使うべき例は，まだ残りはするだろうが限られてくるに違いない．たとえば，アプリのどの画面でもランディング画面にする，というのが不可能な場合が，稀にはあるかもしれない．あるいは，非常に複雑なアプリだと，ユーザが最初にアクセスしたときに見るものは，画面どーん！ではなくて，それほど威嚇的ではないダッシュボードのほうがいいかもしれない．
　Android UIの象徴だったもののひとつ，つまりDashboardパターンにさよならする日は，それほど遠くはなかろう．

Side Navigationには欠点もある

　残念ながら，Side Navigationでうまくやるのは，Dashboardでうまくやるよりも難しい．複雑さが増すからだ．

上へ？

　Androidoの「上へ」概念のことはぜんぜん好きになれない．「上へ」と「戻る」との違いをユーザが理解するのは不可能なんじゃないかと思う．Googleは，左向き矢印を「上へ」を表すものと決めたようだが，これではちっともわかりやすくなっていない．だれに聞いてみても，左上のボタンは「戻る」ボタンと呼ばれてばかりだ．
　Side Navigationは，「上へ」をよけいなものに変えてくれたと思う．あなたのアプリがちゃんと作ってあって，メイン画面からSide Navigationを通じてどこへでも行けるようにしてあるなら，ユーザはもはやどのスクリーンからも，ほんの数クリック以上に離れてしまう（深い階層に行ってしまう）ことはないからだ．「戻る」ですべて事足りる．
　Google+アプリを見て，Side Navigationの動きがわかったら，カテゴリーのホーム画面に戻ってSide Navigationにアクセスするには，まず「上へ」しないとだめだということに気づくはずだ．これでは利点より欠点のほうが勝ってしまっている．たとえば，自分のフィードアイテムを読んでいて，突然グループチャットをしたくなったときに，フィード詳細画面からフィード一覧画面に「上へ」で戻ってからでないと行けないというのは，ばかげている．
　左上には，「上へ」のかわりにホームアイコンを置いて，どこにいようがSide Navigationを開けるようにしておくべきだ．
　それでも「上へ」を使いたいなら，Side Navigationをホームアイコンから開ける場合には「上へ」矢印を消し，開けない場合には「上へ」矢印を出す，という制御をすべきだ．「上へ」矢印を出しっ放しにしたままでは，UIの大原則「ボタンがすることは常に見れば想像がつくようにしておけ」を破ってしまう．
　おそらく，Side Navigation用に，OSレベルでアイコンを用意しておくべきだと思う．そのほうが一貫性が出る．何を言っているかわかるように絵を描いておいた．1枚めは「上へ」として動くホームボタン，2枚めは「Side Navigationを開く」として動くホームボタン．どうしても「上へ」を使いたいアプリでも，これでユーザの混乱は避けられるだろう．

「戻る」のスタック問題

　「戻る」のスタックを正しく積んでおくのは重要だ．Side Navigationは戻るスタックを複雑にしてしまう．Alexander Blomがこの問題について書いている記事は *こちら3* 、 *こちら4* 。

Side Navigationはどの動作で開くのか？

　ユーザがSide Navigationを開きたいとき，どうすればいいだろうか？　どういうジェスチャを採用すべきか？
　Side Navigationはアプリの最重要要素になるので，これを開けないとユーザは何もできない．
　いろいろなアプリを試してみたが，完璧と思えるものは見つからなかった．いちばんよかったのはPrixingアプリだ．「上へ」は捨てて，Side Navigationに特化したホームボタンをつけている．
　このアプリはさらに，ジェスチャショートカットも備えている．画面のふちをスワイプすればSide Navigationが開く（Bezel Swipe）．画面ふちスワイプは，最初に気づくのが難しい場合もありうるが，ホームボタンを押せば同じことがどの画面でもできるのであれば，問題にはならない．（Bezel Swipeについては *こちら5* ）
　あと改善するとしたら，ホームボタンとして使っているのがアプリアイコンそのままであるという点だけだ．どういう動きをするのかわかるようなアイコンを別に作るべきだろう．
　他のアプリでは，他のやりかたでSide Navigationを開いている．例えばEvernoteアプリはUI上でSwipeして開く．この場合，タブを移動するのにSwipeを使っているアプリでは，それと被ってしまうという問題がある．Evernoteの場合，タブをUIで使っているあいだは，左端のタブまで行かないかぎり，サイドメニューをジェスチャでは開くことができない．
　おすすめの方法は，ホームボタンから開けて，画面ふちスワイプでも同じように開けるようにしておく，というものだ．「上へ」を使う必要があるなら，Side Navigationを開くボタンと異なるアイコンにすること．

Side Navigation内でのアクション

　ナヴィゲーションのことばかり書いてきたが，多くの実装はそれ以上のものを作っている．正しい方向だと思う．アクションバーは，アクションバーが出ている画面に応じてコンテキストアクションを出しておく場所だった．では，どの画面からでも行けてほしい重要なアクションについては，どこに載せておくべきか？
　Evernoteは，Side Navigationにアクションを載せることで対応している．優れた実装だと思う．最初はちょっと戸惑うかもしれないが，きれいに分割されたアクションとナヴィゲーションのおかげで，ユーザはすぐに脳内地図を作ることができる．

名前はなんにすべきか？

　パターンの名前は，わかりやすく一貫したしかたでつけなくてはいけない．パターン化することの利点のひとつは，議論のとき簡単に共有できることだ．すでに確立したパターンは，それだけで説明不要になる．「UIにアクションバーをつけよう」「リストにクイックアクションをつけたらどうか」これだけでじゅうぶん意思疎通できる．
　では，このパターンはなんと呼ぶべきだろうか？　これまでSide Navigationと呼んできたが，他にもたくさんの名前がある：

  • Side Navigation
  • Fly-in app menu
  • Slide out navigation
  • Sliding navigation bar
  • Slide Menu
  • Facebook-like UI

　Googleが名前をつけてくれるのを待つしかないだろう．ここで民主的な多数決などには頼れそうもない．いちおうここではSide Navigationで統一しておく．

技術的実装面

　Side NavigationはまだAndroid SDKには入ってない．githubをざっと見まわしたところ，これが見つかった：

将来性

　私が思うに，これはAndroid UIデザインの優れた一歩だろう．実装をばらばらにやりすぎて，ゴミの山を量産してしまわないように気をつけるべきだ．ユーザに混乱を招くからだ．
　Google I/O が近いし，次のAndroidのアナウンスもあるだろう．GoogleがこのややこしいコンポーネントをOSに組み込んでくれるといいが（HoneyCombでアクションバーを取り入れたように）．そうなれば実装に一貫性が出てくる．

要約

  • Side Navigationいいね！
  • まちがったデザインに陥らないよう注意が必要
  • 戻るスタック，ジェスチャ，「上へ」との関係，見た目，これらに注意

（訳者補足）

その他，コードで試せるもの．

■

書籍リスト

最近買った本のリスト．

■

書籍リスト 言語：Java フレームワーク：Android

最近買った本のリスト。

WEB+DB PRESS Vol.68

WEB+DB PRESS Vol.68

Android Layout Cookbook アプリの価値を高める開発テクニック

Android Layout Cookbook アプリの価値を高める開発テクニック

Android UI Cookbook for 4.0 ICS（Ice Cream Sandwich）アプリ開発術

Android UI Cookbook for 4.0 ICS（Ice Cream Sandwich）アプリ開発術

いまAndroidではやりのアプリDashboardの作成については，上掲書のほか，下記の記事が参考になりました．
http://www.androidhive.info/2011/12/android-dashboard-design-tutorial/
ただし，各レイアウトの評価値を算出する際に用いる係数UNEVEN_GRID_PENALTY_MULTIPLIER は，1（ペナルティなし）が妥当だと思います．

■

書籍リスト

最近買った本のリスト．

Pythonプロフェッショナルプログラミング

Pythonプロフェッショナルプログラミング

Emacs実践入門　?思考を直感的にコード化し、開発を加速する (WEB+DB PRESS plus)

Emacs実践入門　?思考を直感的にコード化し、開発を加速する (WEB+DB PRESS plus)

JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス

JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス

The RSpec Book (Professional Ruby Series)

The RSpec Book (Professional Ruby Series)

Redmineによるタスクマネジメント実践技法

Redmineによるタスクマネジメント実践技法


　すでに各所でご指摘のとおり，*Pythonプロフェッショナルプログラミング*はPythonを書く用事が特にないかたにもおすすめ．なんたってPythonはスクリプト言語でもありますからね．治具を作るにはうってつけなのです．私はこれでSphinx-Users.jp — Python製ドキュメンテーションビルダー、Sphinxの日本ユーザ会を覚えました．他にも開発のための教科書となるようなことがらがいっぱいです．
　でも，1行Webサーバは SimpleHTTPServerではなくWEBrickを使っているし，Sphinxからmake htmlする際にはwatchrを使っています．

■

書籍リスト

最近買った本のリスト．

Linuxエンジニア養成読本 [仕事で使うための必須知識＆ノウハウ満載！] (Software Design ｐlus)

Linuxエンジニア養成読本 [仕事で使うための必須知識＆ノウハウ満載！] (Software Design ｐlus)

プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)

プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

基礎から学ぶ Androidアプリ開発

基礎から学ぶ Androidアプリ開発

継続的インテグレーション入門

継続的インテグレーション入門

`gem install activerecord-postgresql-adapter`はproduction用にGemfileを切る

ツール：Git 言語：Ruby サービス：Heroku

herokuにRails3.2.1アプリをpushしようとすると，

adapter: `gem install activerecord-postgresql-adapter` 
(pg is not part of the bundle. Add it to Gemfile.) (RuntimeError)

が出てうまくいかない．
ここにはいくつもの罠がある．

group :production do
  gem 'pg'
end
group :development, :test do
  gem 'sqlite3'
end

(参考：HerokuでRails 3.1.3 でdeployするまで - リンゴの水やり？(はてな))
このように書きかえて，

$ bundle install --without production

をしてはじめて成功する．

行列を素早く作るにはEnumeratorをmapする

言語：Ruby

　技術記事の棚卸をしていて，こちらの記事で勉強していたのですが，
[Ruby] 10行で書ける Dijkstra 法 | singular point


　行列を作る手段としてこちらが使われていました。

n=6
g=n.times.collect{ Array.new(n,-1)}

collectメソッドを使い慣れていなくて（ずっとmap），一瞬なんだかわからなかったのですが，これは

pry(main)> g = n.times.map{ Array.new(n, -1) }
#=> [[-1, -1, -1, -1, -1, -1],
# [-1, -1, -1, -1, -1, -1],
# [-1, -1, -1, -1, -1, -1],
# [-1, -1, -1, -1, -1, -1],
# [-1, -1, -1, -1, -1, -1],
# [-1, -1, -1, -1, -1, -1]]

と同じコードです．timesメソッドがEnumeratorを返すのでこれをmapすることで配列の配列を生成しているんですね．
Class: Integer (Ruby 1.9.3)