2012年04月25日

Metro UIは「UXアプリ養成ギプス」

このエントリーをはてなブックマークに追加
昨日、今日とWindows Developer Days(WDD)に参加してきた。二日間セッションに参加して感じたのは、「Metro UIは『UXアプリ養成ギプス』だ」ということである。

Metro UIにはいくつかのデザインの原則がある。

例えば原則のひとつに、”Content before Chrome”というものがある。これは、「コンテンツを主役にし、ツールバーやメニュー等のコンテンツへの没入を妨げるものは最小限にする」というものだ。

こうしたデザインの原則やガイドラインがきちんと決められている、ということは重要なことではあるが、それ自体はさほど驚くべきことでもない。先日ブログに書いたように、最近の主要なプラットフォームには、大抵UX/UIのデザインガイドラインが定められているからだ。

では私が何に驚いたかというと、Metro UIではこのデザインガイドラインが「半強制」されていることだ。

UX/UIに意識の高い開発者はこうしたガイドラインに目を通した上でプラットフォームと一貫性のあるアプリケーションを設計・構築するかもしれないが、一般に、ガイドラインの存在を知らずにアプリケーションを開発してしまったり、存在を知っていても重視せず読まずに開発してしまったりすることもあるだろう。

Metro UIが面白いと思ったのは、ここで諦めず、「なんとしてでも使いにくいアプリケーションを持ち込ませない」ための一歩踏み込んだ施策を実施したことだ。

施策1. 時間のかかる可能性のある処理は非同期APIしか提供しない
Metro UIのアプリケーションはWindowsランタイムという基盤の上で実行される。アプリケーションからWindowsランタイムの機能を利用するにはC/C++、C#/VB、HTML+JavaScriptいずれかの言語からWin RT APIを経由してリクエストを送ることになるが、Win RT APIは、時間のかかる可能性のある処理については同期APIは提供せず、非同期APIしか提供していない。

これはつまり、「処理中にちょっとでも固まったように見えるアプリケーションなんて、Metroでは書くことさえできないようにしちゃうんだからね!!」ということである。

もちろん、これまでの同期を基本としたAPIでGUIアプリケーションを構築する際にも、時間がかかる処理についてはワーカースレッドと呼ばれる別のスレッドに処理をさせ、アプリケーションが固まらないようにするのがGUIアプリケーションの作法ではあった。

しかしMetroアプリの基盤となるWindowsランタイムではこれが徹底していて、APIを見ていくと、ネットワークを経由して大容量データをダウンロードする等の明らかに時間がかかる処理だけでなく、たとえ小さなローカルファイルに1行文字列を追加する処理でさえ、時間がかかる可能性のある処理についてはすべて非同期APIしか提供されていない。例えばファイルの読み書きのためのFileIOクラスを見てみると、ほぼすべて末尾にAsyncという名のついた非同期メソッドであることがわかる。

これは従来の.NETやJavaなどのAPIの構成を考えると、とてもドラスティックな変更だ。

応答性の重要度に大小をつけると次のようになるため、タブレットやスマートフォンでの動作も考慮したアプリケーションであれば、ユーザーを待たせるなど言語道断、ということが背景にあるそうだ。

 TUC >> GUI > CLI

また、Metroアプリのソースコードが非同期処理にありがちな「ものすごくネストしたコード」にならないよう、asyncとawaitという機構が言語レベルで組み込まれている。これらの機構を使ったMetro UIアプリのソースコードがどんなイメージになるのかはやや細かい話になるので本文の後にAppendixで触れたい。

施策2. デザインガイドラインにそぐわないものはWindowsストアの審査で落とす
従来のWindowsアプリケーションとは異なり、MetroアプリのインストールはすべてWindowsストア経由でインストールすることになる。このため、アプリケーション開発者はこれまでのようにインストーラーを作成するのではなく、代わりにアプリケーションのマニフェストやブロックマップ等を含む.appxファイルを作成し、それをWindowsストアに登録することになる。

Windowsストアへのアプリケーションの登録は無条件に許可されるわけではなく、登録の際にデザインガイドラインに即しているかどうかのチェックが行われる。例えば「検索」は多くのアプリケーションで使われる機能だが、Metro UIのデザインガイドラインでは、検索機能は「チャーム」と呼ばれる画面右端からのスワイプで表示されるプラットフォーム共通のバーの「検索」メニューから利用できるようにしなければならない。アプリケーションごとに異なるアイコンで異なる場所で検索機能が提供されているのは望ましいことではないからだ。

実際の事例として、Metro UIで構築中の楽天レシピでは、当初は独自の検索機能を提供していたが、ガイドラインと照らし合わせて検索機能を必要なときにだけ表示されるチャームに統合することになり、結果として、ユーザーが見たい料理の写真などのコンテンツを前面に押し出すことができたという。

また、フォントのサイズやコントロールのマージンの取り方についてもガイドラインが定められており、フォントであれば見出しは42pt、小見出しは20pt、本文は11pt、補足は9pt、マージンについては1カラム80、1ユニット20 x 20、サブピクセル5 x 5と単位ごとのピクセルサイズが決められている。アプリケーションのパターンに合わせてスクリーンフロー(画面の流れ)のテンプレートも用意されているが、これらは当然すべてデザインガイドラインに即したものとなっている。

どこまで細かくチェックされるかは実際に運用が始まらないとわからないが、ガイドラインに即したアプリケーションでなければ審査を通さないことで、「Metro上で使いにくいアプリが流通しないようにする」ことを半強制するというのは、聞いていて、「うぉ、マイクロソフト本気だな」と感じた。

業界への影響
今回のイベントの中でもUI/UXのデザインに関するセッションが多く、このエントリで書いたような施策からも、マイクロソフトはMetro UIで「Windowsで動くアプリケーションはどれもかっこいいし心地良い」状況を作ろうとしているようだ。

現在、特にPCで動作するアプリケーション、さらにその中でも特に業務系のアプリケーションにはユーザビリティが高いとは言えないものも少なくなく、極端な場合には「ユーザーがどのように使うか一切想定していないアプリケーション」(リンク先の「ユーザビリティを全く考慮してない画面設計」を参照)もあるわけだが、現在企業内のクライアントOSとして主に使われているWindows上で動くアプリケーションが「使いやすいのが当たり前」という状況になれば、業界全体のUX/ユーザビリティについての意識も高まっていくだろうし、用途に関わらず、できるだけ使っていて楽しいアプリケーションをつくろう、というディスカッションも行われやすくなるだろう。

これは、IT業界に身を置く人間として、とても喜ばしい傾向だ。

Appendix. asyncとawaitを用いたプログラミング
asyncとawaitを用いたプログラミングは次のようになる。セッションがメディア以外写真撮影禁止だったことに加え、ノートPCのバッテリーが切れて手書きメモしか取れず、主に記憶を頼りにコードを書いているので細かい点で間違いがあるかもしれないが、大体のイメージはつかめると思う。

async void Process()
{
    FileOpenPicker picker = new FileOpenPicker();
    picker.FileTypeFilter.Add(“.jpg”);
    StorageFile file = await picker.PickSingleFileAsync();
}

上のコードでは、5行目でawaitが使われており、file変数への代入はpicker(ファイルを選択するためのダイアログ)でファイルが選択された後に行われるが、PickSingleFileAsync()メソッドが呼び出された時点で一度UIスレッドのブロックは解除され、UIの他の箇所を触ることができるようになる。awaitを使用するにはメソッドにasync修飾子を付ける必要がある。

async void ReadFeeds()
{
    Task<FeedData> feed1 = GetFeedAsync(“url1”);
    Task<FeedData> feed2 = GetFeedAsync(“url2”);
    Task<FeedData> feed3 = GetFeedAsync(“url3”);
  
    Feeds.Add(await feed1);
    Feeds.Add(await feed2);
    Feeds.Add(await feed3);
}

上のコードでは、3行目から5行目でRSSフィードの読み取りを非同期で行い、7行目でfeed1の読み取りが終わるまで処理をブロックする。ただし、awaitはUIスレッドをブロックするわけではないので、ユーザーから見てアプリケーションが固まったように見えることはない。

時間がかかる可能性のある処理は非同期メソッドになっており、UIスレッドのロックは解除されるため、処理開始後から終了前までの間に画面の他の部品が触られたときのことを考慮する必要がでてくる。画面に多数の部品があればこの状態管理がかなり煩雑になると思われるが、「非同期だと対処できない」ように思える場合の答えは「画面構成そのものを見直す」ことだそうだ。同期メソッドの提供のリクエストは多数出ていそうだが、かたくなに拒み、画面構成自体を見直せ、という辺りにもMetroの養成ギプスとしての特徴がよく表れている。



About Face 3 インタラクションデザインの極意
Alan Cooper Robert Reimann David Cronin
アスキー・メディアワークス
売り上げランキング: 100539


Check このエントリーをはてなブックマークに追加
lalha at 21:54 │プログラミング  │Comments(1)TrackBack(0)

トラックバックURL

この記事へのコメント

1. Posted by waki / マイクロソフト西脇   2012年04月28日 09:52
5 Windows Developer Days へのご参加ありがとうございました。またブログ記事にしていただき感謝でございます。
アプリケーションの開発はご指摘のようにどんどんデザイン重視になってきています。
あらゆるデバイスやサービスがデザインを重要視し、デザインで勝敗が決まるといってもよいくらいです。そういった市場で成功を収めるためには、という取り組みが必要です。そのあたりはまさにこのブログ記事のとおりでございます。

今後とも応援、よろしくお願いします。

この記事にコメントする
(スパム対策のため、英数字のみからなるコメントは自動削除されますのでご注意ください。)

名前:
URL:
  情報を記憶: 評価: 顔