Микровзаимодействия в формах — как часть дизайн-системы
Микровзаимодействия редко прорабатывают подробно. Чаще всего это и не нужно.
Но иногда могут возникать серьезные проблемы — в тех контролах, которыми люди пользуются десятки раз в день. Вот там микровзаимодействия стоит проработать подробно.
Мы — криптовалютная биржа. Наши пользователи десятки раз в день продают и покупают валюты. И десятки раз в день вводят цену и объем сделки. Значит, для нас критически важны инпуты, где это происходит :)
Пример проблемы: десятичный разделитель и его ошибки
Поскольку торгуются криптовалюты, у них почти есть десятичный разделитель. В каких-то странах это запятая, в других — точка, в третьих — вообще специальные символы.
Если пользователь ввел "неправильный" разделитель, что нам делать?
- позволять ли ввести его вообще?
- выводить ли ошибку?
- подменять ли его на правильный?
Проблем и вопросов — десятки
Сначала все было просто. Пришли разработчики с какими-то уточнениями, я ответил. Потом еще. А потом вопросов становится много, а потом происходит перерыв, ты занимаешь 1-2 месяца другой фичей, а потом тебя спрашивать "не помнишь, что мы там решили для такого-то кейса? Да, а ты вроде говорил... Но ведь в другом месте ты сказал вот так сделать..."
Я буквально уткнулся в эти вопросы. Скрываем ли мы сообщение об ошибке, если начали редактировать инпут? Скрываем ли мы тултип с подсказкой, если вылезла ошибка? Продолжает ли отображаться плейсхолер, если мы перенесли фокус в поле, но еще не начали печатать? Что делать, если по инпуту пришло несколько ошибок? А что — если пришла и отобразилась одна, а потом из-за горячей валидации прилетело еще три?
И тогда родилась Библия Инпутов :)
Жизненный цикл инпута
Если какой-то контрол тяжело продумать целиком — можно разделить его на состояния и описать каждое в отдельности.
Действия и события
С инпутом можно совершить ограниченный набор действий. Я выделил всего пять:
Цепочки действий:
В жизни пользователь совершает не одно действие. Он тыкает, тыкает и тыкает курсором и клавиатурой в несчастные формы :)
В каких состояниях какие действия могут быть, как они могут друг за другом следовать, как интерфейс должен на это реагировать...
После этого я описал общую политику того, как мы относимся к пользовательскому вводу, подменяем ли ошибочные символы и т.п.
Затем я нарисовал еще несколько разделов схемы и стало хорошо.
Наступило счастье :)
После рождения схемы было буквально 2-3 вопроса от разработчиков, которые пришлось разобрать отдельно. За 7-8 месяцев.
Во всех остальных случаях я просто смотрел схему и объяснял, что и как должно работать.
- - - - - - - - - -
Интересно научиться на практике? :)
Приходите на курс по схемам