Опыт решения проблемы конфликта имен файлов в Windows 8

Большое спасибо за все комментарии, касающиеся нашей работы по улучшению основ системы управления файлами. Мы очень довольны состоявшимся диалогом — он продемонстрировал заинтересованное отношение участников к тем изменениям, которые были внесены нами в систему. Впечатляют также тон и энергия, с которыми обсуждалась данная тема. Все это делает нашу работу над Windows 8 такой увлекательной и волнующей. Комментарии и предложения касались многих аспектов, затронутых в наших обсуждениях, однако большинство из них так или иначе были связаны с дискуссией (при этом рассматривались все стороны проблемы), касающейся диалогового окна конфликтов имен файлов (всего одного диалогового окна!). Мы подумали, что было бы неплохо "раскопать" архивы нашего проекта, касающиеся всего цикла разработки, и показать вам, чем мы занимались и каким образом пришли к тому конечному результату. В дальнейшем мы, конечно, еще будем возвращаться к затронутым в обсуждениях вопросам и говорить о тех изменениях, которые можно было бы реализовать, однако мы подумали, что стоит затратить некоторые усилия для более подробного рассмотрения истории разработки проекта. Вклад в подготовку этой записи блога был внесен целой группой специалистов, работавших над указанной выше проблемой (все они также работали и над разработкой других компонентов Windows 8), — Бен Трулав (Ben Truelove), конструктор, Мат Дюгнан (Matt Duignan), исследователь UX, Джон Класс (Jon Class) и Илана Смит (Ilana Smith), руководители программ. — Стивен

Наша предыдущая запись блога, посвященная новым операциям копирования в Windows 8, вызвала множество вопросов и комментариев, касающихся нового диалогового окна "Выбрать файлы", используемого для разрешения конфликтов имен файлов. Принимая во внимание уровень интереса, проявленного к данной теме, мы подумали, что было бы забавно поделиться с читателями сведениями об итерациях по конструированию диалога и проведенном нами тестировании его удобства и простоты использования, которое привело нас к получению данного проект.

В реализованном проекте имеется два уровня управления при разрешении конфликтов имен файлов.

  • Первый уровень взаимодействия представлен упрощенным, реализуемым по одному щелчку мыши массовым управлением процессом разрешения всех конфликтов, при котором предлагается "Заменить все" или "Пропустить все". Мы назвали его "Простое диалоговое окно разрешения конфликтов".
  • Имеется также вариант с использованием вспомогательного уровня взаимодействия, при котором предоставляются более широкие возможности для управления и больше необходимой информации. Это "Детальное диалоговое окно разрешения конфликтов".

Рис. 1. Итоговые диалоговые окна

Windows 7 и более ранние версии

Разрешение конфликта имен файлов является внутренне неоднозначной задачей, поскольку предполагает, что нужно сделать правильный выбор между двумя очень сходными вариантами.

Вот как это делалось в 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 (основанных на использовании как касаний, так и мыши/клавиатуры или обоих подходов). Следующая важная итерация в процессе конструирования касалась способов осуществления последовательности копирования файлов, перенесения конфликтов их постановки в очередь в единое диалоговое окно, что позволило бы более эффективно управлять разрешением таких конфликтов.

Была введена идея, связанная с оптимизацией выбора между командами "Заменить все" и "Пропустить все". В большинстве случаев пользователь точно знает, что именно копируется и почему возникает конфликт. Поэтому он может сделать простой выбор действия, которое следует выполнить.

Рис. 5. Добавление возможностей управления массовыми операциями

Для случаев, когда пользователю требуется дополнительная информация или необходим более детальный уровень управления, мы решили перенести необходимые для этого сведения в соответствующие "уровни".

Мы начали со следующих двух уровней:

Рис. 6. Первая двухуровневая структура

Затем мы попробовали трехуровневую структуру:

Рис. 7. Трехуровневая структура

И закончили, вернувшись к одноуровневому варианту:

Рис. 8. Вариант с одним уровнем

Этот подход обладает многими преимуществами. Он предоставляет много полезной информации. Щелчок заголовков позволяет выбрать все элементы соответствующего столбца, что позволяет более эффективно управлять процедурой разрешения конфликтов. Однако в таком виде данный элемент пользовательского интерфейса оказался бы, пожалуй, слишком сложным для использования.

Поэтому взамен него мы попытались объединить лучшие элементы данных вариантов в рамках следующего подхода:

Рис. 9. Одно диалоговое окно с двумя уровнями

Простой детализированный подход к разрешению конфликтов

Было ясно, что такой макет ведет к получению сбалансированного сочетания простоты и эффективности, соответствующих потребностям большинства пользователей.

К сожалению, при использовании такого макета мы столкнулись с серьезной проблемой: выбор варианта "Let me pick" (Выбор пользователя) приводил к получению не совсем понятного и слишком сложного результата, поскольку становились доступными как простые, так и достаточно сложные варианты выбора. Поэтому мы перешли к схеме, в которой "Простое диалоговое окно разрешения конфликтов" и "Детальное диалоговое окно разрешения конфликтов" были разделены.

Рис. 10

Приняв такое решение, мы получили нашу базовую структуру.

Подробности

При подготовке к тестированию с привлечением пользователей мы последовательно вносили изменения в макет.

  • Была снята неопределенность, вызываемая использованием лишь одного эскиза.
  • Более наглядным стало представление исходного и конечного элементов (и их столбцов).
  • Совместно с группой, занимающейся вопросами помощи пользователям (объединяющей экспертов, подготавливающих тексты, используемые непосредственно в продуктах, справке и в Интернете), мы улучшили содержание текстов.

Рис. 11

Забавно было видеть сходство элементов, представленных в простом диалоговом окне разрешения конфликтов, с некоторыми элементами, использованными в предыдущих макетах, в которых разрешались конфликты для отдельных файлов. Также интересно было заметить сходство обоих этих вариантов с итоговым макетом данного диалогового окна.

Первый круг исследования удобства и простоты использования

Для тестирования удобства и простоты использования наши исследователи отобрали ряд тестеров из разных профессиональных сфер с различными уровнями опыта и квалификации, не являющихся сотрудниками Майкрософт. Мы показали им программное обеспечение и попросили выполнить ряд задач. Выслушивая их описания того, что они думают, используя отслеживание движений глаз, чтобы понять, как они воспринимают пользовательский интерфейс, и измеряя результативность выполнения задач, мы получили ценную информацию об элементах, успешно (или не очень) работающих в макете диалогового окна.

Чрезвычайно важно понимать, что тесты удобства и простоты использования являлись единственным и единым инструментом, который использовался нами. Все, кто когда-либо пользовался этим инструментом, знают, что при этом необходимо одновременно быть и экспертом в соответствующей области, и экспертом непосредственно в области разработки самих тестов, поскольку необъективность испытателя и сама конструкция теста легко могут привести к ошибочным выводам относительно безопасности или к попыткам оптимизировать изначально ущербное решение. Чтобы решить эту проблему мы привлекли к разработке тестов квалифицированных экспертов, понимающих границы возможностей объективного тестирования и способных гарантировать, что результаты, полученные при тестировании, соответствуют тому, что предполагалось измерить с помощью соответствующих тестов. В конечном счете, для выбора макета диалогового окна требуется использовать много различных входных данных — как количественных, так и качественных. Не последнюю роль здесь играют опыт и интуиция исследователей.

Мы понимали, что первый круг проведения наших тестов удобства и простоты использования дал нам много полезной информации, и мы внесли большое количество изменений, поэтому в качестве протокола для их учета стали использовать метод RITE. В большинстве исследований удобства и простоты использования у всех пользователей тестировался один и тот же пользовательский интерфейс. Мы постоянно вносили изменения для всех участников, основываясь на полученных в процессе тестирования знаниях. (Тестирование на этом этапе проводилось с использованием слайдов PowerPoint, поэтому обходилось достаточно дешево.)

В итоге мы не стали вносить много изменений в простое диалоговое окно разрешения конфликтов, поскольку его тестирование дало положительные результаты, однако нам пришлось дополнительно тестировать много различных элементов в детальном диалоговом окне разрешения конфликтов:

Рис. 12. Диалоговые окна, протестированные в первом использовании RITE

Основные уроки, которые были нами получены:

  • "Флажки" являются необходимыми элементами управления. Как только мы использовали макет, в котором отсутствовали флажки, результаты тестирования оказывались неудовлетворительными. Пользователи просто не знали, что нужно делать, когда им предлагался такой пользовательский интерфейс. Флажки оказывались гораздо более эффективными при предоставлении соответствующих вариантов для выбора. Мы также обеспечили большую область расположения для выполнения щелчков кнопкой мыши, благодаря чему пользователи для выбора файла могли бы щелкать непосредственно флажок, а также эскиз или соответствующий текст.

Рис. 13. Область расположения для щелчка

Щелкните область расположения для выбора файла

  • Смешивание характеристик-определений (например, "newer" (более новый), "larger" (больше)) и метаданных приводит к путанице. Пользователи интерпретируют их как две различных концепции. Использование характеристик-определений оказалось особенно проблематичным — пользователи думали, что это заголовки или описание расположения файлов (например, "older" (более старый) означает файлы в расположении, в котором они находились перед копированием).
  • Отображение столбцов должно быть более четким. На первый взгляд, они выглядели не как таблица, а как представление "Плитка" в проводнике.

Дополнительные подробности

Простое решение проблем характеристик-определений и столбцов отсутствовало, поэтому потребовалось провести дополнительные исследования макета:

Рис. 14. Подробности промежуточного тестирования

Мы буквально боролись за получение наилучшего способа определения иерархии и важности проблемы отображения исходного/конечного элементов и строк конфликтов. Мы попробовали использовать вертикальные линии, четко разделяющие исходные и конечные элементы. В конечном счете, мы остановились на горизонтальных линях в сочетании с использованием имени файла в качестве заголовка, что позволило придать максимальную наглядность различиям между конфликтами. Использование флажков помогло более четко различать выбор между исходным и конечным элементами, исключив возможность смешивания с указанным выше различием.

Некоторые из предложенных ранее идей были отвергнуты на этом этапе:

  • Мы отказались от выбора по умолчанию. Возможность прокрутки страницы, при которой нужная информация скрывается с экрана, приводит к существенному возрастанию риска потери данных при использовании выбора по умолчанию. Результатом отсутствия выбора в строке будет пропуск данного файла при копировании — поэтому нечего будет и терять.
  • Мы отказались и от использования характеристик-определений. Нам нравились определения типа "более новый" или "больше", но они добавляли элемент неопределенности, а пользователи ценят конкретные данные.
    Вместо этого, чтобы помочь пользователям сделать выбор, мы выбрали более "тонкое" решение — значения метаданных, соответствующие более новым файлам и файлам большего размера отображаются в пользовательском интерфейсе полужирным шрифтом. Это простое решение оказалось удивительно эффективным и не потребовало введения новых концепций.

Дополнительное использование удобства и простоты использования

В следующем круге тестирования удобства и простоты использования мы продвинулись к получению итогового макета и провели тестирование дополнительных альтернатив:

Рис. 15. Второй этап тестирования удобства и простоты использования

Третий вариант оказался чистым победителем. Представление с двумя столбцами оказалось наиболее эффективным по использованию пространства, а флажки были размещены рядом с вопросом. Дата и время должны располагаться на одной строке, поскольку они фактически представляют одно значение.

В детальном диалоговом окне разрешения конфликтов также предоставляются следующие возможности, помогающие в случаях, когда для принятия решения требуется еще больше информации:

  • Двойной щелчок эскиза открывает файл.
  • Щелчок эскиза правой кнопкой мыши открывает стандартное контекстное меню.
  • Синий текст исходного и конечного элементов можно щелкать, после чего соответствующие расположения открываются в Проводнике.
  • При наведении указателя на эскиз или ссылку отображается подсказка с полным путем к соответствующему файлу.

Продолжение исследований

После осуществления первоначальных исследований мы продолжали проведение работы в этом направлении и внесли некоторые незначительные изменения. Однако основной макет диалогового окна остался практически без изменений. На нас произвело большое впечатление та простота, с которой пользователи выполняли задачи тестирования удобства и простоты использования. Разрешение конфликтов имен файлов является довольно сложной проблемой, однако пользователи успешно с ней справились.

Рис. 16. Итоговый макет

Просмотрите видео из нашей предыдущей записи блога об основах системы управления файлами, чтобы увидеть этот макет в действии.

Нам нравится получать отзывы читателей, мы хотели бы их использовать для создания наилучшего макета. Поэтому мы будем внимательно читать все ваши комментарии и надеемся в будущем совместно поработать над их практической реализацией.

- Бен Трулав, Мат Дюгнан, Джон Класс и Илана Смит

(Если вам понравился наш текст, вы можете ознакомиться с комментариями некоторых членов из нашей команды, содержащихся в предыдущих записях блога, в которых рассматривается ряд затронутых здесь вопросов: Алекс, Мат, Джорди, Джон.)