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

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

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

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

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

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

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

Элементы

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

Наблюдения

Ещё теги

Отмена начатого драг-н-дропа

Одна из вещей на Маке, к которой я не могу привыкнуть после Винды, хотя перешёл больше 10 лет назад — невозможность надёжно отменить начатый драг-н-дроп.

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

Это полный кретинизм и непростительное непонимание Фиттса и принципа «Анду». Но никто с этим ничего не делает и, скорее всего, никогда не сделает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 2 комментария    1450   4 мес   веб-дизайн   веб-разработка   видеоблог   подкаст   пользовательский интерфейс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дай нажать

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

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

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

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

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

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

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

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

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

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

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

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

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

Выбор даты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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