Михаил Лихачёв
Именно поэтому Канон не является методичкой по принятию решений и списком устоявшихся правил дизайна, а всего лишь отвечает на вопросы по процессам в команде
Мы как раз поэтому и не пишем гайдлайны по компонентам в том же объёме, в каком делают 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.
Здравствуйте! У нас есть планы на улучшение поддержки доступности, но конкретно сейчас чем-то поделиться не можем.
Спасибо за большое фидбек 😌
Да, с разными паддингами для каждой из стороны было бы конечно здорово. Мы будем рады избавиться от лишних слоёв и контейнеров с отрицательными отступами)
У TT Commons есть обновлённая версия и да, требуется лицензия чтобы всё правильно отображалось. В группе по Figma в ВК ответили, но продублирую тут: разом пересчитать размеры выделенных текстовых слоёв поможет команда в меню Recompute Text Layout in Selection (находится только через поиск).
В интерфейсах TT Commons мы используем только в Panel Header, но для него есть специальный заменяемый компонент Middle в конце списка с системным шрифтом, предполагается использовать его.
Спасибо!) У нас есть несколько компонентов с горизонтальным авто-лэйаутом, например ячейки. Сам хак в следующем: между левой и правой частью ячейки разместили пустой компонент под названием Resize, который отвечает за размер ячейки. Этот компонент имеет Auto Layout и пустой прямоугольник внутри, чтобы замена на другой Resize заставляла менять размер родительского компонента.
Таких компонентов сделали несколько под разные размеры устройств, связав их названием. Меняешь один Resize на другой и тогда обновится размер ячейки.
Как этим пользоваться даже расписали в руководстве перед началом работы, так как это совсем неочевидный момент) В планах есть мысль написать плагин, который бы упростил замену размеров ячеек для всего списка, а то сейчас это неудобно делать когда ячеек много.
Библиотеки компонентов для сайта у нас пока не такие гибкие, как для мобильных устройств. Работаем над этим 🙌
До какого-то времени департамент дизайна помещался одну уютную комнатку, а там вся информация и опыт передавались легко и непринуждённо, так что особого запроса на внутреннюю базу знаний не было. Выхлоп от её создания в тех условиях не был бы соизмерим с затратами по времени
Потребность и потенциальную пользу начали ощущать при переходе на удалёнку в марте год назад и при росте команды