Привет, Хабр! Меня зовут Лена Жукова, я фронтенд-разработчик в Сбертехе.

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

Привет, хабр!

Одним прекрасным вечером, не предвещающим ничего интересного, в наш чатик поступило предложение от автора публикации «Переводим в код 5 действительно полезных шаблонов адаптивной разметки», написанной им весной 2012 года, написать статью-ремейк, но с применением FlexBox и сопутствующим пояснением что и как работает. После некоторой доли сомнений, интерес глубже разобраться в спецификации все таки победил и я благополучно сел верстать те самые примеры. В ходе погружения в эту область стало выясняться множество нюансов, что переросло в нечто большее чем просто переверстать макетики. В общем в данной статье хочу рассказать о такой чудесной спецификации, под названием «CSS Flexible Box Layout Module» и показать некоторые ее интересные особенности и примеры применения. Всех кому интересно, любезно приглашаю под хабракат.

Отзывчивый дизайн — отличное решение проблемы корректного отображения сайта на разных экранах. Однако новичкам зачастую трудно понять основы, обучаясь только по книгам/статьям. С каждым днём появляется всё больше различных устройств, имеющих разные размеры экрана, поэтому создание дизайна в пикселях и только для настольных компьютеров/смартфонов остаётся в прошлом. Именно поэтому сейчас стоит изучить принципы отзывчивого дизайна — дизайна, совмещающего в себе адаптивность и резиновость (если вы ещё не знакомы с адаптивным дизайном, то эта статья будет хорошим выбором для начала изучения).

В начале 2014 года к нам в отдел контентных проектов пришла задача унификации дизайна. Дизайнеры хотели единый стиль проектов и принципы работы интерфейсов. Это будет удобно пользователям, облегчит запуск новых проектов и редизайн существующих (более подробно об этом писал Юра Ветров). Команда фронтенда получит возможность использовать схожие компоненты верстки на разных проектах, что уменьшит время разработки и поддержки существующего функционала. Для команды бэкенда задача оказалась нетривиальной: большинство наших проектов написана на Perl (Template Toolkit), Недвижимость на PHP, Дети и Здоровье используют Django. Но от нас требовалось реализовать не только поддержку единого шаблонизатора, но и согласовать единый формат отдаваемых данных в шаблоны. Обилие подгружаемых AJAX-блочков требовало поддержку еще и клиентской шаблонизации.

Таким образом, задача унификации дизайна превратилась в задачу выбора единого шаблонизатора для Perl, Python, PHP и JS.

От переводчика
Principle — приложение для Mac OS, которое позволяет в два счета создать анимацию элементов пользовательского интерфейса и сгенерировать его интерактивный прототип. Будь то многоэкранное приложение или просто придуманный вами контрол, так просто и быстро реализовать это раньше не позволял ни один сервис. Бенжамин Бергер — бета-тестер ранней версии Principle, описал свой опыт в статье на Medium, где рассказал о первых впечатлениях и привел пару наглядных примеров использования.

В первых частях серии статей о UX-стратегии я описал ее общее видение и дизайнера, который нам нужен для системного развития UX. Что должно быть результатом его работы?

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

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

Во время нарезки графики под приложения часто возникает множество сложностей: от разрешения устройств и проблемы с сетками и рекомендациями Google до непосредственно передачи приложения разработчику. За 2 года я работала над дизайном более 10 приложений, научилась находить решения самых разных проблем и делать так, чтобы в конечном итоге приложение выглядело так же, как и в дизайне.
Об этом и пойдет речь под катом.

Недавно мы в «Я люблю ИП» закончили курсы по дизайну от trydesignlab.com. И это одна из самых важных статей, которую нам посоветовал ментор в процессе обучения. Сегодня мы публикуем вторую часть перевода. Посмотреть все наши работы с курсов можно в ВКонтакте по тэгу #design101@iloveip.

Мы говорили о правилах создания чистых и красивых интерфейсов.

Вот эти правила:

1. Свет падает сверху (Часть 1)
2. Сначала черное и белое (Часть 1)
3. Увеличьте белое пространство (Часть 1)
4. Научитесь накладывать текст на изображения
5. Научитесь выделять и утапливать текст
6. Используйте только хорошие шрифты
7. Крадите как художник

В первой части рассказа об унификации продуктовой линейки Mail.Ru Group я описал наш первый подход к снаряду — решение для мобильного веба. Помимо создания единого стиля и принципов работы интерфейса для дюжины сервисов, мы смогли перестроить дизайн-процесс от классического «прототип → макет → верстка → код» для каждого экрана к более эффективному и современному, основанному на фреймворках. Во второй части я расскажу о переводе на эту же технологию более сложных и масштабных больших версий сайтов — как наш «Bootstrap на стероидах» стал еще мощнее.


Афиша, Авто, Здоровье, Гороскопы, ТВ, Недвижимость, Леди, Hi-Tech, Погода

Весной 2012 года в наше подразделение Почты и портала передали 11 контент-проектов — Авто, Афиша, Гороскопы, Дети, Здоровье, Леди, Мото, Новости, Погода, Спорт, ТВ. Многие из них — лидеры в своей нише в Рунете. Но история создания и развития у каждого была своя, так что дизайн делался по-своему, зачастую на аутсорсе, без систематизации и выработки общих подходов и решений.

Для нашей команды приведение их внешнего вида и логики работы в порядок стало одной из основных задач. А позднее — и необходимость унифицировать подход к дизайну. Простое и понятное решение — интерфейсно-визуальные гайдлайны для всей линейки продуктов. Они должны сделать работу пользователя понятной и предсказуемой — ему легко перейти с одного сайта на другой и не разбираться в новых паттернах взаимодействия. Это также усиливает бренд. И как приятный бонус — облегчает продуктовой команде развитие и поддержку сервисов.

В прошлой моей статье я затронул единицы измерения и тут же в комментариях начались на эту тему споры и обсуждения, поэтому я решил вынести этот вопрос в отдельный пост. Вот теперь и обсудим :)

При разработке дизайна необходимо учитывать корректность его отображения не только на больших экранах, но и на мобильных устройствах. И в первую очередь это касается читаемости контента. Поэтому необходимо уделять особенное внимание типографике, которая является основой веб-дизайна. На эту тему есть полезная статья шестилетней давности — Web Design is 95% Typography (автор Oliver Reichenstein).

Для начала рассмотрим основные моменты веб-типографики с примерами на мобильных устройствах.

Однажды вечером я почувствовал, что пришло время расширить 97‐ й параграф «Ководства» Артемия Лебедева.

На клавиатуре одна чёрточка, она обычно правее нуля и повыше букв «З» и «Х». Неосведомлённые люди называют её попеременно то дефисом, то минусом, то тире. Лебедев объясняет нам, что это четыре (учитывая две разновидности тире) различных символа. На самом деле их как минимум девять, и об этом я и расскажу вам сейчас.

В одной из предыдущих статей наши коллеги описали требования по передаче проекта от дизайнеров разработчикам мобильных приложений. Эти требования мы, как отдел дизайна в Rambler Digital Solutions, должны соблюдать.

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