アプリで Windows 8 のコントラクトのアクティベーションを行う

これまでよく取り上げてきたトピックの 1 つとして、Windows 8 PC のアプリがどのようにして他のアプリや Web サービスと通信できるかということがあります。Windows 8 の手始めとして、アプリが、より充実した操作モデルとより明確なセマンティクスにより、一種のクリップボードのように、共有するデータの移動元または移動先になるというアプローチを選択しました。アプリにコントラクト (英語) を実装すると、Windows 8 は、そのアプリとシステム上の他のアプリ、およびシステム自体をつなぐ糊のような役割を果たします。この実際の動作は、Metro スタイルの Internet Explorer で Web ページから共有チャームを使用するなど、単純な操作を行ったときに確認できます。People アプリなどに連絡先情報を保存しているユーザーと、メール アプリを使ってリンクを共有できます。検索コントラクトを実装するアプリ全体を検索できます。File Open Picker (ファイル オープン ピッカー) コントラクトおよび File Save Picker (ファイル保存ピッカー) コントラクトを実装する任意の場所からファイルを開いたり、その場所にファイルを保存したりすることができます。この革新的なアプローチにより、Windows 8 は、特定のアプリの単一レベルのサポートを “ハードコーディング” するのではなく、任意のアプリとサービスのペアに対応できます。また、(選択している場合) これはすべて Microsoft アカウントによってサポートされ、Facebook から Twitter、LinkedIn など、異なるサービスに接続できます。今週 1 週間にわたって、新しい Microsoft アプリに関する一連の記事を投稿します。これらの記事では、Windows 8 による共有、接続、統合が主なトピックになります。これは、Windows 8 アプリ開発者ブログからの開発者に焦点を合わせた記事の再投稿で、ユーザー エクスペリエンス チームのプログラム マネージャーである Derek…

8

Windows 8 のユーザー エクスペリエンスの作成

このブログでは、これまで製品の詳細と機能に焦点を当てた記事が多く、”理念” や “背景” についてはあまり触れてきませんでした。しかし、Windows 8 に取り入れられている新しいイノベーションの大きさを考えれば、Windows 8 のデザインが生み出されるまでの背景に目を向けることにも価値があると思います。広く使われている製品に大掛かりな変更が加えられる場合の常として、Windows 8 もさまざまな物議をかもしています (各リンク先は英語)。Consumer Preview を日常の作業に使っている多数のユーザーが、それぞれの視点からさまざまな意見を表明しています。New York Times の David Pogue 氏 (英語) や Gizmodo の Mat Honan 氏 (英語) をはじめ、肯定的な立場からの意見も多く見られますが、そうでない意見もあります。特にこのブログのコメントでは否定的な声も目立ち、内容の濃い議論が交わされています。これこそ私たちが求めていたことです。製品に採用されることになったデザイン、今後の Windows の展開、新しいデザインが多様なユーザー層に適しているかどうかについて疑問を投げかける声もあります。Metro スタイル要素と従来のデスクトップをもっと切り離すことが重要 (英語) と考えているブロガーもいます。反対に、デスクトップはもっと Metro スタイル インターフェイスに近づけるべきだ (英語) と熱心に主張する人もいます。Consumer Preview を試用した人の数だけ、多種多様な意見があります。10 億人ものユーザーに使われている製品の新しいリリースを 10 億とおりもの形にデザインすることは、10 億人分のピザを注文するようなものです。その試みを公の場で行ったことで活発な議論が生まれたのは、私たちにとって喜ばしく価値のあることです。この記事は、ユーザー エクスペリエンス チームのプログラム管理ディレクターである Jensen Harris が執筆しました。 — Steven 2011 年 6 月に行われた…

35

信頼できる Metro スタイル アプリを提供する

Windows 8 と新しい Metro スタイル アプリのアプリ モデルを開発したとき、主なアーキテクチャ要件は信頼して使うことができるアプリをユーザーに提供することでした。信頼できるアプリには、リソースをうまく活用して動作する、他のアプリに干渉しない、同意のもとにシステム リソースを消費する、簡単にインストールおよびアンインストールできる、などの特徴があります。これらの属性を実現するには、開発者に堅牢なプラットフォームと強力なツール セットが必要です。これは、作り直しが必要な作業であり、既存のシステム上で改良することはできません。Windows 8 は、この点で作り直されたものです。この記事では、信頼できる Metro スタイル アプリを実現するために私たちがプラットフォーム レベルで行ったことの一部を詳しく説明します。この記事は、開発者エクスペリエンス チームのプログラム マネージャーである John Hazen が執筆しました。–Steven Windows 8 の Metro スタイル アプリ プラットフォーム開発における中心的な原則の 1 つは、ユーザーがアプリを信頼できることでした。これは、皆さんと私たち両方が担っている使命です。この記事では、アプリの信頼性に対する私たちのビジョンについて説明し、皆さんがアプリに計画的に信頼性を組み込むことができるようにします。 最初に、私たちが意味する信頼性とは何かについて説明します。ユーザーが Windows ストアで Metro スタイル アプリを調べているところを想像してみてください。ユーザーには、そのアプリがどんなアプリで、自分に適しているかどうかだけを考えてほしいと思います。また、実際に信頼できる、つまり、そのアプリが期待どおりに動作してシステムでうまく実行できる、許可したデータと情報だけ使う、他のアプリケーションと問題なく共存すると見なしてほしいと思います。 プラットフォームに関する私たちの目標は、信頼性のビジョンを実現するすばらしいアプリを確実に構築できるようにし、初期状態で信頼を得られるようにすることです。このために、システム全体にわたって投資を行いました。次のようなイメージです。 アプリの信頼性: Metro スタイル アプリ用の Windows 8 SDK、Windows アプリ認定キット、アプリの署名、 アプリ コンテナー、評価とレビュー、ストアへの登録、スムーズなインストール、製品利用統計情報のフィードバック この記事ではこれらの分野について扱い、最後の方ではアプリの機能について詳細に説明します。まずは簡単な概要です。 Windows ストア – ユーザーはまず Metro スタイル アプリのワンストップ ショップであるストアからアプリを探し始めます。ストアに登録するため、アプリの技術およびポリシー面での準拠状況…

4

バッテリ消費を抑えながらライブ タイルの更新を行う

私たちが使用するさまざまな “画面” に共通して普及の度合いを増しているのが、軽量な通知機能という概念です。当初は Windows ガジェットがこういった役割を担うことを目指していました。重要な情報 (たとえばニュース、天気、スポーツのスコア、基幹業務関連のイベントなど) をすばやく表示するためのヘッドアップ ディスプレイを提供するという趣旨です。しかしながら、ガジェットの起動時間や動作モデルは、全体的な電力消費量の削減 (デスクトップ PC でもノート PC でも重要な要素です) や、開発者のための全画面表示のプラットフォーム提供といった取り組みとは相容れないものです。また、Windows 8 の [Start] (スタート) 画面では、こういった通知に利用できる面積が大幅に広がると共に、ユーザー主導のインターフェイスを通してデータの更新 (ネットワーク リソースの使用を含めて) を管理できるようになっています。プッシュ配信や構造化されたスニペットを通して提供される情報の比率が増え続けている近代的なエクスペリエンスにおいては、このことが開発者にとってもエンド ユーザーにとってもユニークな機会をもたらします。今回の記事では、Metro スタイルのライブ タイルの開発と、このアーキテクチャが多数のタイルに対応しながら全体的な電力消費量とシステム負荷の軽減を実現するしくみについて、Ryan Haveson がご紹介します。–Steven Sinofsky パフォーマンスとバッテリの寿命が Windows の成功に欠かせない重要な要素だというのは、見解の一致するところでしょう。このブログにいただいているコメントでも、一貫してこれらの点が強調されています。KISSmakesmeSMILE さんのコメントはこの点をよく示したものです。 「…軽負荷/低負荷使用時のバッテリ寿命で、(競合製品と) 同等か、できることならより優れたパフォーマンスを実現してみてほしい」 同時に、すべての近代的な環境 (PC からテレビ、電話まで) において、なんらかの形でガジェット、ウィジェット、プラグインなどのモデルが採用され、ひとめで情報を確認できるようになっているのも事実です。テレビでニュース、スポーツ、天気などを見ていても、複数のソースからの情報がリアルタイムでまとめられ、構造化された画面に表示されています。ユーザーが期待するのは、株価、天気、未読メール数、次の予定、基幹業務アプリケーションの状態、ソーシャル ネットワークの状態などをすばやく確認し、数秒のうちに元の作業に戻ることができるというような動作です。多くの点で、PC はこの領域において他のデバイスに後れを取っていると言えるでしょう。通知インフラストラクチャの設計を始めるにあたっての私たちの課題は、アクティビティを生きた情報として表示しながら、電力消費と帯域幅の使用量においてきわめて高い効率を維持することでした。AndyCadley さんのコメントはこの目標をよく表現しています。 「”Metro” アプリを、常に起動している (ただしバッテリやパフォーマンスにはまったく影響がない) ものとして扱う」 [Start] (スタート) 画面では、ユーザー モデルの観点からもこの点の効率性が強化されており、デスクトップ アプリや Metro スタイル アプリの使用を邪魔することなく、全画面表示のヘッドアップ ディスプレイを提供することができます。これに加え、効率性を追求するだけではなく、通知機能を持つアプリをどれだけたくさんインストールしても、パフォーマンスやバッテリ寿命への影響を心配する必要がないようにしたいとも考えました。 Windows…


横向きと縦向きの両方に向けた最適化

私たちは多くのフォーラムで Windows 8 のデモを行ってきましたが、そのほとんどで、横長の表示 (ワイドスクリーン) を使用していました。プロジェクターを使うことが多く、その場合は横向きの方が見やすいというのが主な理由です。もう一つの理由は、多くの初期のデバイス (//build/ で Windows Developer Preview と共に発表された Samsung タブレットなど) がワイドスクリーンであるためです。新しいスナップ機能を使って、アプリケーションを横に並べて表示する用途にはワイドスクリーンでの横向きが最適です。すばやく滑らかに画面を回転できるようにし、縦向きを好むユーザーの方にもすばらしいエクスペリエンスを味わっていただくために、膨大な量の作業を行ってきました。これからご説明しますが、この背景には、どのような要因によって好みの向きが決まるかについて研究した結果が大きく影響しています。どちらの向きでも優れた動作をするアプリケーションを構築するためのツールを開発者に提供するために、Visual Studio ツールおよび Expression ツールにさえも取り組みました。Windows 8 の横向き画面および縦向き画面に関するこの投稿は、ユーザー エクスペリエンス チームの David Washington が執筆しました。彼は、//build/ で APP-207T セッション (英語) も担当しました。–Steven Windows 8 PC はまったく新しい種類のデバイスで、小型のタッチ操作のみのタブレットからノート PC やデスクトップ PC まで、多岐にわたります。Windows 8 の刷新にあたり、私たちはフォーム ファクターや画面の向きにかかわらず最高のエクスペリエンスを提供できる設計を目指しました。タブレット デバイスは人間工学的な柔軟性を備えているため、表示するコンテンツに合わせて、どちらでも持ちやすい向きに持つことができます。 タブレットの優れた点の一つは、手の中に収まるパーソナルなデバイスであることです。日曜日の新聞を読んだり結婚式の写真を見るときに、手の中に収めてタッチ操作ができると、タブレットに対して感情的なつながりを感じる人も多いと思います。デジタルの時代では、ユーザーにとって最も大切なものの多くがデバイスに保存されています。このため Windows 8 では、デバイスをどのような向きに持っても対応できるようなエクスペリエンスを提供したいと考えました。 Windows 8 でさまざまなフォーム ファクターにおけるエンド ツー エンドのエクスペリエンスを設計するにあたって、私たちは次のような原則を設定しました。 小さい画面、ワイドスクリーン、ノート PC、デスクトップ…

2

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

Windows 8 の [Start] (スタート) 画面のエクスペリエンスを扱った最近の 2 件の投稿については、大いに議論がありました。Developer Preview をご利用されている方の一人一人が、個々のユーザーの使用パターンや、Windows 7 と比べて使いやすくなった点、使いにくくなった点を私たちが理解する助けとなっています。ここで改めて申し添えておくと、Windows Developer Preview は、ユーザー インターフェイスの面で開発途上の機能が多々残っているのを承知のうえで、製品全体を “オン″ にした状態でリリースされたものです。これは議論を促進するための措置で、皆さんには製品が完成形でないことをご理解いただきたいと思います。”選べるようにしてほしい” や “オフにしたい” といった、反射的なフィードバックも少量ながら見られました。これは変化に対する自然な反応ではありますが、新しい製品を作り上げるための議論として最適とは言えなかったのではないかと思います。この投稿では、私たちが建設的なフィードバックにしっかりと耳を傾けながら、さらなる設計の進化に取り組んでいることをお伝えすることに注力したいと思います。具体的なコメントを取り上げ、皆さんのご意見に基づいて行われるアクションについてご説明したこの記事は、Core Experience (コア エクスペリエンス) チームのシニア プログラム管理者リードである Marina Dukhon が執筆しました。–Steven この 1 週間にいただいた、[Start] (スタート) 画面関連の記事への積極的な参加について、チームを代表して皆さんに感謝の気持ちをお伝えしたいと思います。コメントにはすべて目を通しており、可能な範囲で返信させていただいています。今回のような大きな変更が時として大きな論争を呼ぶことは理解しており、今後もこういった対話を続けていきたい考えです。設計に深くかかわる具体的なトピックがこれまでにいくつか挙がっているので、今回の投稿ではこれらに答えていきたいと思います。いただいたすべてのご質問に答えることはできないのですが、ご意見には確かに耳を傾けており、今後も対話を続けていきますので、その点についてはご安心ください。 データはすべてのユーザーをカバーしているのか? Andrew さんのコメント: 「収集されているデータの多くが、おそらく企業ユーザー以外のものであることを指摘したいです。ビジネス ユーザーを無視してホーム ユーザーだけに基づく統計を取っていることになります。ほとんどの企業では、セキュリティへの配慮や無駄なネットワーク トラフィックを防ぐ目的から、グループ ポリシーを使って既定で CEIP をオフにしています」 CEIP (カスタマー エクスペリエンス向上プログラム。ユーザーによる Windows の使用状況について、オプトイン方式で匿名のフィードバックを収集する) を無効にする企業があることは、ご指摘のとおりです。しかし、それでも膨大な量のデータがこのプログラムを通して収集されており、企業ユーザーについても例外ではありません。さらに、地域、言語、エディション、展開属性といった情報も同時に把握できるため、必要に応じてさらに精度の高いデータを得ることができます。ユニークなデータ ポイントの数が “サンプリング” のレベルをはるかに超えるため、私たちはしばしばこのデータを “国勢調査” にたとえます…

9

[Start] (スタート) 画面のデザイン

前回の投稿へのコメントとフィードバックをありがとうございました。このデザインに対する多くのフィードバックをいただき、みなさんの強い情熱がしっかりと伝わってきました。ブログ投稿を通して、引き続きこのデザインについてお話しすると共に、いただいたご質問やコメントに回答していきたいと思います。新しい [Start] (スタート) 画面は、アプリの起動と切り替え、通知、情報をひとめで把握できる表示画面などの役割を担う、新たな、速く滑らかに操作できるツールとしてデザインされました。これはなかなか難しいことです。そしてもちろんこれは、タッチ対応のデバイスを使用する新しいユーザーだけでなく、[スタート] メニューやマウスとキーボードでの操作に慣れ親しんだ、大多数のユーザーに向けた取り組みでもあります。この記事は、Core Experience Evolved (次世代コア エクスペリエンス) チームのグループ プログラム管理者である Alice Steinglass が執筆しました。–Steven 前回の「[スタート] メニューの進化」で触れたように、[スタート] メニューの実際の使用状況をさまざまな方法で研究した結果、[スタート] メニューは主に使用頻度の低いプログラムのランチャーとして使用されていることがわかりました。プラグラムの起動をタスク バーから行うことが増えてくると、使用頻度の低いプログラムを起動するツールとしては、[スタート] メニューに割かれているユーザー インターフェイスの量は随分多いように思えてきます。しかも、[スタート] メニューはこの用途に最適化されたツールとは言えません。カスタマイズ性は限られており、有益な情報はほとんど提供されず、検索結果を表示するスペースもかなり小さなものです。効率性を重視する “事情通” のユーザーは、[スタート] メニューを離れ、頻繁に使用するプログラムはワンクリックでアクセスできるよう、タスク バーにピン留めするようになってきていることがわかっています。こういった傾向はプロフェッショナル向けのワークステーションでよく見られ、必要なツールのセットがすべてタスク バーに収まり、どれも定期的に使用されているというケースが多くなっています。エンジニア、デザイナー、開発者、インフォメーション ワーカーといった層が使うマシンがこのようになってきているのです。 [スタート] メニューが PC の近代的な利用方法に対応しきれていないという証拠が積み重なっていく中、その代わりとなるようなより良いツール (タッチ入力向けかマウス/キーボード向けかを問わず) への関心が高まっていることがわかっています。一方で、わずらわしい通知領域アイコンの使用 (そしてそこに組み込まれるメニューやアクションの数) は増え続けており、同時に、いまだ十分にポテンシャルを発揮しているとは言えないデスクトップ ガジェットに対しても、引き続き関心が寄せられています。 こういった調査結果を踏まえ、Windows 8 では一歩下がって [スタート] の役割をゼロから再検討することにしました。デスクトップ プログラムの強力なランチャーとしては、既にタスク バーが存在します。[Start] (スタート) 画面で目指したのは、単なる [スタート] メニューの代替品ではなく、アプリ起動/切り替えの優れたツールであり、生きた情報を表示できる通知画面であり、カスタマイズ性が高く、強力かつ効率的なツールです。現在はばらばらに存在し、統合性に欠けるさまざまなソリューションを、1 つにまとめる場です。なお、既に触れたとおり、Windows 8 Developer Preview では Metro スタイル…

1

[スタート] メニューの進化

この記事を皮切りとして、今後、何回かにわたって [Start] (スタート) 画面のデザインと、プログラムの起動と切り替えという重要な操作がどのように進化してきたのかについてお話ししていきたいと思います。[Start] (スタート) 画面を Windows 8 の “Metro シェル” と呼ぶ人もいますが、私たちにとってはあくまでも [スタート] メニューとそれに関連した機能が進化したものです。私たちは皆さんから寄せられるコメントに注目してきましたが、このような主要インターフェイスの変更に対して、当然予想したとおりのさまざまな反応が見受けられました。今後の一連の投稿で、皆さんからいただいたコメントにお返事していきたいと思います。まずは現在のデザインにたどりつくまでのいきさつと決定した内容の説明から始めましょう。先日リリースされた Developer Preview はあくまでアプリの構築を主眼としたものであり、ユーザー エクスペリエンスのコア部分はまだ開発段階なので、ここでの議論は、基本的な原則の部分から始めて具体的な設計の詳細をたどり、プロジェクトの次のマイルストーンで目指すものの背景を理解するうえで役立つようなものにしたいと考えています。 この記事は、Core Experience Evolved (次世代コア エクスペリエンス) チームのプログラム管理者リードである Chaitanya Sareen が執筆しました。Chaitanya は Windows 7 でもエクスペリエンス設計に携わっており、マイクロソフトの Engineering Windows 7 ブログで記事を執筆していたので、覚えている方もいらっしゃるかもしれません。 –Steven この投稿から始まる一連のブログ記事では、刷新された [Start] (スタート) の詳細やその背景についてお話ししていきたいと思います。最初の記事では、[スタート] メニューの歴史と進化、そして私たちがユーザーの皆さんから学んだ問題や傾向についてお話しします。私たちがこれからどこへ向かうのかを話し合う前に、まず、どこから来たのかを理解しておくことが重要だと思うからです。この次の記事では新しい [Start] (スタート) 画面の設計の詳細についてご紹介し、そこから次の議論の方向性を検討したいと思います。  人によっては、Windows の変更はどのようなものであっても混乱を生じさせるものなので、そういった変更についてのオープンな対話の場を引き続き確保していきたいと思います。Windows は人々の生活に非常に深く浸透しているため、どのような変化に対しても、「どうやってオフにできるのか」などの咄嗟の反応があったり、効率性が上がったか下がったかという議論が起こりがちです。 タッチ操作についての論争は、マウスとは何かのトリックなのか、時間を浪費するだけの道具なのか、ユーザー エクスペリエンスにおけるイノベーションなのかなど、1980 年代に起こったマウスについての論争と不気味なほどよく似ています。これは、タッチに対するマウスの優位性を主張するコメントが数多く寄せられていることを踏まえ、触れておきたい点でした。マウスが導入されたころの状況と異なり (デスクトップ パブリッシング ソフトウェアの登場まで、マウスの使い道は初期のペイント ソフトを除き、かなり限られたものでした)、私たちの周囲にはタッチ スクリーンが氾濫しています。空港、ガソリン…

6

Metro スタイルのブラウシング: 1 つのエンジン、2 つのエクスペリエンス、妥協は 0

昨日は、Windows 8 に伴う非常に大きなチャンスについてご紹介しましたが、開発者の皆さんからとても暖かい歓迎を受け、たいへん嬉しく思っています。今後この B8 ブログでは、Developer Preview とそれに含まれる機能、そして今後の進化に焦点を移していきたいと思います。ブログでの対話に参加される皆さんが、このビルドをインストールし、使用されることを願っています。これは初期段階のビルドで、開発者向けのものですが、かなり楽しく使えもします。私自身、カンファレンスからの投稿にはすべてあの Samsung 製プレビュー用タブレットを使っています! Metro スタイルのブラウジングと、正真正銘のクロームなしのブラウジング エクスペリエンスを実現するために私たちがやってきたことについて、少しお話したいと考えました。最高のパフォーマンスと信頼性、および高い評価を受けている IE のセキュリティ機能と合わせて、HTML5 と標準のサポートに私たちはかなり力を入れています。同じ HTML5 テクノロジを使用するデスクトップ エクスペリエンスについても、引き続き改良を図り、提供していきます。これが、私たちが IE10 で妥協のないブラウジング エクスペリエンスを実現するやり方です。この投稿では、Windows 8 開発者向けプレビュー リリースに付属の IE10 Platform Preview 3 について説明します。この投稿は Dean が執筆しました。–Steven ブラウザー エクスペリエンスの進化には、単なるタッチ デバイスへの移植にとどまらない要素が数多く関連します。Windows 8 を実行するフォーム ファクターの種類を問わず、最高のブラウジングを実現するために、IE のエクスペリエンスと基盤となっているアーキテクチャを刷新しました。 Windows 8 では、まず、1 つのエンジンで 2 種類のエクスペリエンスを提供する、高性能な HTML5 ブラウジング エンジンの開発に取り組みました。このエンジン 1 つで、Web 標準の強力なサポート、ハードウェア アクセラレータによるパフォーマンスの向上、セキュリティ、プライバシーなどを実現します。次に、このエンジンを基に、2 種類のエクスペリエンスを開発しました。新しい Metro スタイルのエクスペリエンスと、より従来のものに近い、タブと最小限の “クローム”…

1

ここまでの対話を振り返って (パート 2)

前回の投稿の冒頭でも述べたとおり、今回は、以前 Engineering Windows 7 ブログでも行ったように、このブログでのこれまでの対話を振り返り、いくつかのご意見やご質問をさらに深く掘り下げてみたいと思います。前回の投稿に続いてフィードバックの重要性に触れた後、リボン、Metro スタイル、および Media Center の提供について取り上げます。 リボン ファイル コピー関連機能の再設計についての投稿では、集まっている関心の強さを実感しました。ですから、Windows エクスプローラーについて投稿したときは、よくも悪くもたいへんな “反響” があることは覚悟のうえでした。物議をかもすブログ トピックでは、たいてい似たようなパターンが見られるものです。ここでは Slashdot からの照会数 (他の投稿をはるかに超える数です) やブログ サーバーのパフォーマンス (効率向上のためサイト レイアウトの調整を行いました) ではなく、採用された設計に注目して話していきましょう。 何よりも重要なのは、これが製品の一要素にすぎないということです。ファイル名の競合ダイアログのときと同様、一つのことに光を当てすぎると、(見る側にも見せる側にも) 見落としが出てきたり、必要以上に大きく扱ってしまう傾向があります。前回の映画の例で言うなら、映画の宣伝のために選んだシーンが、思いがけずその映画に関する議論に (あるいはターゲット市場そのものに) 変化を及ぼしてしまうようなものです。好材料は、他にもお伝えしたい内容がたくさんあることです。 最初の投稿の内容は繰り返しませんが、ここで付け加えたいのは、私たちが、皆さんからご批判があると思われる点の多くを考慮しているということです。今回、リボン メカニズムを採用していますが、この選択が間違っているとお感じの方には、私たちの考えは違うとしか申し上げられません。あらかじめ予想し、実際に証明されたことですが、このブログをご覧の皆さんの中に、リボンへのご批判が根強いことは承知しています。このご批判については、Windows 7 のブログの一部トピックに関する反響と同じく、多数のご意見をいただくと予想しており、実際に多くのご意見をいただきました。 多様な対象ユーザーに向けたメカニズムの役割がどうあるべきか (初心者向けなのか上級者向けなのか?) については、さまざまな試行錯誤がありました。皮肉なことに、メニューはかつて初心者向けの機能であり (上級者が使うのはキーボードでした)、のちにそれをさらに簡単にしたのがツール バーでした。コンテキスト メニューは当初、上級者向けのショートカットでしたが、結果的にだれもが使う機能になりました。今では、メニューもツール バーも、上級者向けの機能と認識されています。もちろん私たちは、こうした異なるメカニズムを統合して、よりシンプルな操作性を実現することを目指してきました。メカニズムの数が少なければ、当然 UI の表示領域も少なくできるからです。さまざまなご意見がある中で、明らかなのは、リボン機能搭載の弊社製品のお客様満足度は高まっており、この機能の使用率は広く浸透しつつあるということです。ご満足いただけないお客様がわずかにいらっしゃることも承知しております。それは、理由こそ異なれ、リボン メカニズムを採用する以前の各バージョンでも同じでした。どうしたところで、すべてのユーザーにご満足いただくことはできないのかもしれません。 個人的に最も興味深かったフィードバックは、視覚的なオーバーヘッドに関するものです。”Metro” 機能が登場して、より軽量のグラフィカル操作が可能になったうえ、表示するコマンドの数を簡素化してユーザーが求める “ミニマリズム” に応えています。簡素化はだれもが求めています。表示される機能が少なければ、必要な領域も少なくでき、コードの記述、テスト、管理の工数も減らせます。ミニマリズムは、機能を隠すことでもなければ、便利な機能にアクセスしにくくすることでもありません。ミニマリズムとは、余分なものをそぎ落として本質的な機能だけを残すことです。そのためには、本当に必要な機能の見極めが重要になります。私たちが考えるミニマリズムは、コマンドの多層化や、見つけにくい場所への機能のグループ化をやめ (これらのメカニズム自体が概念的になり、コードのオーバーヘッドを生みます。UI が表示する内容だけでなく、UI 自体も肥大化の原因となるのです)、同時に UI に使用するメカニズムの数を減らすことでもあります。このアプローチに従い、私たちは製品の機能を 1 種類の方法で示すことを目指しています。また、ミニマリズムとは盛り込む機能の削減ではないという点も心得ています。エクスプローラーへの機能追加に関するフィードバックの量からも、それは明らかです。 従来の機能表示は段階的、階層的なものでした。キーボード限定の機能やコンテキスト メニューにしかない機能があり、またある機能はトップ…

4