Windows 8 でのファイル名の競合のエクスペリエンスのデザイン

基本的なファイル管理を改良する取り組みについてコメントをお寄せいただきありがとうございます。私たちが進めている改良に対する大きな反響、そしてこのトピックに関するあふれる熱気に圧倒されるばかりです。この熱意こそが、Windows 8 の作業にさらにやりがいを与えてく れています。これまでにお話した内容についてたくさんのコメントやご意見をいただいていますが、中でも特に多方面に (文字どおり問題のあらゆる面について) 意見が交わされているのが、ファイル名の競合のダイアログについてです (1 つのダイアログについてです)。私たちは、開発サ イクルからデザインの資料を掘り起こし、検討事項の一部や検討の過程をお見せすることが有用だと考えています。もちろんこの先も、工程を戻って行う可能性のある変更について説明する機会があるでしょうが、デザインの過程にあえて目を向けることは有用だと考えました。この投稿は、こ れらの機能にかかわった数名の担当者、Ben Truelove (デザイナー)、Matt Duignan (UX 研究者)、Jon Class、および Ilana Smith (プログラム管理者) が編集したものです (全員が Windows 8 の他の部分にも携わっています)。 --Steven

Windows 8 の新しいコピーのエクスペリエンスに関する以前の投稿では、ファイル名の競合を解決する新しい [フ ァイルの選択] ダイアログについて多くの質問やコメントが寄せられました。この関心の高さを鑑みて、このデザインを選ぶまでに検討されたデザインとユーザビリティ テストの一部を共有するのも興味深いかと思います。

実装されたデザインでは、ファイル名の競合 (つまり "重複") に対処するときに 2 つのレベルの制御が用意されています。

  • 1 次エクスペリエンスは簡略化されており、"すべて置換する" または "すべてスキップする" のオプションが用意されたことで、クリック 1 回ですべての競合を一括管理できます。これを "シンプルな競合解決ダイアログ" と呼びます。
  • より詳細な情報ときめ細かい制御を提供する、2 次エクスペリエンスを表示するオプションも用意されています。これを "詳細な競合解決ダイアログ" と呼びます。

図 1 - 最終的なダイアログ

Windows 7 とそれ以前

ファイル名の競合の解決は、非常に類似性の高い 2 つの対象から重要な選択をする必要があるため、本質的に慎重を要する作業です。

Windows 3.1 ではこれをどのように行っていたかをお見せしましょう。

図 2 - Windows 3.1 での競合

Windows 7 でこのようになるまでに、相当の進歩があったことは確かです。

図 3 - Windows 7 の競合解決ダイアログ

Windows 7 では、選択の助けになる多くの情報と、より多くの操作のオプションが提供されています。Windows 8 では、より効率的に適切な判断を下し、より短時間でファイルの転送タスクを完了しやすくなるように、さらに機能を改良できると考えました。前述したように、フィ ードバックとサポートを通じて、既存のダイアログをわかりやすくすることが要求されています。つまり、かなり複雑なダイアログであるため、情報に基づいた選択を行うのに必要な情報を見つけにくくなっていたのです。どれだけの作業時間を費やしても、最適でない点が明らかになるまでに時間 がかかることがあります。数百万人のユーザーがプレリリース版の Windows 7 を使用しましたが、フォーラムではこの機能について大きな話題にならなかったことを思い出してください (話題に上らなかったわけではありませんが、多くのユーザーから指摘されることはありませんでした)。

Windows 7 のエクスペリエンスの改良

まず、基本的に同じエクスペリエンスを維持しながら、判断に必要となる重要な情報を最適化することによって段階的に改良するための方法を検討しました。

図 4 - 単一ファイルの競合の解決に関する初期の概念

これらのデザインでは、その後も維持されるいくつかの概念を取り入れました。

  • 不要なラベル ([更新日] など) や明白な説明のテキストを削除することで、重要な詳細情報をひとめで確認できるようになりました。
  • メタデータの形容詞を強調しました。ファイル サイズなどの値をユーザーに比較させるのではなく、"より大きい" などの言葉を使用することで、ユーザーが適切な概要情報を得られるようにしました。
  • 適切な既定値が事前選択され、ユーザーの作業が軽減されました。

迅速で流動的: 競合の一括管理を向上

Windows 8 では操作をさらに迅速かつ効率的にしたいとの考えから、"迅速で流動的" というのが、すべてのデザイン (タッチの場合はマウスまたはキーボード、またはその両方の同時使用) において Windows 8 に関する重要なデザイン用語になりました。次の主要な デザインの検討では、一括コピーの進捗のエクスペリエンスから引き継げる方法を検討し、キューに登録された競合を 1 つのダイアログにまとめ、より効率的な方法でそれらを管理できる機能を提供しました。

"すべて置換する" か "すべてスキップする" かを選択できるように最適化するというアイデアが導入されました。ほとんどの場合、コピーする対象とそれが競合している理由をユーザーは正確に把握しているため、実行する操作について単純に選択することができます。

図 5 - 一括管理の追加

よりきめ細かく制御するために詳細な情報が必要な場合については、詳細情報を "階層" として開示することに決定しました。

まず 2 階層から始めました。

図 6 - 初めの 2 階層

次に、3 階層を試しました。

図 7 - 3 階層

そして最終的に 1 階層に戻しました。

図 8 - 1 階層

このデザインには、プラスになる特性が数多くあります。まず、多くの情報が提供されます。ヘッダーをクリックすると列全体が選択されるので、競合の管理では真価を発揮します。しかし、1 次エクスペリエンスとして表示する UI としては、非常に複雑でした。

その代わりに、これらのオプションの最も優れた点を組み合わせて、次のような形にしました。

図 9 - 1 つのダイアログに 2 つの階層

シンプルかつ詳細な競合解決

このデザインにより、シンプルさと、ユーザーのパターンに適した機能をバランス良く組み合わせる方向に進んでいることは明らかでした。

残念ながら、このデザインには大きな課題があることが判明しました。[Let me pick] (選択する) を選ぶと、シンプルなオプションと詳細なオプションの両方が選択可能になるため、わかりにくく、煩雑すぎる結果となります。このことから、"シンプルな競合解決ダイアログ" と "詳細な競合解決ダイアログ" を別々のエクスペリエンスにするデザインに変更しました。

図 10 - 基本構造

この決定により、基本構造が定まりました。

微調整

ユーザーによるテストの準備のため、デザインを検討しました。

  • サムネイルが 1 つであるために生じる混乱を解決しました。
  • コピー元とコピー先 (およびそれぞれの列) を、より明確にしました。
  • ユーザー アシスタンス チーム (製品、サポート、および Web で使用するテキストの作成のエキスパートたち) が、より適切なテキストの考案に力を貸してくれました。

図 11 - テスト前

興味深いことに、シンプルな競合解決ダイアログと、単一ファイルの競合に対処するための初期のデザインの一部は類似していることがわかります。また、この両方がダイアログの最終的なデザインとどれだけ類似しているかも、興味深い点です。

第 1 回目のユーザビリティ調査

ユーザビリティ テストでは、マイクロソフトの社員ではなく、多様なスキル レベルと経験を持つ研究員が、幅広い課題を見つけ出します。これらの研究員にソフトウェアを見せて、一連のタスクを実行するように依頼します。その思考プロセスの説明に耳を傾け、UI をどのように見ている かを視標追跡によって調べ、作業を問題なく完了できるまでを測定することによって、デザインに関して何が効果があるか (または効果がないのか) について貴重な情報を得ることができます。

ユーザビリティ テストはマイクロソフトが使用するツールの 1 つであることを理解しておくことが非常に重要です。このツールを使用したことがある人であれば、その分野に精通していると同時に、テストそのもののデザインにも精通している必要があることをご存知でしょう。観察者バイアス とテストの構造によっては、誤った安心感につながることや、本質的に欠点があるソリューションを最適化しようと取り組むことになりやすいからです。その点をサポートするため、マイクロソフトのテストは客観的な研究者によってデザインされます。これらの研究者は、テスト可能な範囲を理解し ており、テストから導かれる結論がテストで意図されている測定対象と一致するようにします。最終的には、デザインの選択には、質的および量的な面で多数の異なるインプットと、経験、そして直観が必要になります。

第 1 回のユーザビリティ テストで多くのことが判明し、多数の変更を加えることになると予想していたため、手続きとして RITE メソッドを使用しました。ほとんどのユーザビリティ調査ではすべてのユーザーが同じ UI をテストしますが、RITE メソッドでは結果に基づいて参加者ごとに連続的に変更します (このときは PowerPoint スライドを使用してテストしたた め、変更は低コストで済みました)。

シンプルな競合解決ダイアログのテストは良好な結果が得られたため、このダイアログには変更を加える必要はありませんでした。しかし、詳細な競合解決ダイアログについては、さまざまな項目を数多くテストしました。

図 12 - 第 1 回の RITE 調査でテストしたダイアログ

主に次のような教訓が得られました。

  • チェック ボックスは必要であることがわかりました。私たちは、チェック ボックスのないすっきりした見た目が好ましいと考えていましたが、テストはうまくいきませんでした。その UI が表示されたとき、ユーザーは何をすべきかを理解できませんでした。選択を促す適切なきっかけを与え るものとして、チェック ボックスは予想以上に効果的でした。ファイルを選択するためにユーザーがチェック ボックス、サムネイル、またはテキストをクリックできるように、クリックのターゲット領域を広く確保するようにしました。

図 13 - クリックのターゲット

ファイル選択のためのターゲット領域

  • 形容詞 ("より新しい"、"より大きい" など) とメタデータを混在させると、混乱を招きました。ユーザーは、これらを 2 つの異なる概念だと解釈しました。特に、形容詞が問題でした。それらをタイトルだと思ったユーザーや、ファイルの場所を表していると捉えたユーザーがいま した (たとえば "より古い" という形容詞は、そのファイルがコピー前に存在していたため、コピー先のファイルを意味すると解釈されました)。
  • 列の区別を、より明確にする必要がありました。一見すると、表ではなく、エクスプローラーでの並べて表示ビューのように見えたためです。

さらなる微調整

形容詞と列の問題に対する単純な解決策がなかったため、デザインの探求をさらに進めることになりました。

図 14 - テスト中の微調整

コピー元またはコピー先と競合を表す列の階層と重要性をどのように定義するのが最適なのか、試行錯誤を重ねました。コピー元とコピー先をはっきり区別するために、縦に並べる方法を試しました。最終的には、競合するファイル間の区別を最も目立たせるために、ファイル名をヘッダ ーとして組み合わせて横に並べる方法に落ち着きました。この区別をわかりにくくすることなく、コピー元とコピー先を見分けて選択できるようにするのに、チェック ボックスが役立ちました。

初期のアイデアの一部は、プロセスのこの時点で放棄しました。

  • 既定の選択肢は設けません。競合に関する情報がページの外にまでわたる場合、既定値によるデータ損失のリスクが高くなりすぎたためです。列を選択しないことで、ファイルのコピーがスキップされ、データが失われることがなくなります。
  • 形容詞は使用しません。私たちは、"より新しい" や "より大きい" という表現を好ましいと考えていましたが、混乱を招き、実際のデータを表すものとユーザーは解釈しました。
    その代わりに、ユーザーの選択を支援するために、より繊細な方法で候補を示すことにしま した。つまり、新しいほう、および大きいほうのメタデータ値を UI では太字にしました。これには、新しい概念を取り入れたり複雑にしたりしなくても、驚くべき効果があることが実証されました。

さらなるユーザビリティ調査

第 2 回のユーザビリティ テストでは、最終的なデザインに近づけることを目指し、テストでの選択肢を少なくしました。

図 15 - 第 2 回のユーザビリティ テスト

3 番目のオプションが選ばれることは明らかでした。この 2 列表示は領域の使用効率が最も高く、チェック ボックスが質問文の近くに移動されています。日付と時刻はそもそも 1 つの値なので、同じ行に表示する必要があります。

詳細な競合解決のダイアログでは、判断のためにさらに多くの情報が必要とされる場合のために、次の機能も提供しています。

  • サムネイルをダブルクリックすると、ファイルが開きます。
  • サムネイルを右クリックすると、標準のコンテキスト メニューが表示されます。
  • 青色の "コピー元" と "コピー先" のテキストはクリック可能になっており、それらの場所がエクスプローラーで開かれます。
  • サムネイルまたはリンクをポイントすると、完全なファイル パスと共にヒントが表示されます。

継続的な検討

最初の調査以降も、さらに調査を実施して軽微な変更を行っていますが、コア デザインは基本的に同じままです。ユーザーがユーザビリティ テストの作業を簡単に完了できることを確認できたことが、大きな励みになりました。ファイル名の競合の解決は慎重を要する問題ですが、ユ ーザーは効率的に問題なく実行しています。

[![図 16 - 最終デザイン](https://msdntnarchive.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/01/29/43/%0Ametablogapi/3566.Figure-16---Final-hero-shot_thumb_0A266392.png "図 16

基本的なファイル管理に関する以前の投稿に含まれるビデオを再生すると、このデザインが機能しているところを見ること ができます。

私たちは、お寄せいただくフィードバックを活かして、可能な限り最適なデザインを実現したいと考えています。このため、いただいたコメントにはすべて目を通しており、皆様に実際に使っていただくことを楽しみにしています。

- Ben Truelove、Matt Duignan、Jon Class、Ilana Smith

(以前の投稿でいただいた質問の一部にお答えするコメントを、数人のチーム メンバーが書き込んでいます。(AlexMattJordiJon)。)