Подписка на блог

В Телеграме помимо ссылок на заметки делюсь околодизайнерскими наблюдениями.

В Твиттере помимо ссылок на заметки пишу всякую чушь.

В Тумблере и Же-же есть автоматические трансляции. Если не работает, напишите мне: ilyabirman@ilyabirman.ru.

По РСС и Джейсон-фиду трансляции для автоматических читалок

Пользовательский интерфейс

Принципы и методы

Элементы

Хотелки и изобретения

Наблюдения

Ещё теги

Автоматические коробки передач и «автостоп»

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

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

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

Это пример дебильного дизайна интерфейса.

 9 комментариев    1185   18 дн   автомобиль   интерфейс бытовых приборов   пользовательский интерфейс

Валидация форм и незаполненные поля

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

Подкаст-версия для тех, кто в дороге:

Сначала — догонка, а тема начинается с 4:56.

Ссылки из выпуска:

Кстати, на подкаст-версию теперь можно подписаться по РСС и слушать в подкастных программах:

https://ilyabirman.ru/meanwhile/tags/podcast/rss/

В Айтюнс-каталог пока не добавил — там надо ещё доработать разное, но по прямому урлу добавляется и работает, попробуйте!

 1 комментарий    1111   1 мес   веб-дизайн   веб-разработка   подкаст   пользовательский интерфейс

Ховер и клик должны совпадать

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

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

Вот некоторые ошибки, которые мне встречались:

  • Меню на сайте состоит из ссылок, завёрнутых в некоторый контейнер. У контейнера в стилях прописана подсветка при наведении. Вокруг текста ссылки остаются некоторые поля до краёв контейнера, где контейнер подсвечивается, но ссылка не работает.
  • Подчёркивание ссылки реализовано как-то так, что клик в саму линию подчёркивания не вызывает перехода по ссылке, хотя ховер есть. Бывает наоборот: ховера нет, а клик срабатывает.
  • Модальный попап закрывается кликом за его пределами. Ховеры элементов вокруг попапа продолжают работать, хотя клик по ним не вызовет связанное с ними действие, а только лишь закроет попап.
  • Функция элемента заблокирована скриптом, а ховер остаётся. Например: главная кнопка на форме отключена из-за ошибки в заполнении, но продолжает подсвечиваться при наведении, как будто работает.
  • Большой контейнер с картинкой и подписью нажимается целиком и реагирует на наведение каким-то эффектом. В углу контейнера есть маленькая иконка, которая делает что-то другое, например, добавляет объект в «Избранное». При наведении на иконку эффект наведения на контейнер сохраняется, хотя клик в этом месте не вызовет действия, связанного с контейнером целиком.

Эта мысль относится к теме «Обратная связь».

 4 комментария    2100   3 мес   обратная связь   пользовательский интерфейс

Интерфейс приложения «Совести»

Я публиковал отзыв Антона Вольных о консультации. После той консультации Антон решил обратиться ко мне за дизайном нового приложения «Совести». А я позвал в помощники Ивана Звягина.

В результате нашей работы получился интерфейс:

Главная идея — вместо форм и условий приложение встречает журналом товаров, которые можно купить в рассрочку по карте «Совесть». Читайте рассказ о проекте.

 1 комментарий    2131   4 мес   пользовательский интерфейс   портфолио   релиз

Истории Танского про флекс

Миша Танский показал видос своего доклада с 404феста:

Там четыре истории, которые полезно послушать начинающим дизайнерам. Прокомментирую.

Первая история про то, как хотели сделать админку для функции X, а потом догадались, что можно сделать без админки, с текстовым конфигом. Отсутствие админки должно быть как раз решением по умолчанию, а не примером такой ловкости-хитрости. Мне кажется, админками мыслят люди, проработавшие много лет в корпорациях, где количество доступных ресурсов на несколько порядков превосходит то, что они способны переварить. Когда ты работаешь в небольшой команде или вообще над своими проектами, мысль «сделать админку» в подобных ситуациях просто не приходит в голову, это какое-то необъяснимое ничем расточительство. Я до сих пор до конца не понимаю, Мишин слайд «Необходимые объекты дизайна» — это антипример в образовательных целях или они правда всерьёз такое рассматривали.

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

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

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

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

Третья история про «анду без анду». Типа люди иногда по ошибке делали в приложении Y и просили анду (правильно просили). Но технически реализовать анду было суперсложно (я в это, конечно, не верю, но это сейчас не важно), поэтому перед действием сделали подтверждение. Фишка в том, что вместо текста «Точно сделать? Да / Нет» в окне подтверждения написано «Готово! Завершить / Отменить». Подтверждение вместо анду — нормально как флекс, но, конечно, это плохой интерфейс. И замена одних слов другими в этом ничего не меняет, потому что проблема подтверждений не в словах, в чём легко убедиться, представив, что интерфейс на венгерском.

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

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

Четвёртая история похожа на первую. Как только Миша рассказал, что люди недозаполняли форму, а потом у них пропадали данные, первый же вопрос в моей голове был — «А чего их в локалсторидж-то не писать»? Я несколько лет назад проходил подобную историю в Эгее, когда думал о том, как не терять недописанные заметки при сбоях интернета. Перед тем, как так и сделать, ребята пытались спроектировать какой-то сложный мир черновиков с горой интерфейса для всего.

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

Возьмите, скажем, эсемески на айфоне. Если написать эсемеску, но не отправить, и вообще выйти из приложения, где будет лежать её текст? Прямо в том поле, где вы его написали! Нет никаких черновиков, не нужно придумывать интерфейс сохранения, восстановления неотправленных эсемесок — ничего этого нет. Просто если ещё раз зайти в диалог с этим же человеком, в поле всё ещё будет вписано то, что было вписано ранее.

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

 5 комментариев    2689   5 мес   видео   пользовательский интерфейс   студентам

Дай нажать

Это такой принцип в интерфейсе — называется «дай нажать».

Приведу три примера.

Группа чекбоксов с одним обязательным

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

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

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

Это плохое решение: я могу захотеть сначала отключить неподходящий вариант, а потом включить подходящий. Блокировка заставляет меня совершать действия в определённом порядке. Причём это ещё и неочевидно: если у меня останется последней определённая опция, скажем, «в чате», и она заблокируется, то это будет выглядеть так, будто уведомление в чате подключать обязательно, а это неправда. Я хочу его выключить, но интерфейс не даёт мне нажать туда, куда я хочу.

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

Чекбокс и поле

В настройке комментариев в Эгее есть чекбокс «присылать по почте», которому подчинено поле адреса:

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

Можно было бы блокировать поле пока чекбокс выключен — всё равно заполнять его нет смысла. Но это бесит. Может, я хочу заполнить адрес, а потом включить чекбокс? Ещё хуже было бы не давать выключить чекбокс, если адрес заполнен. Я же хочу выключить, дай нажать!

Лучше так: давать заполнить поле, даже если чекбокс выключен; включать чекбокс автоматически, как только в поле что-то вписали. В обратную сторону — аккуратнее: если чекбокс сняли, стирать адрес из поля не надо, мало ли. Пользовательские данные обладают бесконечной ценностью.

Выбор даты

Вот возможный вариант реализации выбора даты рождения в интерфейсе:

Как вы знаете, некоторых дней не существует в природе, например не бывает 31 июня. А 29 февраля в некоторые годы бывает, а в некоторые — нет.

Чтобы не дать пользователю ввести несуществующую дату, некоторые разработчики убирают из поля дня несуществующие дни. То есть если выбран месяц июнь, то дня «31» просто не будет в выпадайке. Но что, если у меня день рождения 31 августа? Я хочу ткнуть в 31, а потом выбрать август. Дай нажать!

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

Лучше так: при вводе дня, несовместимого с текущим выбранным месяцем, развыбирать месяц —

Если я выбрал 29 февраля, а выбранном году такого нет, развыбирать год.

Отчасти похожая мысль — кнопка «Купить» всегда доступна.

 9 комментариев    3616   11 мес   пользовательский интерфейс   студентам

Тупой сценарий обновления на Маке

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

Через несколько секунд после запуска программа сообщает, что есть обновление и предлагает скачать:

Ты соглашаешься, она начинает качать:

Пока она качает, ты переключаешься в основное окно программы заниматься тем, зачем её запустил:

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

А потом, когда ты её запускаешь в следующий раз, ты снова видишь вот это:

И снова соглашаешься, и оно снова начинает качать то, что уже давно скачала:

И так до бесконечности.

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

 9 комментариев    2771   2018   Мак   пользовательский интерфейс

Программа «Конспект»

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

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

К сожалению, ребята не успели всё доделать и во время защиты показывали продукт так же, как Стив Джобс показывал Айфон: был заготовлен один-единственный сценарий, при котором ничего не глючило. Можете потыкать в ту версию с защиты, но полагаться на неё не стоит. Не знаю, сколько она ещё проживёт по этому адресу.

А в качестве результата «для всех» была представлена только промостраница будущего продукта:

(Ну, что делать, такой флекс. Лучше так, чем не допуститься до защиты).

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

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

Когда только начали делать, сначала все представляли какую-то страничку с четырьмя колонками, как нарисовано в книге:

Типа, пишешь где-то текст, а потом отдельные его куски как-то переносишь в одну из колонок.

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

А потом мы поняли, что три колонки вообще нафиг не нужны, достаточно просто разметки внутри конспекта и автоматически собираемого туду-листа для отправки клиенту после встречи. Все помогалки, объяснялки и сортировалки должны работать как просто декораторы вокруг конспекта, но не мешать мне тупо писать под диктовку клиента что угодно.

Тут руководитель проекта Анна Доронина дала интервью «Кто студенту», где рассказывает о непростой истории проекта. У неё там процесс дизайна в трёх скриншотах, но на самом деле вариантов было намного больше.

С Бирманом легко: он достаточно толерантен, матом не пишет.

Помимо работы над интерфейсом, тогда же на дипломе мы зафигачили иконку (справа):

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

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

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

 Нет комментариев    2273   2018   пользовательский интерфейс   управление собой

Представь, что интерфейс на венгерском

Сначала написал это в своём телеканале, потом решил перенести сюда.

Когда на своём интерфейсном курсе я начинаю тему привычек, я показываю вот этот скриншот. Это то, что я увидел на своём телефоне, когда попытался подключиться к общественному вайфаю в парке в Будапеште:

Я спрашиваю, что надо сделать, чтобы подключиться. Прошу не подсказывать тех, кто говорит по-венгерски. Все говорят: «нужно поставить галочку и нажать на кнопку!».

Разумеется, сам я на венгерском знаю только «привет», «спасибо» и «осторожно, двери закрываются, следующая станция такая-то», но с лёгкостью тогда преодолел этот интерфейс и подключился к вайфаю:

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

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

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

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

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

 1 комментарий    1592   2018   пользовательский интерфейс   студентам

Узкоспециализированные профессиональные интерфейсы

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

Мало кто в подобных предприятиях понимает, зачем нужен хороший интерфейс, даже если у руководителя Айфон. Последнее может даже быть минусом: люди начинают воспринимать интерфейс как какую-то чисто маркетинговую фичу: красивые иконки, шрифты, анимация. Айфону-то это всё нужно, чтобы он продавался, а нам это зачем? Сотрудники и так будут пользоваться, чем положено, а не чем нравится. Какой смысл тратить деньги на интерфейс?

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

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

 1 комментарий    1113   2018   пользовательский интерфейс
Ранее Ctrl + ↓