Михаил Лихачёв
Именно поэтому Канон не является методичкой по принятию решений и списком устоявшихся правил дизайна, а всего лишь отвечает на вопросы по процессам в команде
Мы как раз поэтому и не пишем гайдлайны по компонентам в том же объёме, в каком делают Apple (Human Interface Guidelines) и Material Design. Хоть и описание некоторых вещей упростило бы нам работу, позволяя не отвечать на одни и те же вопросы, но они бы создавали рамки дизайнерам, заставляя принимать правила как данность
С другой стороны, в таких гайдах всегда можно добавить пометочку, что это всего лишь рекомендация, и что для каждого правила существует исключение 🙃
Для начала гораздо лучше реализовать базовый функционал (MVP), и только затем что-то улучшать. Если бы мы сразу целились в самый идеальный вариант не только с плеером, но и со всеми другими экранами, релиз приложения не состоялся бы в этом полугодии или даже году :)
Так поступили и Apple, сделав именно такую вёрстку плеера в iOS 13. Только через год он был обновлён до версии на вашем скриншоте, где пространство планшета стало использоваться гораздо эффективнее
Приложение на iOS стало универсальным, а это означает что новые функции будут появляться одновременно на iPhone и на iPad
Давайте вместе рассмотрим альтернативные варианты
Вариант как у Apple Music с плеером во весь экран потребует значительной переработки, а также поддержку нескольких экранов внутри (рекомендации, текст песен и плейлист). Да, это выглядит потрясно, но из-за этого не хотелось бы откладывать релиз айпад-приложения, которое и так ждали больше пяти лет
Вариант с вашего скриншота на самом деле следовал из предыдущей версии Apple Music на iOS 13, и в одном из наших концептов сопровождался с мини-плеером прямо в таббаре (этот вариант можно поглядеть на одном из скринов в начале статьи)
Думаю, мы придём к чему-то посередине, сделав плеер пошире (ближе к размеру других модалок) и разместив его по центру
В статье нигде и не было написано, что этим занимались 5 лет :)
С одной стороны это упростило бы работу, с другой стороны это развязывает руки. Лучше всего определиться с одним оттенком для подписей (к примеру), а самый лучший способ это зафиксировать — завести переменную.
Всегда был сложный вопрос про организацию системы с семантическими названиями, как работая с этим не создавать токенов больше нужного. Могу рекомендовать объединять переменные по общим глобальным признакам и тому какой они несут смысл внутри пересекающихся компонентов: например icon_secondary, который относится и к иконке в списке, и к иконке в поле ввода, и к иконке во вторичных кнопках действий. Вместо условных list_icon, input_icon, action_secondary_icon.
Ну а для нас работа с токенами критически необходима для поддержки тёмной темы. У всех компонентов токены уже проставлены, но если рисуем что-то кастомное, сразу обязательно подбираем токен, название которого разработчик потом подставляет себе. В итоге за систему с токенами отвечает команда дизайна. До разработки макеты доходят всегда со всеми токенами, а если чего-то нет, то заранее отправляем пулл-реквест в JSON-схему.
Конечно 😌
VKUI — дизайн-система с открытым исходным кодом и свободной лицензией MIT. То же касается и дизайна: библиотеки компонентов в Figma доступны под лицензией CC BY 4.0.
Пока нет :)
Спасибо за вопрос! ✌️
Если кратко, то это наследие до редизайна. Год назад при работе над тёмной темой мы уменьшали количество оттенков и пришли к текущему количеству синих, понимая, что от некоторых цветов избавиться не получится пока не обновим сами элементы в интерфейсе.
Недавний редизайн, где мы отказались от синей шапки, уже раскатался на всех пользователей последних версий приложения. Теперь можем отказаться от поддержки старой темы с использованием тех цветов, и скоро планируем заняться приведением цветовой палитры в порядок и чисткой от ненужных оттенков. Количество синих получится сократить примерно до 5 штук, сейчас это отдельная палитра Azure. Раньше использовалась палитра Blue.
До какого-то времени департамент дизайна помещался одну уютную комнатку, а там вся информация и опыт передавались легко и непринуждённо, так что особого запроса на внутреннюю базу знаний не было. Выхлоп от её создания в тех условиях не был бы соизмерим с затратами по времени
Потребность и потенциальную пользу начали ощущать при переходе на удалёнку в марте год назад и при росте команды