В комментариях к моим стенаниям про средства прототипирования один из читателей признался, что пользуется Balsamic Mockups. Примерно год назад я рассматривал этот вариант и он мне не показался; но время идет, так что дай, думаю, попробую снова, более внимательно. Специально для таких случаев Balsamiq раздает бесплатную лицензию в обмен на публичную рецензию, так что вот, пишу.

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

А теперь плохое.

1. Очень неудобная панель для выбора контроллеров — неоправданно большая, замусоренная бессмысленными превьюшками (обычный список был бы быстрее в работе). Проблема частично компенсируется возможностью вставки объекта по названию, но в наших условиях она требует переключать раскладку, что нивелирует скорость.

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

3. Нет шаблонных страниц/объектов; претензия может показаться неважной, но правда в том, что значительная часть пользы от продукта начисто испаряется, стоит только попытаться нарисовать (к примеру) окно с вкладками. Замечу, что польза от прототипа, как правило, растет вместе с объемом запрототипированного (хотя бы потому, что прототипированием дешевле всего решать проблемы неединообразия; это ещё не самая большая польза, кстати). Сейчас же Mockups подходит для прототипирования лишь чего-то очень маленького.

4. Ужасно раздражает, что панелька свойств контроллера все время мигает (то исчезает, то появляется, то становится полупрозрачной).

5. Невыразимо уродливо. Как объясняют разработчики «We don’t currently have any short-term plans to support other skins in Mockups. The problem with a polished look and feel is that it gets easily confused for a semi-finished product, discouraging discussion about the structure of the application / web site.» Им виднее, конечно, но могли бы выбрать и другой путь, например, нарисовать контроллеры мультяшно раздутыми, как, например, в интерфейсе Free Realms — спутать прототип с готовым интерфейсом было бы столь же трудно, а эстетическое чувство не страдало бы.

Верю, что проблемы 1-4 разработчики смогут решить за год-полтора; тогда рассмотрю Mockups снова. Пока пользоваться не буду, потому что медленно, уродливо и (как правило) не особо эффективно.

NB: Обязан отметить следующее — я умею очень быстро прототипировать в InDesign, что, по понятным причинам, делает мое мнение о Balsamic Mockups несколько одностронним (это как сравнивать дешевую и простую тачку с дорогим и сложным грузовиком; конечно, грузовик лучше — если он у вас есть и вы умеете его водить; а если нет?). В принципе, если всё, что вам нужно, это раз в несколько недель набросать эскиз интерфейса и дальше его обсуждать, Mockups вполне разумная инвестиция (переделывать при обсуждении быстрее, чем перерисовывать на бумаге). С другой стороны, интерфейс продукта ещё не настолько отполированный под скорость, как хотелось бы, так что при такой периодичности работы научиться быстро оперировать Mockups несколько затруднительно.

Очень интересная статья профессионального Flash-разработчика о том, почему у Flash проблемы на  мобильных устройствах (уж на что Adobe и Apple взаимно любят друг друга, а все равно Flash отсутствует на iPhone и конца этому не видно). Кратко: большинство Flash-изделий используют on-hover как самостоятельный и незаменимый метод взаимодействия; on-hover, в свою очередь, невозможен на современных устройствах с тактильным вводом (его эмуляция хоть и возможна, но убога до безобразия).

Я, откровенно говоря, испытываю в данном случае лишь злорадство. Мне нравится Flash (и ещё больше нравится Air, которая суть Java от людей, не испорченных enterprise-программированием), но всё же — флашеры сами виноваты в том, что получилось. Использовать интерфейсные методы только потому что (а) так можно и (б) другие так не делают — статистически верный способ получить нечто убогое.

Вот вполне реальный сценарий. Есть сайт, на сайте есть анимированное меню. В начале работы в голове дизайнера что-то щёлкает и дизайнер решает — повешу анимацию не на on-click (боже, как это скучно и старо!), а на on-hover. С мышью все работает; с пальцем не работает ничего.

А теперь главный вопрос: чем кнопка на on-hover работает лучше, чем кнопка на on-click? Я вижу только один ответ — теоретически, on-hover быстрее, т.к. не тратится время на стимуляцию.  Но это ускорение настолько мало, что оно не может быть оценено неинструментальными методами (и даже инструментальными может быть измерено лишь с трудом). Так зачем вообще было связываться с on-hover?

Больше того, on-hover не очень хорош даже и как способ подсказки о том, что объект является кликабельным. Если приходится использовать для этой цели on-hover, значит, объект нарисован недостаточно хорошо, т.е. по его облику недостаточно заметно, что объект кликабелен (не могу не отметить, впрочем, что если кликабельность и так видна, on-hover в качестве приправы таки добавит прелести).

Именно поэтому у нас уже довольно давно запрещено проектировать в рассчете на on-hover. На том стоим!

PS. Почти десять лет назад заметка Нильсена Flash: 99% Bad вызвала непомерную бурю возмущения у дизайнеров. Свежо до сих пор.

За последние два года появилось огромное количество средств прототипирования интерфейсов (Protoshare, Jumpchart, Mockingbird, Justproto, inPreso Screens — только часть великолепия). Лично меня это вгоняет в тоску (письменно отказываюсь от ответственности — меня вгоняет в тоску абсолютно всё). В данном случае тоскую по следующим причинам:

• Невооруженным взглядом заметно, что конкуренции слишком много. Конкуренция — хорошая штука, поскольку побуждает разработчиков быстрее улучшать свой продукт. Однако когда конкуренции настолько много, денежный поток от потребителей размывается по слишком большому количеству разработчиков, так что у каждого конкретного разработчика оказывается меньше денег на развитие. Я предпочел бы иметь здесь трех-четырех сильных конкурентов, нежели 20 слабых. К счастью, ближайшие годы выкинут неудачников; но пока остается только ждать.
• Столь же невооруженным взглядом видно, что большинство этих продуктов возникли, когда соответствующие разработчики увидели потенциальную нишу для своих (доселе законсервированных или попросту незрелых) заготовок для Великого Редактора. Интенция, по-видимому, здесь “раз уж не получается нормальный редактор, сделаем убожество и назовем его средством прототипирования — для прототипирования же много не нужно, правда, ребята?”. Что на выходе, то и на входе.
• Принцип тождества среды с сообщением никто не отменял. Уродливый инструмент непроизвольно продуцирует уродливые результаты. В Visio труднее (важно: труднее, а не вовсе невозможно) сделать неуродливый прототип, чем в InDesign — не столько из-за различий в функциональности, сколько потому, что InDesign спроектирован дизайнерами для дизайнеров, а Visio маркетоидами для маркетоидов. Visio же — шедевр по сравнению с Axure. Уродливое же Axure незамедлительно оказывается не лишенным приятности, стоит лишь бросить взгляд на (к примеру) Balsamiq Mockups. Да, прототип не должен выглядеть как готовый интерфейс, но не настолько же!
• Большинство (не все) этих средств прототипирования не решают никакой реальной проблемы. Сделать прототип легко, для это не нужно никакое специальное средство, подойдет и творческое использование имеющихся инструментов (мы, например, используем для этого InDesign, для которого это, мягко говоря, непрофильное применение). Гораздо труднее прототипировать лучше, либо больше, чем так. Например, Axure из прототипа автоматически делает убогий, но хоть какой-то бумажный документ, на который можно поставить подпись (ура, InDesign делает это не хуже). Protoshare идет дальше, там акцент сделан не на само прототипирование, а на обсуждение новых версий и формализацию процесса утверждения (InDesign здесь просто пасует). Большинство же новых средств ничего подобного не может, вдобавок, будучи почти сплошь веб-приложениями, работают очень медленно. Простор, кстати сказать, здесь очень широкий — можно автоматически анализировать интерфейс на ошибки, строить списки исключительных ситуаций (которые надо будет отработать), готовить специальный прототип под сценарии тестирования и т.п.

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

Adobe Photoshop исполнилось 20 лет. Хорошее время вспомнить тот зимний день 1994ого года, когда я впервые установил (пиратскую, разумеется) третью версию на компьютер – и увидел палитру слоев.

До этого Photoshop был одной из многих программ; так, Aldus Photostyler делал всё то же, но работал быстрее. С появлением же слоев Photoshop стал единственным. Работать по-старому, т.е. сохранять отдельно все версии монтажа, стало совершенно бессмысленно. Потом уже, в версии 5, в Photoshop появилась множественная отмена, но это уже не воспринималось как революционное изменение (все равно проще хранить промежуточные версии в отдельных слоях).

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

Одно из самых унылых занятий в профессии — проектирование структуры навигации по сайту, т.е. раскладка страниц по папочкам/признакам (то, что называлось информационной архитектурой). С одной стороны, интересно, потому что сложно. С другой стороны — скушно, потому что очень уж однообразно. Хуже, однако другое — начиная с определенного размера, структура уже не может быть хорошей; в лучшем случае, навигацию удается сделать разве что неплохой:

• Некоторые решения хорошо смотрятся на структуре (например, очень широкие меню), но плохо работают в реальном интерфейсе и/или их невозможно адекватно нарисовать (те же очень широкие меню).
• В больших структурах обязательно получается ассиметрия, в которой одни ветви гораздо больше (шире и/или глубже) других. В таких случаях приходится нормализовывать навигацию (т.е. конкретное навигационное решение) под определенную глубину/ширину. Вуаля — все ветви прочих размеров становятся немного корявыми, например, в меню, оптимизированное под 7 элементов в одном месте впихнуто целых 11.
• Деление объектов по смыслу (сиречь таксономия) начинает сбоить, если есть значимые объекты с несколькими значимыми признаками одновременно (на практике таких объектов всегда полно). Хрестоматийный пример — помидор, который и овощ и ягода одновременно (а порой и фрукт). Отказаться же от обязательной таксономии — значит отказаться от фактически стандартной и всеми ожидаемой иерархической навигации.

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

Вот как это работает:

Как видите, это обычный сайт, но:

• Первые два уровня меню не показываются всё время; вместо этого они скрыты, пока пользователь не откроет меню сам.
• Навигация внутри разделов всюду немного разная: в каждом разделе она такая, как нужно для этого конкретного раздела, а не такая, чтобы всюду было одинаково.

Понятно, что решение не без недостатков:

• Теоретически, меню медленное, поскольку пользователям надо сделать лишний клик, чтобы перейти в другую ветвь. Однако эта медлительность остается, по-сути, только теоретической. Во-первых, закон Хика никто не отменял, так что по крайней мере огромное меню первого уровня не замедляет пользователей все время. Во-вторых, что ещё важнее, процент посетителей, которым за время сессии нужно несколько ветвей, обычно совершенно ничтожен.
• Если кнопка, открывающая меню, не вопиет «Щелкни меня!» такая навигация будет работать плохо. Нарисовать такую кнопку — большая и сложная творческая задача. Еще более сложная и творческая задача — помешать т.н. стейкхолдерам сайта заботливо окружить её баннерами, на фоне которых даже самая вопиющая кнопка перестанет быть заметной для невооруженного взгляда.
• Большое количество посетителей приходят на сайт из поисковиков — сразу на внутреннюю страницу. Меню со скрытым первым уровнем не может сказать пользователям «Смотри, чего тут ещё есть!»; с другой стороны, даже и «нормальное» меню справляется с этой задачей довольно плохо.

Зато достоинства, достоинства-то какие:

• Быстро работает. Ненужная почти в любой отдельный момент времени навигация не показыватся, экономя время хотя бы за счет уменьшения прокрутки (+ закон Хика).
• Меню первого уровня можно сделать более широким (соответственно, не особо глубоким), а широкое меню работает почти всегда гораздо лучше узкого (соответственно, глубокого).
• Не обязательно тратить время и усилия на нормализацию структуры и оформления навигации. В разных ветвях навигация разная — ну и ладушки.
• При появлении новых разделов первого уровня (что неизбежно случается), не нужно сильно перетряхивать остальной сайт.
• Поскольку показывать меню первого уровня можно теперь нелинейно, становится возможным джакстапозицией акцентировать и структурировать отдельные элементы в нем. Более того, всю основную навигацию можно аккуратно сложить в одном блоке (например, на сайте Novell во фрейм с меню изящно всунули поиск по сайту, а могли еще и выбор языка).
• При большом желании можно делать навигацию глубже, чем обычно практически доступно. Так, пятый уровень — ни ни, хотя бы потому, что показывать пять уровней навигации просто негде, не хватает пикселей. Если же отрезать первых два уровня, этот пятый уровень, формально оставась пятым, становится третьим.
• (Организационное!) Особо ретивому стейкодержателю можно выделить ветку, в которой он сможет резвиться, как ему пожелается — не гадя в остальных ветвях.

Когда-то такая система навигации была применена на сайте Microsoft (вот один из сайтов, сохранивший еще старый дизайн; значимая ссылка All Microsoft Sites в правом верхнем углу). Работало это не очень хорошо, но всё-таки работало (учитывая размер сайта, этому следует безмерно удивляться). Теперь же, когда у нас есть слои, анимация и всяческий Аякс это может работать гораздо лучше (собственно, пример Novell доказывает, что работает; вряд ли они это решение не тестировали).

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

В своём выступлении на ВДЮ2009 я, среди прочего, говорил о том, что с эвристиками Нильсена лучше дела не иметь. Тогда у меня не было времени сделать одно очень важное уточнение, поэтому делаю его только сейчас (лучше поздно, чем никогда):

Эвристики Якоба Нильсена исключительно хороши и глубоки.

Вот список его эвристик в моём (корявом) переводе:

Интерфейс защищает пользователя от совершения ошибок • Совпадение поведения/объектов с внекомпьютерным окружением: единые термины, концепции, конвенции • Читаемость/заметность текущего состояния системы • Совместимость со стандартами и единообразие • Эстетика и лапидарность дизайна и подачи важных для пользователя сведений • Интерфейс помогает пользователю опознать совершенные им ошибки и исправить их • Справка: быстрая, краткая, продуктивная • Отсутствие необходимости вспоминать • Свобода совершения ошибок пользователем • Дополнительная гибкость для опытных/профессиональных пользователей.

Не заметили ничего примечательного? Я вот замечаю — из десяти эвристик посвящены отработке ошибок целых три (на первый взгляд, непропорционально много):

Интерфейс защищает пользователя от совершения ошибок • Интерфейс помогает пользователю опознать совершенные им ошибки и исправить их • Свобода совершения ошибок пользователем.

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

Фокус вот в чём. Люди (в т.ч. и пользователи) учатся через ошибки. Не знаешь, что делать? Нажимаешь не кнопку (или идешь по ссылке и т.п.), которая, скорее всего, сделает то, что нужно. Вполне возможно, что ошибешься, но в хорошем интерфейсе сможешь отменить своё действие и сделать ещё несколько попыток.

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

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

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

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

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

PS. Кветч.

PPS. Обновление. Разбили бачок от унитаза и диско-шар. Праздник, я считаю, удался.

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

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

Специальные термины возникают не сами по себе, а по причине нехватки старых

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

Например, понятно, что интерфейс должен быть хорошим. Но каким должен быть интерфейс, чтобы быть хорошим? Очевидно, что эта хорошесть не может определяться через себя же — фразы «Мы сделали хороший интерфейс, который хороший» и «Чтобы быть хорошим, этому интерфейсу не хватает хорошести» глубоки, но, пожалуй, глубоки чересчур.

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

NB: Между прочим, если понимать юзабилити-специалиста как человека, который специалист в том, чтобы повышать юзабилити, то, действительно, никакой разницы между юзабилити-специалистом и эргономистом нет (вообще говоря, юзабилити и эргономику разделять нет никаких причин; понятие юзабилити есть результат и достижение дисциплины human factors, каковое есть просто американское название эргономики). Это одна из причин, по которой мне более близко другое понимание термина «юзабилити-специалист» — как человека, который специалист в проведении юзабилити-тестирования — для специалиста по повышению юзабилити термин «эргономист» подходит вполне. Т.е. какой-либо термин нужен, при этом, чтобы быть работоспособным, он должен обладать несколькими свойствами:

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

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

Конечно, «юзабилити» — всего лишь слово; предполагать, что оно как-то влияет на реальность, значит расписываться в веру в магию. Кто угодно волен писать об интерфейсах, пользуясь любыми словами (например, постулируя, что хороший интерфейс есть интерфейс с высокой степенью трансмогрификации) — но, чтобы быть корректно понятым, нужно в начале дать определение этой трансмогрификации. Если в начале не указать особо, что под юзабилити автор понимает нечто отличное от ISOшного значения, будет как минимум неудобно.

Если тебе не нужен термин, не факт, что он не нужен кому-либо еще

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

Например, в человеческой стопе 26 костей, каждая уникальная как-то называется. Насколько я знаю, хирургов при обучении заставляют все эти названия (больше 200 костей + невесть сколько суставов и мышц) учить — но лично мне не тепло и не холодно от того, что я не знаю точно ни одного из них. Это — не моя работа; я имею право (а точнее — возможность) быть здесь некомпетентным. Если мне в руки попадется медицинский журнал, я, возможно, испытаю сожаление о том, что ничего в нём не понимаю, но пока Асклепий миловал, читаю одну поэзию. Главное же — я не обижаюсь на врачей, которые зачем-то напридумывали названий, вместо того, чтобы честно называть все кости «ну вот эта хреновинка такая треугольная с дырочкой вот здесь (показывает)». Не обижаюсь, потому что предполагаю, что им зачем-то все эти термины нужны.

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

Незнание чужой профессиональной терминологии не грех, пока её не употребляешь сам

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

Лично я ничего не знаю про устройство автомобиля, но зато знаю, что где-то внутри у него сидит дроссель, о котором я тоже ничего не знаю. Если я осмелею настолько, что буду считать вообще все детали дросселями или называть дросселем какую-либо другую авточасть (кардан, к примеру) — моё появление на автосервисе будет вызывать много радости и смеха. Если же я на автосервисе появляться не буду, зато в периодической печати (читай — в интернетах) буду активно пользоваться термином «дроссель» как универсальным — смеха будет меньше, а плача больше.

Так что реакции Паши Сушкова удивляться не след!

Даже плохой термин выживет, пока не появится замены

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

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

27 ноября 2009
Уважаемые покупатели! В продажу поступил цифровой фотоаппарат от фирмы SONY. В разделе «Цифровое Фото/Видео» в подразделе Фотоаппараты цифровые вы сможете ознакомиться с такой новинкой как:

26 ноября 2009
Уважаемые покупатели! В продажу поступил цифровой фотоаппарат от фирмы Panasonic. В разделе «Цифровое Фото/Видео» в подразделе Фотоаппараты цифровые вы сможете ознакомиться с такой новинкой как:

25 ноября 2009
Уважаемые покупатели! В продажу поступил MP3-плеер от фирмы SAMSUNG. В разделе «Мультимедиа» в подразделе MP3-плееры вы сможете ознакомиться с такой новинкой как:

24 ноября 2009
Уважаемые покупатели! В продажу поступили GPS навигаторы от фирмы Shturmann. В разделе GPSвы сможете ознакомиться с такими новинками как:

23 ноября 2009
Уважаемые покупатели! В продажу поступил цифровой фотоаппарат от фирмы SAMSUNG. В разделе «Цифровое Фото/Видео» в подразделе Фотоаппараты цифровые вы сможете ознакомиться с такой новинкой как:

По-моему, восхитительно.

Прочитайте эти предложения:

• «Юзабилити этой программы стоит улучшить».
• «У этого сайта недостаточно хорошее юзабилити».
• «Это совершенно неюзабильный интерфейс».

Если по прочтении:

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

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

Определение по ISO 9241-11 гласит:

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

Usability — the extent to which a product can be used by specified users to achieve specified goals with efficiency, effectiveness and satisfaction in a specified context of use.

Простого взгляда на этот текст достаточно, чтобы понять, что:

1. Юзабилити — это степень нескольких показателей.
Юзабилити не может быть хорошим или плохим. Юзабилити нельзя улучшить или ухудшить. Юзабилити можно повысить или понизить.

2. Не существует никакой общей степени юзабилити.
Термин содержит в себе метрики, которые вполне могут противоречить друг другу (например, скорость обучения и скорость работы не могут быть равновысокими).

3. Юзабилити — не синоним слов «удобство», «дружелюбность», «интуитивность», «понятность» и им подобных.
Возьмем для примера «дружелюбность». По определению Ушакова это:

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

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

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

P.S: пользуясь случаем выражаю глубокую признательность Роману Настенко. Без его замечательных статей (и их почитателей) мир был бы куда скучнее.