Жанр: Учеба
Дизайн пользовательского интерфейса
...онов) листов, жизнь становится значительно более
насыщенной. Для решения этой проблемы были придуманы (еще
библиотекарями) картотеки, содержащие основные сведения о каждом
объекте. Человек формулировал поисковый запрос, а потом тем или иным
способом отбирал подходящие карточки.
Этот метод жив и поныне, хотя, конечно, в несколько других формах.
Теперь это делается на компьютере (что действительно облегчило жизнь),
а поиск производится языком SQL и иже с ним. Я вовсе не собираюсь вас
этому учить, есть много людей, которые понимают в этом больше, чем я.
Я попробую рассказать вам иное.
Дело в том, что метод карточек хорошо справляется с поиском
конкретных данных и проверкой доступности. Со всеми остальными
видами поиска он справляется из рук вон плохо. Возьмем, например,
свободный поиск. Его цель состоит в том, чтобы найти некий паттерн,
закономерность, нечто, что в начале поиска вообще неизвестно ("найди то,
не знаю что"). Пользуясь методом карточек, приходится совершать
огромное количество поисковых запросов, держа при этом в голове
полученные ранее данные. Вероятность того, что при этом будет найдена
информация, а не данные2, невелика.
. Конечно, при условии, что нужная информация на этом листе вообще есть.
. Иерархия значений собирается следующим образом: сначала идут данные, из них
собирается информация (т. е. данные, отсортированные и подготовленные к
использованию), из информации собирается знание (информация, лишенная
несущественного), а из неё - мудрость (только общие законы без конкретики
вообще).
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ВСЯЧИНА
Но выход есть. Чтобы его найти, нужно углубиться в историю и задать
себе три вопроса. Вопрос первый, зачем появились карточки. Ответ:
потому, что мы не в состоянии охватить взглядом всю информацию. Вопрос
второй - почему в результате поиска мы вытаскиваем часть карточек из
картотеки? Опять таки потому, что мы не можем охватить их взглядом,
равно как мы не можем охватить взглядом место этих карточек в общей
куче. Вопрос третий - как нам оценить найденное в целом, не отвлекаясь на
частности? Ответ: разложить их на столе, молясь, что стола хватит.
Всё это издержки и ограничения самой концепции поиска карточек и
вытаскивания их из общей кучи. Эти ограничения имелись, пока мы не
имели ничего, кроме карточек. Теперь, когда у нас есть компьютеры, эти
ограничения пора отправить на свалку. Компьютер позволяет так визуали
зировать данные, что появляется возможность увидеть все данные (пускай
издали), видя при этом в этих данных информацию.
Т. е. при таком поиске искатель не формулирует запрос, получая на
выходе горсть записей базы данных, но задает правила визуализации всех
данных и видит, какие данные либо выбиваются из общего ряда, либо
наоборот слишком уж обычны. Это позволяет как найти нужные сведения,
так и сразу увидеть взаимосвязи и паттерны.
При этом стандартный поиск с последовательностью запросов имеет
еще один важный недостаток: он слишком абстрактен. Большинство же
людей, хоть и способно создавать сложные алгоритмы, плохо управляется
с абстракциями. Не имея ощутимых, не побоюсь слова "видимых",
промежуточных результатов, многие люди неспособны сформировать
сложный, многоступенчатый вопрос. Визуализация, напротив, позволяет
это ограничение обойти.
Но не поиском единым сильна визуализация. Она позволяет также
многократно сократить время, затрачиваемое на восприятие найденной
информации, за счет того, что визуально выраженные закономерности
воспринимаются гораздо быстрее и легче, нежели численные или
цифровые (но об этом позже).
Теперь, когда я (надеюсь) убедил вас в животворящей силе визуализации
данных, перейдем к практике.
Как визуализировать
Предположим, есть два числа: 83 и 332. Эти числа содержат в себе всю
информацию, которую из них можно тем или иным способом вычислить
(включая устройство Вселенной). Проблема состоит в том, что они никак
не помогают найти нужную информацию, например, мало кто может сразу
сказать, что второе число больше первого в четыре раза.
Рис. 19. Если показывать не только цифры, но и какие либо визуальные репрезента
ции (слева), скорость восприятия взаимосвязи между ними многократно увеличится.
Если отказаться от показа цифр (в центре), оставив только репрезентации, скорость
возрастет еще больше, но потеряется возможность точно определить искомые значе
ния (что зачастую не страшно). А если явно показать различия между значениями
(справа), либо относительные, как на иллюстрации, либо абсолютные, скорость
возрастет еще больше, более того, появится возможность передавать дробные
значения.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ВСЯЧИНА
Это делает числа негодными средствами для быстрой передачи их
реальных значений и взаимосвязи между ними. Даже тот факт, что в
десятичной системе счисления ширина числа кое как показывает размер
числа (так, понятно, что 20 меньше 200, поскольку число 200 шире1), не
делает их лучше.
Всегда выводите цифры, предназначенные для сравнения,
моноширинным шрифтом
Таким образом, отдельные числа зачастую необходимо показывать не как
последовательность цифр, но как визуальные объекты, свойства которых
тем или иным образом связаны с самим числом.
Несколько иная ситуация с текстовыми данными. Понятно, что более
менее сложный связный текст автоматически визуализировать невозможно
("Мороз и солнце!"). К счастью, обычно такой необходимости и не возни
кает. Почти всегда нужно визуализировать сравнительные и/или описа
тельные атрибуты, т. е. нет особой разницы между текстовыми и числен
ными данными.
Рассмотрим пример: в гипотетической системе складского учета есть
отчет, показывающий все товары на складе. Одним из вариантов вида этого
отчета является банальный список. Попробуем сделать его лучше. Сначала
нужно определить, зачем этот отчет нужен, и какие поля должны быть в
списке. Здесь очень многое зависит от ситуации, поэтому я не буду произ
водить попытки таксономии складов, а просто скажу: предположим, что
нам нужно облагородить столбцы Товар, Дней до порчи, Количество и
Занимаемый объем . Поехали.
Без каких либо усилий, только лишь благодаря запросу, получится при
мерно такой список (предположим, что складское место измеряется в
квадратных метрах стеллажей):
Рис. 20. Начальное состояние отчета.
Это явно можно сделать лучше2. Начнем со второго столбца - дни до
порчи. Как видим, отображаются числа, которые, как мы уже знаем,
воспринимаются "не так чтоб очень". Но прежде чем что либо менять,
нужно определить, зачем вообще этот столбец нужен. Судя по всему, его
предназначение заключается в том, чтобы сделать ненужным отчет
"Товары, которые вот вот придется выкидывать". Из этого можно сделать
два вывода:
Точное число дней или месяцев не так уж и важно. Важно, много
времени осталось до порчи или нет.
Помимо знания времени, оставшегося до порчи, важно так же
сознавать, насколько товар уже попорчен, т. е. какую часть общего
срока хранения составляет остаток.
. Это опасно тем, что трудно оценить малые различия между числами на границе
порядков ( не сильно меньше ) и в тех случаях, когда числа не целые (число
. меньше числа ).
. Вообще говоря, эту таблицу можно сделать лучше и без всякой визуализации.
Например, второй столбец, выровненный по правому краю, будет сканироваться
взглядом гораздо быстрее. Но писать об этом я не хочу, поскольку эта тема
подробно рассмотрена в литературе по коммуникационному дизайну.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ВСЯЧИНА
Эти выводы подразумевают множество возможных решений. Выбор
одного варианта в таких условиях обычно затруднен, поскольку на него
влияет много факторов и поиск компромисса довольно сложен. Однако
пойдем по порядку.
Пункт первый, количество оставшихся дней. В таблице из примера есть
определенные проблемы - имеющаяся нотация никак не учитывает того,
что измерять большие промежутки времени удобнее в неделях и месяцах.
В примере же спокойно написано "142 дня". С одной стороны это хорошо,
потому что сразу видно, что времени осталось много. С другой стороны,
трудно понять, сколько именно осталось времени. Т. е. лучше было бы писать
либо "4 мес 22 дн", либо "4 мес 3 нед 1 дн", но, с ещё одной стороны, гро
моздкость таких конструкций не позволяет надеяться, что их восприятие
будет легким и быстрым (не надо забывать и о существовании годов).
При визуализации массивов отдельных параметров важно добиться не
просто красоты и понятности отдельных блоков, но легкости прочтения
многих блоков за малое время. Популярно говоря, каждый вариант прове
ряйте на большом количестве данных, не ограничивайтесь проверкой на
одном значении.
Тут возможно несколько способов улучшения. Первый и самый эффек
тивный способ, а именно представление чисел как визуальных объектов,
здесь может и не пройти: для этого способа может потребоваться либо
слишком много места на экране (которого нет), либо слишком много
цветов (из за которых экран станет похож на новогоднюю елку и перес
танет быть читаемым). Но попытка не пытка: за пятнадцать минут я
изготовил пару вариантов решения.
Рис. 21. Два варианта визуализации времени, оставшегося до протухания товара.
Единицы времени упорядочены по продолжительности, т. е. самые темные блоки
обозначают годы (к сожалению, в первом варианте обойтись только изменением
насыщенности не удалось), а самые светлые, располагающиеся справа - дни. Первый
вариант более разборчив, зато второй занимает меньше места. Если бы можно было
использовать цветовое, а не только "световое" кодирование, разборчивость можно
было сильно повысить.
Оба варианта эксплуатируют одну и ту же идею: чем длиннее и темнее
полоска, тем больше осталось времени. Конечно, для точного определения
оставшегося времени они не слишком удобны, но, как уже было сказано, это
обычно и не нужно, тем более что численное значение всегда можно выво
дить, например, в контекстной всплывающей подсказке.
Разумеется, эти варианты имеют еще и тот недостаток, что они зани
мают много места на экране: что будет, если понадобится отобразить
продолжительность в десять лет, 11 месяцев, три недели и семь дней? Здесь,
однако, тоже есть решение: чем больше срок, тем менее актуальна точность
его отображения, например, совершенно неважно, сколько дней может
пролежать на складе мыло, если срок его хранения все равно измеряется
годами. Это позволяет отказаться от показа частностей, т. е. можно
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ВСЯЧИНА
установить правило, согласно которому у товаров, которые могут хранить
больше года, не показываются недели и дни. Также можно показывать
короткие полоски разреженными, а длинные - уплотненными. Не говоря
уж о том, что можно воспользоваться обоими способами одновременно.
Конечно, в некоторых случаях такой способ вывода чисел неприемлем и
приходится от чего то отказываться. Тем не менее, даже и отказавшись от
многого, можно облегчить восприятие этих чисел: можно, например,
визуально отображать годы, месяцы и дни, оставляя числам собственно
значения (см. рис. 22).
Рис. 22. Ещё два способа визуализации. Первый вариант визуально отображает годы,
месяцы, недели и дни, оставляя числам собственно передачу значения, что частично
позволяет воспользоваться идеей связи длины и светлоты полоски с реальным числен
ным значением. С другой стороны, числа на полосках отвлекают, а значит, замедляют
распознавание. Во втором варианте отображаются только одни единицы отсчета вре
мени, благодаря чему достигается самая большая легкость и скорость распознавания,
равно как сохраняется приемлемый размер блока. Другой разговор, что такое реше
ние может работать только в том случае, когда все товары, которые хранятся на скла
де, имеют длительности хранения одного порядка, измеряемые, например, в неделях.
Теперь о втором пункте. Важно сознавать, насколько товар уже попор
чен. Для этого есть множество стандартных индикаторов, из которых наи
более удобными являются линейный и круговой.
Рис. 23. Индикатор оставшейся доли. Левый вариант плох тем, что занимает довольно
много места, правый меньше, зато его легче прочесть обратным образом, т. е. непра
вильно. С другой стороны, с правым вариантом легче индицировать критический слу
чай, т. е. ситуацию, при которой товар вот вот испортится: надо лишь покрасить его
в красный цвет.
Выбор варианта обычно сильно зависит от контекста. Поскольку прос
транство экрана обычно весьма дорого, обычно выбирают меньший
вариант, но это не догма. Чтобы избежать путаницы, эффективнее всего
выбрать тот вариант, который не используется в том же отчете, при этом
сам вид индикатора будет подсказывать пользователю, на какой именно
столбец он смотрит.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ВСЯЧИНА
Идеально было бы придумать обобщенный индикатор, показывающий
оба смысла. К сожалению, чаще всего (и в данном случае в частности) это
невозможно, поскольку в одном индикаторе пришлось бы показывать
слишком большой объем информации. Тем не менее, прилагать усилия к
достижению этого идеала стоит вполне.
Итого, со столбцом "Дней до порчи" разобрались. Пора обновить отчет.
Предположим, что наиболее подходящим индикатором времени, оставше
гося до порчи товара, была признана полоска с треугольниками, а инди
катор оставшейся доли срока хранения было решено показывать только
тогда, когда этой доли осталось менее половины. Тогда отчет станет
выглядеть примерно так:
Рис. 24. Промежуточное состояние отчета. Улучшен только второй столбец.
Итого, со столбцом "Дней до порчи" разобрались. Следующим идет
столбец "Количество". Здесь другая проблема - единицы измерения у
разных товаров различаются, что не позволяет визуализировать "сравни
тельность" параметров. Невозможно также визуализировать количество
элементов, поскольку это количество может быть очень большим (визуали
зировать тысячу ночных горшков можно, но при этом будет затрачено чуть
ли не всё пространство экрана, а главное, явной разницы между девятью
сотнями и тысячей горшков видно не будет). Таким образом, остается лишь
возможность визуализации единиц измерения, в данном случае штукам,
тоннам и коробкам можно нарисовать пиктограммы.
Весь вопрос в том, стоит это делать или нет. Большинство людей полу
чает такое удовольствие от рисования пиктограмм, что сам вопрос необхо
димости этого рисования отходит на второй план. В то же время пикто
граммы в такой роли имеют как достоинства, так и недостатки. Недостатки
у пиктограмм следующие (более подробно о пиктограммах см. стр. 100):
им нужно учиться
если разные пиктограммы похожи друг на друга, количество случаев
неправильного распознавания неприлично возрастает
они добавляют лишний визуальный шум
на их рисование нужно время
при появлении необходимости в еще одной пиктограмме возникает
много проблем.
С другой стороны, у пиктограмм есть и достоинства: разборчивость и
эстетическая насыщенность. Проблема в том, что если недостатки совер
шенно реальны, то достоинства потенциальны: стоит эти пиктограммы
нарисовать не очень хорошо, как разборчивость и красота начисто исчезают.
Так что пользоваться пиктограммами, как индикаторами в списках, чаще
всего неэффективно. Однако, если точно известно, что количество единиц
измерения невелико, а найти их внятные репрезентации непроблематич
но, пиктограммы могут быть более чем хороши. Но случается это реже, чем
хотелось бы.
Так что идею рисования пиктограмм для этого столбца мы оставим кому
нибудь другому. Следующий столбец - "Объем". С ним c одной стороны
легко, с другой - не очень. Единица измерения всего одна, что хорошо. Зато
объем, занимаемый товаром, может быть большим, а значит, плохо визуа
лизирующимся (и пятнадцать метров стеллажей говядины визуализировать
нелегко, что уж говорить о ста метрах). Но это всё техника. Главное, напро
тив, не визуализировать параметр, а визуализировать нужную информацию
из этого параметра.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ВСЯЧИНА
И с этим то как раз не всё ясно. Что пользователь хочет узнать из чисел,
показывающих, сколько места на складе занимает товар? Если ему нужно
всего лишь узнать, много он занимает места или нет, лучше всего будет
работать уже описанный индикатор полоска. Если ему нужно точно узнать,
сколько места занимает товар, можно оставить числа. Но вполне может
оказаться и так, что ему нужно узнать, сколько процентов общей площади
склада занято товаром. В этом случае подойдет либо полоска, либо более
компактная круговая (блочная) диаграмма, либо те же числа. Основная
проблема визуализации заключается именно в определении потребностей
пользователей.
Предположим, что нужен как раз процент. Поскольку малые проценты
показываются на малюсенькой диаграмме не очень хорошо (равно как и на
полоске), числа лучше оставить, но сделать их поддерживающими. Подразу
мевается, что если пользователю нужно грубое, но быстрое знание, он смот
рит на диаграмму. Если ему нужна дополнительная точность, он переводит
взгляд на число. А чтобы число не отвлекало без нужды, лучше снизить его
визуальную насыщенность, проще говоря, выводить число процентов не
черным, а серым цветом. Единственно надо обратить внимание, что боль
шинство товаров будут занимать на складе сравнительно небольшое место.
Это значит, что индикатор надо оптимизировать не для показа всех возмож
ных значений, а для показа их части (при этом части самой неудобной для
показа). Например, так:
Рис. 25. Вариант вывода процентных значений. Обратите внимание, что этот вариант
плох отсутствием универсальности: пользуясь им, нельзя показать значения, большие
8% (графику придется заменять голыми цифрами). С другой стороны, с практической
точки зрения это может быть и не страшно - не так уж много складов, которые до
отказа забиты чем то одним.
Обратите внимание, что процентное значение вполне может оказаться
дробным. В нашем случае от идеи визуализации процента придется отка
заться. Искомый отчет в качестве полигона графического показа про
центов не подходит: говядина занимает пятнадцать складских мест, а
ночные горшки всего три, причем есть товары и на четыре и на пять мест.
Установить процентные соотношения в таких условиях возможно, но
вероятность того, что эти проценты будут "слишком уж дробные" (напри
мер, 0.273), чтобы их можно было визуализировать, слишком велика. Не
надо забывать, что в нашей таблице только четыре строки, а в жизни строк
может быть и двести и триста. Кто знает, какие параметры там могут ока
заться? Но показ процентов, в общем то, экзотичен. Почти всегда нужно
просто показывать, большое значение или, наоборот, маленькое. В таких
условиях обычная полоска из блоков справляется на ура.
Таким образом, в результате отчет может выглядеть примерно так:
Рис. 26. Финальное состояние отчета.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ВСЯЧИНА
Что гораздо лучше, поскольку более разборчиво и, пожалуй, эстетичней.
Осталось сказать одно: эта глава в большей степени демонстрирует алго
ритм мышления, нежели рекомендует какие либо конкретные действия. Я
совершенно уверен, что при достаточном прилежании вам удастся изобрес
ти значительно лучшие индикаторы, равно как и использовать существую
щие лучше, нежели это получается у меня. Здесь всё в ваших руках. И ещё.
Поскольку большая сила подразумевает большую ответственность, никогда
не пытайтесь визуализировать то, что визуализировать не надо. Ни к чему
хорошему это не приведет.
Теперь о больших объемах данных. Поскольку эта тема более сложна и
менее нужна (точнее - реже нужна в интерфейсе), нежели визуализация
малого объема, сюда вместилось только краткое введение в проблему.
Визуализация большого объема данных сильно отличается от визуализа
ции малого объема. Если при малом объеме данных нужно показывать сами
эти данные, то при большом объеме нужно показывать распределение
значений. С одной стороны, это проще, поскольку самих данных нет, есть
только распределение. С другой стороны, каждому критерию необходима
либо своя ось, либо иной метод выделения.
Рис. 27. Пример крайне удачной системы визуализации данных. Эта карта показывает
состояние торгов на бирже NYSE. Карта поделена на зоны, такие как Здравоохранение
и Энергетика. Каждый прямоугольник показывает состояние акции одного эмитента.
Размер прямоугольника показывает объем торгов конкретными акциями за текущий
день, цвет - изменение стоимости акций (синие теряют в стоимости, желтые
приобретают). SmartMoney http://www.smartmoney.com/maps/
Если осей немного, всё просто. Распределение эффективнее всего
строить в виде либо двумерной карты, либо в виде псевдо трехмерного
пространства. Как правило, трехмерность не очень эффективна, поскольку
она требует от пользователя долго искать наиболее удобный ракурс (более
того, чтобы увидеть эту трехмерность, карту нужно некоторое время
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ВСЯЧИНА
вращать). С другой стороны, эти ненужные по сути дела действия могут
приносить пользователям удовольствие, так что потеря времени будет
скомпенсирована.
Читателям, заинтересовавшимся этой темой, настоятельно рекомендую,
во первых, прочесть уже упоминавшиеся книги Эдварда Тафта, во вторых,
почерпнуть вдохновение в любом пакете математического анализа и
статистики (например, Mathematica или Mathcad).
Навигация
В любой системе, использующей единое устройство вывода (читай - экран)
для любых задач, качество навигации является важной составляющей:
поскольку все физические атрибуты системы фактически отсутствуют, их
необходимо передавать визуалом экрана. Наличие в системе развитой
навигации здорово облегчает процесс обучения работе с системой,
поскольку при визуальной навигационной системе не нужно помнить
контекст своих действий (как я сюда попал? что я хотел сделать?),
поскольку этот контекст сам по себе показывается на экране.
Разработка навигационной системы есть сложная и большая работа,
требующая большого количества знаний, навыков и талантов. К сожале
нию, эта книга не способна дать вам ни первого, ни второго, ни третьего,
тем более что тема навигации хорошо проработана в литературе. Тем не
менее, здесь всё таки рассматриваются две темы: первая слишком часто
забывается, а вторая недостаточно хорошо проработана в существующей
литературе.
О навигации в пределах документа см. "Полосы прокрутки
и их альтернатива" на стр. 91.
Цели навигации
Любая система навигации обязана выполнять несколько функций, а именно
показывать пользователям:
Где они находятся сейчас. Для понятия "не знать своё теперешнее
положение" есть два коротких синонима: заблудиться и потеряться.
Ни то, ни другое не приносит удовольствия.
Куда они вообще могут переместиться. Невозможность узнать, что
можно сделать дальше, приводит к тому, что ничего не делается.
Где они уже побывали. Невозможность определить пройденный
маршрут приводит к тому, что пользователи попадают туда, куда
попасть они не хотят (они тут уже были), что является человеческой
ошибкой.
Куда им разумно пойти. В большинстве случаев пользователям
удобнее не думать самим о том, что им нужно сделать, но восполь
зоваться готовым вариантом действия, а сбереженные ресурсы
потратить на что либо иное.
С какого именно экрана (страницы) они пришли. Точно знать
направление своего движения полезно, поскольку это помогает
поддерживать контекст действий.
При этом от навигационной системы требуется множество дополни
тельных свойств, таких как эстетическая привлекательность, малый размер
и так далее (эти свойства не вполне интерфейсные, поэтому здесь они не
разбираются).
Так вот, очень важно сделать навигационную систему, которая выполняет
максимум этих задач, просто потому, что невыполнение части из них делает
систему неполноценной. Всякий раз, создавая навигационную систему,
нужно вкладывать в неё максимальное количество ответов.
Битва против меню
Почти любая навигационная система является меню. Это имеет множество
достоинств, но также и некоторые недостатки.
Во первых, меню ограничивает возможность выбора только определен
ным набором вариантов. Это хорошо, поскольку позволяет исключить
заведомо неправильные действия. Но в навигационных системах это
оказывается нехорошо: взамен свободного передвижения по системе
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ВСЯЧИНА
пользователям приходится ходить по заранее проделанным для них тро
пинкам, т. е. степень свободы пользователей сокращается. Иногда это
полезно, но чаще - нет.
Рис. 28. Примеры навигационных систем, которые принципиально действуют одинако
во, но выглядят различно и выполняют разные цели. Сверху приведены четыре после
довательных экрана сайта фирмы Relevare (читаются слева направо), в которых
навигационная система жестко задана один раз. Снизу экран системы Antarcti.ca,
позволяющей перемещаться по всем сайтам из каталога Yahoo. Единые принципы
устройства навигационных систем могут быть применены многими разными путями,
главное - провести анализ требований к навигационной системе и подойти к делу
творчески. Relevare, Antarcti.ca
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ВСЯЧИНА
Во вторых, любое многоуровневое меню страдает от каскадных ошибок
(см. стр. 80). Способы борьбы с ними существуют, но от этих ошибок лучше
бы вообще избавиться. Сделать же это можно, только изъяв либо само
меню, либо потребность его использовать.
В третьих, большинство меню не способно показать пользователям, куда
им разумно пойти. Это не значит, что меню плохо, но только то, что нужно
как то усиливать навигацию помимо меню.
Единственным универсальным (и работоспособным) алг
...Поділитися у соцмережах
