Замкнутость интерфейса: проверочные вопросы

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

У нас есть правило: для каждого поля ввода указать правила:

1. Фильтрации. Например: «Убрать непечатные символы в начале и конце». Тогда « Вова „, становится „Вова“. Или: „Заменить знак . на ,“ — это для полей ввода дробей, когда пишут 3.14, а по смыслу там 3,14.
2. Валидации. Например: „Неотрицательное целое число“.
3. Форматирования. Например: „Указывать два десятичных знака после запятой“. Это особенно важно для программистов, которые не парятся и ставят как есть: 3.14159265359.

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

Самое базовое, что мне видится и о чем забывают 90% дизайнеров — это банальные микроанимации. Как это обычно бывает — «Вот тут сделаем по клику всплывающую плашку». А как эта плашка всплывает? Через прозрачность? Со смещением? С какими изингами? Похожа ли эта анимация на те транзишены, что применены к ссылкам? Будут ли они в консонансе друг с другом? А что произойдет по клику на кнопке на плашке? Попап пропадет или появится сообщение? Закроется ли он сам или надо будет нажать на крестик?

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

Добавлю

1. Нужно прогонять все экраны, как они будут выглядеть при других глобальных режимах. например, если пользователь не залогинен.

2. Расширю п. 4 исходного поста: переменным может быть не только количество элементов, но и количество знаков/слов внутри элемента. Как правило, если специально не оговорить, верстальщик верстает только то, что нарисовано в макете. А что будет если вместо 2 слов названия товара выведется 20, появится вторая строка? А как этот элемент будет выглядеть в активном состоянии или сложным ховером?

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

А вот ребята придумали штуку, которая помогает думать про состояния интерфейса: https://sketch.systems/