Считаю, что прозрачность лучше всего работает с текстом в монохроме и в hover state - в противном случае элементы, которые идут внахлест, будут иметь совсем иной цвет в разных контекстах (цветная шапка с вторичной СТА и тот же элемент на нейтральном фоне). Поэтому лучше иметь плотную заливку на каждый цвет.
+++
А ещё не поддерживаю комментарий автора по поводу использования одного значения прозрачности в светлой и тёмной теме. «Он и там и там, будет смотреться хорошо» – я ни разу на практике не видел, чтобы такое случалось :) В тёмной теме цвет должен быть в принципе другого оттенка, менее «яркого» (речь идёт не о характеристике Brightness, а о визуальном восприятии), чтобы снизить нагрузку на зрение.
Опять же, кмк, лучше захардкодить плотную заливку, подобранную вручную.
То, что я на практике не встречал, это конечно же не значит, что такого не бывает :) Другое дело, что по моему мнению данный подход менее универсален. Речь идёт больше о "брендовых" цветах, условно – ярко синий цвет, ярко красный и прочие.
Оттенки всё равно же надо записывать, и неважно, используют ли они прозрачность или имеют плотную заливку. Для фронта это так и так +1 переменная. Мы как-то пытались на одном проекте уменьшить количество цветовых токенов, но так и не смогли прийти к идеальному решению.
Вот на счёт опасити, пробовал сам на разных проектах. Дизайнерам действительно проще, а вот разрабы ворчали, у них мол и так переменные и им погоду не меняет сколько оттенков. К опасити лично отношусь приемлемо.
Я вот думал на тему юзать HSL для палетты. Тогда оттенки легко можно извлечь параметром L сохраняя одинаковые H и S.
Так мне кажется могут получиться общие кодированные параметры оттенков типо Primary-70, Primary-90 и Secondary-70...
Совет про "нечёрный" чёрный с точки зрения пользователя считаю экстремально вредным. С каждым годом OLED-экранов становится всё больше, а абсолютный чёрный в их случае означает выключенный экран и уменьшенное энергопотребление. Игра в "очень тёмный серый" вместо чёрного превращает "тёмные темы" в фикцию, потому что экран продолжает работать по всей площади.
Насчёт названий цветов в дизайн-системах. Замечал несколько разных подходов:
1. Прямое название - в честь оттенка (Black, White, etc)
2. Название по назначению (Comment, Stroke, etc)
3. Название для состояния (Warning, Danger, etc)
4. Градация по частоте (Primary, Secondary, etc)
5. Цвета в зависимости от палитры (Accent, Brand, etc)
Самое страшное – подходы перемешиваются между собой, что приводит к путанице как при использовании, так и при составлении цветовой палитры. Например, когда у тебя есть несколько цветов обводки, которые разнятся в зависимости от типа объекта, а так же некоторые из типов имеют разное по степени важности выделение, а могут ещё и состояния.
Последний апдейт фигмы позволяет вкладывать все уровни друг в друга, что немного снимает боль (ведь ещё есть группировка по теме: Dark, Light, etc), но принципиально проблема однозначного именования цветов не решена.
Когда смотришь чужие дизайн-системы, понимаешь, что подходы налеплены друг на друга в случайном порядке. Часть цветов названы оттенками, часть – состояниями, часть – в зависимости от палитры и так далее. Использовать это с удобством может только автор самой палитры :)
А кто-нибудь может сказать или подкинуть, как адекватно работать с брендовым зелёным? Как адекватно отделить от success state зелёного?
И вообще чёт хороших примеров основного зелёного не встречал... Поделитесь примерами?
Комментарий недоступен
Считаю, что прозрачность лучше всего работает с текстом в монохроме и в hover state - в противном случае элементы, которые идут внахлест, будут иметь совсем иной цвет в разных контекстах (цветная шапка с вторичной СТА и тот же элемент на нейтральном фоне). Поэтому лучше иметь плотную заливку на каждый цвет.
+++
А ещё не поддерживаю комментарий автора по поводу использования одного значения прозрачности в светлой и тёмной теме. «Он и там и там, будет смотреться хорошо» – я ни разу на практике не видел, чтобы такое случалось :) В тёмной теме цвет должен быть в принципе другого оттенка, менее «яркого» (речь идёт не о характеристике Brightness, а о визуальном восприятии), чтобы снизить нагрузку на зрение.
Опять же, кмк, лучше захардкодить плотную заливку, подобранную вручную.
Комментарий недоступен
То, что я на практике не встречал, это конечно же не значит, что такого не бывает :) Другое дело, что по моему мнению данный подход менее универсален. Речь идёт больше о "брендовых" цветах, условно – ярко синий цвет, ярко красный и прочие.
Комментарий недоступен
Оттенки всё равно же надо записывать, и неважно, используют ли они прозрачность или имеют плотную заливку. Для фронта это так и так +1 переменная. Мы как-то пытались на одном проекте уменьшить количество цветовых токенов, но так и не смогли прийти к идеальному решению.
И есть ещё интересная тема по шрифтам https://vc.ru/u/680298-neyromarketing/199803-podsoznatelnoe-vozdeystvie-shrifta
Про opacity не совсем понятно. Почему это она предпочтительнее непосредственных оттенков?
Комментарий недоступен
Не проще ли прописать просто несколько номеров палитры, а не один номер и несколько значений opacity? Так удобнее лично мне и людям.
Комментарий недоступен
Вот на счёт опасити, пробовал сам на разных проектах. Дизайнерам действительно проще, а вот разрабы ворчали, у них мол и так переменные и им погоду не меняет сколько оттенков. К опасити лично отношусь приемлемо.
Я вот думал на тему юзать HSL для палетты. Тогда оттенки легко можно извлечь параметром L сохраняя одинаковые H и S.
Так мне кажется могут получиться общие кодированные параметры оттенков типо Primary-70, Primary-90 и Secondary-70...
(И да я согласен что hex читается легче чем hsl)
@Аккаунт удален что думаешь?
Комментарий недоступен
Не люблю цитаты с медиума но этот чувак наглядно осветил идею с примером стилевых переменных:
Не в коем случае не спор за лучший подход, интересен был твой опыт на тему HSL, буду иметь ввиду! Спасибо!
Спасибо за статью. Интересный материал
Ссылки на Coolors.co и Designspiration.com хорошо бы починить.
Комментарий недоступен
Нет :) Как минимум в разделах 4 и 8 остались битые ссылки, ведущие на komarov.design.
Совет про "нечёрный" чёрный с точки зрения пользователя считаю экстремально вредным. С каждым годом OLED-экранов становится всё больше, а абсолютный чёрный в их случае означает выключенный экран и уменьшенное энергопотребление. Игра в "очень тёмный серый" вместо чёрного превращает "тёмные темы" в фикцию, потому что экран продолжает работать по всей площади.
Комментарий недоступен
В мобильной версии можно и #000 использовать, если это в целом уместно. Пока нет уголовных статей, запрещающих это.
Насчёт названий цветов в дизайн-системах. Замечал несколько разных подходов:
1. Прямое название - в честь оттенка (Black, White, etc)
2. Название по назначению (Comment, Stroke, etc)
3. Название для состояния (Warning, Danger, etc)
4. Градация по частоте (Primary, Secondary, etc)
5. Цвета в зависимости от палитры (Accent, Brand, etc)
Самое страшное – подходы перемешиваются между собой, что приводит к путанице как при использовании, так и при составлении цветовой палитры. Например, когда у тебя есть несколько цветов обводки, которые разнятся в зависимости от типа объекта, а так же некоторые из типов имеют разное по степени важности выделение, а могут ещё и состояния.
Последний апдейт фигмы позволяет вкладывать все уровни друг в друга, что немного снимает боль (ведь ещё есть группировка по теме: Dark, Light, etc), но принципиально проблема однозначного именования цветов не решена.
Когда смотришь чужие дизайн-системы, понимаешь, что подходы налеплены друг на друга в случайном порядке. Часть цветов названы оттенками, часть – состояниями, часть – в зависимости от палитры и так далее. Использовать это с удобством может только автор самой палитры :)
Годная статья, плюс однозначно
А кто-нибудь может сказать или подкинуть, как адекватно работать с брендовым зелёным? Как адекватно отделить от success state зелёного?
И вообще чёт хороших примеров основного зелёного не встречал... Поделитесь примерами?
Комментарий недоступен