Pull to refresh

Comments 3

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

Описанное решение является следствием ряда факторов, на каждый из которых по отдельности или на их совокупность в целом невозможно было оказать существенного влияния.
Представьте ситуацию, когда степень педантичности и уровень точности, предъявляемый к желаемому результату, имеют решающее значение, а проект представляет унаследованную кодовую базу, где элементы интерфейса и их стили уже описаны «магическими» значениями в попытке добиться желаемой точности для поддержки 10+ локализаций, часть из которых используют шрифты с процентом пустых областей порядка 10-15% от необходимого размера. Модификация интерфейса в этом случае подразумевает многочисленные ручные пересчеты, что существенно сказывается на итоговых временных оценках. Добавим сюда распределенную команду дизайнеров со стороны клиента, работающих одновременно с десятком направлений и без унифицированного стайлгайда.

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

Sign up to leave a comment.

Articles