Комментарии 34
Но я другое хотел узнать — а «команда маркетологов» точно в курсе, сколько он стоит?
Учитывая наличие огромного количества фотографий… Жестокие вы люди.
Интересно узнать ваше мнение в свете 4К мониторов. Насколько актуально использовать жесткую привязку к пикселям при верстке? Есть ли смысл переходить на использование пунктов или другой отностительной единицы?
— нарисовали расстояние 10px в макете
— верстальщик сверстал 10px (если нет текста рядом, чтоб пересчитать в em)
— на экранах с плотностью 1:1 — будут в результате те же 10 физических px, на экранах двойной плотности — 20 физических px и т. д. (не смотря на то, что верстальщик указал 10 css px).
Какая-то безумная каша из адаптированных к тач-взаимодействиям и чисто мышиных контролов… Вы тут про популярность айфонов у молодых мамаш пишите, и тут-же предлагаете им попадать наманикюренными пальцами в микроскопические чекбоксы и текстовые ссылки… Всюду ховеры (это для айфонов то!), невнятные тоскливые контрасты… Радиусы скруглений, несмотря на все пожелания маркетологов, должны отличатся у контейнеров и содержимого… "Лорем ипсум" — это, конечно, дурной тон, а вот "Вся информация носит ознакомительный характер" — это уже совсем другой уровень, верно? В целом — весьма посредственная работа, совершенно не понятно чем тут хвастаться.
Ну так напишите свой кейс про то как гайдлайны разрабатываете, сделайте это лучше чем я, расскажите секреты свои! А я с интересом поучусь у коллеги, чей опыт обширнее. Слабо? А камень бросить — это всегда очень просто…
Простите если задел, серьезно. Но Хабр — это не личный бложек и не ваша рекламная страничка с портфолио. Тут принято делиться чем-то полезным. В данном же случае я вижу пример того, как делать НЕ надо. А именно:
- В современных адаптивных интерфейсах никаких ховеров быть не должно. Догадываетесь почему?
- Шрифт Circe — ужасный выбор для набора блоков текста. Для заголовков — может быть, но тоже "не фонтан". И это не вкусовщина, его просто мучительно читать, такая уж у него структура символов.
- У всех активных элементов должна быть очевидная "область контакта", достаточная по размеру для попадания в нее пальцем средней толщины. Это не касается только гиперссылок, но таковые могут иметь место только внутри текстовых блоков (как часть текста) и они не должны являться частью основной навигации (использовать на крайний случай, с пинч-ту-зумом).
- Ваш визуальный язык общения с пользователем, по возможности, не должен содержать синонимов (минимализм рулит). Не стоит заставлять пользователя изучать разные виды контролов, которые делают одно и то-же — от этого интерфейс кажется сложнее чем он есть на самом деле (а мамаш легко напугать сложным интерфейсом, поверьте). Выберите что-то одно. К примеру, либо чекбоксы, либо тогглеры. У переключателей "on/off" есть своя специфика взаимоотношений с их лейблами, это довольно капризный элемент, без особой необходимости лучше его вообще не использовать.
- Как будут выглядеть карточки, если "Имя" с "Фамилией" на них разрастается на две строки, а заголовок — на три? Такие карточки вообще работают только на статичном макете, в реальности они станут проблемой при подборе иллюстраций (замучаетесь кадрировать) и текст на них будет обрываться на самом неприличном месте (для выравнивания по высоте).
- Чередование однопиксельных рамок со скругленными краями и с прямыми — выглядит беспорядочно.
- Понимаю, что цвета подбирали не вы, но UX-дизайнер должен отстаивать принципы, а именно — достаточный уровень контрастов (минимальный и максимальный).
- Таблицы без вертикальных разделителей ячеек должны иметь большие отступы между ячейками, поэтому их трудно сделать компактными и поэтому лучше так вообще не делать, если ячеек по горизонтали больше двух.
- Помимо разрозненных UI-элементов в гайдлайне должны присутствовать принципы их взаимодействия: правила выбора элементов, построения тулбаров, группировки в блоки, вложенности блоков и т. д. Примеров выборочного применения шагов сетки для этого недостаточно. Почитайте гайды от ведущих вендоров: они все делают упор на это.
- И нужно убрать все рамки и подчеркивания у элементов с заливкой на сером фоне, от них общая картина выглядит грязно. Если элемент без заливки — хорошо бы избавиться от прямых контактов серого с зеленым (болото и тоска). Так, при сохранении общей палитры, картинка будет куда аккуратнее.
PS: это прежде всего web гайдлайн, мобайл будет в следующих главах.
- Несбалансированные отступы (вертикальные/горизонтальные и внутренние/внешние).
- Неединообразие в формах. Например, плейсхолдеры: «имя пользователя» и «введите пароль» (глагола нет/есть). И далее про глаголы: зарегистрироваться, войти (неопределенная форма) и тут же рядом введите пароль, войдите через соцсети (повелительное наклонение).
- Пиксельные отступы (вот эти самые розовые кубики) бесполезны для верстальщика, потому что CSS не умеет откладывать расстояние от самого символа, а только от границ DOM-элемента.
- Нездоровая тяга везде впихнуть хотя бы немножко MD, чаще всего неуместная.
Уж очень напоминает старенький nvidia experiens
Из личного опыта.
- Обычно сначала составляем UI-kit — собирая в него все необходимые элементы (и для редакторов, т.к. все элементы всегда под рукой и для Axure для составления библиотек).
- Далее анализируем от чего можно отказаться, что можно стандартизировать — на выходе получаем документ с перечнем всех изменений, правок и т.п..
- Создаем (или правим существующий) гайд, где прописываем как какой элемент работает и его характеристики — это больше для дизайнеров. Соответственно для разработки можем из Axure выгрузить код.
Вообще, что для редакторов, что для Axure рекомендую юзать библиотеки — все всегда под рукой. Главное вовремя обновлять и актуализировать)
К шрифту Open Sans, который использовался в текущей версии сайта, у меня тоже возникали вопросы. Кажется, он всё реже встречается в повседневном мире.
Ага только Zeplin в годовом отчете говорили обратное: Самый популярный шрифт на всех платформах
Кейсы: разработка спецификаций и гайдлайнов (web ui kit)