Aero スナップの設計

Aero スナップの設計

ここでは Windows 7 の Aero Snap 機能の設計について側面から検討してみます。私たちは、機能の全体的な設計プロセス、および使用したツールと手法に注目することも興味深いと考えました。この機能では、ユーザーインターフェイスなしでこの機能を使用すること、特にこの機能を呼び出すことに関する固有の設計課題が提示されました。すべての機能と同様に、これは、エンジニアリング分野全体に渡るコラボレーションです。この投稿では、 Stephan Hoefnagels (UX シニアデザイナー ) は、設計の分析観点について説明します。 --Steven ( 追記 : 今週開催した MIX カンファレンスにご注目ください !)

「Windows を管理するウィンドウ」および「フォローアップ：Windows ウィンドウの管理」では、Windows 7で対応する可能性があるいくつかの興味深いウィンドウ管理のシナリオについて話をし、知識を共有しました。さらに、一般的な構成に関するデータと、この分野での考えの指針についても言及しました。

この投稿では、多数のユーザーが既に PDC ビルドで、そしてベータ版で経験できた Aero Snap 機能についてもさらに詳しく検討します。機能そのものについて簡単に説明しますが、主に設計プロセスの側面についても考察し、反復法、課題、および考慮事項を共有してもらいたいと考えています。

目標とシナリオ

前回の投稿で掘り下げて説明したように、Aero Snap 機能の最大の目標は、ユーザーが望むようにウィンドウを配置する使いやすい方法を提供することです。一般的な動作を実行するために必要なクリック数と正確な操作数を軽減しようとしています。一般的な意味では、ユーザーが自信を持ってウィンドウを管理し、かつ効率的に制御できるようにしようと考えています。これは、Windows 7 のタスクバーに関する投稿について、また、実際には、新しいデスクトップ エクスペリエンスに組み込まれているテーマについても説明するものです。

この設計の目標への対処方法を検討する前に、手短に説明しておきます。以下のシナリオでは、対話型の手順の詳細について理解できます。たとえば、ウィンドウを選択し、キャプション ボタンをクリックし、ウィンドウのサイズを変更するなどの手順です。対話型の手順をこのレベルで詳細に検討することには、多少の困難があります。これらの手順は、個々には非常に些細で頻繁に発生するため、通常はほとんど意識しません。これらの詳細を単に無視することができないでしょうか。このようなイベントを明確することにより、オーバーヘッドを認識することを余儀なくされ、当面のタスクに着手する必要が生じることがあります。通常、実現できないことを実現することを余儀なくされます。さらに、問題に対する洞察を提供すると共に、解決策を検討するための適切な詳細を提供します。

それでは、設計について検討して行きます。

左右に並べて表示したウィンドウ

多くのご指摘のように、1 つのウィンドウから別のウィンドウへのドラッグ アンド ドロップ操作を行うことは、面倒な場合があります。ウィンドウは重ねて表示される傾向にあり、適切な場所に配置しようとすると、多くのマウス操作が必要になります。多くの場合、手順は次のようになります。1 つのウィンドウを選択し、適切にサイズ変更し、画面上に配置して、ドラッグ アンド ドロップの対象としてウィンドウがよく見えるようにします。さらに、別のウィンドウにも同じ動作を繰り返します。単に 2 つのウィンドウを比較するために、多くのマウス クリック、サイズ変更動作、慎重な配置、ウィンドウの切り替え、かなりのマウス移動距離が必要です。

Aero Snap を使用すると、ウィンドウをつかんで、マウスを画面の端まで動かすと、ウィンドウが画面の半分にサイズ変更されます。これを別のウィンドウで繰り返します。2 つの簡単な動作で、これら両方のシナリオをより簡単に実行できるセットアップが可能になりました!
 

Aero Snap を使用してカーソルを画面の端まで ( 左か右、上から下 ) 動かすことによって、ウィンドウを左右に並べて配置できます。

垂直に最大化されたウィンドウ

最大化したウィンドウの状態をユーザーが好むことを理解しています。多くのユーザーが、すべてのウィンドウを最大化して、その他の状態で実行することがないような状態を好んでいます。しかし、解像度を高くした画面やワイドスクリーン レイアウトがさらに普及すると、最大化したウィンドウの状態は、特定の場合には、その魅力を失うことがあります。電子メールがその例です。画面の水平方向に長いテキストを読むのは、読みやすいとは言えません。画面いっぱいに行を目で追うのは大変です。別の例としては、Web の参照があります。横に使用していない空白のスペースが残ったままになっていると、コンテンツが画面の幅全体に埋まらないことがあります。

そこで、Aero Snap では、垂直方向だけを最大化できます。画面の最上部までウィンドウをサイズ変更すると、画面の下端にもサイズ変更されます。長いブログ投稿を読むのに最適です。

ウィンドウを画面の端までサイズ変更すると、 Aero Snap で垂直に最大化されます。

最大化ウィンドウの画面から画面への移動

一部のユーザー、特のこのブログの読者がマルチモニターを使用していることを知っています。最大化ウィンドウをもう 1 つの画面に移動するより簡単な方法をご存知ですか。キャプション復元ボタンをクリックし、マウスをタイトル バーに移動し、ウィンドウを別の画面にドラッグして、最大化キャプション ボタンを再度クリックする手順よりもすばやい方法があります。Aero Snap を使用すると、ウィンドウ最大化ボタンをドラッグしたまま、ウィンドウを別の画面に移動して、画面上端で離すという、オールインワンのジェスチャですみます。ついに簡単な操作ができるようになりました。

ノート PC でのウィンドウの整列

前のセクションで説明したように、デスクトップ PC でウィンドウを整列させようとすると、余分なささいな動作や、細かいマウス操作、かなりのマウス移動距離が発生します。ノート PC では、マウスを使用しないことにより、これらの動作のいくつかはより手間がかかるため、この状況はさらに悪化します。これらのシナリオのために、またパワー ユーザーのために、便利なキーの組み合わせを導入しました。Windows キーを押しながら、いずれかの方向キーを押して試してみてください。特にマルチモニター設定の場合には、Shift を押したままでの操作も可能です。

設計プロセス

それでは、ここでいくつかのシナリオを紹介し、それに対する対処法を紹介します。十分にわかりやすいと思います。特に、ベータ版のビルドで Aero Snap を使用しているユーザーにとっては簡単です。すべてが期待どおりに動作します。しかし、どのようにして、ここまでできたのでしょうか。そこで、次は、普段は行わないようなことを試みてみます。実際に、デザイン プロセスの側面と私たちがこれまでに直面した潜在的な問題について説明します。これは、簡単な概要で、包括的なものではないことにご注意ください。たとえば、ユーザビリティ テストを示唆していますが、この投稿では、これらの取り組みの範囲に対する洞察を与えることを意味していません。それらのトピックのうちのいくつかは、将来、説明する機会があると思います。

それでは見ていきましょう。

スケッチ

2007 年初頭の頃に、潜在的な関心分野としてウィンドウ管理を確立して、複数の魅力的なシナリオを特定した後に (この段階のプロセスの詳細については、以前の投稿を参照)、アイデアを出し合うためにブレーンストーミングを開始しました。「もっと効率的にウィンドウを整列できないのか」、「もっと直接的にするにはどうするのか」、「より楽しくするには」というような問題点をぶつけ合いました。これは、設計、ユーザー研究、プログラム管理、開発などが含まれる、分野横断的なプロセスでした。概して、当時、このスペースについて考えようと、10 人に満たない人数が集まりました。

私たちは自分自身に重要な制約を課しました。それは、UI に追加のウィジェットを導入せずに、目標を達成しようと考えました。たとえば、ウィンドウのタイトル バー上の追加キャプション ボタンを想像してください。これは 1 つのウィンドウでは悪くないように思えますが、10 以上のウィンドウを問題にした場合、画面上にかなりの混乱が生じました。そして、それは私たちの気に入らないものだったのです。結局、PDC での UX Principles の話のように、「発見能力ではなく、問題を解決すること」の価値を認めています。

内部 Web サイト経由で共有した、非常に迅速なスケッチで多くのアイデアを入手しました。オフィスや通路のホワイトボードから転送されて、それぞれのスケッチには 5 分もかかりませんでした。以下のスケッチは、いくつかの Aero Snap のアイデアを形成できる実例の一部です。

初期のアイデアは簡単で使い捨てできるスケッチになります。

初期のコードにおける対話型プロトタイピング

紙ベースでの多くのアイデアで、最良のアイデアを熱心に試みました。そして、プロトタイプを作成する段階に入りました。このプロセスの非常に初期の段階にいることに留意してください。プロトタイプを対話型にしたいと考え、また、通常の業務内でプロトタイプの作業を行えると考えました。したがって、日常作業用のコンピューター上で実行できる初期のコードを使用して、そのアイデアを実装することに決めました。たとえば、下記のイメージは、Windows Vista で実行される「スマートなリサイザー」のプロトタイプを示します。もちろん、これらのプロトタイプは、実際に出荷できる機能まで開発されていません。ここでは、単に基本的な概念が機能しているだけで、間違いなくいくつかの問題 (バグJ) があります。しかし、重要なことは、ユーザビリティ調査のフィードバックを得ると同時に、相互作用を自分自身で経験することが可能である点です。

Windows Vista 上で実行される初期の「スマートなリサイザー」プロトタイプ。プロトタイプで作成されたタスクバーボタン ( およびプロセスのどの段階にいるのかがわかる予定表の日付 ) に注目してください。

この直接のエクスペリエンスと初期のユーザビリティ フィードバックを使用して、最終設計におけるアイデアの見直しを繰り返します。非常に偏見のない方法でこの段階のプロセスに取り組んでおり、私たち自身でも驚くことがあります。紙面上ではそんなに良く見えないアイデアが、驚くほどに効果的であることが証明されることもあります。他方では、別のアイデアが紙面上では良く見えても、実際上ではうまく行かないことも発見しました。いずれか 1 つのアイデアに集中していませんし、まだ実装していないため、アイデアを自由に設定し直したり、中断したりできます。

最後に、プロトタイプは設計の詳細を考えやすくしてくれます。また、いくつかの洞察に遭遇する場合もあります (もちろん、実在の功績は、洞察を認識して、それを維持することであると自分自身に言い聞かせています)。以下は、チーム メンバーの 1 人からの、「スマートなリサイザー」プロトタイプの新バージョンに関する当時の電子メールの例です。

何かが変化したことに気づきました。元のバージョンでは、最大にサイズ変更をした場合、ウィンドウが「超大型化」されました。次に、ウィンドウを小さいサイズ変更すると、通常の元のサイズの状態に戻りました。超大型の状態が元のサイズの状態と異なるかのようでした。このバージョンでは、ウィンドウを超大型化し、次に後でサイズを再び変更する場合、以前の元のサイズに戻りません。元のサイズの状態と異なる超大型の状態に関しては、だいたい良かったと言えました。この点に関してさらに考慮して、それを設計の一部に入れることを検討する必要があります。

多くのプロトタイプの後、左右に並べて配置するウィンドウと垂直に最大化されるウィンドウの概念に決めました。何を構築するのかについて、より明確になりました。

詳細設計 : 状態移行

ここで、良いスペックだがフルスペックではなく、相互作用と動作を設定するというアイデアを決定しました。詳細な質問をすることにより、未設定の箇所を決める段階が始まります。「以前はウィンドウを最小化、元のサイズ、最大化するだけだった状況で、左右に並べて配置するウィンドウは、どのような意味を持つのか」「この新しいウィンドウの状態をどれくらい正確に理解して利用できるのか」上記の部分的な電子メールの中で、これらの質問のいくつかについて既に指摘されています。

現在、一般的なウィンドウの状態は、 ( 左から右へ ) 最小化、元のサイズ、および最大化となっています。左右に並べて配置するウィンドウと垂直に最大化されるウィンドウをどのように組み込んだら良いでしょうか?

状態の問題を詳細に考えてみましょう。以下は、この段階で作成された 2 つの提案の例です。すべての異なる状態の間で、あるウィンドウの状態から別の状態にどのように移動できるか示しています。どちらのモデルの方が良いですか。

2 つの提案では、状態間を遷移できるさまざまな方法の詳細を説明しています。

その質問の回答を見つけるために、「どの状態を直接リンクしたいのか、また、状態間をどのように遷移するのか?」、「垂直に最大化した状態から直接最大化の状態に遷移することは必要なのか?」、「垂直に最大化する状態と左右に並べて配置する状態は、それらが類似して見えるように、同じように動作するべきなのか?」などの、より明確な質問を検討しました。回答は、もちろん、現在使い慣れたモデルになりました。モデル B です。

しかし、この回答によって、この問題が終了したわけではありません。さらに多くの詳細について作業を進める必要がありますし、さらに多くの質問が出てきます。「垂直に最大化したウィンドウを側面に移動したい場合はどうしますか?」、「その幅をサイズ変更しますか?」、「次に、そのウィンドウを下に移動させますか?」などの質問です。

すぐに、複雑な一連のイベント、可能性のある多くの操作、さらに可能性のある多くの結果があることに気がつきます。システム全体を実際に使用する際に最も期待されるのは、何でしょうか?

意思決定プロセスに役立てるために、いくつかの基準ステートメントを作成しました。仮定が正しいと仮定します。例は次のとおりです。「マウス動作によってトリガーされた効果を元に戻す直感的な方法は、反対のマウス動作を行うことです」および、「ウィンドウを合理的なサイズに戻すための余分な作業を回避するために、前の「元のサイズ」の状態に戻すことが、常に楽な方法です」または、「ユーザーが特定の状態のウィンドウに幅を指定した場合、それが意味をなす場合、そのサイズが状態の変更を越えて保持する必要があります」

これらのステートメントを使用して、予測可能な方法で上記のような質問に回答し、その結果、予測可能なエクスペリエンスを作成することができました。また、根本的な状態の遷移と規則がかなり複雑であると、一度に追加された場合、結果として動作が直観的に理解されます。それは、明らかに私たちが目的としていることです。

競合する規則

以下は、実際に注意深い読者向けの一連の問題の例です。多数の新しい状態遷移によって作業する場合、発生したことを判定する規則が競合する場合があります。次のシナリオを検討します。新しいウィンドウ モデルの 2 つの規則は次のとおりです。

1. 画面の上端にウィンドウをドラッグすると最大化します。

2. マウス動作によってトリガーされた効果を元に戻す / キャンセルする直感的な方法は、反対のマウス動作を行うことです。

それでは、Windows 7 のビルドで次のシナリオを実行してみましょう。元のサイズに戻したウィンドウで開始します。画面の上端にサイズ変更することにより、垂直に最大化します。マウスを解放します。1 つの動作で、ウィンドウを下へドラッグし (サイズ変更しない)、再び上にドラッグします。マウスを解放します。何が起こりましたか。

ウィンドウが最大化されているはずです。つまり、この場合は、規則 1 に従うことを選んでいます。さらに、ルール 2 に従うことがあります。その場合には、ウィンドウは垂直に最大化されます。このシナリオでは、ルール 1 がユーザーの精神モデルをより正確に反映するだろうと考えました。

これは、ウィンドウの状態間の各遷移に対して決定する必要があった意思決定の 1 つの例です。

このプロセスの全体で、現在のモデルで微妙な点を保持することにしました。一部のユーザーは精通している可能性がある、微調整した小さな 1 例は、画面からウィンドウ タイトル バーをドラッグして離すシナリオです。以前の Windows リリースでは、垂直のスペースを可能限り最適化する一方で、ウィンドウを動かせる十分なスペースを提供するために、ウィンドウを後ろに中程まで動かしました。元に戻して、少し慎重で単純にすることを選択することにより、タイトル バー全体が表示されます。これにより、すべてのウィンドウが、常に、非常に簡単につかむことができ、さらにタッチを使用して、動かせるという事実を信頼できるようになります。タイトル バーの半分で十分であると実際に考えた場合、タイトル バーを常に半分にすればいいでしょう。垂直に最大化したウィンドウの状態では、タイトル バー全体を表示することを選択するため、包括的に連続した情報となります。

ストーリーボードおよびその他の視覚エフェクト

状態グラフは、世界を調べるただ 1 つの方法です。わかりやすさ、可用性、および目的に基づいたメディアを選ぶことにより、機能の異なる側面を通知するためにさまざまな方法を使用しました。以下に説明するように、ASCII アートを使用することを避けませんでした。問題点を明らかにするどのようなツールでも使用します。とりわけ、相互作用ストーリーボードは、ユーザー フローを理解するために、非常に価値のある手法でした。また、これが小さな例であったとしても、相当数を実施したことがわかります。

機能詳細は、適切な手段を使用して、全体に通知されます。

意図しないトリガー

状態の遷移を正しく理解することに加えて、最大の議論の 1 つは、状態の遷移が正確にいつ発生するのかについてでした。すなわち、この機能がいつトリガーされるかということです。「意図しないトリガー」、つまり、そうなるように意図的に設定されることなく、機能が実行されることについて多くを議論しました。

Aero Snap は、マウスで画面の端をタッチすることによりトリガーされます。

そもそもの最初から、その機能が、ウィンドウを画面の外側面に押し込むなど、現在のシナリオの障害にならないことを常に確認してきました。結局、現在の、期待されるウィンドウ管理方法に不利益な影響を与えないことを考えてきました。そのため、遷移をトリガーするには、ウィンドウ端ではなく、画面の端をマウスで文字通りタッチする必要があります。

しかし、現段階では、現在ご存知のような機能は、1 つの非常に重要で基本的な方法において異なっていました。初期のビルドでは、Aero Snap は「即時コミット」モデルに従いました。画面の上部にマウスを移動させると、まだドラッグしている間に、ウィンドウは文字通り最大化されます。つまり、マウスを解放する前でも、最大化されます。1 つの動作を戻すと、文字通りウィンドウが元のサイズに戻ります。「プレビュー」が非常に正確だったので、このアプローチを気に入っていました。つまり、そのプレビューはウィンドウだったのであり、コミット モデルがない場合に、特定の率直性があります。

UI が設計によって表示されないので、多少の意図しないトリガーを予期していました。実際、ある意味で、機能の検出能力の役に立つ意図しないトリガーに依存していました。しかし、ビルドをしばらくの使用した後、意図しないトリガーが予想よりも多く発生したため、少し心配になりました。遠隔測定データから、ユーザーがこの機能を実行して、この機能をコミットするよりもキャンセルすることがほぼ 2 倍になっていることがわかりました。ユーザビリティ調査では、何がこの動作をまさにトリガーしたのかについて、混乱していることが観察されました。この原因は、ウィンドウの端にタッチしたことだったのでしょうか。ジェスチャなのでしょうか。あるいは、他の何かだったのでしょうか。

現在、2008 年の年初です。何を実行する必要があるでしょうか。機能全体を削除するべきでしょうか。実際にオプションとしてこれを検討しました。重ねて言いますが、現在のウィンドウ管理動作を尊重しており、また、エクスペリエンスを低下させることは、最後の手段です。より構造的に、これらの問題点に対処する設計の微調整を行うために、この課題を引き受けました。複数のソリューションを調査しました。サイズ変更の遷移をスムーズにすることにある程度集中したため、意図しないトリガーは少なくともスムーズになります。従来のアプローチは、確かに機能しますが、おそらく、現実的な解決策には十分ではないでしょう。他方で、画面端への動作の角度、または動作速度に基づいて、ユーザー意図をより正確に検出することを試みました。それがあまりにも複雑であると分かったので、予測できませんでした。端をダブルバンプする場合にのみ線をトリガーするようにする必要があるかもしれません。これが、流動性と現在のモデル フローのエクスペリエンスを低下させるだろうと心配しました。

結局、使い慣れた実装に決定しました。ウィンドウに何か起こる前に、簡単に影響を取り消せるように、マウスを解放するまでトリガーしません。さらに、発生した内容を理解するのに役立つ、スムーズなプレビュー アニメーションとカーソル効果を提供します。この方法により、今後より慎重に進めることができ、この機能の利点を十分使用できます。

これで問題が解決されたでしょうか。お気軽にご連絡ください:-)

概観

振り返ってみると、この時点までは、基本的に表示される UI なしの機能を設計したことは、興味深いことです。ここで急に、ウィンドウ プレビューとカーソル効果が提供されます。これらはどのような見栄えにする必要があるでしょうか。また、どのような動作が必要でしょうか。

さて、幸いにも、継続する必要があるいくつかの点があります。この時点で、タスク バーの外観 (これを「個性」と呼び、今後の投稿で詳しく説明します) の明確なイメージを既に確立しています。Aero プレビューのグラス シートを使用することに決定しました。プレビュー ウィンドウに同じ視覚的な表現を使用する機会を得ました。しかし、グラス シートはどのように表示されなければならないでしょうか。実験の後、カーソルから作成するスケール アニメーションに決定しました。これは、このプレビュー ウィンドウが何に由来するかについての巧妙なヒントになります。さらに、遷移をアニメーション化することにしました。たとえば、現在のビルドで以下を試みます。マウスを解放せずに 1 つの動作で、ウィンドウを上に移動し、次に側面に移動します。プレビューのスムーズな形態に注目してください。この件に時間を費やしたのはなぜでしょうか。もちろん、良きにつけ悪きにつけ、小さな事柄が問題だ “Small Things Matter, Good and Bad” ということを信じています。

スナップトリガーで軽い影響が出ていました。スナッププレビューにグラスシートが使用されます。

最終的に、トリガー表示のための「光」に関するアイデアをいくつか結び付けました。これをチューニングして目立つが大きすぎないようにしました。また、タッチ フィードバックなどのシステム内の他の光効果と同期させるようにしました。

この投稿では設計プロセスを含む Aero Snap 機能の実態についてお話しました。皆様のご意見をお待ちしています。

Stephan Hoefnagels

Comments

• Anonymous
  May 12, 2009
  Aero スナップは大変素晴らしい改良だと思います。 ですが、RC 版を試用して大変残念に感じた点が１つだけあります。 それは、Aero スナップが複数モニタ環境で、私が期待したのとは少し異なる振る舞いを見せることです。 私は 24 インチのモニタを２つ持っていて、それを横方向に並べて試用しています。（左側のモニタがモニタ #1, 右側のモニタがモニタ #2 です） 私は何度か、ブラウザ（とは限りませんが、例として）をモニタ #1 の表示領域の右端にスナップさせようと試みましたが、どうにも期待するような結果が得られません。 同様に、モニタ #2 の表示領域の左端にもスナップしてくれません。 どうやら、Aero スナップはモニタの表示領域の端ではなく、論理的なデスクトップの端にウィンドウをスナップさせるようです。 ですが、これは私には自然な振る舞いには思えません。 RTM では各モニタの表示域の端にウィンドウがスナップされることを期待しています。 どうかまだ間に合いますように…