Pull to refresh

Comments 20

Вижу уже не первый раз, поэтому спрошу: зачем каждый раз представляться в начале статьи? Про автора можно прочитать в профиле.

UFO just landed and posted this here
«Обычно дизайнеры всем этим не занимаются, а рисуют картинки по стайл-гайдам платформы и по концептуальной модели гуя, называемой дизайн-системой (Material Design — одн из таких систем). Опытного дизайнера обычно отличает интуитивное восприятие её закономерностей, понимание цельного и деталей, общего и частного. Мы же немного формализовали всё это дело и выкатили свою редукционистскую дизайн-систему без концепций обобщения, параметризования контейниров и прочих композиционных возможностей. В качестве названия фреймворка мы выбрали фундаментальную науку, чтобы показать завышенные амбиции данного начинания. Догоняйте.»
Mathematical Driven Design: размеры и отступы

По названию подумал что речь пойдет об параметрическом дизайне.


Ну а то, что вы описали, по факту является grid based design, одной из основ дизайна интерфейсов, что все размеры должны быть выдержаны и одинаковы, а не случайные для каждого элемента, а так же элементы должны располагаться четкой сеткой и выдерживать вертикальный ритм.


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


Обычно дизайнеры всем этим не занимаются, а рисуют картинки по наитию. Опытного дизайнера обычно отличает интуитивное восприятие описанных тут закономерностей.

Если дизайнер не знаком с дизайном по сетке — он, как минимум, что-то упустил во время обучения. Это что-то сродни пропустить тригонометрию для математиков.


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

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


И еще, все отступы одинаковые или кратные — это здорово. Только потом появляются блоки, которые должны быть пронумированы типа 1, 2, 3 и т.д. и цифра стилистически должна быть большой. Вот если делать влоб с одинаковыми отступами — визуально блоки будут прыгать достаточно сильно, придется вручную двигать отступы по пару пикселей. Это же относится к началу параграфа с тире, плюса и еще чего. Хоть это и не настолько частая задача, она все же встречается, особенно в попытках сделать "газетную верстку".

то, что вы описали, по факту является grid based design, одной из основ дизайна

Вы зря пытаетесь усмотреть в моей статье что-то большее, чем точный расчёт размеров и отступов.


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

Давайте не будем утрировать. Это неприлично.


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

Не очень понял проблему о которой вы говорите. Можно визуальный пример?

Что-то с цифрами пример оказалось сложнее найти, но вот для цитаты есть хороший пример. Когда есть открывающая ковычка (елочка), она смещает первую строку и хочется чтобы блок текста был выравнен, поэтому необходимо задавать отрицательный маржин. Конечно, можно спорить что на вкус и цвет, да и вообще, никто в эпоху технологий этим не заморачивается, но проблема с тем что цифра "1" визуально сильно уже цифры "8" никто не отменял. Для интерфейсов обычно это не сильно заморочено — ну уже и уже, все равно кнопки там, блоки, границы, но просто бывают примеры, когда некоторые тексты нужно двигать ручками чтобы они выглядели лучше.


Spoiler header


и с отступом


Вы зря пытаетесь усмотреть в моей статье что-то большее, чем точный расчёт размеров и отступов.

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


[ привет ]
[ + добавить ]


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

А, вы про висящую пунктуацию. Это всё от навязчивого желания выстроить тексты по струнке. Сюда же относится и выравнивание по ширине, и капитализация. Тексты могут гулять туда-сюда на несколько пикселей и это нормально. Более того, такие неровности помогают различать строки, а это значит, что при переносе не начнёшь случайно читать ту же строку повторно.


А совмещать кнопки с иконками и кнопки без иконок само по себе не консистентно. Тут либо всем иконкам стоит добавить иконку, либо у всех убрать, а не пытаться это как-то выравнивать. Тем более, что их как ни выравнивай — будет смотреться криво.

Я скорее про то, что визуально круглое кажется меньшим чем квадратное при одинаковых габаритах, что в итоге невольно приведет к несколько неодинаковым размерам и подгоном на лету. Хотя опять же, как правило это сразу учтено уже в иконке и, тем более, шрифте. Сейчас я работаю в проекте с компонентым дизайном, где мы собираем интерфейс из компонентов, все размеры заданы и все такое — очень удобно. Но есть вот такие артифакты, что местами текст выглядит немного не выравненным, но не велика беда. Но были и проекты где дизайнер заставлял двигать каждый абцаз на пару пикселей чтобы все было идеально и там была сетка, была строгая структура, но математичностью это назвать было сложно (хотя технически, "оптическое выравнивание" или как оно там называется приплести сюда можно, но удобнее было просто пододвинуть на пару пикселей).

Вы, я вижу, соображаете в вопросе (сам я лишь поверхностно охватил взглядом проблематику когда-то, сюда ещё можно добавить неодинаковую трактовку DPI на различных платформах, сложности с ретиной, и вообще ад и израиль), не находили ли вы какого-то решения, подхода к унификации и автоматизации дизайна с учётом всех этих психофизических восприятий шрифта? Возможно, это какая-то библиотека, которой в рантайме кормишь текст, DOM-элемент, и она в нём рисует текст с выбранными параметрами не абсолютными, а в стиле «толщина шрифта должна условно видиться как 12 ариал на айфоне, межстрочный интервал для чтения лонгрида, перенос по словам». Или какой-то набор макросов для CSS, что-то, что позволит худо-бедно обойтись без продвинутого верстальщика/дизайнера, но сделать текст красивым? В духе современности представляется даже нейросетка, которая смотрит на страницу в браузере и подсвечивает проблемные места (а ядра нейросетки для обучения натравливать как раз на утяжеляющие строку хвосты, на слипающиеся буквы, на повисающие знаки и т.п.)

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

Справедливости ради, у данной примитивизации дизайн-системы есть свои несомненные плюсы — она очень удобна для параметрической генерации интерфейса (а не самого дизайна, на что будто бы намекает название фреймворка :)). Можно себе представить систему, в которой бизнес-логика программируется на очень высоком уровне (например, в виде конфигов/политик ABAC над объектами, экспозируемыми какой-нибудь ERP или СУБД), а так же сверху накатываются роли, права доступа и всё остальное, что влияет на доступность в интерфейсе тех или иных возможностей. И тогда все формы (например, для CRUD-операций) для всех бизнес-объектов можно бы было генерить через этот фреймворк, расставляя тупо по порядку все элементы управления, доступные пользователю. Т.е., это фреймворк для машинно-генерируемых форм, я бы так его спозиционировал.
Правило центроида. Человек уверенно попадает по контролам, если их размер не менее 6 мм, что соответствует 40 css пикселям.
Непонятно, при чем тут центроид, ну да ладно.
По стандарту CSS подразумевает разрешение экрана 96dpi, так что 6mm не могут соответствовать 40px.

Центроид — засчитываемая точка касания.


Речь про физические миллиметры, а не про то, что в css обозначается как mm.

Миллиметры css достаточно хорошо соответствуют физическим при условии дефолтных настроек.
Несколько лет назад мейнстримовые матрицы в точности подгонялись под 96dpi (не с потолка же взято это число) — например, 1920x1080@23. Последнее время стандарт де-факто — 110dpi.

Я забыл тут уточнить, что тут речь идёт про тач скрины. Мышью-то можно попадать и в куда меньшие габариты.


Впрочем, можете сами взять линейку и померить 40 пикселей. У меня на всех экранах это не меньше 6мм.

UFO just landed and posted this here

Есть же. Расстояние до детей устанавливается равным расстоянию между детьми. Это масштабируется на любой уровень вложенности.

Дизайнер от слова design (проектирование), а не от слова style (дизайн).

Господи, это прекрасно!
Sign up to leave a comment.

Articles