Три года назад мне попалась интересная научная статья сотрудника Microsoft Кента Салливана о процессе и результатах проектирования нового пользовательского интерфейса для Windows 95. С тех пор веб-страница исчезла — одна из причин, почему я такой цифровой Плюшкин.Статья описывает некоторые общие проблемы оболочки Менеджера программ в Windows 3.1 и рассматривает варианты разработки отдельной оболочки для «новичков». Я склоняюсь к мнению, что она предположительно создавалась в духе программы At Ease от Apple, довольно популярной во времена System 7. Я хорошо помню, как мы запускали At Ease в начальной школе, так что детишкам не приходилось возиться с жёстким диском в Finder.
Итак, вот что Кент дословно написал в своей статье под названием «Пользовательский интерфейс Windows 95: конкретный пример проектирования функциональности» (The Windows 95 User Interface: A Case Study in Usability Engineering). Публикуем её, чтобы документ никогда не потерялся.
Резюме
В разработке пользовательского интерфейса для большого коммерческого программного продукта вроде Microsoft Windows 95 участвует много людей. У этого проекта обширные задачи и агрессивный график выполнения работ. Краткое изложение проекта здесь описывает опыт успешного применения принципов проектирования юзабилити, итеративной разработки и отслеживания проблем, чтобы повысить управляемость процессом разработки UI. Также обсуждаются конкретные проблемы дизайна и их решения.
Введение
Windows 95 — это обширное обновление продуктов Windows 3.1 и Windows for Workgroups 3.11. Почти во всех частях Windows произошли многие изменения. Не стал исключением и пользовательский интерфейс. В этой статье обсуждается дизайнерская группа, её задачи и процесс работы. Затем объясняется, как в проекте применялись принципы проектирования юзабилити, такие как итеративная разработка и отслеживание проблем. В качестве примеров приведены конкретные проблемы дизайна и их решения.
Дизайнерский отдел
Группу разработки пользовательского интерфейса Windows 95 сформировали в октябре 1992 года на ранней стадии проекта. Я подключился к группе в декабре 1992 года в статусе помощника для обеспечения сервисов юзабилити. Команда была по-настоящему междисциплинарной, со специалистами в области проектирования, графического дизайна, тестирования юзабилити и компьютерных наук. Количество сотрудников колебалось в ходе проекта, но в среднем нас было двенадцать. Ещё столько же программистов для реализации пользовательского интерфейса.
Цели дизайна
Дизайнерская группа работала над двумя очень широкими задачами:
- Сделать проще изучение Windows для людей, которые только начали пользоваться компьютерами и Windows.
- Сделать проще использование Windows для людей, которые уже работали с компьютерами — как для обычных пользователей Windows 3.1, так и для продвинутых, опытных пользователей Windows 3.1.
С более чем 50 млн установок Windows 3.1 и 3.11 плюс практически нетронутым рынком домашних ПК с самого начала стало понятно, что задача выпуска лучшего продукта станет нетривиальным упражнением. Без тщательного дизайна и тестирования мы скорее всего сделаем продукт, который улучшит юзабилити только для определённой категории пользователей, но ухудшит его для миллионов остальных (существующих или потенциальных). Мы хорошо понимали проблемы средних и продвинутых пользователей, но мало знали о проблемах, которые испытывают новички.
Процесс дизайна
С учётом очень широких задач и агрессивного графика работы перед выпуском продукта (на проектирование и программирование пользовательского интерфейса отводилось примерно 18 месяцев) мы с самого начала знали, что разработка по традиционной каскадной модели («Водопад») не предоставит нам достаточной гибкости для достижения наилучшего решения. На самом деле нас беспокоило то, что традиционный подход приведёт к созданию непригодной системы.
В каскадной модели проектирование системы разделяется на части (обычно ограничено фазой написания спецификаций), а тестирование юзабилити, как правило, происходит ближе к окончанию процесса, во время мероприятий по контролю качества. Мы поняли, что этого недостаточно для создания дизайна, его проверки на пользователях (возможно, в сравнении с другими дизайнами), произведения изменений и сбора отзывов. К счастью, наше желание отказаться от каскадной модели в пользу итеративной разработки совпало с аналогичными попытками в других отделах компании, так что у нас имелись конкретные примеры её преимуществ и применимости.
Итеративная разработка на практике
На рис. 1 в общих чертах показан процесс нашей разработки. Он типичен для большинства продуктов, которые разрабатываются итеративно: идеи дизайна опробовались в виде прототипов на бумаге или в цифровом виде для сбора лабораторных данных о юзабилити. После программирования дизайна он уточнялся в лаборатории. При достижении достаточного уровня кодирования и уточнения проект изучали более широко, со временем, в боевой обстановке. Незначительные проблемы в юзабилити тут же исправляются до выпуска готового продукта. Что более важно, собранные в полевых условиях данные используются для направления работы над следующей версией.
Наш процесс итеративной разработки проходил в три основных этапа: изучение, быстрое прототипирование и тонкая настройка.
Рис. 1: Процесс итеративной разработки Windows 95
Этап изучения
На этом первом этапе мы экспериментировали с разными направлениями дизайна и собирали первые отзывы пользователей. Мы начали с прочного фундамента визуального дизайна UI, используя работу, проделанную группой Cairo. Мы унаследовали от них значительную часть фундаментального UI и интерфейсов взаимодействия: рабочий стол, трей (область уведомлений), контекстные меню, трёхмерный вид и проч.). Мы также получили данные из службы поддержки о 20-ти главных проблемах пользователей Windows 3.1.
На рис. 2 показан прототип дизайна рабочего стола Windows 95, юзабилити которого мы тестировали в январе 1993 года. Дизайн основан на Cairo и включает в себя первый проход исправления некоторых известных проблем Windows 3.1 (в частности, управления окнами).
Рис. 2: Ранняя версия рабочего стола Windows 95 (с выносками для ясности)
Верхняя иконка File Cabinet открывала вид в стиле менеджера файлов Windows 3.1 (слева иерархия, справа контент). Вторая иконка World показывала элементы в сети. Третья иконка Programs — это папка с другими папками, полными ссылок на программы, установленные в системе. Вдоль нижей части экрана располагается системный трей с тремя кнопками (System, Find и Help) и областью хранения файлов. Другая иконка Wastebasket представляет собой контейнер удалённых файлов.
Исследования юзабилити этого прототипа рабочего стола проводились в лаборатории юзабилити Microsoft, также как и последующие тесты. Мы провели типичные итеративные исследования юзабилити. От трёх до четырёх пользователей, каждый из которых представлял отдельную интересующую группу (обычно начинающие и средние пользователи Windows 3.1) выполняли задачи на прототипе. Во время тестирования мы хотели получить ответы и на очень широкие вопросы (например, нравится ли интерфейс пользователям), и на очень конкретные (например, обнаружит ли пользователь в течение 10-ти минут возможность копирования файла путём перетаскивания мышкой). Мы собрали типичные данные для итеративных исследований: вербальные протоколы, время выполнения задачи, количество ошибок, типы ошибок и оценки.
Первые результаты
Юзабилити-тестирование этого прототипа принесло много результатов, в том числе несколько неожиданных:
- Начинающих и многих средних пользователей путал двухпанельный интерфейс менеджера файлов (рис. 3). Они были не уверены в связи между панелями и в том, как переходить в другие папки. Новичков часто поражала визуальная сложность менеджера файлов — и они испытывали более базовые проблемы, такие как непонимание возможности существования одних папок внутри других папок. Многих пользователей смущала иконка Parent Folder. Она появлялась в каждой папке и выглядела как файл, хотя на самом деле это элемент навигации для выхода на предыдущий уровень иерархии.
Рис. 3: File Cabinet, ранняя версия менеджера файловой системы - Пользователей всех уровней квалификации смущала папка Programs. Мы думали, что наличие на рабочем столе такой папки с другими папками и ссылками на программы внутри станет естественным для пользователей Windows 3.1, привыкших к менеджеру программ, и в то же время её будет относительно просто освоить новичкам. Мы ошибались! Новички быстро заблудились во всех папках (в отличие от File Cabinet, здесь каждая папка открывалась в новом окне), а у других пользователей возникло много проблем с попытками понять, видят они реальную файловую систему и её файлы или просто ссылки на на настоящие файлы.
- У пользователей возникли значительные сложности с определением, для чего нужна каждая из трёх кнопок в трее, а позже возникли трудности с запоминанием, куда идти для выполнения конкретной команды, поскольку в определённых контекстах их функции пересекались (например, для поиска чего-то в разделе помощи Help нажать Find или Help?)
Сравнение с Windows 3.1
С первых лабораторных экспериментов стало понятно, что нам требуется база Windows 3.1 для лучшего понимания, какие проблемы существовали до Windows 95, а какие проблемы уникальны для нового дизайна. Сначала мы собрали данные рыночных исследований о 20-ти самых частых задачах, которые выполняют пользователи Windows 3.1. Затем провели несколько лабораторных исследований, сравнивая Windows 3.1 и Windows 95 с учётом этих 20-ти задач. Мы также провели собеседования с профессиональными преподавателями Windows 3.1 (и Macintosh, для сравнения), чтобы понять, какие аспекты операционной системы они считают простыми и сложными в обучении юзеров.
Ключевые результаты:
- В Windows 3.1 новичкам требовалось в среднем 9,5 минут для поиска и открытия программы, которая не видна сразу на экране. В нашем прототипе Windows 95 результаты оказались ненамного лучше. Такие результаты явно неприемлемы с учётом того, что данные рыночных исследований (и здравый смысл) говорили о том, что запуск программ у пользователей является задачей номер один.
- Новые и некоторые средние пользователи испытывали большие проблемы при использовании мыши, особенно двойного щелчка. В результате они часто не могли найти элементы в контейнерах, доступ в которые открывался только по двойному щелчку.
- Начинающие и многие средние пользователи для поиска команд полагались почти исключительно на визуальную информацию. Они полагались на строки меню и панели инструментов, но не использовали всплывающие (контекстные) меню даже после обучения.
- Все, кроме самых продвинутых пользователей, не понимали, как эффективно управлять множеством перекрывающихся окон. Больше всего проблем возникло у новичков — при сворачивании окна они думали, что оно «ушло», если оно было закрыто другим окном. От преподавателей мы слышали много историй (и наблюдали это в лаборатории), как пользователи исчерпывали всю оперативную память на компьютере, запуская многочисленные копии программы вместо переключения на первую запущенную копию. Средние пользователи проявили больший опыт, но тоже испытывали проблемы, особенно с приложениями Multiple-Document-Interface (MDI), такими как Менеджер программ и Microsoft Word. Данные рыночных исследований подтвердили проблему: оказалось, что 40% средних пользователей Windows не запускали больше одной программы одновременно, потому что испытывали какие-то трудности с этим.
- Начинающих пользователей сбивала с толку иерархическая файловая система. Средние пользователи обычно справлялись с иерархией, но зачастую делали это с трудом и сохраняли все свои документы в директорию по умолчанию для той программы, которую использовали. Эта проблема (особенно у новичков) наблюдалась и у пользователей Macintosh.
Смена направления
Результаты этих исследований и собеседований сильно изменили дизайн пользовательского интерфейса Windows 95. В раннем прототипе Windows 95 мы специально изменили некоторые элементы Windows 3.1 (например, элемент Desktop теперь стал реальным контейнером), а другие оставили без изменений (например, иконки менеджера файлов и менеджера программ на рабочем столе), потому что боялись слишком сильно менять дизайн. Мы знали, что продукт с радикальными отличиями от Windows 3.1 может запутать и разочаровать миллионы существующих пользователей, что явно неприемлемо.
Однако данные, собранные в прототипе Windows 95 и в Windows 3.1, показали невозможность сохранения текущего дизайна. Результаты начинающих пользователей в выполнении базовых задач оказались неприемлемо плохими, а многие средние пользователи выражали мнение, что Windows 95 просто другая, но не лучшая система.
Мы решили отступить и несколько дней подумать над ситуацией. Дизайнерская группа провела выездное собрание вне офиса и рассмотрела все данные, собранные на тот момент: базовые исследования юзабилити, собеседования, рыночные исследования и информацию из службы поддержки. Во время обсуждения данных мы поняли, что нужно сконцентрироваться на самых часто выполняемых задачах. Мы также поняли, что слишком много внимания уделяли связности с Windows 3.1.
По сути мы осознали, что жизнеспособное решение необязательно должно выглядеть как Windows 3.1, но определённо должно быть привлекательным для пользователей любого уровня, потенциально по разным причинам. Мы поняли, что по-настоящему удобная система будет масштабироваться в соответствии с нуждами разных пользователей: её легко освоить и изучить, и в то же время она обеспечит эффективность (через ярлыки или альтернативные методы) для более опытных пользователей.
Этап быстрых итераций
Когда мы начали работать над новым дизайном, то надеялись избежать классического парадокса «легко освоить, но трудно использовать». Мы постоянно держали в уме, что базовые функции UI должны масштабироваться. Мы знали, что для достижения этой цели нужно быстро опробовать много разных идей, сравнить их и выполнить повторение тех, которые кажутся самыми перспективными. Для этого требовались очень эффективные процессы проектирования и оценки.
Эволюция процесса спецификаций UI
Хотя мы с самого начала выбрали процесс итеративной разработки, у нас остался один элемент каскадного метода: монолитная конструкция спецификаций дизайна («спеки»). В первые несколько месяцев спеки стремительно росли и отражали сотни человеко-часов работы. Но из-за проблем, обнаруженных во время пользовательского тестирования, задокументированный в спеках дизайн внезапно устарел. Предстояло принять важное решение: потратить недели на изменение спецификаций для отражения новых идей и потерять ценное время, необходимое для итераций, или прекратить обновление спецификаций и позволить прототипам и коду выполнять роль «живых» спеков.
После некоторых споров группа выбрала второй вариант. Хотя такое изменение в чём-то затруднило сторонним группам возможность следить за нашей работой, но позволило проводить итерации на максимальной скорости. Изменения также привели к неожиданному эффекту: они сильнее сплотили команду, потому что бoльшая часть спецификаций существовала в устной форме и обсуждалась в беседах и на белой доске в кабинетах сотрудников. Последовало много «коридорных» разговоров, которые продолжались на протяжении всего проекта.
Чтобы все заинтересованные стороны всегда были в курсе актуального дизайна, мы организовали следующие мероприятия:
- Регулярные собрания сотрудников дизайнерского отдела. На еженедельных (иногда чаще) собраниях каждый сверял свою работу с общим проектом и все обсуждали, как работа каждого сотрудника может повлиять на других.
- Рассылка графиков и результатов тестирования юзабилити по электронной почте. Сотрудники дизайнерской группы получали регулярные уведомления о предстоящих тестах юзабилити и результатах завершённых тестов, чтобы быть в курсе, как продвигается дизайн.
- Формальное отслеживание проблем юзабилити. С проектом масштаба Windows 95 мы понимали, что требуется стандартный способ записи выявленных проблем юзабилити, когда и как они должны быть исправлены — а затем закрывать тикеты после исправления проблемы и успешной проверки на пользователях. Этот процесс более детально описывается в главе «Отслеживание открытых тикетов».
- Регулярные презентации дизайна для внешних групп. По мере продвижения проекта всё больше и больше групп (внутри и за пределами Microsoft) хотели посмотреть, что мы делаем, так что мы проводили такие презентации. Они эффективнее, чем рассылка документов, потому что презентации проще поддерживать в актуальном состоянии и они позволяют своевременно обсуждать дизайн.
Отдельный UI для новичков
Первым важным изменением дизайна, которое мы рассмотрели, стал отдельный UI («оболочка») для начинающих пользователей. Дизайн быстро набросали в Visual Basic и протестировали в лаборатории юзабилити (рис. 4). Тестирование показало неплохой результат, поскольку дизайн успешно ограничивал возможный выбор действий пользователя очень маленьким набором действий, но чем больше пользователей участвовали в тестировании, тем отчётливее проявлялись ограничения:
- Если в оболочке для новичков не поддерживалась всего одна нужная функция, то пользователю приходилось отказываться от использования оболочки (по крайней мере, временно).
- По идее, большинство пользователей после набора опыта должны оставить оболочку для новичков и перейти в стандартный интерфейс. Но опыт, который они получили в оболочке для новичков, необязательно переносится в стандартную оболочку.
- Оболочка для новичков вообще не похожа на все остальные программы, которые запускает пользователь (текстовые редакторы, электронные таблицы и др.). В результате пользователям приходилось изучать два способа взаимодействия с компьютером, что вносило путаницу.
Рис. 4. Частичный вид отдельной оболочки для новичков
По этим и другим причинам мы отказались от идеи. Важно отметить, что благодаря инструменту прототипирования и немедленному тестированию в лаборатории юзабилити у нас по-прежнему оставалось много времени для проверки других идей.
Примеры быстрой итерации
Ниже обзор пяти областей, для которых были спроектированы и протестированы три или более крупных итерации в дизайне. Итерации применялись и во многих других областях, но здесь недостаточно места, чтобы обсуждать их.
1. Запуск программ: меню «Старт». Хотя мы отказались от идеи отдельной оболочки для новичков, мы сохранили её самые полезные функции: доступ по однократному щелчку, хорошая различимость, взаимодействие через меню. Мы набросали много вариантов в Visual Basic и проверили их на пользователях всех уровней, не только на новичках, потому что это дизайнерское решение должно было хорошо восприниматься пользователями любого уровня. Рис. 5 показывает окончательный вариант меню «Старт» и подменю «Программы». Это меню служит не только для запуска программ, но сочетает в себе и другие функции. Все они открываются нажатием одной кнопки.
Рис. 5. Меню «Старт» и подменю «Программы»
2. Управление окнами: панель задач. Наша первая идея по улучшению управлением окнами была не очень амбициозной, но мы не знали, сколько работы понадобится для решения проблемы. Первой идеей было изменить внешний вид свёрнутых окон из иконок на «плитки». (рис. 6).
Рис. 6. Свёрнутые окна в виде «плиток»
Мы надеялись, что проблему можно решить, если свёрнутые окна будут отличаться на вид и иметь больший размер. Мы ошиблись! Пользователи испытывали практически такие же затруднения, как в случае с Windows 3.1. Результаты тестирования показали, что основная проблема в том, что окна не отображаются постоянно, так что пользователи не видят, какие окна открыты, и не могут быстро получить к ним доступ. Поняв это, мы быстро пришли к идее панели задач, показанной на рис. 7. У каждой задачи есть собственное место на панели, которая отображается поверх всех окон. Тестирование на пользователях показало, что это приемлемое решение проблемы.
Рис. 7. Панель задач с кнопкой «Старт», программами и часами
3. Работа с файлами: диалоги «Открыть» и «Сохранить как...». Информация из службы поддержки и результаты лабораторных тестов показали, что новички и средние пользователи испытывают много проблем с системными диалогами открытия и сохранения файлов (рис. 8).
Рис. 8. Диалоговое окно открытия файла в Windows 3.1
Проблемы вызваны тем, что поля диалогового окна находятся не в логическом порядке и имеют сложную методологию выбора. Команда Cairo взяла на себя инициативу в решении этой проблемы и разработала всесторонний прототип на Visual Basic, в том числе макет файловой системы. Мы протестировали несколько вариантов, пока не остановились на окончательном варианте, показанном на рис. 9.
Рис. 9. Диалоговое окно открытия файла в Windows 95
4. Печать: мастер установки. Информация из службы поддержки говорила о том, что установка и конфигурация принтера является главной причиной звонков от пользователей Windows 3.1. Многие проблемы проистекают из интерфейса установки принтера (рис. 10).
Рис. 10. Основное диалоговое окно установки принтера в Windows 3.1
Найти нужный принтер сложно, потому что все они находятся в одном длинном списке. Для выбора порта, особенно в сетевом окружении, требовалось спуститься на 4-5 уровней с нестандартными и сложными вариантами выбора. Примерно в то время, когда мы начали решать эту проблему, сотрудники дизайнерского отдела начали рассматривать мастер (визард) как решение для многоэтапных нечасто выполняемых задач. Установка принтера отлично вписался в это определение, и созданный визард показал хорошие результаты в тестировании на пользователях. На рис. 11 показан экран выбора принтера из окончательного варианта визарда.
Рис. 11. Экран мастера добавления принтера в Windows 95
5. Помощь: диалог поиска и вкладка с индексом. Лабораторное тестирование Windows 3.1 показало, что пользователи испытывают проблемы с поисковом диалогом в справочном разделе (рис. 12).
Рис. 12. Диалог поиска по справочной информации в Windows 3.1
Люди с трудом понимали, что диалоговое окно по сути состоит из двух частей и что нужно сначала выбрать что-нибудь из первого списка, а потом из второго, используя разные кнопки. Мы проверили несколько идей, прежде чем пришли к окончательному варианту вкладки с индексом (рис. 13). На этой вкладке только один список, а ключевые слова с более чем одной темой вызывают всплывающее окно диалогом, которое трудно не заметить.
Рис. 13. Вкладка индекса в справочном разделе Windows 95
Этап тонкой настройки
Когда мы спроектировали все основные области продукта, то поняли, что нужно сделать шаг назад и посмотреть, как все кусочки складываются вместе. Для этого были проведены итоговые лабораторные тесты и длительное исследование с реальными пользователями.
- Итоговые лабораторные тесты. Используя 20 основных задач из рыночного исследования мы провели комплексное тестирование всего UI. Пользователям разного уровня подготовки предлагали изоморфные наборы задач для измерения скорости обучения и уровня использования после освоения. Мы сравнивали эффективность работы с базовым уровнем Windows 3.1. После проведения собственного пилотного теста для выяснения возможных проблем с процедурой окончательное тестирование осуществил посторонний подрядчик, так что эти результаты можно использовать в официальных документах [3]. Результаты оказались весьма обнадёживающими — пользователи завершали выполнение задач примерно вдвое быстрее, чем в Windows 3.1 и в 20 из 21 категорий показали большее удовлетворение работой Windows 95.
- Длительное полевое исследование. Двадцать человек приняли участие в полевом исследовании на бета-версии Windows 95. Сначала мы изучали, как они работают в Windows 3.1, а затем наблюдали за установкой Windows 95. Дополнительные тесты проводились через неделю и через месяц для проверки уровня обучения и произошедших изменений. Мы не нашли никаких серьёзных пробелов в юзабилити продукта, но подкорректировали формулировки в UI и темах справочного раздела. Некоторые из собранных данных впоследствии использовались при планировании следующей версии Windows, а также сотрудниками службы поддержки, в том числе краткий перечень тем, которые можно ожидать с началом звонков в службу поддержки.
Отслеживание открытых тикетов
В ходе разработки и тестирования пользовательского интерфейса Windows 95 мы применили различные принципы и практики разработки юзабилити [2] [4]. С проектом масштаба Windows 95 мы понимали, что требуется стандартный способ записи выявленных проблем юзабилити, когда и как они должны быть исправлены — а затем закрывать тикеты после исправления проблемы и успешной проверки на пользователях.
Для этого мы разработали реляционную базу данных (рис. 14).
Рис. 14. Образец записи в базе данных с тикетами
После каждого этапа лабораторного тестирования я вносил туда новые проблемы и положительные результаты и назначал на каждый тикет соответствующее ответственное лицо — обычно одновременно дизайнера и преподавателя, который обучает пользователей. Статус текущих проблем обновлялся — тикет или оставался открытым, если требовалась дополнительная работа, или он закрывался в случае решения проблемы. Каждые несколько недель я выпускал ряд отчётов с распечаткой всех оставшихся проблем, по каждому ответственному лицу, и раздавал их сотрудникам (рис. 15). Мы встречались для обсуждения текущего прогресса и решали, когда изменённый дизайн будет готов для тестирования на пользователях.
Рис. 15. Образец отчёта в базе данных с тикетами
Отчёт
Как и в любом проекте, практика — критерий истины, так что приведу некоторые сводные статистические данные.
Лабораторные тесты
Мы провели 64 этапа лабораторного тестирования с 560 пользователями. 50% из них имели средний опыт работы с Windows 3.1; остальные — это новички, продвинутые пользователи и пользователи других операционных систем. Эти цифры не включают тестирование компонентов, поступивших от других команд (почтовый клиент Exchange, программа для отправки факсов и проч.). Тестирование этих компонентов прошло примерно в 25 этапов с участием 175 человек.
Выявление проблем
Для ключевых компонентов оболочки в ходе проекта в базу данных были внесены 699 «отчётов юзабилити». Из них 148 положительных результатов и 551 проблема. Проблемам присваивался один из трёх уровней серьёзности:
- Уровень 1: Пользователи не могут продолжать выполнение задачи или серии задач.
- Уровень 2: Пользователи испытывают значительные сложности с выполнением задачи или серии задач, но всё-таки способны продолжить её выполнение.
- Уровень 3: Пользователи испытывают незначительные сложности с выполнением задачи или серии задач.
Из 551 выявленной проблемы 15% получили уровень 1, 43% — уровень 2 и 42% — уровень 3.
Резолюции по проблемам
В ходе проекта использовалось пять резолюций по проблем:
- Решено. Команда исправила проблему и успешно испытала решение на пользователях.
- Запланировано. Команда разработала исправление проблемы и мы ожидаем его реализации.
- Под вопросом. Команда не уверена, нужно ли решать проблему, или не знает, возможно ли её решение.
- Частично. Команда разработала решение и оно протестировано на пользователях с удовлетворительными результатами, но всё равно остаются некоторые вопросы.
- Не решено. Команда не собирается решать проблему.
К завершению проекта все проблемы с резолюциями «запланировано» или «под вопросом» перешли в одну из других категорий. 81% проблем завершились успешным решением, 8% остались с резолюцией «частично», а 11% остались нерешёнными. В большинстве случаев причиной отсутствия решения стали технические ограничения, а иногда — ограничения рабочего графика.
Выводы
Для многих сотрудников отдела проект Windows 95 стал первым опытом итеративной разработки, тестирования юзабилити и отслеживания проблем.
Итеративная разработка
Возможно, лучшим доказательством нашей приверженности итерационной разработке стало то, что буквально никакая деталь изначального дизайна UI для Windows 95 не сохранилась без изменений в конечном продукте. В начале процесса проектирования мы не предполагали того масштаба и объёма изменений, которые придётся сделать. Итеративная разработка с использованием прототипов и продукт в качестве спецификации, а также непрерывное тестирование на пользователях позволили быстро исследовать много разных способов решения проблем.
Группа настолько привыкла к итерациям дизайна, что мы чувствовали спешку, когда ближе к окончанию проекта пришлось выполнить некоторые последние дизайнерские работы. Не было времени для итераций. Мы чувствовали разочарование, что нет времени для тонкой настройки и повторного тестирования дизайна.
Процесс спецификации
Подход «прототип или код являются спецификациями» в целом работал хорошо, хотя со временем мы естественным образом уточнили процедуру. Например, все прототипы конкретного релиза начали выкладывать в открытый доступ (для всех сотрудников) с инструкциями по их установке и запуску.
Дизайнерская группа редактировала документы из первоначальной спецификации и распространяла их для получения обратной связи на раннем этапе. Однако когда началось прототипирование и тесты юзабилити, то зачастую спеки отсылали читателей к прототипам для получения актуальной информации. По сути, мы обнаружили, что прототип представляет собой более богатую форму спецификации, требуя меньше времени на создание. При этом у него есть и другие полезные применения (тестирование юзабилити, демо-версии и т.д.). Прототип стимулирует более содержательные отзывы, поскольку рецензенту не так сильно нужно подключать воображение, чтобы понять работу системы.
Тестирование юзабилити
Хотя дизайн и итеративные тесты позволили создать отдельные функции, но именно тестирование юзабилити всего продукта целиком стало ключом для аккуратной подгонки отдельных частей друг к другу. Как уже упоминалось, на основании собранных данных мы произвели изменения в формулировке UI и темах справочного раздела. Если бы мы не провели то тестирование, то продукт не выглядел бы таким эффективным и приятным в работе.
Отслеживание проблем
Высокий процент исправленных проблем юзабилити не стал бы возможен без интенсивной самоотдачи всех членов команды. База для отслеживания проблем повысила управляемость процесса и гарантировала, что проблемы не ускользнут из вида. Однако исправления не были бы сделаны, если бы команда не верила в создание продукта максимально возможного качества. В этой вере главным стало наше понимание, что мы, наверное, не получим правильный результат с первого раза — и что неправильный результат настолько же полезен и важен для создания продукта, как и правильный.
Все тикеты с пометками «частично» и «не решено» перенесли в новую базу. Они стали начальной точкой для проектирования следующей версии Windows. Специалисты по планированию и дизайнеры ежедневно работали с этой информацией, а также анализировали отчёты из службы поддержки.
Список литературы
1. Dumas, J. S., Redish, J. C. (1993). A Practical Guide to Usability Testing (стр. 324-325). Norwood, NJ: Ablex Publishing Company.
2. Nielsen, J. (1993). Usability Engineering. San Diego, CA: Academic Press, Inc.
3. Usability Sciences Corporation. (1994). Windows 3.1 and Windows 95 Quantification of Learning Time & Productivity.
4. Whiteside, J. L., Bennett, J, & Holtzblatt, K. (1988). Usability Engineering: Our Experience and Evolution. In M. Helander (Ed.), Handbook of Human-Computer Interaction (стр. 791-817). Amsterdam: Elsevier Science Publishers, B. V.
5. Wiklund, M. E. (1994). Usability in Practice: How Companies Develop User-Friendly Products. Cambridge, MA: Academic Press, Inc.
Комментарии (68)
chernish2
09.02.2018 23:21А я очень скучаю по интерфейсу Windows 3.1. Возможно это иррациональная ностальгия, но было в нём что-то завораживающее, почти магическое, чего ни в 95, ни в OS/2 не было. С удовольствием бы поставил себе сейчас и на Linux и на Windows 7, если бы была возможность.
kovserg
09.02.2018 23:48+1Win3.11 в DosBox работает и под linux и под win7
Gnuava
10.02.2018 02:38Ну, сейчас это уже немного не то — поиграться максимум, не более: эту штуку никак толком не интегрируешь в современную ОС, а если что и получится — то с большими костылями.
chernish2
10.02.2018 11:19Она и под Android работает при большом желании, только речь не о том. Речь об интерфейсе.
Landgraph
10.02.2018 10:49Статья из времени, когда сначала думали, а потом делали.
Ни у кого нет ссылки на аналогичное изыскание, после которого пришли к тому ужасу, что есть сегодня? Очень интересно было бы сравнить.turone
10.02.2018 12:41полностью согласен, аж ностальгия розыгралась по win 95. А в win 10 может я пока чего-то не понимаю, но пока как в сказке — чем дальше тем страшнее, неудобно и на планшетах и на десктопе — дубли в десктопе и метро приложениях. А создание и настройка подключений так вообще ужас, даже просто вкл выкл wifi и то проблема. Такое впечатление, что никто не думает и тем более не проводит опросы и сбор мнений.
Landgraph
10.02.2018 13:04Это плата за универсальность.
Универсально != одинаково хорошо. Универсально == одинаково плохо.
Всё остальное — жалкие попытки скрыть неудобства как можно сильнее.
RedCatX
11.02.2018 12:17В начале 90-х, когда велась разработка Windows 95, Microsoft ещё не была безоговорочным монополистом, и поэтому ставила цель угодить пользователям, тем самым повысив продажи. Сегодня же, Windows является практически безальтернативной ОС для персональных компьютеров, и Microsoft может давить пользователей и навязывать им любые свои решения. Даже если Microsoft сделает для Windows ужаснейший интерфейс всех времён и народов, пользователи лишь поплюются немного, но будут его использовать, ибо альтернативы нет. Монополисту нет смысла проводить опросы и сбор мнений, ведь его продукт будут покупать в любом случае.
fzn7
10.02.2018 12:44Не видел ui оси лучше, чем есть в win10, не понимаю что там может быть ужастного по сравнению с 95
Landgraph
10.02.2018 12:58+3Забыли [sarcasm][/sarcasm]?
Даже интерфейс командной строки стал казаться очень удобным после появления 10-ки 8)
Дожили, пуском проще пользоваться вводя названия приложений, чем гуёвым интерфейсом…mistergrim
10.02.2018 16:06> Дожили, пуском проще пользоваться вводя названия приложений, чем гуёвым интерфейсом…
Я это вижу так: наконец-то можно вводить названия приложений и не пользоваться гуёвым интерфейсом.
LynXzp
10.02.2018 18:07+1То что можно вводить в поиск — это хорошо, даже для ХР было куча лаунчеров с этой функцией. Но из гуя сделали свалку. Хвала Ктулху существует Classic Menu объединяющие плюсы и поиска и нормального гуя.
P.S. поиск должен быть моментальным, а не то что там.mistergrim
11.02.2018 08:57Но гуй изначально свалкой был. Сидишь и мышкой ведёёёшь — а где же у нас вот это вот. Сейчас я начинаю вводить «ph» и сразу получаю Photoshop, а раньше надо было помнить, что он находится в папочке Adobe (а каждый софт считал своим долгом создать одну-две подпапки).
fzn7
11.02.2018 11:05Небыло сарказма. Быстрый доступ к консоли кому надо это и есть на мой взгляд отличный ui
Silverado
11.02.2018 12:16И это прекрасно. Пуск был и есть свалкой на большинстве компьютеров, сейчас же я имею возможность при запуске программ не лазить ни туда, ни на рабочий стол. При этом имеется аж три способа открытия программ в 1/2 клика (запуск с таскбара, плитки и самые используемые приложения в «пуске»), а, если знаешь название программы, текстовый поиск в 99% случаев быстрее чем искать в дереве (или мелком скроллящемся списке а-ля виста).
Landgraph
11.02.2018 15:15ИМХО, сама идея пуска, такая как она была заложена, как мне кажется идеальна или близка к этому. Но затем её стали мягко говоря неверно истолковывать различные разработчики. Отсюда появилась (есть и сейчас) вложенность ради вложенности
Но есть и ещё более вопиющие случаи, например, вынесение части функционала приложения в меню пуск (это касается справки, которая доступна внутри приложения, каких-то «запусков с определёнными ключами»), а также дублирование функционала, например, удаления. Я уже молчу о всяком мракобесии вроде текстов лицензий, ссылок на сайта и т.п. бреда на который никто никогда не жал и жать не будет, но оно есть в отдельном каталоге меню.
И не поймите меня неправильно, я в каком-то смысле рад, что появилась возможность поиска по меню, но это было сделано не в дополнение, а вместо основного функционала, к сожалению.
Ну т.е. задумка хорошая, но не была ясно донесена до других участников.
vbif
11.02.2018 22:58У «Пуска» есть родовая травма — пихать туда вместе с ярлыком программы кучу мусора вроде «Readme», «Uninstall», «посетите наш сайт». И вместо того, чтобы как-то бороться с этим, они пытаются придумывать костыли, типа раскрывающихся деревьев в Vista и +, или «стартового экрана» в Windows 8.
navion
12.02.2018 18:32Это фича и она прекрасно работала в ХР с выпадающими меню.
vbif
12.02.2018 18:43Гораздо лучше было бы, если бы этой «фичи» не было. В идеале все эти дополнительные функции либо должны раскрываться по правой кнопке, или как-нибудь ещё, чтобы при этом не мешать запускать программы из меню.
sumanai
12.02.2018 19:35+1Плюс XP в том, что можно настроить что угодно прямо в меню пуск при помощи мыши и клавиатуры. А суперсовременное меню в десятке не даёт даже пункта переименовать, в итоге приходится шариться по глубоко спрятанным папкам, чтобы настроить это меню.
advan20092
11.02.2018 12:17Забыли видео, в которых пользователи по 5-10 минут пытались войти в систему с логин скрина?
Или выключение компьютера с совершенно неинтуитивной выезжающей панели?
Или самопроизвольно включающийся на ноутбуке режим планшета из-за чего приходится полчаса гуглить как его выключить?
Таких примеров полно можно привести, UI десятки и восьмерки просто ужасные
mSnus
10.02.2018 11:13-2Странно, что разрабатывать дизайн интерфейса доверили людям, которые не очень разбирались ни в дизайне, ни в интерфейсах.
При том, что удобные интерфейсы вполне были к тому времени — а у этих людей получилось в графическом режиме многие вещи сделать хуже, чем было на тот момент в текстовом.
Один Проводник чего стоит до сих пор, вместе с окнами Открыть/Сохранить..
khim
10.02.2018 16:46Если бы. Я тоже проводником пользоваться не могу — жуть же жутка, но… оставленный мною FAR никто никогда ни для чего не использует.
Так что остаётся только признать, что программисты как-то по другому устроены. Врождённое это или привычка — не знаю…
musicriffstudio
10.02.2018 16:03Если уж сравнивать подходы, то неплохо бы почитать про принятие решений при разработке Вин 8.
Микрософт так же разрушил обратную совместимость в пользовательском опыте, но получилось настолько плохо, что главным преимуществом вин 10 пользователи называют возвращение кнопки Старт, ностолько им поплохело.
Бывает и так.
Смена парадигмы UI при переходе 3.11 -> 95 стал огромным успехом который кормил корпорацию десятилетие. Переход 7 -> 8 был полным провалом.khim
10.02.2018 17:07Смена парадигмы UI при переходе 3.11 -> 95 стал огромным успехом который кормил корпорацию десятилетие. Переход 7 -> 8 был полным провалом.
Угу. Однако, удивительным образом, проблема была не в методологии.
А в том простом факте, что в 1995м меньше трети семей имели компьютер (в США, в других странах ещё меньше), а в 2012м — порядка 80%.
Всё просто: радикальные инновации достаточно легко усваивают те, кто компьютер в глаза не видел — но когда их много, они «вытягивают» за собой консерваторов, а вот когда наоборот…musicriffstudio
10.02.2018 22:06+1кнопка Пуск в вин95 привлекала пользователей т.к. она удобная. Убрали кнпоку Пуск и пользователи буди недовольны. Вернули кнопку Пуск и пользователи стали довольны.
khim
11.02.2018 16:43кнопка Пуск в вин95 привлекала пользователей т.к. она удобная
Это вам сейчас кажется, что она удобная. А в 95м — было много людей, включавших Program Manager.
Убрали кнпоку Пуск и пользователи буди недовольны. Вернули кнопку Пуск и пользователи стали довольны.
А вот это, кстати, куда как более серьёзный симптом: в Windows 95 можно вернуть интерфейс Windows 3.x без установки дополнительных программ. А в Windows 8 они это сделать побоялись. То есть они ожидали что люди будут возвращать старый интерфейс…musicriffstudio
12.02.2018 00:07нет. В статье доступно написано как тестировали и по каким причинам появилась кнопка Пуск.
mSnus
12.02.2018 05:28-1В статье зато НЕ написано, что идея Start Menu была реализована ещё в DOS-овские времена, в том же VC по F2, например, или в резидентных утилитах. Как было на Apple и OS/2 в тот момент уже не очень помню, но вроде уже было там такое меню.
То, что они только к 95-й сообразили, что все же надо это сделать, и ещё и представить так, как будто они сами, с нуля это придумали — ну-ну..
khim
12.02.2018 06:19Ну вообще-то разница между меню, которое вызывается в Norton Commander'е (который как бы несколько раньше, чем VC появился, да) по F2 и Start Menu в Windows 95 — примерно как между Start Menu и тем ужасом, в которое оно превратилось в Windows 8.
Если вы о «концептуальной одинаковости» — то реакцию на Windows 8 никак объяснить нельзя. Вопрос ведь именно в том как и где оно расположено и как выглядит, а не в том, что «хорошо бы в системе иметь меню для запуска программ».mSnus
12.02.2018 13:26Я просто пользовался VC, а не NC, и мне казалось, что меню там было лучше организовано (вложенные списки или что-то в этом роде), но это неважно. Главное, что потребность в некотором Quick Launch Menu была к тому моменту очевидна, и для текстовых, и для графических интерфейсов.
А в Windows 8 попытались из Quick Launch Menu сделать нечто с блекджеком и свистелками, вот и пришлось возвращать к разумному уровню — «просто меню для быстрого запуска программ».khim
12.02.2018 14:53В большинстве систем Quick Launch Menu было доступно в ограниченные моменты времени (почти все системы на базе DOS), либо была вмонтирована в системное меню (MacOS, GEOS) — но в этом случае было важно, чтобы у всех программ меню было одно.
В Windows95 — ни то, ни другое. Меню доступно всегда и «вмонтировано» оно не в меню программ (которое тут в всех программ своё), а в taskbar (который был до Windows95 тоже, но вот кнопки «пуск» вроже не было нигде).
Да, это обьединение двух известных идей… ну так большинство изобретений строятся на базе других!
McAaron
10.02.2018 22:55Человек, который разрабатывал контейнерный виджет (control в терминах MS) для всех виндовсов и полуоси, был из IBM. Он плохо воспринял захват микрософтом активов команды OS/2, поддержанный Конгрессом, и сделал все, чтобы исходники контейнерного виджета в микрософт переданы не были. В результате, как в '95, так и в '98 этот компонент дескотопа собирался из 16-битного объектного модуля времен совместной работы IBM и Microsoft над виндовсами 3.11.
Jogger
11.02.2018 01:24Вот мне интересно — на каком этапе всё сломалось? Почему вместо тестирования дизайна стали делать абы как? Вот скажем дизайн по-умолчанию Windows XP (спасибо хоть на классический можно было переключаться) мне лично не понравился именно по той причине, которая описана в этой статье — среднее время «поиска и открытия программы, которая не видна сразу на экране» — увеличилось. И это для меня, пользователя с немалым опытом на момент выхода XP. О более поздних версиях и говорить не приходится, когда сталкиваюсь с Win7 или Win10 без установленного Classic Shell — каждый раз тихонько матерюсь про себя. Кто-то вообще этот дизайн проверял на пользователях, прежде чем выпустить? Есть у меня большие сомнения…
khim
11.02.2018 17:09Сломалось, как я уже писал выше когда база пользователей перестала расти. Вы не поверите, но для новых пользователей, без опыта работы на предыдущих версиях Windows, новые версии удобнее.
Но пока новички составляли большинство — это было важно. А сейчас большинство пользователей — это люди с опытом. А для них, вы не поверите, самый удобный интерфейс — это тот, к которому они привыкли. Как бы ни был он плох объективно.Jogger
11.02.2018 17:19Позволю себе с вами не согласится. Я переходил с windows 3.11 на windows 95, и скажу я вам, хотя это и не был привычный интерфейс, но он был удобнее, причём намного! Я уж не говорю про переход dos->windows. Да, сначала я испытывал то чувство, о котором вы говорите — было непривычно мышкой тыкать вместо горячих клавиш. Но привыкание проходит быстро, потому что — ну удобно блин! А вот переход на новый ленточный интерфейс в офисе был не таков — да, перешёл, да, пользуюсь, но как было неудобно — так и остальось неудобно. Так что ваш довод, что «самый удобный интерфейс — это тот, к которому они привыкли. Как бы ни был он плох объективно» — в корне неверен. А значит и выводы на основе него, тоже неверны. Просто интерфейсы стали объективно хуже.
khim
11.02.2018 22:26Я переходил с windows 3.11 на windows 95, и скажу я вам, хотя это и не был привычный интерфейс, но он был удобнее, причём намного!
Кому как. Мне и до сих пор интерфейс Turbo Pascal 7.0 больше импонирует, чем Intellij Idea или CLion. Перешёл в GUI только из-за того, что в текстовом режиме меньше текста на экране умещается (у меня 30" монитор).
А вот переход на новый ленточный интерфейс в офисе был не таков — да, перешёл, да, пользуюсь, но как было неудобно — так и остальось неудобно.
А вы сколько времени в офисе на работе проводите? 10% или 90%?
Потому что люди, проводящие в нём 90% времени (всякие секретари или даже маркетологи с отлуком) через какое-то время начинают его яростно защищать.
А вот маньяки вроде меня, сталкивающиеся с ним раза два-три в месяц — да, продолжают плеваться… Ну так это потому что невозможно же привыкнуть к новому интерфейсу когда везде кругом (во всяких IDE и прочих всяких условных Photoshop'ах) — старый!Jogger
11.02.2018 22:39>Мне и до сих пор интерфейс Turbo Pascal 7.0 больше импонирует, чем Intellij Idea или CLion.
Не могу сказать ничего плохого про интерфейс Turbo Pascal, но как по мне — до возможностей современных IDE ему таки далеко, так что опять же, как по мне, это шаг в сторону увеличения удобства.
>А вы сколько времени в офисе на работе проводите? 10% или 90%?
Обычно немного, но вот недавно почти год большая часть моей работы была связана именно с офисом, так получилось. Нет, защищать не начал. И опять же, по поводу того, что везде старый — непонятно. Если бы ленточный интерфейс был хорош — его бы все копировали. Но не копируют почему-то. Собственно почему, если он действительно хорош?khim
12.02.2018 01:49Если бы ленточный интерфейс был хорош — его бы все копировали. Но не копируют почему-то. Собственно почему, если он действительно хорош?
Потому что он запатентован и Microsoft тщательно бдит, чтобы его не копировали.
Chamie
12.02.2018 03:16Так они и дабл-клик в своё время умудрились запатентовать. Много ли, кого это остановило?
khim
12.02.2018 03:28Проблема в том, что дабл-клик применялся задолго до этого патента. Потому веса у этого патента не было никакого (вы, я надеюсь, знаете как это обходится в суде).
А вот ribbon'а — я до Microsoft'а нигде не видел толком. Так что…Chamie
12.02.2018 04:30А вот ribbon'а — я до Microsoft'а нигде не видел толком. Так что…
Wiki:
Although Microsoft popularized the term with a new meaning, similar tabbed layouts of controls had existed in previous software from other vendors, including 3D Studio MAX R3 and later, Adobe Dreamweaver, Borland Delphi, HotDog and Macromedia HomeSite.
Собственно, и правда, вот скриншот HotDog 7.03 (2004 года выпуска):
Обратите внимание на правый верхний угол.khim
12.02.2018 06:31Обратите внимание на правый верхний угол.
Смотрю. Пытаюсь найти совпадения по ключевым пунктам из Википедии:
— полный отказ от системного меню программы… не наблюдается.
— кнопки функций, которые нужны постоянно (отменить, повторить, сохранить), вынесены в заголовок окна… не замечено
— кнопки на лентах, в отличие от панели инструментов, могут быть разного размера… не вижу
— кнопки, которые нужны более часто, могут быть больше, а также внутри них могут располагаться образцы применяемых стилей… хде?
— кнопки объединяются в группы; редко используемые кнопки скрываются, но доступ к ним сохраняется через выпадающие меню в нижней части ленты, возле заголовка группы — screenshot этого не показывает и я сильно сомневаюсь, что тулбары HotDog 7.03 автоматически меняли размеры кнопок (так-то на скриншоте они вообще все одинаковых размеров)
Вообще же… Чем то, что там в правом верхнем углу, принципиально отличается от Delphi 1.0? Тем, что табы не снизу, а сверху? Ну да… маленький такой шажочек в сторону риббона… только без отказа от главного меню он, скорее делает интерфейс менее удобным…
Jogger
12.02.2018 10:09Мдэ. Это вообще странный ход. В то время, как все борются за унификацию интерфейсов и единообразие — собственными руками создавать на своей системе зоопарк… О чём и вопрос был — когда всё сломалось?
khim
12.02.2018 01:57Не могу сказать ничего плохого про интерфейс Turbo Pascal, но как по мне — до возможностей современных IDE ему таки далеко, так что опять же, как по мне, это шаг в сторону увеличения удобства.
Та же самая ситуация, что и с ленточным интерфейсом, на самом деле. Да, фич в новых IDE гораздо больше — вот только почему-то кода от любителей CLion'а и Idea поступает не больше, чем от любителей VIM'а и Emacs'а.
Похоже что все фичи, после банального Copy-Paste и полудюжины кнопок в отладчике — так же маргинально влияют на производительноcть, как и куча фич в MS Office.
Основная проблема в том, что последняя Turbo-Vision версия Borland C++ вышла четверть века назад и приложения под современные операционки она собирать не умеет, увы.Chamie
12.02.2018 03:17кода от любителей CLion'а и Idea поступает не больше, чем от любителей VIM'а и Emacs'а.
Откуда статистика?khim
12.02.2018 03:30Локальная. У нас в компании нет ограничений на используемую IDE и есть достаточно много людей пользующий весь зоопарк (за вычетом платформно-зависимых Visual Studio и т.п., так как Windows у нас нету).
vbif
11.02.2018 23:13Мне пару лет приходилось довольно долго работать в MSOffice. И ленточный интерфейс я так и не смог полюбить.
А вообще, я считаю, что ленточный интерфейс — это костыль, вызванный избыточной функциональностью, которую не дают удалить лишь обратная совместимость и привычки старых пользователей, например — госучреждений.gaidukav
12.02.2018 13:22Познакомился с MS Word в 1989 году, это была версия для MS Word 5.0 for DOS. У нее был достаточно удобный для опытного пользователя безмышиный интерфейс через кнопку Esc — ESC-T-C-B (formaT-Character-Bold). Затем вышла версия MS Word 5.5 for DOS со стандартным, как сейчас, меню. Так же удобно плюс стало более наглядно. Всего то нужно было переучится с «Esc» на «Alt» — клавишный вызов команд всегда будет эффективней мышки. MS Office 2007 с ленточным интерфейсом был принят «на ура» — еще более наглядный, запоминающийся и удачно сгруппированный. А контекстные ленты меню — всю жизнь ждал подобного!
MS Office 2007 — пример очень удачной смены парадигмы интерфейса. Дальше стало хуже. Стали добавлять кнопки на ленты уже не думая о их назначении. Стало красивее (моднее) но менее удобно.
Если человек знаком только с 5% функций в ворде — для него любая новая парадигма интерфейса будет в тягость. Функций оказалось слишком много, охватить, сгруппировать и запомнить их такому человеку будет очень тяжело. Надо просто понимать какая функция к какому виду работ может относится — а ленты по видам работ сгруппированы.musicriffstudio
12.02.2018 14:19офисный ленточный риббон это пример плохого, неудачного решения.
Отказ от кнопки Пуск сделал невозможной работу большинства пользователей, на этом корпоративные покупатели потеряли много денег.
Замена тулбара с меню на риббон просто ухудшила работу пользователей без катастрофических последствий. Поэтому несильно возмущаются, некоторые даже сами себя убеждают что поиск нужно пункта меню медленней всего-то в два-три раза это не смертельно.
Jogger
12.02.2018 15:00>Если человек знаком только с 5% функций в ворде — для него любая новая парадигма интерфейса будет в тягость.
Вот так одно неудачное утверждение ставит под сомнение остальные размышления. Вот он я, для которого старые версии Office, начиная с 6 кажется были удобны, хотя и я знал тогда 5% функций. А новые версии с ленточным интерфейсом — неудобны, хотя сейчас я знаком с куда большим набором возможностей. Вряд ли я такой уж уникальный человек, да и ваше утверждение не предусматривает исключений, тем более полностью противоположных.
>Надо просто понимать какая функция к какому виду работ может относится — а ленты по видам работ сгруппированы.
Для меня всё ещё непонятно, почему те или иные функции на тех или иных лентах. А вот когда было главное — было понятно, почему сгрупированно именно так а не иначе, у меня не возникало вопросов в какое меню лезть за нужной функцией, даже если я никогда ей не пользовался, а только предполагал, что она может существовать. Впрочем, возможно из этого следует интересный вывод — плохи не сами ленты, а просто группировка инструментов в этих лентах сделана через жопу. Но увы, чтобы это проверить — надо как минимум сделать альтернативную версию офис.gaidukav
12.02.2018 16:20+1Много моих коллег тоже жаловалась на ленточный интерфейс, возмущаясь что спустя целых 30 секунд при самом первом запуске ворда они не смогли понять как выполнить манипуляции по изменению структуры таблицы, или как изменить собранное оглавление…
Меня всегда удивляло — почему люди возмущаются что продукт с тысячами функций может потребовать какого то времени на освоение.
— Найди пару часов, открой свой самый сложный документ, пройдись по всем кнопкам, посмотри на реакцию системы — это если лень читать мануал.
«чтобы это проверить — надо как минимум сделать альтернативную версию офис.»
— у братьев китайцев есть замечательный продукт — WPS Office.
это бесплатная (без макросов) версия офиса, наиболее близко по функциям и по качеству к MS Office (на пару голов выше чем libre/open office).
В этом WPS Office есть возможность включить и ленту и меню — можно там сравнить. Мне и там лента показалась удобней чем меню. Единственное, что не понравилось в русском интерфейсе — не совсем удачно сделанные переводы кнопок на ленте. Нет, не подумайте, оно без ошибок, просто длинные русские слова растопыривают расстояния между кнопками.musicriffstudio
12.02.2018 17:57можно и зайца научить курить. Но зачем?
В статье описано как и проводились тесты интерфейса, как оценивалось и какие выводы были сделаны в команде разработчиков.
Так же делали сторонние специалисты по риббону. Их вывод — лажа. По совокупности свойств.
vbif
11.02.2018 23:06Сломалось, похоже, уже на 98-й, когда вместо устранения своих огрехов и привнесения опыта из других систем они взялись добавлять «революционные фичи», которые никем как следует не тестировались не только в плане UX, но и порой на банальную работоспособность.
Crazy_Pit
11.02.2018 12:16Раньше, насколько я понимаю, интерфейс делался для людей которые не понимают в компьютере. Сегодня же, для людей которые могут (не без бутылки) но разобраться.
Майкрософт делает огромные усилия чтобы я все-таки пересел на линукс.
И WIN 10 меня наверное добьет.
последней каплей было на тачпаде прокрутка вверх ДВУМЯ ПАЛЬЦАМИ. Без возможности сделать как раньше(старый драйвер только WIN 8).
пс. Новый ноутбук месяц лежит. я его не трогаю.
есть надежда что драйвер поправят.Chamie
11.02.2018 16:32Мне б ваши проблемы. У меня с апдейтом 8>10 тачпад просто отвалился, приходится мышку таскать.
vbif
11.02.2018 22:52Windows 95 в плане UI была прорывной. К сожалению, как Microsoft не старалась, ни одного прорыва уровня 95-й они совершить не смогли. Более того, многие совершенно очевидные вещи, такие как множественные рабочие столы или назначение CapsLock на переключение раскладки либо реализованы на десятки лет позже конкурентов, либо так до сих штатными средствами реализовать нельзя.
Rudolfo
12.02.2018 04:22Сколько бы я не пользовался по неволе «прогрессивным» интерфейсом Win10, всегда классический интерфейс без тем оформления в Win7 греет душу… жаль надежда на вменяемый редизайн будущих Win мертва.
KeyJoo
Было время эпохальных шедевров UI. Почему бы сейчас не сделать таких "легковесов"?