[Start] (スタート) 画面についていただいたコメントを振り返る


Windows 8 の [Start] (スタート) 画面のエクスペリエンスを扱った最近の 2 件の投稿については、大いに議論がありました。Developer Preview をご利用されている方の一人一人が、個々のユーザーの使用パターンや、Windows 7 と比べて使いやすくなった点、使いにくくなった点を私たちが理解する助けとなっています。ここで改めて申し添えておくと、Windows Developer Preview は、ユーザー インターフェイスの面で開発途上の機能が多々残っているのを承知のうえで、製品全体を "オン" にした状態でリリースされたものです。これは議論を促進するための措置で、皆さんには製品が完成形でないことをご理解いただきたいと思います。"選べるようにしてほしい" や "オフにしたい" といった、反射的なフィードバックも少量ながら見られました。これは変化に対する自然な反応ではありますが、新しい製品を作り上げるための議論として最適とは言えなかったのではないかと思います。この投稿では、私たちが建設的なフィードバックにしっかりと耳を傾けながら、さらなる設計の進化に取り組んでいることをお伝えすることに注力したいと思います。具体的なコメントを取り上げ、皆さんのご意見に基づいて行われるアクションについてご説明したこの記事は、Core Experience (コア エクスペリエンス) チームのシニア プログラム管理者リードである Marina Dukhon が執筆しました。--Steven

この 1 週間にいただいた、[Start] (スタート) 画面関連の記事への積極的な参加について、チームを代表して皆さんに感謝の気持ちをお伝えしたいと思います。コメントにはすべて目を通しており、可能な範囲で返信させていただいています。今回のような大きな変更が時として大きな論争を呼ぶことは理解しており、今後もこういった対話を続けていきたい考えです。設計に深くかかわる具体的なトピックがこれまでにいくつか挙がっているので、今回の投稿ではこれらに答えていきたいと思います。いただいたすべてのご質問に答えることはできないのですが、ご意見には確かに耳を傾けており、今後も対話を続けていきますので、その点についてはご安心ください。

データはすべてのユーザーをカバーしているのか?

Andrew さんのコメント:

「収集されているデータの多くが、おそらく企業ユーザー以外のものであることを指摘したいです。ビジネス ユーザーを無視してホーム ユーザーだけに基づく統計を取っていることになります。ほとんどの企業では、セキュリティへの配慮や無駄なネットワーク トラフィックを防ぐ目的から、グループ ポリシーを使って既定で CEIP をオフにしています」

CEIP (カスタマー エクスペリエンス向上プログラム。ユーザーによる Windows の使用状況について、オプトイン方式で匿名のフィードバックを収集する) を無効にする企業があることは、ご指摘のとおりです。しかし、それでも膨大な量のデータがこのプログラムを通して収集されており、企業ユーザーについても例外ではありません。さらに、地域、言語、エディション、展開属性といった情報も同時に把握できるため、必要に応じてさらに精度の高いデータを得ることができます。ユニークなデータ ポイントの数が "サンプリング" のレベルをはるかに超えるため、私たちはしばしばこのデータを "国勢調査" にたとえます (オプトイン方式の匿名データである点は改めて付記しておきます)。

企業ユーザーにアクセスし、ニーズを理解するための経路は、CEIP 以外にも幅広く用意されています。たとえば私たちは、顧客との直接のやり取り (オンサイト訪問や世界各地の Briefing Center など)、各種諮問機関や早期導入プログラム、そして TechEd//build/ (英語) などの公的なイベントを通して、常にフィードバックを集めています。また業界アナリストと (コンサルテーションや彼らの調査を通して) 緊密に協力すると同時に、直接的な調査研究も独自に幅広く行っています。こういったやり取りを通して、私たちは企業が現行の [スタート] メニュー以上の機能や管理性を求めているということを理解しており、Windows 8 における変更点の設計や開発にも確実に組み込んでいます。

データを見てみると、企業ユーザーが得ている [スタート] メニューのエクスペリエンスは、それ以外のユーザーと確かに異なる点があります。

  • ホーム ユーザーの 81% では [スタート] メニューの右側に [コントロール パネル]、[ゲーム]、[ドキュメント] といった既定のリンクが残っているのに対し、企業ユーザーではその数は 2% 未満
  • 多くのユーザーが [スタート] メニューのこの部分から一部のアイテムを削除している (削除されることが最も多いのは [ゲーム] と Media Center へのエントリ ポイント)
  • 企業ユーザーはホーム ユーザーよりも 68% 高い頻度で [スタート] メニューにピン留めしたアプリを起動しているが、それでもピン留めアイテムの使用率は全セッションの 10% 未満にとどまっている
情報の活用方法

一般的に、個々の企業ユーザーは、管理者がカスタマイズした [スタート] メニューを使用しています。これらの調査や企業コミュニティとの関係を活かして、[Start] (スタート) 画面のカスタマイズのニーズに応える特別な機能を準備中です。たとえば、企業では [Start] (スタート) 画面から [Games] (ゲーム) や [Help & Support] (ヘルプとサポート) を削除しておくことができます。Windows 8 では、[Start] (スタート) 画面にビジネス グループのニーズに合わせたレイアウトでタイルを表示し、より多くの数のピン留めアプリを事前定義してユーザーに提供するような展開シナリオがサポートされます。また、[Start] (スタート) 画面のカスタマイズを制限し、社内で共通のものを使用してもらうこともできます。こういった機能は企業ユーザーをターゲットとして特に用意されたもので、これまでに提供してきた既存機能と、今後予想される企業ユーザーのニーズが考慮されています。また、多くの方がご存知のように、技術に詳しい方なら、個人でもこういったカスタマイズ機能を活用していただけます。

[Start] (スタート) 画面は PC を一望するビューとして効率が低いのではないか?

mt327000 さんのコメント:

「[Start] (スタート) 画面はただアイコンが散らかっているように見えます。記事で説明されたような [スタート] メニューの問題点はすべて残っているし、そこに新たな問題も加わっています。私はデスクトップをきれいに整理して使っていて、Windows Vista で導入された [すべてのプログラム] のビューでも、コンピューター内のアイテムを一望することができます。[Start] (スタート) 画面は私には合わないとしか言いようがありません。より優れている [スタート] メニューと比べて有利な点があるとも思えません」

PC が管理下にあることを実感するうえで、何がインストールされているかを把握でき、それらを一望できることが重要な要素であるという点は、多くのコメントからはっきりと伝わってきました。この点についての [スタート] メニューの動作を検討し、[Start] (スタート) 画面と比較してみましょう。

現在の [スタート] メニューでは、[すべてのプログラム] ポップアップを展開した場合に、スクロールせずに表示できるアプリは既定では合計 20 個です。これはモニターがどれだけ大きくても変わりません。私たちが行った調査の一つでは、ユーザーは数か月の間に平均して 57 種類の異なるアプリを起動することがわかっています。しかもこれには、ユーザーが日々利用する多数のウェブサイトは含まれません (起動やピン留めに関してはウェブサイトの数も重要だと私たちは考えています)。こういったウェブサイトの一部は、今後 Metro スタイル アプリへと進化していく可能性があります。アイテムを 20 個しか表示できない小さなウィンドウでは、このようなシナリオに対応できないことはおわかりいただけると思います。こういった数のアプリやウェブサイトの利用がこのブログの読者の皆さんにとって日常的なものであることはコメントからも明らかで、利用方法は一般的にこの方向に推移していくものと考えます。

[スタート] メニューの [すべてのプログラム]

一定量のアプリをインストール後は、[すべてのプログラム] ですべてのアプリのフォルダーを見るためにスクロールが必要なことが多い

スペースが限られていることに加え、[すべてのプログラム] ではアプリがフォルダーやサブフォルダーを使った階層構造の中に埋もれており、目的の場所に誘導してくれるアイコン表示などもありません。さらに、目的のアプリを探してフォルダーの展開や折りたたみを行うと、アイテムの位置があちこちに動いてしまうことが多く、効率性はさらに低下します。この制約は Windows XP の [スタート] メニューと比べても設計上の退行だと言う人もいます。理屈のうえではこれは否定できませんが、メニューであるという点は共通です。階層構造を持った 1 本の列であり、操作する際に一定以上の精密さが要求されることには変わりありません。Windows XP 型の設計のスケーラビリティに対しては、時間の経過と共に否定的なフィードバックが際立ってきており、このことが Vista と Windows 7 での再設計につながりました。

XP/Vista/7 の時代以上に大量のアプリ (およびサイト) が使用されることが見込まれる Windows 8 では、さらなるスケーラビリティが必要でした。また、全体を一望できるビューと、要求される操作の精密性がずっと低いナビゲーション モデルを提供したいとも考えていました。全画面表示を使用することで、スクロールや階層構造によるナビゲーションを使用することなく、より多くのアプリを表示することができます。階層を排してフラットな構造を使用することで、アプリのアイコン表示を活用することができ、製造元の名前が付いたアプリを探していくつものフォルダーをクリックしていく労力が不要になります。これは結果としてもう一つの一般的な苦情に対応することにもなります。[スタート] メニューのフォルダー名を変更したり、フォルダーの統合や整理を (たとえばメニューの折り返しを防ぐために) 行うと、アプリを正常にアンインストールすることができなくなるという点です。こういったケースでは、リンク切れを防ぐために定期的に [スタート] メニューを掃除する必要がありました。

この記事で後述するように、非常に大きなメニュー インターフェイスを操作するのに必要な動作の精密性は、優れたユーザー インターフェイス デザインとは相容れないものです。メニューを通してアクセスするのは使用頻度の低いアイテムだとしても、メニューにとらわれることで、エクスペリエンス全体の質が低下します。画面の端で折り返す XP 型のメニューを採用したり、現在の [スタート] メニューのサイズを大きくすることで、問題が "解決" するはずだという声もありました。この記事の後半ではフィッツの法則に触れ、サイズの拡大や折り返しによっては問題が解決しないことを説明します。dpi の値やモニターのサイズが大きくなるにつれ、メニューの中をジグザグ移動して細長いボタンを押すという動作は難しくなってきます。下に示すのは Bleipriester さんがコメントで提供してくださったスクリーン ショットですが、マウスで一定の経路をたどる必要があり、上下にオーバーフロー シェブロンという補助ナビゲーションが必要になることがおわかりいただけるかと思います。このことを踏まえてフィッツの法則についての部分をお読みください。

Bleipriester さんの提案する 3 列ナビゲーション型の [スタート] メニュー

複数列のナビゲーションを使った Bleipriester さんの進化型 [スタート] メニュー

こういった点から、使用するモニターが大きくなるにつれ、[Apps] (アプリ) 画面 ([Start] (スタート) 画面の全アプリ表示) の優位性が増してきます。次の表は、各モニター サイズで [Apps] (アプリ) 画面に表示されるアプリの数を、Windows の最新のビルドについて示したものです。

想定されるフォーム ファクター

サイズ
(インチ)

解像度

[Apps] (アプリ) 画面の 1 ページあたりのタイル数

[すべてのプログラム] の 1 ページあたりのアイテム数

ノート PC

12.1

1280 × 800

36

20

 

13

1366 × 768

40

20

 

13.3

1440 × 900

42

20

デスクトップ PC

21.5

1920 × 1080

80

20

 

23

1920 × 1080

80

20

 

27

2560 × 1440

150

20

各モニター サイズで [Apps] (アプリ) 画面に表示できるアプリ数の推定

コメントでは多くの明確なフィードバックをいただいており、指摘のあった設計上の問題の多くは私たちも同意せざるを得ないものです。何人かの方が言及されていた点として、フォルダー名がなくなるとアプリを見つけるのが難しく、フォルダー構造を完全になくすとスイートとして入手したアプリを見つけるのは困難だということがありました。

aroush さんのコメント:

「現在採用されている全アプリを表示する Metro スタイルのリストは不適切です。アイテムがすべてアルファベット順に並んでいますが、たくさんある追加プログラムの名前をすべて覚えているわけにはいきません」

このフィードバックについては、こうしているうちにも対策が講じられつつあります。次に示すのは最新の [Apps] (アプリ) 画面のデザインです。現行の [すべてのプログラム] で親しまれている構造が復活しています。

再設計された [Apps] (アプリ) 画面に、グループ分けされたアプリのスイートが表示されているようす

ご覧のとおり、単純なアルファベット順のリストではなく、[スタート] メニューと同様に、アプリのスイートがグループ化されて表示されるようになっています。これによって、たとえば Visual Studio スイートに入っていたのは確かだが正確な名前が思い出せない、というような場合に、そのアプリを見つけ出すのが容易になります。また、開発者が実行可能ファイルの実際の名前を伝えるのにフォルダー名に頼っていたために、アルファベット順のリストがわかりにくい名前のアプリのタイルで埋め尽くされるということもなくなります。

フォルダー構造の追加と、対応するスイートごとにアプリを整理する機能に加え、私たちはこのビューの表示密度をさらに上げようと取り組んでいます。画面に表示できるコンテンツの量を増やすことで、コンピューターにインストールされているものをひとめで把握しやすくなり、スクロールが必要な場面も減ります。また、折り返しを使ったメニュー構造や、フォルダーやサブフォルダーを使ったプログラムの管理の必要性も低減されます。

この設計により、システム内を一望することが容易になり、インストールされているアプリをいつでも簡単に把握することができます。

新しい [Start] (スタート) 画面では、仕事の生産性を確保できるようなカスタマイズは可能か?

Ed1P さんのコメント:

「Metro スタイルの [Start] (スタート) 画面が、タッチ スクリーン搭載の小型コンピューターで有効なことは理解できますが、大きなワイド スクリーン モニターを使うデスクトップ PC では、生産性が大幅に下がってしまうでしょう。私は 1 回の作業セッションで定期的に利用するアプリやフォルダーが 50 以上あるのですが、カスタマイズした Windows 7 の [スタート] メニュー (カスタマイズをはじめ、Alice が不可能だと言っている多くの処理は実際には可能です。[スタート] メニュー直下の [すべてのプログラム] を右クリックしてプログラム フォルダーの構成を変更するだけです) は使わないようになっており、代わりに無料アプリである Stardock Fences を使っています。Fences では、アプリやフォルダーを即座にアクセス可能なタイルとして画面上でグループ化することができます。

Stardock Fences のグループと Metro の [Start] (スタート) 画面の "ページ" との間に類似点があるのは認識していますが、Fences が Metro よりも生産的だと言える大きな違いが 1 つあります。それは、Fences ではグループ化したアイコンを画面の左側に縦に固定しておき、右側をリアルタイムに情報を表示するガジェット用のスペースとして使い、中央には作業に十分な 1200 × 1024 の領域を残しておくことができるという点です。コードを書いたり 3D モデリングを行ったりという作業は中央のスペースで快適に行い、瞬時に別の作業に切り替えることもでき、しかもその間リアルタイムの情報に目を配っておくこともできます。タスク バーはほとんど使っておらず、自動的に隠れるアラート領域となっています。

Metro を縦型にして画面の横に固定しておくことができれば、私のデスクトップ レイアウトでもずっと使いやすくなるでしょう。縦にスクロール可能な 2 つの領域に分けることができればもっと良いと思います。片方にリアルタイムの情報やガジェットを置き、もう片方からアプリやフォルダー/ファイルを開けるようにすれば、中央に作業可能なスペースを広く確保しておくことができます」

まとまったコメントをありがとうございます。マシンをお好みの環境にしあげるため、時間をかけてカスタマイズされてきたのではないかと思います。これは、Windows が幅広いユーザー層に対応する柔軟性を備えていることを示す好例と言えます。Windows 8 でも引き続きこのような柔軟性を提供していきたいと考えており、また、ユーザー固有のニーズに応える多様なサード パーティのランチャーは今後も幅広く提供され続けることと思います。拡張性にかかわる目に付きやすい機能の多く (たとえば色や背景の設定) は、Developer Preview では意図的に割愛されていますが、最終的な製品では提供される予定です。しかしここでは、話題にのぼった高度なカスタマイズに焦点を絞りましょう。

Ed1P さんが行われているカスタマイズは、間違いなく私たちが "上級" ユーザーに想定するレベルのものです。1 回の作業セッションで使用されるアプリやフォルダーの数からも、上級ユーザーであることがよくわかります。次の表は、1 回の作業セッションでユーザーが行う作業についてのデータをまとめたものです。

開いているウィンドウ数のピーク値

全セッション数に占める割合

0-5

20.40%

6-9

49.30%

10-14

21.30%

15-19

4.60%

20-24

2.69%

25-29

1.30%

30-39

0.23%

40-49

0.08%

50-59

0.03%

60-79

0.03%

80-99

0.01%

100+

0.03%

ユーザーがセッション中に同時に開いているウィンドウ数の最大値

ご覧のように、Ed1P さんの数値は私たちのデータによる "平均的" なユーザーを大きく超えますが、Windows はあらゆるレベルにわたるユーザーが利用しています。非常に小さな値を示しているデータは、何か 1 つの作業をしてすぐにログオフする、いわゆる "短い" セッション (これはプロフェッショナルにも見られることです) を反映しているのではないかと思う方もいらっしゃるでしょう。非常に大きな値のデータについては、ユーザーが意図せずマルウェアを起動し、大量のウィンドウが開いてしまったケースも含まれているかもしれません。このような理由から、こういった集約的なデータを見る際は平均値に注目するのが現実的な結果につながると考えています。データは、なんらかの主張を通す意図で利用されがちです。だからこそ私たちは、この場を使ってデータのコンテキストを十分にご説明し、なんらかの制約がある場合はそれをご理解いただけるようにしたいと考えました。これらのデータは、設計上の判断を押しつけるためではなく、その背景を説明する意図でご提供しています。

私たちがシステムをロー エンド向けに設計していると言う方もいらっしゃるかもしれませんが、そのようなことはありません。反面、ハイ エンド向けにシステムを設計すれば、多くのユーザーにとって概念を理解するうえで負担となってしまうこともご理解いただけるかと思います。私たちの設計の趣旨は、多くのユーザーにとって最適なスイート スポットをねらいつつ、ハイ エンド ユーザーには柔軟性を提供することにあります。この点についてはアプローチは従来からまったく変わっておらず、Windows の設計全体に対する私たちのアプローチそのものでもあります。

Fences で人気のある要素の一つが、アイテムを論理的な方法でグループ化でき、さらにグループに名前を付けることもできるという点です。一方で Ed1P さんはこの設計が抱える難点についても言及されています。グループがデスクトップに置かれており、必然的に開いているウィンドウの下に隠れてしまうため、他の作業の最中にアクセスするのが難しいという点です。実際にどのようにデスクトップをセットアップされているかはわかりませんので、以下は単なる推測になってしまうのですが、このアプローチを採用しているユーザーの少なくとも一部は、日常的にある程度の負担を強いられるのではないかと想像しています (もっとも、お話からすると Ed1P さんは注意深くバランスを取っておられるようですが)。つまり、時間をかけて作業スペースを調整し、開いたウィンドウがランチャーの隣に配置されるようにすれば、ランチャーにすばやくアクセスしたり、同時にリアルタイムの更新情報も把握しておくことができるものの、代償として利用できる画面スペースは減り、崩れやすいウィンドウ配置を手動で管理する手間が生じるのではないかと思うのです。

コンテンツを 2 次元の平面に展開することの価値

Fences のもう一つの重要な要素は、空間的な配置を使ってショートカットを整理できるという点です。アイテムの場所を覚えるのは、1 次元のリストよりも 2 次元の平面での方がはるかに楽です。もともと私たちの脳は位置 (そして色や大きさといったその他の属性) を記憶しやすいようにできており、たとえば画面の右上にあることを既に知っているアイテムを見つけるのは、多くの場合、アルファベット順のリストをたどるよりも容易です。また、[スタート] メニューについてよくある批判として、多くのフォルダーが同じ文字から始まっており、区別するには単語をいくつか読み進めなければならないという点があります (たとえばグラフィック関係のプロフェッショナルの場合、あるソフトウェア メーカーの名前の関係で、"A" で始まるフォルダーをたくさん抱えることになりがちです)。

あるアイテムをすばやく効率的に見つけるのに、複数の特徴や属性があった方が容易であることは、多くの研究が裏付けています。Windows ではこれまでも、ファイルや検索結果の詳細情報を表示したり、開いているウィンドウのサムネイルとタイトルの両方を表示するなど、こういった研究結果を活用してきました。[Start] (スタート) 画面では、人間の認知処理の特徴を活かす設計が採用されています。これらの特性は、私たちに刻み込まれた基本的な神経論理パターンで、そもそも人間がコンピューターを使うまでに進化した背景の一部とも言えます。

  • 人間特有の空間記憶 - ものを置いた場所や何かが現れる場所を記憶する能力。これには空間的関係、つまり 2 つ以上の物体が空間内で相対的にどのような位置関係にあるかという情報を活用する能力も含まれる。
  • 運動記憶 - ある動作が、意識することなく自動的に行えるようになること。
  • チャンキング – アイテムをグループ化して把握することで、後で思い出しやすくすること。
  • 信号検出理論 – "ノイズ" や関心のないアイテムがたくさんある状態でも、関心のあるアイテムを識別することができるという人間の能力を説明する理論。

私たちはこういった属性を活かした設計を実現したいと考えました。[すべてのプログラム] ビュー、最も頻繁に使用されているアプリケーション (MFU) の一覧、ピン留めされたアイテムの一覧などの要素を抱える [スタート] メニューでは、スペースやレイアウトの面でかなりの制約がありました。1 次元のリストでは、リッチで空間的なフレームワークを構築することはできません。[Start] (スタート) 画面なら、2 次元的な空間を活用することが可能です。Microsoft Research は、ドキュメント管理 (英語) や情報の取得 (英語) における空間記憶、Task Gallery (英語) についてなど、さまざまな研究を通して、1 次元的なビジュアル テキストのリストにリッチな整理方法を加えることで、6 か月の中断期間を置いてもなお、アイテム発見の効率が向上することを示しています。私たちは、この効果を活かして [Start] (スタート) 画面におけるアプリの発見をより迅速なものにしたいと考えました。

多くのコメントで、大型のモニターやマルチ モニターを使用するケースへの言及がありました。当初得られた反応は [Start] (スタート) 画面がこのアプローチに向けて最適化されているとは言えないというものでしたが、設計上の目標はまさにこういった環境での機能性を強化することにありました。他の多くのケースと同様、開発チームにはハイテク志向のパワー ユーザーが大勢おり、複数の HD+ 画面を使って、多数の Win32 アプリケーションを常に実行していると言っても、驚かれることはないと思います。多数のアプリやサイトを利用する場合は、中央のモニターで [Start] (スタート) 画面を利用することで、最も迅速に起動や切り替えを行って作業に戻ることができます。また同時に、さまざまな (今後書かれるであろう) ビジネス アプリケーションのステータスを表示するヘッドアップ ディスプレイが利用できることは、ユーザーに新しいレベルの機能性をもたらします。

[Start] (スタート) 画面で空間配置を活用する

[Start] (スタート) 画面におけるタイルのグループ化は、これらの原則を念頭に設計されました。グループの大きさが、各ユーザーがまとめるアイテムの種類によって当然ばらつくことは、既にわかっています。この柔軟性のメリットは整理のしやすさだけではありません。各グループの形状や大きさがそれぞれ異なる、不均一なレイアウトになることも重要です。これによって、たとえば右の端がぎざぎざになっている小さなグループの中、あるいは完全な長方形になっている大きいグループの中という風に、タイルを見つけるのが容易になります。

[Start] (スタート) 画面のレイアウトの概略図

[Start] (スタート) 画面のレイアウトでは位置、形状、相対的な位置関係、色などがアプリを見つけるのに役立つ

グループの大きさや形状以外にも、いくつかの要素が目的のタイルを探す際に役立ちます。グループの上端の右端 (赤)、大きいグループの中にある横長の緑色のタイルの隣 (黒)、大きいグループの上の列で最初に出てくる正方形のタイル (水色)、[Start] (スタート) 画面の一番最後のタイル (黄色) など、目的のアイテムを探す際に複数の属性を手掛かりにすることができます。タイルのグループについても同じことが言えます。ゲームが入ったグループやニュース アプリが入ったグループを探す際、画面をスクロールしながら、一般的な色やグループの形状によって目的のグループを識別することができます。

人間の進化を通して空間認識を説明する

進化の観点から見ると、この種の認識能力は、最も基本的な生存スキルとして私たちの潜在意識に根差しています。人間は何種類もの感覚を駆使して刺激のマッピングを行います。刺激の場所を確認し (相手はどこだ?)、位置づけを行う必要があります (私を食べようとするだろうか?)。また、将来的な処理と比較のために記憶しておく必要もあります。このような流れを速く滑らかに処理するためには、ユーザーが適切な選択を行い、選択内容を記憶するために十分なだけの情報を提示し、それでいて受け取った情報を解釈するために脳が立ち止まる必要がないよう、処理能力を要求し過ぎない内容にする必要があります。

こういった話は既に聞き覚えがある方もいらっしゃるかもしれません。これが基本的に、アイコンを使った表示によって効率性が増す理由です。不規則なパターンが視覚的なヒントとなり、情報処理の必要がなくなって感覚運動的なスキルだけで操作が可能になる理由でもあります。また、同様の書式のテキストが大量に並んだメニュー (またはグラフィカルなボタン) が、最も脳の処理能力を要求するのも同じ理由です。こちらに視覚認知の原理 (英語) についての入門的な資料として適切な記事があります。また、もちろん他にももっと踏み込んだ技術的な資料が存在します。

偶然ながら、コメントでは空白の削減、透明な要素の使用、UI の角を丸くすることでデザインに視覚的な "甘味" を加えることなどの提案もいただいていました。明確なスペーシング、ソリッドな輪郭や背景、長方形の使用などは、実は、プログラムを認識しやすくし、頭痛等の原因となる脳の処理負担を減らすための大きな改良点です (輪郭強調の錯覚 (英語) や色が提供する価値 (英語) についてのマサチューセッツ大学の調査をご覧ください)。基本的にこういった装飾の追加は脳に錯覚を与えるもので、単に反応するのではなく、時間をかけて刺激の内容を "理解" する必要があると思い込ませる効果があります。

カスタマイズ性向上への取り組み

カスタマイズ性について言えば、現在の [スタート] メニューもカスタマイズが可能であるというご指摘は、間違いなく正しいものです。Ed1p さんの挙げられた方法によって、フォルダー名を変更すること (ただし正常なアンインストールができなくなります) や、ファイルを移動すること (ただしユーザー単位、マシン単位のセットアップが崩れます) ができ、システム上のアプリのツリー構造は、基本的に再構成が可能です。また、[スタート] メニュー内でアイテムをドラッグ アンド ドロップしたいという勇敢なユーザーがいらっしゃれば、それも (操作ミスが非常に起こりやすいですが) 可能です。

しかしこれらはかなりの上級者向けのカスタマイズ方法で、多数のユーザーのニーズには (当初はその意図で設置された機能であったとしても) 残念ながら対応できません。相当の時間がかかるだけでなく、[スタート] メニュー内で直接作業することができず、間接的な操作になってしまう点も問題です。希望する結果を得るまでに、エクスプローラーのウィンドウとポップアップ メニューとを何度も行き来する手間が生じます。

[Start] (スタート) 画面のパーソナル化は、私たちがぜひ優れた機能にしあげたいと考えている点で、現在も改良に向けた試行錯誤が続いています。柔軟なグループ サイズ、タイルのピン留め解除、横長のタイルから正方形のタイルへの変更などは、Windows Developer Preview の段階でも既にお試しいただけるようになっています。そしてベータ版では、グループの作成と名前の変更、並べ替えなどのほか、ここでの対話に基づいたその他の改良点も盛り込まれます。

drewfus さんのご指摘:

「私が言った "PC にどんなアプリがインストールされているか (つまりどんなタイルがあるか) は把握可能でもないし固定されてもいない" というのは、アプリのリストは一定のものではないということです。時間が経てばアプリは増えるし、より重要なことに、アプリ追加の時系列と追加されたアプリの重要性には (偶然を除いて) まったく関係がありません。結果として、ユーザーの既存の [Start] (スタート) 画面のレイアウトに常に影響が出てしまいます」

これは鋭いご意見です。使用するアプリは通常、時間が経つにつれて増えたり入れ替わったりするもので、最初に [Start] (スタート) 画面を整理してから何か月も後にお気に入りのアプリが見つかることもあるでしょう。私たちが目指したのは、[Start] (スタート) 画面に対するユーザーの制御性を保ちつつ (つまり既に整理した内容に影響を与えないよう、新しく入手したアプリは端に配置し)、同時に必要な場合は容易に変更できるようにすることです。グループの並べ替えは、drewfus さんが言及したシナリオで特に役立ちます。インストールしたアプリが増えてくれば、お気に入りのアプリが [Start] (スタート) 画面の端に追いやられてしまうことは十分にあり得ます。グループ単位での並べ替えによって、1 つのグループをまるごと先頭に持ってくることができ、タイルを一つ一つ移動させる必要がなくなります。また、グループを末尾に移動させるのも同様に簡単です。

Developer Preview はこの点においては明らかに未完成でしたが、この件については私たちも非常に重要だと考えており、従来の製品からの変更を正当化するのに十分なだけの柔軟性と全体的な改良を盛り込んだソリューションを、必ず実現するつもりです。

空間的なレイアウトで好きなようにアプリを配置できること、グループを使って認識性を高められること、そして画面内で自由にタイルを移動させられることは、[スタート] メニューと比べて非常に大きな改善と言えます。これによって整理やカスタマイズの方法が新しい次元へと広がり、非常に大量のアプリやショートカットを扱う作業が劇的に効率化されるものと考えています。

ジャンプ リストに投資させておきながら廃止してしまうのか?

tN0 さんのコメント:

「[Start] (スタート) 画面のライブ タイルにジャンプ リストを実装してほしいです。タイルを上に向かってスワイプするか右クリックすればジャンプ リストが表示されるのが望ましいと思います」

アプリ内のコンテンツにすばやくアクセスできるというのは優れた機能です。Windows 7 のジャンプ リストに熱意が向けられ、使用量も増えてきているのは、私たちにとっても嬉しいことです。Metro スタイル アプリに対しては、ジャンプ リストのコンセプトに基づく新しい機能を開発しました。この新機能は、エンド ユーザーにとってはさらに強力で、アプリ開発者にとってはさらに豊かな可能性をもたらすものとなるはずです。しかしまずは背景として、今日の Windows におけるジャンプ リストの利用状況についてお話ししたいと思います。

ジャンプ リストの現在の利用状況

ジャンプ リストは上級ユーザーからは好意的な熱意を持って言及されることが多いのですが、現実問題として、[スタート] メニューのジャンプ リスト (たとえばアプリで最近使ったドキュメントのリストなど) の利用は、タスク バー上のものと比べるとあまり盛んではありません。比較してみると、タスク バーのジャンプ リストを開くためのクリックが記録されるセッションは全体の 20% にのぼるのに対し、[スタート] メニューでジャンプ リストを呼び出すためのクリックが記録されるセッションは 1.2% にとどまっています。[スタート] メニューでジャンプ リストを呼び出す別の方法として、マウス カーソルを合わせるという操作がありますが (タスク バーのジャンプ リストではドラッグ操作)、この操作については回数をデータとして使用するのが困難です。これは、ユーザーが意図的にジャンプ リストを開いたのか、偶然マウス カーソルが一定時間そこに置かれていただけなのかを判断できないためです。いずれにせよ、マウス カーソルによる偶発的な呼び出しを含めて数えても、[スタート] メニューのジャンプ リスト使用頻度は、タスク バーのものの半分以下です。

Metro スタイル アプリへの適用

このデータから、最も一般的に使用されるデスクトップ アプリで活用できるよう、タスク バーのジャンプ リストは残しておく必要があることがわかりました。しかし Metro スタイル アプリに対しては、もっとカスタマイズされたものを提供したいと考えました。現行のジャンプ リストの難点は、Windows が最もよく理解できるもの、つまりファイルしか扱えないという点です。これはファイルを中心に扱うアプリでは有効ですが、今日のアプリの多くはファイルという概念から離れ、ホストされたコンテンツという形態に近づいています。こういったアプリでは、ドキュメントを中心としたジャンプ リストという考え方はあまり有効ではありません。

ファイル構造を基盤とした発展形の代わりに、Metro スタイル アプリではよりアプリ中心のアプローチが採用されています。ホストされるコンテンツについて、より詳しく理解しているのはアプリです。RSS フィードであれ、アルバムであれ、得点データや人物のプロフィールであれ、アプリが扱うコンテンツに対するすばやいアクセスを提供するのであれば、そのアプリ自体が行うのがベストでしょう。こういったコンテンツは Windows が把握しているシステム内のファイルに関連するものではなく、アプリ内の情報だからです。このため、ジャンプ リストのコンセプトを拡大して、意味論的によりリッチなリンクを提供することにしました。

しかし、お気に入りのアイテムのリストを複数管理するのは面倒です。[Start] (スタート) 画面に期待される役割の一つは、ユーザーが最も気に入っているアプリをホストする、パーソナルな場所となることです。セカンダリ タイル機能は、ユーザーは作業に必要なアプリのコンテンツへのすばやいアクセスを求めており、アクセスは単一の予測しやすい場所から可能であるべきだという考えに基づいて設計されています。この機能により、Metro スタイル アプリでは、ユーザーが [Start] (スタート) 画面に追加でタイルをピン留めでき、このタイルからアプリ内の任意の場所に移動することができます。しかも、このタイルをライブ タイルにして、その特定のコンテンツに関する最新の情報を提供させることも可能です。ファイル ベースのアプリで、同様の機能をファイルについて提供することももちろん可能でしょう。使用状況データから、ユーザーは一般的なドキュメントをかなりていねいに、かつこまめに再利用することがわかっています。Office アプリやタスク バーで見られるような、ファイルをピン留めできる MRU は、非常に人気があります。私たちが開発者に向けて提供するサポートはこのことをストレートに反映しています。

たとえば、親友のソーシャル タイルを [Start] (スタート) 画面にピン留めしておけば、彼女についての最新の情報を常に把握しておくことができます。あるいは、RSS リーダー内の "xkcd" のフィードを追跡することができます。または、従来ジャンプ リストでやっていたのと同じように、毎朝聴くことにしている曲の入った再生リストにすばやくジャンプすることも可能です。各種ビジネス アプリケーションでもこのような "深いリンク" が許可され、特定のマシンのモニタリングや、アカウント情報の確認、その他の例外処理 (以前の記事でご紹介したバグ追跡ツールのような) が可能になることを期待しています。しかも、すべてが [Start] (スタート) 画面内で可能なのです。これらの情報が、その他のお気に入りのアプリと共に整理して表示されるため、迅速にアクセスでき、消費したいコンテンツにすぐにたどりつくことができます。

セカンダリ タイルの活用

Metro スタイル アプリの開発者が、ライブ タイルを通してユーザーにパーソナルでリッチなコンテンツを提供できるよう、私たちは今後もサポートを続けていきます。セカンダリ タイルは、マシンをさらに便利でパーソナルなものにするうえで多いに役立ち、ユーザーに愛されるものとなるはずです。開発者がユーザーのためにより多くのシナリオを実現できるよう、さらに多くのライブ タイルのテンプレートを作成してカタログに追加していきます

全体として、ユーザビリティ上の現実的な問題と言えるのではないか?

mt327000 さんのコメント:

「従来の [スタート] メニューの復活を求める多くの声は、単なる変化に対する不満ではありません。私には、新しい [Start] (スタート) 画面は実際に [スタート] メニューよりも効率が低下しているように感じられます。確かに、このブログに投稿されているコメントの中には、主張を通したいがために中傷まがいの発言になっているものもありますが、科学的な観点から言って、Windows 7 と Windows 8 のユーザビリティをクリックの回数で計測してみれば、Windows 7 が圧勝するはずです。これは単純な不満ではなく、現実的なユーザビリティの問題です。Microsoft は対策を講じてほしいと思います」

効率性、つまりタスクを正確に完了するのに要する時間は、設計においてきわめて重要な要素です。これは間違いありません。"最も重要な要素" と呼ぶことはしませんが、これは、ある機能の動作を設計する際は、さまざまな属性を幅広く考慮しているためです (リソースの活用、信頼性、アクセシビリティ、ローカライズの可否、セキュリティ、トレーニングの要否、発見可能性など)。効率性とユーザビリティの両面で製品の改良に取り組む際には、ユーザー インターフェイスに関するいくつもの要素を考慮します。たとえばマウスの移動距離、対象の大きさ、読み込み時間、情報の解釈にかかる時間、クリックの回数などです。どのような変更であっても、効率性においてプラスの面があり、時にはマイナスの面もあり得ますが、すべてを合算すれば最終的には "純利益" が生じるよう、細心の注意を払っています。

多くのコメントに共通して見られたのは、変化を直ちに拒否する姿勢です。どのような内容の変更であっても、必ず採算がとれないほどの生産性の低下につながるという考え方です。私たちが使う比喩の一つとして、道路の改良工事や交通量があります。たとえば新しい道やインターチェンジの建設です。こういったプロジェクトでは、建設工事に何年もかかり、多くの人がその間に無駄にする時間の量に苛立ちを覚えます。しかしプロジェクトが完了すれば、その後は改善された道路環境をだれもがずっと享受することができます。現在から将来にわたって通行する人すべてに対して "純利益" が発生するのです。現在のユーザーに対しては短期的なコストが発生しますが、代わりにすべての人がメリットを享受できることになります。それでも、工事が続く間、無駄になった時間を埋め合わせるだけのメリットが本当にあるのかどうか気にしてしまうのは、当然のことでしょう。私たちが耳にする懸念の声もこのような種類のものです。道路工事と異なり、Windows では、変更によるメリットが何時間や何日、あるいは何週間というスパンでユーザーの皆さんに戻ってくるよう、変更の内容を設計します。交通量の改善を行う際、わずかな期間であっても決してユーザーの邪魔にならないことを前提とすれば、結局いつまでも何も改善できず、だれにとってもエクスペリエンスが徐々に衰退していく結果となるでしょう。Windows の場合も同じような困難があります。製品は新しい利用方法や新しいハードウェアに対応して改善していく必要があり、必然的になんらかの変化が常に発生することになります。道路の建設と同様、従来のルートと新しいルートを同時に開通させておくわけにはいきません。しかしさいわいなことに、道路工事とは違って、ユーザーは自分の PC を自由に管理することができ、好きなタイミングで切り替えを行うことができます。特に企業に対しては、最短で 10 年間のライフサイクルが保証されています。

"純利益" の確保については、小さな一例として、Windows キーを押してすぐにキー入力を始めるだけでアプリを検索できるという点があります。検索ボックスが画面に現れなくても、即座に入力が始められるよう、特に注意しました。これによってアプリ検索の効率性が守られます。この設計上の選択により、ユーザーがこの機能を発見するまでには若干の時間を要するものの、一度発見すれば、効率性が大きく向上することになります。実際的な話をすれば、この機能は通常、Windows 8 を使い始めてから何時間かで発見されるようです。このことは Developer Preview を使用されている方のツイートの動向から知ることができました。発見されなかったとしても、検索コマンド自体はそこにあり、クリック 2 回で検索ボックスに行きつくことができます。しかも、余分な UI の省略というメリットは、全員が享受できるのです。

マウスの移動距離とクリックの回数

コメントの中には、マウスの移動距離やクリックの回数に注目して効率性を議論するものが多く見られました。これらは確かに効率性を計測するうえで重要な指標ですが、大きな影響を持つもう一つの要素として、対象の大きさというものがあります。フィッツの法則については既にご存知の方も多いかと思いますが、簡単におさらいして、ソフトウェアに対してどのように適用されるか見てみましょう。

フィッツの法則は、オハイオ州立大学の心理学者で、航空技術の専門家だったポール フィッツ氏にちなんで名付けられました。フィッツ氏はコックピットにおける人間工学のモデル化を目指す研究を行っており、人間が物理的なボタンにどれだけすばやく触れられるかを定式化するモデルの開発に成功しました。このモデルは間もなくソフトウェアにも適用されるようになり、画面上の対象物をどれだけすばやくマウスでポイントすることができるかを算出するのに使用されています。

数式はやや複雑ですが、基本的な考え方は次のとおりです。

  • 対象が遠くにあるほど、マウスで捕捉するのに時間がかかる
  • 対象が小さいほど、マウスで捕捉するのに時間がかかる

つまり、対象をマウスでクリックできる速さは、対象の大きさと対象までの距離の両方に影響されます。

 小さな正方形: 近くにあるが、小さいため、捕捉するには動作の精度が要求される。大きな正方形: 遠くにあるが、大きいため、捕捉する際に動作の精度はあまり要求されず、簡単にすばやくクリックすることができる。
対象が近くにあるほどすばやく捕捉でき、対象が大きいほどすばやく捕捉できる

2 つの補足対象をもう少し数学的に比較するためによく使用される数式として、シャノンの公式化があります。

T = a + b log 2 (1 + D/W)

ここでは次のようになります。

  • T: 対象を捕捉するのにかかる平均時間
  • a および b: 線形回帰によって求められる実験定数
  • D: スタート地点から対象の中心までの距離
  • W: 動作の方向に測った対象の幅 (対象にどれくらい接近すれば捕捉したと見なされるか)
Windows 8 へのフィッツの法則の適用

Windows 8 で、フィッツの法則の適用対象として最もわかりやすい要素の一つが [Start] (スタート) ボタンです。"チャーム" はタッチ操作に最適化されていますが (画面の右端から内側に向かってスワイプすることで [Start] (スタート) ボタンにアクセス可能)、マウス ユーザー向けに、画面左下の角にもコントロールが確保されています。フィッツの法則では、画面の角は対象としての "幅" が無限大となり、この位置にある UI は最も捕捉しやすいことになります。[Start] (スタート) ボタンの高い効率性を維持することはユーザーにとって重要なため、新しい UI のパラダイムを作り上げる際も、この点については議論の余地はありませんでした。

フィッツの法則が活用されている箇所として、もう一つ明らかな例が、[Start] (スタート) 画面です。一般的に、[スタート] メニューの各エントリ ポイントと比べると、タイルはマウス カーソルから離れた位置にありますが、サイズが大きいことで距離による効率性のロスが打ち消され、効率性が向上している場合さえあります。

デスクトップ モニターについて見てみましょう。同じデバイスの使用を前提とするため定数 a および b は固定し、[スタート] メニューと [Start] (スタート) 画面に応じて D および W を変化させることで、アプリへのリンクを捕捉する速さを算出することができます。この結果をヒート マップで表して比較したものを次に示します。

 [スタート] メニューにヒート マップをオーバーレイしたようす。メニュー上部にある (マウスから遠い) アイテムは赤色、中ほどのアイテムは黄色、下部にある (マウスに最も近い) アイテムは緑色で表示されている。
[スタート] ボタンから [スタート] メニューの各アイテムへの到達にかかる時間を表したヒート マップ
(緑色のアイテムは最も所要時間が短く、赤いアイテムは最も長い)

 [Start] (スタート) ボタンから [Start] (スタート) 画面の各タイルへの到達にかかる時間を表したヒート マップ。緑色のタイルがマウスに最も近い左下の角に、黄色のタイルが中ほどに、赤色のタイルがマウスから最も遠い右上に表示されている。
[Start] (スタート) ボタンから [Start] (スタート) 画面の各タイルへの到達にかかる時間を表したヒート マップ
(緑色のタイルは最も所要時間が短く、赤いタイルは最も長い)

緑色で表示されるアイテムを数えると (白線で境界を表示)、[スタート] メニュー (アプリ 2 つ) よりも [Start] (スタート) 画面 (正方形のタイル 17 個程度) の方がかなり多いことがわかります。[Start] (スタート) 画面では、より多くのアイテムにすばやくアクセスできるのです。

[スタート] メニューでは、最上部のアイテム (通常は MFU のアプリかピン留めされたお気に入りのアプリ) が濃い赤に近い色になっています。これは残念なことです。リストでは通常上から下にアイテムを並べるため、[スタート] メニューもこのロジックに従っていますが、効率性を最優先にするなら、順序を逆にしてリストの最下部に配置したかったところです。一方 [Start] (スタート) 画面では、左下に位置するタイルがマウスで最も到達しやすいアイテムで、しかも [スタート] メニューのどのアイテムよりも到達しやすくなっています。

[スタート] メニューの最上部のアイテムは赤色で表示され、到達するのに時間がかかることを示している。下部のアイテムは緑色で、到達に要する時間が短い。 左下の角のアイテムは緑色で表示され、アクセスしやすいことを示している。右上のアイテムは黄色で、到達に要する時間が長い。 
[Start] (スタート) 画面と比べ、[スタート] メニューでは最も頻繁に利用するアイテムが遠くにある

最終的なタイルの大きさや形状を決定する作業には何か月もの時間がかかり、その間かなりの試行錯誤がありました。ご想像いただけると思いますが、さまざまなパターンが検討され、その多くは実際にラボで試用されました。ちょうどフィッツ氏が空軍機のコックピットの最適化のために行ったであろうように、私たちも被験者にさまざまな種類のボタンをマウスで捕捉してもらいました。マウスの移動距離 (そしてタッチ対象の大きさ) は検討事項の一部にすぎません。タイルの大きさを決めるうえでは、これらに加えて次の要素を考慮しました。

  • 画面サイズ – 各モニター サイズで、画面 1 ページあたり何個のアプリが表示されるべきか?
  • フォーム ファクター – 使用するフォーム ファクターの違いは、アイテムの適切なサイズにどのように影響するか (たとえば長椅子に座ってスレートを手に持っている場合と、大型モニターを机に置き、少し離れて座っている場合とではどのように違うか)?
  • ざっと見たときの把握しやすさ – コンテンツにざっと目を通しやすいようにゆとりを確保しながら、同時に十分な密度と有用な情報を提供するにはどうすればよいか?
  • レイアウト – グリッド状に配置されたコンテンツを把握しやすくするにはどのようなレイアウトが最適か? 情報を読み取りやすくするには各タイル サイズにはどのような相関性があるべきか?
  • ライブ コンテンツの表示とアプリのブランディングに必要なスペース – タイルで有用な情報を提供するには十分な大きさが必要だが、情報量が多すぎない程度の大きさに抑える必要がある。また、実際にアプリを起動する際にあまりスクロールが必要にならないようバランスをとる必要がある。
  • 視覚的に心地よい形状 – タイルは視覚的に心地よい外見にする必要があり、ページに並べたときの形も訴求力のあるものでなければならない。

これはタイルの大きさや [Start] (スタート) 画面の密度を設計する際に検討したさまざまな要素のうち、ほんの一部にすぎません。マウスでの動きの効率性や対象の捕捉しやすさ、情報の読み取りやすさ、さまざまなフォーム ファクターや画面サイズでのリアルタイムのデータを一望できる表示などのバランスをとり、強力で効率的な使用感を目指した結果が現在の [Start] (スタート) 画面です。

それで、必要なクリックの回数は?

前回の記事で Alice が触れたように、現行の [スタート] メニューは、使用頻度の低いアプリの起動が主な用途となっており、使用頻度の高いアプリはタスク バーやエクスプローラーから起動されています。実際のところ、今日ではアプリ起動の 88% が [スタート] メニュー以外の場所から行われます。代わりに主に使用されているのはタスク バー (41%) で、残りはエクスプローラーやデスクトップ (47%) で起動されています。[スタート] メニューの有用性が低下してきていることは明らかで、同時に、より便利で価値のあるものを目指して再設計を行うチャンスでもありました。この対話では、最終的に "ロング テール" 的な位置づけにしかならない使用ケースについての論争に、エネルギーを注ぎすぎないようにしたいと考えています。

一方、古いパラダイムを捨ててみると、次に問題となるのは、クリックの回数を増やすことなく同じタスクを行うにはどうすればよいのか、という点です。この点を常に念頭に置きながら設計プロセスを進め、設計が決まると何種類かのタスクを選んで、一つ一つクリックの回数を比較しました。

MFU またはピン留めされたアプリの起動

[スタート] メニューの左側に表示されているアプリを起動するには、何回クリックする必要があるでしょうか。

Windows 7 では、目的のプログラムが [スタート] メニューの左側に表示されているものと仮定すれば、必要なクリック回数は 2 回、[スタート] ボタンをクリックし、アプリをクリックするだけです。[Start] (スタート) 画面でもこれと同等の効率性を保つことが重要でした。よって、[Start] (スタート) 画面の 1 ページ目にアプリが表示されていれば、クリック 2 回で起動できるようになっています。

ただし、この "2 クリック" での起動という恩恵を得られるアプリの数は、新旧の UI の間で異なります。既定では、[スタート] メニューではお気に入りのアプリ 10 種類を 2 クリックで起動することができます。このほかに Windows が自動で追加する 10 個の特別なフォルダーがありますが、こちらは頻繁に使用されるものは多くありません。最も使用率が高いのは [コンピューター] で、全セッションの 8% 程度で使用されていますが、これ以外のアイテムでは数値は劇的に小さくなります。また、[スタート] メニューのこの部分は限定的ながらカスタマイズが可能ですが、ホーム ユーザーの 81% が既定の状態のまま使用しています。

一方 [Start] (スタート) 画面では、ずっと多くのアプリに 2 クリック アクセスを提供することができ、画面のレイアウトをすべて自由に制御することができます。[Help and Support] (ヘルプとサポート) へのリンクが不要なら、置いておく必要はありません。代わりにそのスペースにお気に入りのアプリを追加することができます。また、モニターが大きくなれば、2 クリックで起動できるアプリの数もそれに応じて増加します。ちょうどカスタマイズも従来よりずっと簡単にできるように改良されており、アイテムを整理する際に [プログラムの追加と削除] を呼び出す必要はなくなっています。各モニター サイズで表示できるタイルの数を次に示します。

フォーム ファクター

サイズ (インチ)

解像度

[Start] (スタート) 画面の 1 ページあたりのタイル数

[スタート] メニューのアイテム数

スレート

10.1

1366 × 768
1920 × 1080

横長 12 個または
正方形 24 個

10

10.6

1366 × 768
1920 × 1080

横長 12 個または
正方形 24 個

10

11.6

1366 × 768
1920 × 1080

横長 12 個または
正方形 24 個

10

ノート PC

12.1

1280 × 800

横長 16 個または
正方形 32 個

10

12.1

1366 × 768

横長 20 個または
正方形 40 個

10

13

1366 × 768

横長 20 個または
正方形 40 個

10

13.3

1440 × 900

横長 25 個または
正方形 50 個

10

デスクトップ PC

21.5

1920 × 1080

横長 36 個または
正方形 72 個

10

23

1920 × 1080

横長 36 個または
正方形 72 個

10

27

2560 × 1440

横長 42 個または
正方形 84 個

10

モニター サイズに応じた [Start] (スタート) 画面のスケーラビリティと、[スタート] メニューとの比較

表示されるアプリ数に加え、[Start] (スタート) ボタンをクリックした際に何が表示されるかというロジックも変更されています。[スタート] メニューでは、ヒューリスティックによってここに表示される MFU (最も頻繁に使用されている) アプリが決まります。しかし残念ながら、こういった複雑なヒューリスティックによる推定は間違っていることもあり、ここに表示されるアプリは時間と共に変化するため、予測できない要素がランチャーに持ち込まれることにもなります。一方 [Start] (スタート) 画面ではユーザーによる管理と予測可能性に重きが置かれており、カスタマイズを奨励すると共に、何がどこにあるか確信しやすい設計になっています。これはタスク バー設計の際に設定したデザイン目標と同じです。

[すべてのプログラム] リストからのアプリの起動

[すべてのプログラム] リストからの場合、起動するアプリによって (たとえば頭文字が A に近いか Z に近いかなどによって) 必要なクリック回数が異なります。ある程度の数のアプリがインストールされている場合の一般的なケースでは、概ね次のようなワークフローになるでしょう。

[スタート] ボタン –> [すべてのプログラム] ボタン –> スクロール バー ボタン –> 目的のアプリのフォルダーを展開する (フォルダーが合っていますように!) –> アプリ = クリック 5 回

[Start] (スタート) 画面ではフローは異なりますが、同様のシナリオでは次のようになります。

[Start] (スタート) ボタン –> 左下にカーソルを合わせる –> [Search] (検索) ボタンをクリックして [Apps] (アプリ) 画面を起動 –> スクロール バー –> アプリ = クリック 5 回

この比較ケースでは、[すべてのプログラム] 機能を使った場合と [Apps] (アプリ) 画面を使った場合とで同じクリック回数になりましたが、これは [スタート] メニューで 1 回で正しいフォルダーを開くことができたということが前提になっています。また、[Start] (スタート) 画面ではモニターの広さを活用できるため、アプリを見つけるためにスクロール バーを使わなくても済む可能性も高まります。この場合、Windows 8 ではクリック 4 回ということになります。他のタスク、たとえば [スタート] メニューの右側のアイテム (例: [コントロール パネル] や [コンピューター]) を起動する場合についても、数えてみれば新旧 UI で同じクリック回数になることがご確認いただけると思います。

また、キー入力の回数についても同様の結果になります。これらの指標においては、少なくとも同等の効率性を確保するよう、注意が払われています。

システムの他の部分からの起動

既に述べたように、実際のアプリ起動の 88% は [スタート] メニュー以外の場所から行われています。他の起動元はタスク バー、エクスプローラー、およびデスクトップで、これについては Windows 8 でも従来と同様です。ただし、抜けのないように補足しておくと、マシンを起動すると最初に [Start] (スタート) 画面が表示されるため、タスク バーやデスクトップに移動するには、最初に 1 回余分なクリックが必要ということになります。幅広い枠組みで捉えた場合、作業セッションを通して行うクリックの回数を考えれば、最初にデスクトップに移動するために行う 1 回のクリックは全体的な効率性にはほぼ影響しませんが、この点についての質問も何件かいただいていましたので、なぜこのような設計になっているか、簡単にお話ししておきたいと思います。

[Start] (スタート) 画面は Metro スタイル アプリとデスクトップ アプリ両方のランチャー (および切り替えツール) なので、マシンを起動するとまずこの画面が表示されます。ここが新しいホーム ベースです。これによって、最初に起動するアプリを (デスクトップ アプリであれ Metro スタイル アプリであれ) ユーザーが自由に選ぶことができます。また、このフローにより、日々のタスクに入る前に、まずお気に入りのアプリからの最新の情報を (アプリ自体を起動することなく) ダッシュボードで確認する機会を得ることができます。こういった通知やダッシュボードを一切見たくないとコメントされている方もたくさんいらっしゃったことは理解しています。私たちから述べておきたい点は 2 つあります。

1 つ目は、情報の通知を行うアプリやガジェットが重要だと考えられていることは、上記のようなコメントからも理解できるという点です。

2 つ目は、このリリースが Developer Preview である以上、現時点では利用可能な Metro スタイル アプリがあまり存在しないということを私たち全員が認識しておかなければならないという点です。このため、当然ながら起動するたびにデスクトップに移動することになり、[Start] (スタート) 画面から開始するのはばかげているように思えてしまいます。しかしお気に入りのアプリがたくさんインストールされた状態になれば、このフローは意味のあるものとなるはずです。その後もデスクトップ アプリの使用が中心となる場合は、デスクトップのタイルをクリックしてタスク バーを使うことで簡単に起動でき、また、[Start] (スタート) 画面をカスタマイズして、お気に入りのデスクトップ アプリを画面の最初に表示しておき、直接起動するという方法もあります。これは意識しておくべき点です。現在、タスク バーにすぐにアクセスするためにデスクトップに移動されている方もいらっしゃるかと思いますが、タスク バーに置いているアプリを [Start] (スタート) 画面に置いてそこから起動 (または切り替え) したり、毎回必要な最も使用するアプリを、フィッツの法則に沿った使いやすい場所に置くという方法もあることは、覚えておいていただければと思います。そしてもちろん、ロック画面からログオンすることで今後実現されるであろう大幅なクリック回数の節約についても忘れるべきではありません。余分なキー操作の分を十分に補うだけの即時的なメリットが全体的なワークフローに対して発生することになります。

[Start] (スタート) 画面の効率性向上に向けて続いている取り組み


Developer Preview をお見せした後も Windows の改良は続いていますが、その際、効率性という点には常に注意が払われています。いただいたフィードバックに基づく改良点の一つとして、すべてのプログラムによりすばやく到達できるよう、デスクトップで [Search] (検索) をクリックすると直接 [Apps] (アプリ) 画面が開きます。これによって潜在的にこのタスクから手順を 1 つ削減することができ、Windows 8 におけるデスクトップからのアプリ起動が Windows 7 と比べてさらに効率的なものとなります。また別の取り組みとして、大型モニターを使用している場合に表示できるタイルの行数を増やすという点があります。これによって、より多くのお気に入りのアプリをマウスから近い位置に追加することができ、アプリの起動がこれまで以上に迅速になります。

皆さんが新しい [Start] (スタート) 画面で効率性を得ることができるよう、私たちは努力を続けています。同じ条件で比較することができないため、この種の分析はしばしば困難です。場合によってはマウスの移動距離が増えたことによる損失があり、場合によっては対象のサイズが大きくなったことによるメリットがあります。空間的な配置や色がアプリの発見に役立つこともあれば、マウスのすぐ下にアプリがあることでクリックしやすいケースもあります。[Start] (スタート) 画面で得られる効率性のメリットは、これまでに慣れ親しんだものとは異なる形で現れることもあります。予想しない形で生じるメリットもあるでしょう (たとえば、ライブ タイルによって株式相場がわかり、そもそもアプリを起動する必要がなくなったとすれば、効率性は大幅に向上しているはずですが、これを定量化するのは困難です)。新しい UI の効率性は今後も継続的にテストし、改良していきます。

ここまでお付き合いくださった方は、これだけの数の問題をなぜ 1 件の長大な記事の中でまとめて扱ったのか、不思議に思われるかもしれません。しかも、それでも回答するべきフィードバックや質問はまだまだ残っているのです。私たちの意図は、Windows の構築において提供している過去に例を見ない透明性に基づき、その延長として、皆さんにこの製品の開発の内面まで踏み込んでいただくことにあります。Windows 8 の開発が、非常に複雑な取り組みであることは、もうご理解いただけていることと思います。数多くの変数や選択肢、大量のデータがあり、それらを考慮すれば、最小限の変更を行うにあたっても非常に多くの労力を払うことになります。皆さんとこうして対話することができ、Windows をお届けするために行っている仕事の深度についてご説明する機会を持てることは、私たちにとって本当に嬉しいことです。Windows チームの全員が、すばらしい製品を構築できるよう、プロフェッショナルとしてのキャリアすべてを捧げて取り組んでいます。情熱と知識を持ったユーザーの皆さんと、この作業の細部についてお話しできること、それ自体が、私たち一人一人にとって特別なボーナスとなっています。

--Marina Dukhon

Comments (9)
  1. masathi says:

    新しいもの(スタート画面)への取り組みに対する、真摯な調査・研究・努力・情熱などが伝わってくる、素晴らしいコメントだと思います。開発にあたっている全ての皆さんに敬意を表します。

  2. Null says:

    個人的にはたたむべきところはたたんだほうがよさそうに思います……。

  3. ろうし says:

    もう精神論でスタートメニューを残してくれ。それだけだ。合理性などいいから。

  4. メトロのスタートを自動的に動くようにして! says:

    使ったアプリが自動的にメトロのスタートの左下に集まるようなオプションを用意してほしい。

    個人用なら使ったものが常に左下に来れば便利だと思う、企業などの共用のPCだとややこしくなるでしょうけど。

  5. はまかぜ says:

    なんか2chや本社のブログのコメント欄見ていると、スタートボタンを返せという発言が多いですね。これならオプションでつければ問題ないのではと思います。

    あと半透明表示機能が廃止されるそうですね。これはちょっと残念に感じました。オプションで付けてくれればいいなと思いますので、ぜひよろしくです。レジストリでも構いませんが・・・。

  6. すたんとメニュー says:

    スタート画面は画面全体が隠れてしまう。スタートメニューは画面全体は隠れない。

    もう年だから、スタートボタンを押したときに、あれ?何を起動するんだっけと思う事がある。

    スタート画面は思い出せない。

    スタートメニューは見えているので自動的に思い出す。

    使っている画面を全て隠すのはページをめくるのに似ている。

    初期のIBMの汎用機のエディタでもページスクロールでなくて、半ページスクロールがついていたのに。。。

  7. pnnx says:

    スタートメニューは見えているので自動的に思い出す。

    →これは無い。

    そもそもスタートボタンを押した瞬間に記憶喪失になる人が本当にいるのか。

    仮に存在したと仮定しても、ジャンルごとに整理できるスタート画面の方が思い出しやすいはず。

  8. nnn says:

    翻訳だよね?ってぐらいしっかり訳された記事ですね

    でもこの内容で納得するユーザーがそんなに多くいるのかなと、ちょっと疑問です。

    自分がこの記事に来た理由のスタートボタンの廃止について言うなら

    一月に57種類のアプリケーションの数を使用するから~というのが妙に思う部分です。

    ユーザーが認識しない類のものが多いはず。バックグラウンドで動作するものはもちろんだけど、

    ファイルに関連付けられた編集ソフト、閲覧ソフトだってそう。

    加えて、利用頻度の違いは明確にあるはず。一月に一度だけ利用するソフトをいつも視界に置く前提で、

    マウスの移動距離云々というのはおかしいこと。

    今はスタート画面をスタートメニューのように使うよう努力はしていますが、

    一々作業を中断され、画面全体を覆われるのは結構なストレスです。

    部屋の中でリモコンをばらばらに置くと、よくわからなくなってしまいます。

    左下がショートカットであると、頭の中での割り切っていることは非効率ではないと思います。

  9. 名無しさんです says:

    なぜ"オフにしたい"、"選ばせて欲しい"の声に耳を最後まで傾けなかったのか?

    8で"最近のWindows 10レベル"なことをしていればここまで批判されることもなかったのに。。。

    Microsoftも一気に落ちたもんだ、前からMicrosoftファンだった私としては非常に残念で誠に遺憾だ。

    今後もこのような醜い「改悪」ばかりを続けるようなら、Windows以外のOSにしようかな。OSだけじゃなく、Officeもまた然り。

    直近のWindows Update(月例パッチ)での相次ぐトラブルや不具合といい正直もううんざりなのだ。

    こう考えてる利用者は私だけじゃないはずだ。企業でも同じ思いをしてるところは少なくないはず。

    今に客離れで思い知る日がそう来るであろう!!!!!!(激怒プンプン←これ本気よ。

Comments are closed.

Skip to main content