Если спросить любого дизайнера, что такое оптическая компенсация, он ответит: это когда круг делают больше, чем квадрат, чтобы выглядело так, будто они одинакового размера.
Это базовое знание, с него начинается любой курс для начинающих.
На практике этот принцип чаще всего применяют так, как он был описан, когда в макет нужно поместить что-то круглое вместе с чем-то некруглым: иконку добавить в начало строки или, например, аватарку выровнять относительно блока с описанием. В таких случаях круглый элемент делают чуть больше и сдвигают на пару пикселей влево и вверх, чтобы компенсировать оптическую потерю веса.
А если этот принцип применить шире? Там, где нет ничего круглого, но один элемент так же может потерять вес относительно другого, равноценного ему. Например, в формах.
Формы могут быть разные, но чаще всего они состоят из двух одинаково важных частей: набора полей и блока с действием. Самая простая форма — одно поле с кнопкой.
Поле и кнопка одинаковой высоты, имеют одинаковый вес и хорошо работают друг с другом.
Форма может быть вертикальной и состоять из нескольких полей и кнопки. Как на авторизации, скажем. И здесь тоже всё одинакового размера и хорошо работает.
Но чем богаче становится набор полей, тем больше он начинает «отъедать» веса у блока с действием. И если в небольшой форме кнопка по весу приравнивалась ко всему набору полей, то в большой её вес становится равен отдельно взятому полю. Из-за чего слабеет восприятие кнопки как кульминации формы.
Это лучше видно на реальном примере.
Здесь хорошо вспомнить принцип оптической компенсации и пойти схожим путём: повысить вес кнопки за счёт увеличения её высоты относительно полей формы.
Да, это не совсем оптическая компенсация. Предпосылки другие. Здесь нет оптических иллюзий, мы работаем только с визуальным весом. И пусть решение то же самое (увеличиваем размер), принцип правильнее будет называть «визуальной компенсацией».
Если тебе повезло (или не повезло) и у проекта есть библиотека элементов, достаточно взять из неё кнопку на один размер больше. Если в форме поля размера S, то кнопку берём M, если поля M, то кнопка L. Принцип простой.
Если у проекта нет библиотеки элементов, это хороший предлог начать её собирать. Как раз с самого базового элемента — кнопки. Разница в размерах по высоте может быть от восьми до 16 пикселей — по твоему усмотрению.
Комментарий удален модератором
Отличная статья, спасибо.
Статья так себе. Идентифицируйте себя чтобы мы сложили представление, что за чудо-контора так пиарится.
Хорошо, что вы себя идентифицируете сразу. Так мы имеем представление и о вас
Но как может быть одинаковый вес у светло-серого поля и черной/яркой кнопки?..
Ну вес это ведь просто термин (а как еще удачнее назвать-то?)
Суть в том, что среди обилия инпутов кнопка может тупо потеряться и юзеры ее не смогут найти. Поэтому надо делать её увесистой, чтоб не приходилось напрягать зрение и мозг.
Когда я только начинал изучать проектирование и дизайн интерфейсов, меня больше всего поражали советы вроде "Делайте кнопку КУПИТЬ большой, яркой и заметной, и помещайте ее туда, где ее легко будет найти". Я тогда думал - ппц, разве это неочевидно? Что за имбецилия? А потом выяснилось, что 99,9999% интерфейсов и вправду страдают имбецилизмом, и разобраться в них бывает очень сложно даже для продвинутого юзера - как раз вот из-за таких мелочей.
Иллюстрировано как раз таки в статье
Вес зависит не только от цвета. Есть еще размер, форма и положение относительно друг друга.
Как раз столкнулся с подобной задачей, прям под руку!)