Дизайн Anatol Alizar
25 435

Как создавался интерфейс Windows 95

Материал сотрудника Microsoft Кента Салливана о процессе и результатах проектирования нового пользовательского интерфейса для версии Windows 1995 года.

В закладки

Перевод опубликован в издании «Хабрахабр».

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

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

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

Итеративная разработка на практике

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

Процесс итеративной разработки Windows 95

При достижении достаточного уровня кодирования и уточнения проект изучали более широко, со временем, начинали проводить «проверку боем». Незначительные проблемы в юзабилити тут же исправляются до выпуска готового продукта.

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

Этап изучения

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

Мы унаследовали от них значительную часть фундаментального интерфейса пользователя и интерфейсов взаимодействия: рабочий стол, трей (область уведомлений), контекстные меню, трёхмерный вид и прочее). Мы также получили данные из службы поддержки о двадцати главных проблемах пользователей Windows 3.1.

Ниже показан прототип дизайна рабочего стола Windows 95, юзабилити которого мы тестировали в январе 1993 года. Дизайн основан на Cairo и включает в себя первый проход исправления некоторых известных проблем Windows 3.1 (в частности, управления окнами).

Ранняя версия рабочего стола Windows 95 (с выносками для ясности)

Верхняя иконка File Cabinet открывала вид в стиле менеджера файлов Windows 3.1 (слева иерархия, справа контент). Вторая иконка World показывала элементы в сети. Третья иконка Programs — это папка с другими папками, полными ссылок на программы, установленные в системе.

Вдоль нижней части экрана располагается системный трей с тремя кнопками (System, Find и Help) и областью хранения файлов. Другая иконка Wastebasket представляет собой контейнер удалённых файлов.

Исследования юзабилити этого прототипа рабочего стола так же проводились в лаборатории юзабилити Microsoft, как и последующие тесты. Мы провели типичные итеративные исследования юзабилити. От трёх до четырёх пользователей, каждый из которых представлял отдельную интересующую группу (обычно начинающие и средние пользователи Windows 3.1), выполняли задачи на прототипе.

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

Первые результаты

Юзабилити-тестирование этого прототипа принесло много результатов, в том числе несколько неожиданных:

  • Начинающих и многих средних пользователей путал двухпанельный интерфейс менеджера файлов. Они были не уверены в связи между панелями и в том, как переходить в другие папки. Новичков часто поражала визуальная сложность менеджера файлов — и они испытывали базовые проблемы, например, непонимание возможности существования одних папок внутри других папок. Многих пользователей смущала иконка Parent Folder. Она появлялась в каждой папке и выглядела как файл, хотя на самом деле это элемент навигации для выхода на предыдущий уровень иерархии.
File Cabinet, ранняя версия менеджера файловой системы
  • Пользователей всех уровней квалификации смущала папка Programs. Мы думали, что наличие на рабочем столе такой папки с другими папками и ссылками на программы внутри станет естественным для пользователей Windows 3.1, привыкших к менеджеру программ, и в то же время её будет относительно просто освоить новичкам. Мы ошибались. Новички быстро заблудились во всех папках (в отличие от File Cabinet, здесь каждая папка открывалась в новом окне), а у других пользователей возникло много проблем с попытками понять, видят они реальную файловую систему и её файлы или просто ссылки на настоящие файлы.
  • У пользователей возникли значительные сложности с определением, для чего нужна каждая из трёх кнопок в трее, а позже возникли трудности с запоминанием, куда идти для выполнения конкретной команды, поскольку в определённых контекстах их функции пересекались (например, для поиска чего-то в разделе помощи Help нажать Find или Help?).

Сравнение с Windows 3.1

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

Затем провели несколько лабораторных исследований, сравнивая Windows 3.1 и Windows 95 с учётом этих двадцати задач. Мы также провели собеседования с профессиональными преподавателями 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, но определённо должно быть привлекательным для пользователей любого уровня, потенциально по разным причинам.

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

Этап быстрых итераций

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

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

Эволюция процесса спецификаций интерфейса пользователя

Хотя мы с самого начала выбрали процесс итеративной разработки, у нас остался один элемент каскадного метода: монолитная конструкция спецификаций дизайна (спеки). В первые несколько месяцев спеки стремительно росли и отражали сотни человеко-часов работы. Но из-за проблем, обнаруженных во время пользовательского тестирования, задокументированный в спеках дизайн внезапно устарел.

Предстояло принять важное решение: потратить недели на изменение спецификаций для отражения новых идей и потерять ценное время, необходимое для итераций, или прекратить обновление спецификаций и позволить прототипам и коду выполнять роль «живых» спеков.

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

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

Последовало много «коридорных» разговоров, которые продолжались на протяжении всего проекта. Чтобы все заинтересованные стороны всегда были в курсе актуального дизайна, мы организовали следующие мероприятия:

  • Регулярные собрания сотрудников дизайнерского отдела. На еженедельных (иногда чаще) собраниях каждый сверял свою работу с общим проектом, и все обсуждали, как работа каждого сотрудника может повлиять на других.
  • Рассылка графиков и результатов тестирования юзабилити по электронной почте. Сотрудники дизайнерской группы получали регулярные уведомления о предстоящих тестах юзабилити и результатах завершённых тестов, чтобы быть в курсе, как продвигается дизайн.
  • Формальное отслеживание проблем юзабилити. С проектом масштаба Windows 95 мы понимали, что требуется стандартный способ записи выявленных проблем юзабилити, когда и как они должны быть исправлены — а затем закрывать тикеты после исправления проблемы и успешной проверки на пользователях. Этот процесс более детально описывается в главе «Отслеживание открытых тикетов».
  • Регулярные презентации дизайна для внешних групп. По мере продвижения проекта всё больше и больше групп (внутри и за пределами Microsoft) хотели посмотреть, что мы делаем, так что мы проводили такие презентации. Они эффективнее, чем рассылка документов, потому что презентации проще поддерживать в актуальном состоянии, и они позволяют своевременно обсуждать дизайн.

Отдельный интерфейс пользователя для новичков

Первым важным изменением дизайна, которое мы рассмотрели, стал отдельный интерфейс («оболочка») для начинающих пользователей. Дизайн быстро набросали в Visual Basic и протестировали в лаборатории юзабилити.

Частичный вид отдельной оболочки для новичков

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

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

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

Примеры быстрой итерации

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

1. Запуск программ: меню «Старт». Хотя мы отказались от идеи отдельной оболочки для новичков, но сохранили её самые полезные функции: доступ по однократному щелчку, хорошая различимость, взаимодействие через меню.

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

Ниже показан окончательный вариант меню «Старт» и подменю «Программы». Это меню служит не только для запуска программ, но сочетает в себе и другие функции. Все они открываются нажатием одной кнопки.

Меню «Старт» и подменю «Программы»

2. Управление окнами: панель задач. Наша первая идея по улучшению управления окнами была не очень амбициозной, но мы не знали, сколько работы понадобится для решения проблемы. Первой идеей было изменить внешний вид свёрнутых окон из иконок на «плитки».

Свёрнутые окна в виде «плиток»

Мы надеялись, что проблему можно решить, если свёрнутые окна будут отличаться на вид и иметь больший размер. Мы ошиблись. Пользователи испытывали практически такие же затруднения, как в случае с Windows 3.1.

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

Поняв это, мы быстро пришли к идее панели задач. У каждой задачи есть собственное место на панели, которая отображается поверх всех окон. Тестирование на пользователях показало, что это приемлемое решение проблемы.

Панель задач с кнопкой «Старт», программами и часами

3. Работа с файлами: диалоги «Открыть» и «Сохранить как...». Информация из службы поддержки и результаты лабораторных тестов показали, что новички и средние пользователи испытывают много проблем с системными диалогами открытия и сохранения файлов.

Диалоговое окно открытия файла в Windows 3.1

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

Диалоговое окно открытия файла в Windows 95

4. Печать: мастер установки. Информация из службы поддержки говорила о том, что установка и конфигурация принтера является главной причиной звонков от пользователей Windows 3.1. Многие проблемы проистекают из интерфейса установки принтера.

Основное диалоговое окно установки принтера в Windows 3.1

Найти нужный принтер сложно, потому что все они находятся в одном длинном списке. Для выбора порта, особенно в сетевом окружении, требовалось спуститься на четыре-пять уровней с нестандартными и сложными вариантами выбора.

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

Экран мастера добавления принтера в Windows 95

5. Помощь: диалог поиска и вкладка с индексом. Лабораторное тестирование Windows 3.1 показало, что пользователи испытывают проблемы с поисковом диалогом в справочном разделе.

Диалог поиска по справочной информации в Windows 3.1

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

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

Вкладка индекса в справочном разделе Windows 95

Этап тонкой настройки

Когда мы спроектировали все основные области продукта, то поняли, что нужно сделать шаг назад и посмотреть, как все кусочки складываются вместе. Для этого были проведены итоговые лабораторные тесты и длительное исследование с реальными пользователями.

  • Итоговые лабораторные тесты. Используя двадцать основных задач из рыночного исследования мы провели комплексное тестирование всего интерфейса пользователя. Пользователям разного уровня подготовки предлагали изоморфные наборы задач для измерения скорости обучения и уровня использования после освоения. Мы сравнивали эффективность работы с базовым уровнем Windows 3.1. После проведения собственного пилотного теста для выяснения возможных проблем с процедурой окончательное тестирование осуществил посторонний подрядчик, так что эти результаты можно использовать в официальных документах. Результаты оказались весьма обнадёживающими — пользователи завершали выполнение задач примерно вдвое быстрее, чем в Windows 3.1 и в 20 из 21 категорий показали большее удовлетворение работой Windows 95.
  • Длительное полевое исследование. Двадцать человек приняли участие в полевом исследовании бета-версии Windows 95. Сначала мы изучали, как они работают в Windows 3.1, а затем наблюдали за установкой Windows 95. Дополнительные тесты проводились через неделю и через месяц для проверки уровня обучения и произошедших изменений. Мы не нашли никаких серьёзных пробелов в юзабилити продукта, но подкорректировали формулировки в интерфейсе и темах справочного раздела. Некоторые из собранных данных впоследствии использовались при планировании следующей версии Windows, а также сотрудниками службы поддержки, в том числе краткий перечень тем, которые можно ожидать от звонков в службу поддержки.

Отслеживание открытых тикетов

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

Образец записи в базе данных с тикетами

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

Статус текущих проблем обновлялся — тикет или оставался открытым, если требовалась дополнительная работа, или он закрывался в случае решения проблемы. Каждые несколько недель я выпускал ряд отчётов с распечаткой всех оставшихся проблем и раздавал их сотрудникам. Мы встречались для обсуждения текущего прогресса и решали, когда изменённый дизайн будет готов для тестирования на пользователях.

Образец отчёта в базе данных с тикетами

Отчёт

Как и в любом проекте, практика — критерий истины, так что приведу некоторые сводные статистические данные.

Лабораторные тесты

Мы провели 64 этапа лабораторного тестирования с 560 пользователями. 50% из них имели средний опыт работы с Windows 3.1; остальные — это новички, продвинутые пользователи и пользователи других операционных систем. Эти цифры не включают тестирование компонентов, поступивших от других команд (почтовый клиент Exchange, программа для отправки факсов и прочее). Тестирование этих компонентов прошло примерно в 25 этапов с участием 175 человек.

Выявление проблем

Для ключевых компонентов оболочки в ходе проекта в базу данных были внесены 699 отчётов по юзабилити. Из них 148 положительных результатов и 551 проблема. Проблемам присваивался один из трёх уровней серьёзности.

  1. Пользователи не могут продолжать выполнение задачи или серии задач.
  2. Пользователи испытывают значительные сложности с выполнением задачи или серии задач, но всё-таки способны продолжить её выполнение.
  3. Пользователи испытывают незначительные сложности с выполнением задачи или серии задач.

Из 551 выявленной проблемы 15% получили первый уровень, 43% — второй уровень и 42% — третий уровень.

Резолюции по проблемам

В ходе проекта использовалось пять резолюций по проблемам:

  • Решено. Команда исправила проблему и успешно испытала решение на пользователях.
  • Запланировано. Команда разработала исправление проблемы, и мы ожидаем его реализации.
  • Под вопросом. Команда не уверена, нужно ли решать проблему, или не знает, возможно ли её решение.
  • Частично. Команда разработала решение, и оно протестировано на пользователях с удовлетворительными результатами, но всё равно остаются некоторые вопросы.
  • Не решено. Команда не собирается решать проблему.

К завершению проекта все проблемы с резолюциями «запланировано» или «под вопросом» перешли в одну из других категорий. 81% проблем завершились успешным решением, 8% остались с резолюцией «частично», а 11% остались нерешёнными. В большинстве случаев причиной отсутствия решения стали технические ограничения, а иногда — ограничения рабочего графика.

Выводы

Для многих сотрудников отдела проект Windows 95 стал первым опытом итеративной разработки, тестирования юзабилити и отслеживания проблем.

Итеративная разработка

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

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

Группа настолько привыкла к итерациям дизайна, что, когда ближе к окончанию проекта пришлось выполнить некоторые последние дизайнерские работы, нам была неприятна спешка. Не было времени для итераций. Мы чувствовали разочарование, что нет времени для тонкой настройки и повторного тестирования дизайна.

Процесс спецификации

Подход «прототип или код являются спецификациями» в целом работал хорошо, хотя со временем мы естественным образом уточнили процедуру. Например, все прототипы конкретного релиза начали выкладывать в открытый доступ (для всех сотрудников) с инструкциями по их установке и запуску.

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

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

Тестирование юзабилити

Хотя дизайн и итеративные тесты позволили создать отдельные функции, но именно тестирование юзабилити всего продукта целиком стало ключом для аккуратной подгонки отдельных частей друг к другу. Как уже упоминалось, на основании собранных данных мы произвели изменения в формулировке интерфейса пользователя и темах справочного раздела. Если бы мы не провели то тестирование, продукт не выглядел бы таким эффективным и приятным в работе.

Отслеживание проблем

Высокий процент исправленных проблем юзабилити не стал бы возможен без интенсивной самоотдачи всех членов команды. База для отслеживания проблем повысила управляемость процесса и гарантировала, что проблемы не ускользнут из вида. Однако исправления не были бы сделаны, если бы команда не верила в создание продукта максимально возможного качества.

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

Все тикеты с пометками «частично» и «не решено» перенесли в новую базу. Они стали начальной точкой для проектирования следующей версии Windows. Специалисты по планированию и дизайнеры ежедневно работали с этой информацией, а также анализировали отчёты из службы поддержки.

#дизайн

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Anatol Alizar", "author_type": "self", "tags": ["\u0434\u0438\u0437\u0430\u0439\u043d"], "comments": 70, "likes": 67, "favorites": 1, "is_advertisement": false, "subsite_label": "design", "id": 33217, "is_wide": true, "is_ugc": true, "date": "Tue, 13 Feb 2018 11:10:59 +0300" }
{ "id": 33217, "author_id": 141078, "diff_limit": 1000, "urls": {"diff":"\/comments\/33217\/get","add":"\/comments\/33217\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/33217"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199114 }

70 комментариев 70 комм.

Популярные

По порядку

Написать комментарий...
10

Кнопка «Пуск» гениальное решение тогда в дизайне, да и сейчас (в рамках единого управления).

Ответить
0

А где она в iOS и андроидах? Чем она лучше рабочего стола/домашнего экрана?

Ответить

Комментарий удален

0

Раньше в настройки сети можно было попасть из системного трея. Вы про Windows 10?

Ответить

Комментарий удален

0

В статье ведь обычные люди с обычными потребностями, поэтому мне было интересно узнать зачем им кнопка Пуск, т.к. сам им никогда не пользовался.
Разве отсутствие Пуска в современных мобильных ОС не показатель ненужности?
А ты вообще про VPN.

Ответить

Комментарий удален

0

Ок, Роман, а как Вы запустите, например Notepad, Calculator, Control Panel - Power options - в Windows XP? Можно Start - Run, можно вроде Windows Key + R, но это не всегда удобно.
...
В конце концов, как запустите доп. софтинку в программном пакете, которая редко нужна?

Ответить
0

Через контекстное меню рабочего стола создам текстовый файл.
Калькулятор можно держать на столе.
Настройки питания всегда в трее были.
Ба, да это же современные мобильные ОС, получается.

Ответить
1

Для PC, до выхода смарт устройств

Ответить
0

Шторка уведомлений?

Ответить
1

Это, скорее, системный трей.

Ответить
0

В Андроидах она есть. Очень похожа на ту, что была в Win '95 по поведению. В iOS модель, скорее, Win 3.1, с менеджером программ на рабочем столе.

Ответить
10

Классная статья, спасибо, вернулся в воспоминания с интересом.

Только мало, приносите ещё такого, пожалуйста! :)

Ответить

Комментарий удален

0

Метро - это не погоня за трендами, это сам тренд и есть. Уже после него к флэту подтянулся весь веб, и даже ios. Единственное что осталось - OSX, оно до сих пор выглядит как говно динозавра со своим сквевоморфизмом.

Ответить

Комментарий удален

0

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

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

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

Ответить

Комментарий удален

0

хаха, все конечно же не так.
"красиво" - это твоя субъективная оценка.
"трудоемко" - ну ломом яму копать тоже трудоемко.

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

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

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

Ответить

Комментарий удален

0

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

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

А вот софт для массового пользователя без рюшечек просто не взлетит.

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

Ответить
8

Ура, статья не про биткойн наконец)

Ответить
1

Как приятно читать, когда люди собрались вместе чтобы работать по плану. И спокойно по нему двигались, без интервью, инвесторов, посевов, акселераторов ... Ло-ги-ка, декомпозиция сложных задач в простые, разумное ограничение перфекционизма, ориентация на реальную аппаратную базу и совместимость с парком старой техники и уже вышедших приложений ... блин, раньше и трава была зеленее, и небо на заставке в Винде голубее :)

Ответить
4

Про ограничение перфекционизма - не согласен. Сейчас даже Apple стала делать good enough software (т.е. "и так сойдет" :) ) . А умудриться сделать софт, который тормозит и лагает на современном железе делая то же что и 10 лет назад сейчас уже все приловчились.

Ответить
3

Сергей, вот есть (было) у дедов всяких теплое такое чувство к какому-нибудь старому грузовику, на котором они учились водить, и потом на кусок хлеба с маслом зарабатывали - ну там грузоперевозками или ремонтами. Они на нём каждую детальку знают. Он для них как родной.
Для меня Windows 95 - совпала со многими вещами в жизни, и прежде всего изменением имиджа "компьютерщика" в обществе, с шизанутого радиолюбителя, повернутого на детальках и кнопочках ... на кхм, точно такого же, но вдруг всем нужного и очень полезного.
И вот как-то связано у меня это тесно именно с Win 3.1, Win 95/98, уж простите

Ответить
2

Я и не говорил что win95 плохая, я на ней тоже сидел, а программировать еще с DOS начинал. :) Я про то, что сейчас качество софта (как и железа) сильно упало и это считается нормой. Так что немного перфекционизма как раз не помешало бы.

Ответить
1

Я Вас вроде бы понял. Только хотел и свою позицию объяснить ... За любым "нелогичным" мужским решением стоит определенный набор данных, при котором мы с Вами скорее всего поступили бы также ...

Про ограничение перфекционизма - не согласен

Это - с чем Вы не согласны, остается, пожалуй единственным способом _в принципе_ видеть новые версии софта.
Любая операционка сейчас - это диплодок (спец. посмотрел виде динозавра) - голова которого уже в новых гаджетах, тело (основная масса пользователей) еще в гаджетах 1-2 поколенря назад, и длинный хвост совместимости с прежними моделями. Которых, например у Apple уже невообразимо много (слишком много).
 
Вы наверное знаете о знаменитых игровых проектах, которые делались годами, и потом останавливались - оставляя только несколько скриншотов. Там люди старались изо всех сил сделать идеально, а аппаратная база менялась, можно было сделать еще лучше ... потом выходил конкурирующий проект, потом бета-тестирование подсказывало возможное улучшение, потом портился баланс ... и в итоге :(

Ответить
–8

Только вот пользователи как были тугие, так и остались. Дерево папок в боковой панели их смущало, понимаешь, и вложенность папок друг в друга они не могли уяснить. Это ж до чего надо быть дубовым, чтобы не увидеть в этом живые аналогии с оглавлением книги и конвертами внутри папки внутри ящика внутри шкафа? Я понимаю, что есть и более тяжёлые случаи, но ориентироваться на такое в разработке — это жесть.

Ответить
9

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

Ответить
0

Во-первых, спасибо, что сопроводили "минус" текстовым комментарием. Это правда радует.
Тут нет ошибки, которую допустили авторы. Сложность организации хранения данных — это _объективная_ реальность. Даже хранение фоточек требует какой-то рубрикации (если говорить именно о мало-мальски системном хранении, а не о мимолётном потоке фоточепухи в ленте). Так что сложность инструментов соответствует сложности выполняемых задач. И упрощение инструментов тут приводит лишь к скрытию проблем, а не к их устранению. Так что есть аккуратно смысл приучать большинство к росту, а не идти на поводу у него, подсказывать пользователю более продвинутые подходы наряду с примитивными, а не ограничивать его выбор примитивом. К счастью, в данном конкретном случае на факторы лишь обратили внимание, но не дали ходу вытекающим из них упрощениям. Но есть много случаев, где история пошла иначе.

Ответить
1

Не понимаю почему вот это не стало популярным. Видимо, Apple запатентовала.
Пробовали?

Ответить
4

Вот! Это как раз отличная иллюстрация к моим словам про пропорциональность инструментов задачам и приучение к росту.
Я с Маками редко сталкиваюсь (не хейтер =) , просто так сложилось), и когда увидел в Finder этот режим столбцов, был просто в восторге. Мне самому, как хардкорному пользователю Total Commander, этот режим не так что бы сильно по душе, но на сколько я понимаю, что нужно массовому пользователю, чтобы работать эффективно без лишних сложностей, то этот вариант — самое оно, разрабы UX сработали на славу.

Ответить
0

Это какой-то страх божий.

Ответить
1

Почему же?
Моментальная навигация, всегда знаешь где находишься, никакие окна не перекрывают другие окна. Я бы хотел себе такой рабочий стол на Винде.

Ответить
0

Связка Windows + Office + Internet Explorer = решала большую часть компьютерных задач почти до середины 2000-ных. Да, не идеальное, да кажется сложноватой по сравнению с iOs. Да, "одно лишнее движение, и Вы отец" - т.е. системные вещи не сильно спрятаны от пользователя.
Но как бы компьютеризация в нашей стране напрямую связана с доступностью линии продуктов MS. Это те самые "наркотики, которые сперва дадут попробовать бесплатно, а потом Вы не сможете от них отказаться" - которыми пугали в детстве :)

Ответить
0

Если пользователю непонятно, значит команда плохо проработала. Пользователь прав всегда , потому что он платит деньги. Компьютер на то и компьютер, чтобы разруливать сложные кейсы и выдавать очень простой ui. Называть личные фотографии пользователей фоточепухой - мягко говоря - оскорбительно по отношению ко всем пользователям.

Ответить
0

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

Ответить
0

Может быть, мсье, дело не во мне?;)

Ответить
0

Обиженные пользователи, которые "всегда правы", минусуют. Такими их маркетологи и продакт-менеджеры вырастили, что поделать.

Ответить
0

Вы говорите с позиций пользователя, имеющего многолетний опыт использования компьютеров. Представьте человека, который впервые сел за Виндовс. Там весь интерфейс подчинён квадратно-гнездовой логике айтишников, а не естественной логике 90% людей.

Ответить
0

Как Вы, уверен, заметили, я начал с рассмотрения момента, касающегося дерева папок и вложенности папок. Это вообще не является вопросом интерфейса. Это абстракция, которую человек либо понимает, либо ему надо немного напрячься для её понимания, любо он обречён всегда везде все вещи/объекты хранить в одной несистематизированной куче, будь то бумажные документы, одежда или компьютерные файлы.

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

Ответить
3

Хорошая статья. Помню как поставил Windows 95 на свой 486DX40 8 MB 340 hdd. Поставил, потом снес и вернул 3.1+Dasboard который имел аналогию пуск несколько виртуальных окон и кучу приятностей радующих глаз. Потом в 1996-м снова поставил 95 OSR2. В 1997 продал 486DX и купил K6-200 64 MB и сел на NT4.0 рабочую станцию. Вот это была ОС!

Ответить
1

Читаю и плачу ). Вспоминаю свой 386 с 4 мегабайтами оперативки, винтом на167 Мб и Windows 3.11 for Workgroup. Ээх.

Ответить
0

Помню на работе 386DX33 4 МБ памяти и 170 винты. MS Word 6.0 под 3.11 и 1 страницу с формулами почти не тянул. А 95-ка загружалась на этом ровно 10 минут... А мне надо было книгу писать в MS Word 6. Пришлось 486DX40 c 8 МБ покупать. Более 1 года писал книгу. Постоянно у 3.1 заканчивались ресурсы (памяти 8 Мб хватало), а вот % свободных ресурсов после нескольких формул на странице убывал катастрофически. Приходилось набирать не более 3-х страниц с формулами в 1 файле. Но тогда я думал, что когда будет 64 ГБ оперативки, то MS Word оживет...

Ответить
0

K6-200 64 MB - достаточно мажорненько, хоть и не пень2

Ответить
0

AMD бяка! Только и исключительно Intel :)
 
А уж разгоняльщики c охладильщиками и замеряльщики по тестам - реально достали - в какой-то момент заполонили все компьютерные журналы, FIDO эхи, и компьютерные форумы :(

Ответить
1

Да нормальный был на тот момент в лице К6 конкурент Pentium MMX. Хотя Pentium MMX был не плох. Я сам проводил измерения тактов каждого процессора тогда для оптимизации алгоритмов и математического описания под новые процессоры. Диссертация такая была. А королем разгона, если память не изменяет, был Celeron 300A...

Ответить
0

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

Ответить
0

Да не особо и мажорно. Помню как сейчас 205 долларов отдал за К6-200, бросил в процессор в карман, сел в маршрутку, приехал - а ножки погнулись... К счастью всё аккуратно выпрямил. Память 2 модуля SDRAM по 32 ГБ, а вот плата вроде FIC с чипсетом от VIA тогда это был чипсет популярен так как кэшировал более 64 МБ памяти...

Ответить
0

К процам (даже OEM), такие типа поддончиков же шли, из прозрачного пластика. Так-то $200 - это была месячная зарплата entry level job в Питере, и бросать ее в карман не глядя могли только те люди, кто на маршрутках не ездил :)

Ответить
2

установка и конфигурация принтера является главной причиной звонков от пользователей Windows 3.1. Многие проблемы проистекают из интерфейса установки принтера.

За 25 лет в этом плане так ничего не изменилось.

Ответить
0

Сотни моделей принтеров - уже к моменту выхода Win 3.1. Тысячи - к выходу Win XP. И что Вас удивляет?

Ответить
1

Лично я в виндах старше ХП принтеры не настраивал, но меня поразило то, насколько просто это делается в макоси по сравнению с даже более молодыми версиями винды.
Как-то в офис ставили принтер (уже не помню модель, ноунейм какой-то), у меня к макбуку и по USB и по сети всё автоматом скачалось и настроилось (ну, почти автоматом — в настройках отобразился принтер, нажал "добавить" и всё), у коллеги же на винде (то ли 8, то ли 10) заебались дрова искать для него :)
Ну и с другими принтерами тоже проще было — Samsung SCX-3200, например, в винде тоже автоматом не ставится.

Хотя с настройками принтера, походу, у всех ОС есть косяки — на днях настраивал Kyocera ECOSYS M5521cdn на макоси по сети, он в процессе настройки ушёл в сон, и после этого вообще нивкакую не хотел цепляться по AirPrint, только через PostScript. Пришлось немного поплясать с бубном.

Ответить
0

У меня лет 6 Samsung SCX-3205. Уже и забыл, когда установочным диском пользовался. Если вообще пользовался :))

Ответить
0

Абсолютно упоротый принтер, честно говоря. Я на нём Wi-Fi один раз в жизни смог настроить, больше вообще не получалось :)

Ответить
0

Артем, мне сложно Вам ответить предметно, т.к. это будет долго :) Вкратце, внедрение Plug-and-Play в Windows потребовало создания огромной библиотеки старого железа (включая давно неиспользуемое hardware), но за это время вышло много нового - и так оно и продолжается дальше. На принтера и видеокарты да, все время приходится ставить "свои" драйвера ... В этом отношении Mac, как мне кажется, всегда поддерживал гораздо меньше разных устройств, и парные наклеечки Windows XP/7/10 /// Mac , они ведь появились не так давно на железках - меньше 10 лет назад. До этого буквально _надо было узнавать_ подойдет ли конкретный девайс к использованию с Макинтош.
 
В Dos/Windows в прошлом часто требовалось - ручная настройка (джамперами) IRQ/DMA для модема/звуковухи, переключение LPT порта на другой режим (ECP/EPP/Regular) в BIOS, перевод COM порта в другой режим, чтобы заработал какой-нибудь хитрый адаптер ...
Теперь из этого осталось переключение принтера в режим "градации серого" или "графика" при печати, например, некоторых странных PDF документов.
 
Я о чем собственно - если проблема была с Виндами, ее решение уже с конца 90-х находилось в англоязычном Internet. А если проблема была с Mac, то проще было позвонить в местный сервисный центр (очень отзывчивые люди в Амос СПб, кстати), потому что Mac прятал все доп. настройки от пользователя, и добраться до них было не очень легко :(

То есть именно Ваша ситуация - сетевой принтер добавляется влет, но или не печатает, или печатает не так. Я в свое время разбирался с этим в одной организации, куда часто приезжали люди с разными ноутами - на Винде-то как раз - накатил драйвер и все заработало - а на Mac - принтер добавился, но ему как-то не так ... в итоге они закупали еще 2 принтера, чтобы подсоединять к Mac временных сотрудников напрямую - это помогло.

Ответить
1

Вспомнилось, как в win98 пытался удалить папку windows 😃 а на win95 в игрушки гоняли

Ответить
1

Да, именно, для игрушек она и была :)
Либо DOS => Dos4GW => и играть либо Windows 3.1 => работать.
А потом все смешалось в доме Мелкомягких :)

Ответить
0

Ностальгия)) Автору спасибо. Побольше таких статей, современная молодежь и не узнает что такое Windows 95, 98)) Вот тоже интересные факты http://cl-box.ru/fakti_o_pc/ Автор напиши подобную статью по чему-нибудь отсюда, буду рад почитать)

Ответить
0

Хотя бы заголовок статьи вставили бы - или кратую аннотацию. Так-то на непонятную ссылку не очень хочется нажимать ... ну просто совет - пояснения писать, что там.

Ответить
1

Искал в статье красивую историю про создание кнопки Пуск... на мой взгляд это самое главное изменение в дизайне вин 95

Ответить
0

+1 Провальную идею сумели преобразовать в удачную.
По-моему, свидетельство того, что кнопка Пуск родилась из отдельного "интерфейса для новичков" - это самое ценное в этой статье.

Ответить
1

Вспомнил - прослезился) После ДОСа, так другая вселенная)

Ответить
0

Ну так-то была Win 3.1 / 3.11 и переход на Windows 95 был довольно растянут по времени .. все же железа требовал совсем другого.

Ответить

Комментарий удален

0

Полная копия с хабра

Ответить
0

Через одно место.

Ответить
0

По поводу дизайна, то этот интерфейс стал "классическим" для Windows, но далеко не был революционным и многие его элементы были заимствованы. Например, подобие кнопки "Start" существовало в дашборде для W3.1/3.11от сторонних разработчиков (в свою очередь те черпали идеи в NeXTSTEP). Ну и стоит сказать, что за год до W95 вышла OS/2 Warp3, между интерфейсами этих ОС можно найти много общего -- вплоть до дефолтного цвета рабочего стола.

Ответить

Комментарий удален

0

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Голосовой помощник выкупил
компанию-создателя
Подписаться на push-уведомления