Жанр: Учеба
Дизайн пользовательского интерфейса
... при
котором количество функций ограничено, позволяет упрощать интерфейс,
но при этом требует от пользователя понимать, как из многих низко
уровневых функций "собирать" функции более сложные. Подход, при
котором помимо низкоуровневых функций есть высокоуровневые,
позволяет потенциально обеспечивать большую скорость работы (за счет
отсутствия пауз между низкоуровневыми функциями), но зато требует от
пользователя знаний о том, где эти высокоуровневые функции найти и как
с ними работать, при этом они перегружают интерфейс.
Судя по всему, людям больше нравится пользоваться низкоуровневыми
функциями, поскольку это позволяет добиваться более тонких и предска
зуемых результатов. С другой стороны, доказательств этого не так уж много
(сам факт того, что PhotoShop продается лучше, чем PhotoPaint, говорит не
так уж о многом). Таким образом, выбор подхода не слишком прост. С дру
гой стороны, остается возможность компромисса: всегда можно включить в
систему средства автоматизации, чтобы пользователи получали возмож
ность создавать (и распространять) свои метафункции, каковой подход как
раз и применен в PhotoShop. Я полагаю, что это оптимальный подход.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ
Создание
пользовательских
сценариев
Это самый веселый этап работы. Его цель - написать словесное описание
взаимодействие пользователя с системой, не конкретизируя, как именно
проходит взаимодействие, но уделяя возможно большее внимание всем
целям пользователей. Количество сценариев может быть произвольным,
главное, что они должны включать все типы задач, стоящих перед
системой, и быть сколько нибудь реалистичными. Сценарии очень удобно
различать по именам участвующих в них вымышленных персонажей.
Возвратимся к многострадальному тостеру. Это очень простая система,
поэтому для нее достаточно одного сценария.
"Виктор Х. отрезает кусок хлеба и кладет его в тостер. Он
включает тостер и ждет, пока хлеб не поджарится"
Но это просто, ради такого результата не стоит огород городить.
Обычно всё несколько сложнее. Предположим, что необходимо разра
ботать сценарии для будущей почтовой программы. Судя по всему (я не
анализировал действия пользователей, так что не уверен), для этой задачи
необходимо три сценария:
А) Елизавета Бонифациевна запускает почтовую программу.
Она включает процесс скачивания новой почты. Получив
почту, она читает все сообщения, затем часть их удаляет, а на
одно сообщение отвечает. После чего выключает почтовую
программу.
Б) Еремей Карапетович делает активным окно уже открытой
почтовой программы и включает процесс скачивания новой
почты. Получив почту, он ее читает. Одно сообщение он
пересылает другому адресату, после чего удаляет его, а еще
одно печатает. После чего переключается на другую задачу.
С) Пришло новое сообщение, и Джамиля Валериевна воспри
няла соответствующий индикатор. Она делает активным окно
почтовой программы и открывает полученное сообщение.
Она читает его, после чего перемещает его в другую папку.
После чего переключается на другую задачу.
Польза этих сценариев двояка. Во первых, они будут полезны для
последующего тестирования. Во вторых, сам факт их написания обычно
(если не всегда) приводит к лучшему пониманию устройства проектиру
емой системы, побуждая сразу же оптимизировать будущее взаимодействие.
Дело в том, что на таких сценариях очень хорошо заметны ненужные шаги,
например, в третьем сценарии гипотетическая Джамиля Валериевна после
получения индикатора не смогла сразу же открыть новое сообщение, но
должна была открыть окно системы, найти нужное сообщение, открыть его
и только тогда прочесть. Понятно, что от этих ненужных этапов смело
можно избавиться уже на этой, весьма ранней, стадии проектирования.
Прилив
вдохновения
Этот этап либо происходит сам, либо не происходит вовсе. Предыдущие
этапы дают достаточное представление о сущности создаваемой системы.
Поэтому всегда не вредно несколько задержаться на этом этапе и спросить
себя "верно ли то, что методы, которые я собираюсь избрать, самые луч
шие? Нельзя ли их сделать принципиально лучше?" Как правило, вдохно
вение, пришедшее на дальнейших этапах, обходится значительно дороже.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ
Проектирование
общей структуры
Итак, информация о будущей системе собрана. Теперь, пользуясь этой
информацией, необходимо создать общую структуру системы ("вид с высо
ты птичьего полета"), т. е. выделить отдельные функциональные блоки и
определить, как именно эти блоки связываются между собой. Под отдель
ным функциональным блоком я понимаю функцию/группу функций, свя
занных по назначению или области применения в случае программы и груп
пу функций/фрагментов информационного наполнения в случае сайта1.
Рис. 64. Типичная структура сайта (слева) и типичная структура программы. Если сайты
обычно разветвлены, в том смысле, что функции обычно размещаются в отдельных
экранах, то программы обычно имеют только один изменяющийся экран, в котором и
вызываются почти все функции. Разумеется, это не догма.
Проектирование общей структуры состоит из двух параллельно происхо
дящих процессов: выделения независимых блоков и определения связи
между ними. Если проектируется сайт, в завершении необходимо также
создать схему навигации.
Выделение
независимых блоков
Для этой работы трудно дать какие либо конкретные рекомендации,
поскольку очень многое зависит от проектируемой системы. Тем не менее,
можно c уверенностью рекомендовать избегать помещения в один блок
более трех функций, поскольку каждый блок в результирующей системе
будет заключен в отдельный экран или группу управляющих элементов.
Перегружать же интерфейс опасно.
Результатом этой работы должен быть список блоков с необходимыми
пояснениями. В качестве примера рассмотрим гипотетическую программу
ввода данных. От пользователя требуется выбрать из списка клиента (или
добавить в список нового) и указать, какие именно товары клиент заказал
(товары в список тоже можно добавлять). Несколько клиентов постоянно
что то заказывают, так что заставлять пользователя каждый раз искать в
списке такого клиента неправильно. При этом блоки разделяются
следующим образом:
. Я не различаю функции и блоки информационного наполнения из за того, что
сама по себе функция сайта - предоставлять информацию. Это значит, что с точки
зрения потребителя (не пользователя, а именно потребителя продукта) в интер
нете нет принципиальной разницы между собственно функциональными
возможностями и контентом. Например, поиск по сайту есть явная функция. Но
тогда и любое оглавление тоже есть функция сайта - а именно фильтрация инфо
рмации с определенной целью.
Основной экран Навигация между функциями
системы
Создание нового заказа
Добавление существующего товара в
заказ
А так же простой поиск товара
в списке
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ
Определение
смысловой связи
между блоками
Существует три основных вида связи между блоками. Это логическая
связь, связь по представлению пользователей и процессуальная связь.
Логическая связь определяет взаимодействие между фрагментами системы
с точки зрения разработчика (суперпользователя). Пользователи имеют
свое мнение о системе, и это мнение тоже является важным видом связи.
Наконец, процессуальная связь описывает пусть не вполне логичное, но
естественное для имеющегося процесса взаимодействие: например, логика
напрямую не приказывает людям (с трудом удержался, чтобы не написать
"пользователям") сначала знакомиться, а уж потом спать друг с другом, но
обычно получается именно так.
Все три типа взаимосвязи должны быть заранее предусмотрены при
конструировании системы. Разберем это подробнее.
Логическая связь.
С установлением логической связи между модулями
обычно проблем не возникает. Важно только помнить, что полученные
связи очень существенно влияют на навигацию в пределах системы
(особенно, когда система многооконная). Поэтому, чтобы не перегружать
интерфейс, стоит избегать как слишком уж отдельных блоков (их трудно
найти), так и блоков, связанных с большим количеством других. По моему
опыту, для одного блока оптимальным числом связей является число три.
Связь по представлению пользователей. В информационных системах
(читай - в интернете), когда необходимо гарантировать, что пользователь
найдет всю нужную ему информацию, необходимо устанавливать связи
между блоками, основываясь не только на точке зрения разработчика, но
основываясь на представлениях пользователей. Дело в том, что чуть ли не
единственный распространенный способ поиска, а именно поиск по
классификации признаков, работает только в том случае, когда пользова
тели согласны с принципами этой классификации. Большинство же
понятий однозначно классифицированы быть не могут из за наличия
слишком большого количества значимых признаков. Также проблема
состоит в том, что реальный классификационный признак может
отличаться от широко распространенного. Например, нужно как то
классифицировать съедобные растения. Помидор, который почти все
считают овощем, на самом деле ягода. Не менее тяжело признать ягодой
арбуз. Это значит, что классификация, приемлемая для ботаника, не будет
работать для всех остальных, причем обратное не менее справедливо.
В то же время, существует очень простой способ создания классифи
кации, с явной ненаучностью сочетающий не менее явную практическую
пользу. Способ этот называется карточной сортировкой, при этом его
название полностью совпадает с его сущностью. Все понятия, которые
требуется классифицировать, пишутся на бумажных карточках из расчета
"одно понятие - одна карточка". После этого группе пользователей из
целевой аудитории предлагается эти карточки рассортировать (при этом
каждый субъект получает свой набор карточек). Получившиеся кучки из
карточек нужно разобрать на составляющие и свести результаты от разных
субъектов в один способ классификации.
Сложный поиск товара
Добавление нового товара в список
Добавление существующего клиента
в заказ
А так же простой поиск клиента
в списке
Добавление нового клиента
в список
Выбор постоянного клиента
Обработка заказа Печать и его переход в папку
Исполняемые
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ
Ничего более работоспособного до сих пор человечеством не приду
мано. В то же время этот способ имеет определенные недостатки: во
первых, трудно заполучить на несколько часов представителей целевой
аудитории, а во вторых, при малом количестве субъектов результаты могут
быть сомнительны (как минимум, нужно 4 5 человек).
Процессуальная связь. Установление качественной процессуальной
связи обычно довольно трудная задача, поскольку единственным источ
ником информации является наблюдение за пользователями. В то же время
установление такой связи дело исключительно полезное. Зачем, например,
рисовать на экране сложную систему навигации, если точно известно, к
какому блоку пользователь перейдет дальше? В этом смысле зачастую оправ
дано навязывать пользователю какую либо процессуальную связь, жертвуя
удобством, зато выигрывая в скорости обучения (поскольку пользователю
приходится думать меньше). Жестко заданная связь позволяет также умень
шить количество ошибок, поскольку от пользователя при ней не требуется
спрашивать себя "не забыл ли я чего?". Хорошим примером жестко задан
ной процессуальной связи является устройство мастеров (wizards, см.
"Последовательные окна" на стр. 98), при котором пользователя
заставляют нажимать кнопку Далее.
Результат
В конце этого этапа должна получиться примерно такая схема (в примере
используется та же задача с вводом данных):
Рис. 65. Пример общей схемы (вторая версия). Прямоугольник обозначает отдельный
экран, прямоугольник со скругленными углами - область экрана, пунктирная линия -
альтернативное действие. Обратите внимание, что в этой схеме интерфейс заставляет
пользователя выполнять задачу в сугубо определенной последовательности.
Существует любопытная закономерность: чем эстетически привлекатель
ней выглядит схема (без учета цветового кодирования и веселеньких шриф
тов), тем она эффективней. Всегда надо стараться сделать схему возможно
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ
более стройной и ясной. Например, показанная схема изначально
выглядела значительно хуже. Я потратил некоторое время на её доводку,
при этом, разумеется, нашел пару ошибок.
Рис. 66. Первая версия схемы. Свободное взаимодействие человека и системы
(пользователь волен выполнять работу в произвольной последовательности).
Рисовать такие схемы очень удобно в MS Visio или подобной ей системе.
Результат, в особенности сложно выглядящий и напечатанный на листе
бумаги большого формата, очень хорошо смотрится на стене и животво
ряще действует на заказчиков и руководство (далее вы узнаете, как сделать
эту схему еще более красивой и непонятной).
Проектирование
отдельных блоков
Итак, теперь вы знаете, сколько экранов (страниц) вам нужно и что должно
происходить на каждом экране. Настало время проектировать отдельные
экраны.
Это, пожалуй, самая сложная часть работы (не считая наблюдения за
пользователями). Хуже того, она плохо поддается алгоритмизации. Именно
на этом этапе, помимо пачки бумаги с карандашом, пригодится вам содер
жимое первых двух частей этой книги. Но помимо этого есть еще две вещи,
которые вам нужно узнать: GOMS и адаптивная функциональность.
Предсказание
скорости
Часто приходится выбирать между разными вариантами реализации интер
фейса, причем отбрасывать варианты жалко, потому что они хорошие.
Можно, конечно, сделать несколько прототипов и протестировать их на
пользователях, но это довольно длительный и трудоемкий процесс. К
счастью, есть метод оценки интерфейса, позволяющий быстро выбрать
лучший вариант.
В 1983 году Кард, Моран и Ньювел создали метод оценки скорости
работы с системой, названный аббревиатурой GOMS (Goals, Operators,
Methods, and Selection Rules - цели, операторы, методы и правила их
выбора)1.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ
Идея метода очень проста: все действия пользователя можно разложить
на составляющие (например, взять мышь или передвинуть курсор).
Ограничив номенклатуру этих составляющих, можно замерить время их
выполнения на массе пользователей, после чего получить статистически
верные значения длительности этих составляющих. После чего предска
зание скорости выполнения какой либо задачи, или, вернее, выбор
наиболее эффективного решения, становится довольно простым делом -
нужно только разложить эту задачу на составляющие, после чего, зная
продолжительность каждой составляющей, всё сложить и узнать длитель
ность всего процесса. Обычно тот интерфейс лучше, при котором время
выполнения задачи меньше.
Впоследствии было разработано несколько более сложных (и точных)
вариантов этого метода, но самым распространенным всё равно является
изначальный, называемый Keystroke level Model (KLM). К сожалению, этот
вариант метода имеет определенные недостатки (что, впрочем, уравнове
шивается его простотой):
он применим в основном для предсказания действий опытных
пользователей;
он никак не учитывает ни прогресса в обучении, ни возможных
ошибок, ни степени удовлетворения пользователей;
он плохо применим при проектировании сайтов из за непредска
зуемого времени реакции системы.
Для его использования достаточно знать правила разбиения задачи на
составляющие и длительность каждой составляющей (рекомендую на
первое время повесить у себя на рабочем месте листок с цифрами).
Правила GOMS
Нажатие на клавишу клавиатуры, включая Alt, Ctrl и Shift (К): 0,28 сек
Нажатие на кнопку мыши (М): 0,1 сек
Перемещение курсора мыши (П): 1,1 сек
Разумеется, согласно закону Фитса (см. "Быстрый или точный" на
стр. 10), время, затрачиваемое на перемещение курсора, зависит как
от дистанции, так и тот размера цели. Тем не менее, это число
представляет достаточно точный компромисс.
Взятие или бросание мыши (В): 0,4 сек
Продолжительность выбора действия (Д): 1,2 сек
В среднем, за 1.2 секунды пользователь принимает решение, какое
именно действие он должен совершить на следующем шаге. Обычно
это самый сложный оператор, поскольку часто непонятно, в каких
именно местах процедуры его необходимо ставить. Например, иногда,
когда пользователь совершал искомую последовательность действий
не раз и при этом совершенно уверен в том, что общий ход процедуры
не будет отличаться от обычного, это время затрачивается только в
самом начале выполнения (далее действия будут совершаться автома
тически). С другой стороны, начинающим пользователям приходится
выбирать действие перед каждым своим шагом. Однако в большинстве
случаев достаточно считать, что это время нужно добавлять перед
всеми нажатиями, которые не приходятся на область с установленным
фокусом, перед всеми командами, инициированными мышью и после
существенных изменений изображения на экране (но и здравый смысл
тут не помешает). С практической точки зрения важнее устанавливать
этот оператор везде одинаково, нежели устанавливать его возможно
более точно.
Время реакции системы (Р): от 0,1 сек до бесконечности
Для базовых операций, таких как работа с меню, это время можно не
засчитывать, поскольку с момента создания метода производи
тельность компьютеров многократно возросла.
. Card, Moran, and Newell, "The Psychology of Human Computer Interaction",
Erlbaum . См. также David Kieras, "Using the Keystroke Level Model to Estimate
Execution Times", (доступно в интернете).
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ
Методика расчетов
Предположим, от пользователя со средним опытом требуется сохранить в
активном каталоге текущий документ под именем Опись и выйти из про
граммы. Подразумевается, что диалоговое окно сохранения файла выгля
дит следующим образом:
Рис. 67. Диалоговое окно сохранения файла в Word. Microsoft.
Эта задача состоит из следующих составляющих:
Тип
действия
Продолжи
тельность
Комментарий
Д 1,2 Пользователь анализирует свою задачу и
создает алгоритм её решения
П 1,1 Перемещение курсора к меню Файл
М 0,1 Нажатие кнопки мыши
Д 1,2 Открылось меню и пользователю необходимо
найти нужный элемент (и понять, какую именно
команду он должен выбрать: Сохранить или
Сохранить как!
)
П 1,1 Перемещение курсора к элементу меню Файл:
Сохранить как!
М 0,1 Нажатие кнопки мыши
Р 0,1 Время реакции системы - открывается
диалоговое окно сохранения файла
Д 1,2 Открылось диалоговое окно сохранения файла.
От пользователя требуется рассмотреть его и
понять, что именно ему нужно сделать
П 1,1 Перемещение курсора к полю ввода названия
файла
М 0,1 Нажатие кнопки мыши для перемещения
фокуса ввода
Д 1,2 Пользователь выдумывает файлу название (но
мы то знаем, что он лишен свободы воли и
назовет файл словом Опись)
В 0.4 Перенос руки с мыши на клавиатуру
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ
Итого на эту операцию пользователю потребуется 16,08 секунд. Предпо
ложим теперь, что ту же самую операцию выполняет продвинутый
пользователь, знающий, что если закрыть программу с помощью пикто
граммы в её титульной строке, имея несохраненный документ, то програм
ма сама предложит его записать:
К х 6 0,28 х 6 Ввод названия файла. В слове Опись пять букв,
при этом к ним добавляется нажатие на кнопку
Shift (поскольку первая буква прописная).
В 0.4 Перенос руки с клавиатуры на мышь
П 1,1 Перемещение курсора к кнопке Сохранить
М 0,1 Нажатие кнопки мыши
Р 0,1 Время реакции системы - диалоговое окно сох
ранения файла закрывается, а файл
сохраняется
Д 1,2 Пользователь вспоминает, как закрывается
программа
П 1,1 Перемещение курсора к меню Файл
М 0,1 Нажатие кнопки мыши
Д 1,2 Открылось меню, и пользователю необходимо
найти элемент Выход
М 0,1 Нажатие кнопки мыши
Р 0,1 Время реакции системы - программа
закрывается
Тип
действия
Продолжи
тельность
Комментарий
Д 1,2 Пользователь анализирует свою задачу и
создает алгоритм её решения
П 1,1 Перемещение курсора к меню элементу окна
Закрыть
М 0,1 Нажатие кнопки мыши
Р 0,1 Время реакции системы - открывается
диалоговое окно сохранения файла
Д 1,2 Открылось диалоговое окно сохранения файла.
От пользователя требуется рассмотреть его и
понять, что именно ему нужно сделать
П 1,1 Перемещение курсора к полю ввода названия
файла
М 0,1 Нажатие кнопки мыши для перемещения
фокуса ввода
Д 1,2 Пользователь выдумывает файлу название
В 0.4 Перенос руки с мыши на клавиатуру
К х 7 0,28 х 7 Ввод названия файла. В придачу к шести
изначальным нажатиям, пользователь нажимает
клавишу Enter, сразу инициируя запись файла
Тип
действия
Продолжи
тельность
Комментарий
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ
Итого 8,56 сек. Чуть ли не вдвое меньше. Второй вариант при прочих
равных условиях эффективнее. Все и раньше это знали, но зато теперь у нас
есть научное доказательство.
Адаптивная
функциональность
Помимо общей логики работы, в системе должна быть ещё одна логика,
упрощающая первую и делающую работу пользователя более простой и
естественной. Я называю эту вторую логику адаптивной функциональ
ностью.
Возьмем пульт от телевизора. Телевизор выключается только одной
кнопкой на пульте, но включается от нажатия любой кнопки. Это не следует
напрямую из логики системы, но это естественно. Когда на этаж приезжает
лифт с неавтоматическими дверями, дверь можно открыть ещё до того, как
погаснет кнопка вызова (чтобы лифт не увели). Это не вполне логично, но
естественно. Другой известный, но не всеми осознаваемый, пример: когда
Windows при входе в систему спрашивает пароль, нужно нажать
Ctrl+Alt+Delete
. В этом же диалоговом окне есть кнопка Справка, нажатие на
которую открывает ещё одно диалоговое окно, повествующее о том, как
нажать эти три клавиши. Так вот, чтобы войти в систему, это окно не нужно
закрывать, нажать Ctrl+Alt+Delete можно по прежнему. С системной точки
зрения это неправильно (почему пользователь не закрыл сначала окно с
подсказкой?), но для пользователей это естественно.
Все три примера демонстрируют готовность системы (а точнее, её
разработчиков) усложнить свою логику, чтобы упростить логику пользо
вателя. Результат: систему легче использовать. Я вообще полагаю, что
наличие адаптивной функциональности служит отличным индикатором
качества дизайна системы. Систему, которая не подстраивается под
пользователей, невозможно назвать зрелой.
Остается один вопрос: как определить, какие фрагменты и функции
системы должны быть адаптивными? Ответ: единственным решением
является детальный анализ взаимодействия пользователей с системой.
Помочь здесь может только тестирование интерфейса на пользователях.
Результат
Итак, у вас есть куча мятых бумажек, на которых нарисованы все диало
говые окна. Как можно скорее перерисуйте их на компьютере (чтобы не
растерять). При этом вы найдете несколько не замеченных ранее ошибок.
Исправьте их.
Р 0,1 Время реакции системы - диалоговое окно
сохранения файла закрывается, файл
сохраняется, после чего закрывается и
программа
Тип
действия
Продолжи
тельность
Комментарий
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ПЕРВОНАЧАЛЬНОЕ ПРОЕКТИРОВАНИЕ
Создание
глоссария
Еще в процессе проектирования полезно зафиксировать все используемые
в системе понятия. Для этого нужно просмотреть все созданные экраны и
выписать из них все уникальные понятия (например, текст с кнопок,
названия элементов меню и окон, названия режимов и т.д.). После этого к
получившемуся списку нужно добавить определения всех концепций
системы (например, книга или изображение).
Теперь этот список нужно улучшить. Для этого:
Уменьшите длину всех получившихся элементов.
Покажите этот список любому потенциальному пользователю сис
темы и спросите его, как он понимает каждый элемент. Если текст
какого то элемента воспринимается неправильно, его нужно
заменить1.
Уменьшите длину всех получившихся элементов.
Проверьте, что одно и то же понятие не называется в разных местах
по разному.
Уменьшите длину всех получившихся элементов.
Проверьте текст на совпадение стиля с официальным для выбранной
платформы (если вы делаете программу, эталоном является текст из
MS Windows).
Уменьшите длину всех получившихся элементов.
Убедитесь, что на всех командных кнопках стоят глаголы инфинитивы
(Задушить, Отравить, Выкинуть из окна).
После чего список нужно повесить на стену и стараться не менять его в
будущем.
Сбор
полной схемы
К этому моменту вы обладаете:
общей схемой системы
планами отдельных экранов
...Поділитися у соцмережах
