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

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

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

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

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

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

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

Элементы

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

Наблюдения

Ещё теги

Плакат о синтаксисе элементов интерфейса

Нас несколько лет просили, и мы наконец сделали!

Теперь наш плакат о синтаксисе элементов интерфейса можно купить на Принтдиректе.

В Коворкафе уже висит пару месяцев:

Что это? Вот цитата из моей книги «Пользовательский интерфейс», главы «Синтаксис»:

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

Но в английском начальная форма и повелительное наклонение глагола не отличаются. А по-русски «Сохранить», «Сохрани» и «Сохраните» — разные слова. Здесь речь только о кнопках, и только о тех, что отдают команды, а этот фрагмент даже нельзя однозначно перевести на русский.

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

Идею о том, что интерфейс подчиняется синтаксису языка, Артём Горбунов сформулировал в 2007 году. Тогда же мы задались целью систематизировать знания о синтаксисе в приложении к интерфейсу.

...

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

В прошлом году плакат перевестал Серёга Фролов.

В правой части стоят номера страниц в книге, где соответствующие примеры обсуждаются подробно.

Вот кусочек крупнее:

Если закажете и повесите у себя, присылайте фотки!

 2 комментария    1209   9 дн   пользовательский интерфейс

Подкаст АТП про интерфейс многозадачности на Айпаде

Я давно хотел написать что-то о том, почему интерфейс многозадачности на Айпаде — это полный ад и кошмар, и что Эплы сошли с ума, если думают, что «упростили» «слишком сложную» модель классических оконных интерфейсов типа Макоса и Винды. Но в 363-м выпуске АТП как раз это подробно и прекрасно обсудили:

Разговор про Айпад начинается с 1:24:55. Особенно здорово Джон Сиракьюса объясняет, почему неверно мнение, что «это просто вы привыкли к классическим окнам и не привыкли к айпадовой модели», это где-то с 1:31:25.

Noöne would see someone on a Mac with two windows open goes, “Wow, you must be a Mac expert”, but you someone with three things with split screen on iPad and a slideover, and you assume they are an iPad expert.

Ну и вообще этот выпуск клёвый, можно слушать целиком с удовольствием.

 2 комментария    1122   18 дн   Айпад   подкасты   пользовательский интерфейс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дай нажать

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

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

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

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

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

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

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

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

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

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

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

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

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

Выбор даты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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