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

1. Нелапидарные интерфейсы медленнее лапидарных — они хуже/медленнее читаются/сканируются взглядом. Поскольку большинство интерфейсов делаются в рассчете на скорость, лапидарность выигрывает (конечно, есть исключения, например, презентационные или рекламные сайты, в которых оптимизировать подачу под скорость нет особого смысла).
2. Для каждого сюжета существует свой минимальный размер в пикселях. Если пикселей недостаточно, хорошо нарисовать сюжет не получится в принципе, даже если стилизовать/упростить его по самое нехочу. Увы, интерфейсы, в которых есть лишние пикселы, довольно редки — красоту (в рамках «чтобы богато было!») наводить хочется, да негде. Конечно, есть исключения, например, сам я ещё в 2002 году умудрился нарисовать модель паровоза Ов-5109 размером в один пиксель)

Обе эти причины имеют технический лимит — экраны, а точнее, их разрешение. Всего лет десять назад нормой было 72 точки на дюйм; для сравнения — глянцевые журналы печатают в России с разрешением 175 линий (полиграфическая линия не тождественна пикселям, но, как и пиксель, определяет физический размер самой мелкой возможной цветной детали изображения). Сейчас ситуация побогаче — большинство внешних копьютерных мониторов имеют разрешение около 90 пикселей на дюйм, некоторые ноутбуки 120-130. Бывает и больше — мониторы многих дорогих коммуникаторов имеют экраны с разрешением 150+ пикселей. Например, у iPhone уже несколько лет экраны имеют разрешение 160 пикселей; при этом размере пиксели ещё видны, но нужно специально приглядываться, чтобы их разглядеть.

У последней же модели, iPhone 4, количество пикселей удвоено по обеим сторонам (их теперь в 4 раза больше, чем раньше) — разрешение скакнуло до 326 точек на дюйм. Теперь увидеть отдельный пиксель можно разве что случайно (например, пиксель бракованный), да и то такие пиксели не сильно отличаются от пылинки на экране.

Это открывает невиданные ранее возможности:

• Первая причина лапидарности интерфейсов (скорость считывания) несколько ослабла. Например, в ОС iPhone исторически используется Гельветика. Оставляя за скобками эстетические соображения, этот выбор был понятен и разумен — Гельветика прекрасно читается с экрана, благо лишних деталей в этом шрифте нет (отсюда некоторая скучность Гельветики). Однако с новым разрешением этот выбор — лишь один из очень многих возможных. Теперь можно использовать почти все гарнитуры (кроме разве что самых оголтелых в своей акцидентности) — да, это скажется на читабельности, но не сильно. Чем, например, хуже такая или такая? Ну хорошо, я знаю, чем именно хуже. Но зато сколько радости!
• Вторая причина ослабела ровно в два раза по арифметике и гораздо сильнее — субъективно. Там где раньше приходилось рисовать пиктограмму 32 на 32 пикселя, стало можно рисовать 64 на 64. Любой рисовальщик пиктограмм подтвердит, что это две очень большие разницы.

Суммируя, впервые в интерфейсостроении стало возможно не избегать мелких деталей в оформлении. Где были прямые линии — стало можно рисовать волнистые. Где угол скругления кнопочки выбирался из расчета качества растеризации — стало можно выбирать его произвольно. Где помещались только одна тень и один рефлекс — стало возможным рисовать и тень и все рефлексы (а ещё бликов накидать). И т.д.

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

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

Я предрекаю как раз ар-деко (как минимум, первые годы). Как раз столько рюшечек, сколько надо.

По производственной необходимости (заказчик заставил) поработал в Adobe Fireworks. Раньше я Fireworks только изучал на предмет использования в качестве средства прототипирования (вердикт был «Уступает InDesign»), так что моё знание было чисто теоретическим. То ли дело теперь! Вот результаты, сжато (работал еще в CS4):

1. На работу, которую в Photoshop я ранее выполнял за неделю, ушло 2 дня.
2. Без многих шаблонных страниц работать плохо.

Вердикт: Я и раньше не понимал, как вебдизайнеры работают в Photoshop, который суть программа для ретуши и использование которого для дизайна не менее нецелевое использование, нежели использование InDesign в том же качестве. А теперь и тем более не понимаю. Цифры говорят сами за себя — в Fireworks работа с текстом и слоями реализована лучше, чем в Photoshop и всего лишь это дало более чем двукратный прирост производительности (работает Fireworks, что смешно, медленнее, чем Photoshop или InDesign).

В то же время, пока шаблонные страницы, оформление текста, таблицы и текстовые стили в Fireworks столь рудиментарны (и ещё виснет, зараза, и работает медленно!), остаёмся в InDesign.

Так что если вы каждый день рисуете сайты в Photoshop, очень рекомендую перестать. И, если вам важны отдельные пиксели (т.е. растеризация кривых и, в особенности, прямых) рекомендую перейти на Fireworks, а если не важны, то в InDesign.

Нашлось ещё два сайта, прячущих меню под кнопками – Reuters и The Globe and Mail (кнопка + Show all sections). Тенденция внушает надежду. С другой стороны, Novell частично вернулся к традиционному меню – кнопок стало больше, но под ними по прежнему кучи всего. Непонятно, кому верить.

Очень интересная статья профессионального 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 вызвала непомерную бурю возмущения у дизайнеров. Свежо до сих пор.

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

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

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

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

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

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

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

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

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

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

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

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

В Wired’e опубликована дивная статья, в которой несколько дизайнеров показывают, что, с их точки зрения, нужно срочно менять в Craigslist (а ещё ранее подобная статья была опубликована в Smashing Magazine). Статья дивная, поскольку блестяще иллюстрирует как дарования гг. дизайнеров, так и феноменальный эффект антинаучного мышления, который я называю синдромом «Менять! Ломать! Крушить!».

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

1. имеющаяся теория полёта либо неверна, либо неполна
2. шмель летает благодаря волшебству.

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

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

• имеющаяся у меня теория работы Craigslist либо неверна, либо неполна, так что я неизбежно что-то испорчу
• я сломаю волшебство и принцесса превратится в тыкву.

Гг. дизайнеры из Wired’овской статьи этого страха вовсе лишены. Я преклоняюсь перед их отвагой, однако что-то подсказывает мне, что ввязываться в бой, не изучив волшебства Craigslist (которое несомненно есть) несколько безрассудно.

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

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

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

1. Скреплялись руководства не клеем или скрепками, а размыкаемыми кольцами, как некоторые ежедневники. Делалось это по двум причинам. Во-первых, кольца (как и пружины, использующиеся в особо правильных тетрадях; чао, модненькие Молескины) позволяют открыть нужную страницу, положить книгу на стол и вовсе не беспокоиться о том, что страница самопроизвольно закроется. Во-вторых, производитель время от времени рассылал клиентам исправленные/измененные страницы, так что пользователям достаточно было вынуть устаревшую страницу и заменить её новой.
2. Руководства набирались очень крупным кеглем (нормой было 14 пунктов, это на два пункта больше букварей, в которых уже огромный набор). Это было сделано опять-таки по двум причинам. Во-первых, это позволяло врачам класть при работе руководство куда удобно, вместо того, чтобы класть его поближе. Во-вторых, это облегчало замену страниц (если измененная страница разбухала текстом, на ней просто делали меньше кегль, а не вставляли новую страницу (что грозит поломкой нумерации страниц; по этой же причине нумерация страниц была не сплошной, а по разделам, например, 2-11, 2-12, 3-1 и т.д.).
3. Часть руководств набиралась поперёк обычного набора. Я сначала не понимал, зачем, потом, уже увидев готовую книгу, сразу все понял. Поскольку руководства были на кольцах, их можно было просто ставить на стол (как ставят перекидные календари). Это явно и несомненно облегчало использование руководства: читать с вертикально стоящего листа легче, чем с лежащего.
4. Поиск нужного параграфа облегчался всеми возможными способами: два или даже три уровня колонтитулов (часть → раздел → параграф), маркеры на боковом обрезе страниц для ускорения листания.
5. Все параграфы начинались не просто с новой полосы, но с новой правой полосы (правая полоса не двигается при быстром пролистывании, если читатель не левша). В руководстве было примерно четверть пустых листов, но буржуев это нисколько не смущало.

Такие приемы вообще характерны для руководств, в которых описываются сложные и редко выполняющиеся процедуры. Всё это – интерфейс; и сугубо интерфейсных методов в оформлении справочных изданий, вообще говоря, много. Поэтому нечего удивляться тому, что до появления на русском языке About Face самыми большими, детальными и проработанными русскоязычными книгами по интерфейсостроению были труды Аркадия Эммануиловича Мильчина. И эти книги я не устаю рекомендовать всем дизайнерам интерфейсов.

…пока он розовый. Этой мантрой я уже давно замучил всех дизайнеров нашей дивной компании – а теперь хочу замучить и вас. Вот небольшой учебный фильм; если заменить всего несколько слов в нём, всё будет применимо и к интерфейсам! Не забудьте только включить режим HD.

На мой взгляд, главная проблема поля из вчерашней викторины – оно не учитывает социальную составляющую. С карточкой работает много людей, если я, пользователь, напишу комментарий, его увидят и другие. Это порождает неуверенность (я напишу, а коллеги будут глядеть на меня как на идиота), отсюда – большинство карточек остаются пустыми, даже если про контрагента можно написать очень многое. Решать эту проблему можно разными способами, например, к полю ввода можно присобачить перечень допустимых и желательных тем. Поэтому ближе всего к правильному ответу приблизились гг. Илья Бирман, Константин Терещенков и frst.

Но это только половина проблемы. Вторая половина – формат того, что пользователи в это поле вводят. Само по себе поле никак не помогает указать введенные сведения правильно. Например, в одном из таких полей во вполне работающей системе я однажды увидел лапидарную фразу «После 4» (никто не знал, что это значит; после этого случая я и перестал доверять такого рода полям). Часто видел введенные сведения с феноменальными опечатками (писавшие явно торопились; NB: обратите внимание, что текст с опечатками, вообще говоря, полнотекстовым поиском не находится). А ещё однажды поле принимало RTF, поэтому копируемый туда из Word и почты текст сохранял неуместное форматирование и в некоторых карточках был почти нечитаемым. Т.е. нужно как-то учить пользователей, что в поле (а) надо писать достаточно, чтобы это потом могло понять другие люди и (б) гадить в поле не надо.

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

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

Комментарии:

Что с полем не так? На HTML не смотрите, он только для иллюстрации.