Mikhail Koloskov
Mikhail Koloskov
Design Systems at Yandex.Money, Maintainer of whitepaper.tools

БЭМ-одержимость. Последствие параметрического дизайна

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

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

Мне, как дизайнеру, не хочется тратить 90% времени на формирование окружения (структуру, сборщики и другие подобные вещи). А писать HTML и CSS по старинке, я позволить себе не могу. Таким образом, появляется необходимость в среде для «умного» дизайна.

Анти-кастомщина

Какое-то время я был горд проделанной работой. То, тем как поменялись процессы в нашей команде, как мы выходили из полного дизайн-хаоса. Я описывал это в статье «Дизайн масштабируемых проектов». Но меня беспокоило несколько моментов. И ощущение того, что мы написали свою кастомщину (хоть и достойно справляющуюся со своими задачами) все чаще напрягало.

Все начало меняться, когда на одном из @cssunderhood, появился Виталий Харисов. Своими твитами он все сильней давил на те зудящие проблемы, имеющиеся в текущем процессе. И к концу недели я был совершенно обескуражен и не видел причин не попробовать БЭМ более основательно.

БЭМ как методология или что-то большее

К методологии БЭМ я пришел прогрессивным путем через МCSS. И вопрос об ее использовании, уже не стоял. Но «Дизайн в браузере» — итак жутко пугающая вещь для многих дизайнеров, а реализация его по БЭМ методологии ручными способами просто обескураживает.

БЭМ-больше чем просто методология

Вся проблема в том, что вы пытаетесь писать результирующий код. Но все резко меняется, когда вы ставите project-stub и пробуете описать ваш интерфейс на BEMJSON. Я бы сказал, что это своего рода точка невозврата — когда мышление, восприятие интерфейса, его конструкций и способ реализации, меняется бесповоротно. Вот для примера карта коммитов на github-е. Тут можно увидеть тот момент, когда я познакомился с project-stub

Bem-components

БЭМ-компоненты были одной из основных причин, чтоб начать использовать БЭМ. Они были идеальны для прототипирования. Хотя и конструкции компонентов, мягко говоря, не предсказуемые. Я думаю об этом можно догадаться по докладам из жанра — «Как сверстать кнопку». Но именно эти конструкции перекрывали все спорные моменты, с которыми раньше приходилось мириться или решать костылями.

Для меня была важна закономерность параметров. Зная, склонность к порядку БЭМ команды, я рассчитывал найти закономерность в Яндексовских интерфейсах. Посмотрев большинство Яндекс сервисов, я обнаружил большую разношерстность, несмотря на внешнее сходство всех проектов. И я решил, заточить дизайн среду под себя.

Распотрошил bem-components

  1. 1. Мой старт начинался с прототипирования на BEMJSON, c использованием bem-components. Для прототипов нужно было составить небольшие гайды. Так как я прошерстил несколько Яндексовых сервисов, у меня уже сложилось общее понимание, как устроен их UI, хотя общего между сервисами, за исключением веб компонентов, было не так уж и много. Я раздробил каждый сервис по нескольким составляющим: типографика, цвета, отступы, размеры контролов, конструкции и т.д. Найдя закономерности, опираясь на накопленный опыт в формировании живых стаил гайдов, я составил вот такой гайд для прототипов + заиспользовал bem-grid для конструкций каркаса страниц.
  2. 2. Второй глобальной задачей для меня было внести кастомность. Чтоб формировать проектный UI на базе сверстанного прототипа. И я начал с цветов. Оптимизировал bem-components, для удобной кастомизации их цветов.
    1. 2.1 Вытащил все цвета, которые были в файлах common.blocks/компонент/_theme/компонент_theme_island.styl. Получился 31 цвет (вместе с оттенками, прозрачностями и тд).
    2. 2.2 Привел все к hsla, чтоб были наглядно видно основные цвета.
    3. 2.3 Разбил цвета(оттенки) на группы, по основным цветам.
    4. 2.4 Вытащил в переменные основные цвета:
      • $base = #000
      • $active = #070
      • $link = #44b
      • $project = #fc0
      • $alert = #e00
      • $normal = #f6f5f3
    5. 2.5 Задал hue, saturation, lightness, opacity через Stylus.
    6. 2.6 Создал файлик design/colors.styl и импортировал его в стили компонентов.
    7. 2.7 Процесс оптимизации — codepen.io/koloskof/full/gaNGgB

      Что получилось — github.com/bemdesign/bemdesign-components/tree/cosmetic.

      Это было хорошее начало, но хотелось более гибкой настройки.

    8. 3. Проанализировал все параметры, которые нужно менять при формировании своей «темы», в соответствии со стилем проекта. Таким образом, их получилось 200 штук. Все они были вынесены в отдельный файл. Многие из них были неочевидны, так как отражали особенность конструкций БЭМ компонентов. Поэтому рядом с каждой переменной указано, что она меняет (сейчас процесс оптимизации продолжается)
    9. 4. Когда у вас есть большинство зависимостей для того, чтоб заниматься «Параметрическим дизайном», трудно остановиться. И захотелось сфокусироваться на типографике. По статистике Джефри Зельдмана, 90% составляющих интерфейса это типографика. И она заслуживала отдельного внимания, поэтому ее я вынес в отдельный компонент, с несколькими группами модификаторов. Что позволяет гибко, но достаточно дисциплинированно использовать ее в компонентах. (Пару значений размеров пересекаются с компонентами, на это стоит обратить внимание при кастомизации)
    10. 5. Стартонул базовый Kit, импортировав в блоки переменные отступов и цветов. Это сыроватый набросок открытого прототипа Kit-а с которым я буду довольно много экспериментировать, дошлифовывая БЭМ для своих дизайнерских нужд.

    Самая ценная дизайнерская инвестиция

    Хотя я проникся только начальной часть этой большой методологии, БЭМ стал для меня самой ценной дизайнерской инвестицией. Зная свою «симпатию» к «Дизайну в Браузере», могу сказать, что БЭМ делает его логичным, мощнейшим и самым естественным способом реализации качественного UI-я.

    P.S. Если вы не сделали первые шаги в БЭМ, как дизайнер, то у вас есть отличная возможность. Не стесняйтесь постучаться в БЭМ-сообщество, которое довольно активное и в моменты ступора направит вас в нужное направление.

    Stay BEMed!

Читать дальше

Параметрический дизайн. Следующие пол шага после Дизайна в браузере

Дизайн в браузере — Параметрический дизайн — Автоматический дизайн

Начну с фразы Григория Бакунова, которую большинство выпустили из внимания, но я не мог проскочить мимо нее.

«Произойдет вытеснение на рынок большого количество специалистов, которые в этот раз вместо того, чтоб рисовать дизайн, будут настраивать средства для построения автоматического дизайна»

Это было упомянуто в контексте автоматического дизайна, что сразу приковало мое внимание. Детально, я пока слабо представляю техническую реализацию автоматического дизайна, разве, что несколько размытых мыслей, не подкрепленных технологиями. Но понятно, что это будет сложная, интересная и гибкая экосистема.

Откатимся немного назад. Буквально года полтора назад, камнем преткновения были отрисованные макеты. Так, как основной проблемой, была разница в отображении/поведении возможностях графического редактора и живого кода. Затем многие «тру» дизайнеры, в основном проектные, перешли на сторону «Дизайна в браузере» и планка логики стала возрастать в довольно быстром темпе. Все синхронизировались в понятиях. Стало понятней общаться с интерфейсными спецами разных уровней и разных ролей (в интерфейсном процессе). Дизайн в браузере само собой точка не возврата, но это всего лишь отправной пункт долгого пути.

UI параметры

После того, как у вас сработал тумблер браузерного мышления, ваш мозг словно сняли с ручника и ощутив резкий скачек уровня проработки интерфейсов, вы жаждите нечто большего, еще более логичного, мощного и технологичного. И вы начинаете «потрошить» ваш интерфейс, искать изменяемые и неизменяемые части, смотреть то, как они взаимодействуют друг с другом, искать зависимости между ними. И после старта погружения приходит осознание, что весь UI это параметры.

Сопровождаясь жутчайшей депрессией и подхлестывающейся эйфорией, ваш привычный воркфлоу рушится. Реализация будущих проектов становится туманной. Но одно вы стабильно понимаете, что теперь не одна созданная вами UI сущность не будет нарисована/спроектирована просто так. Так как она должна четко вписываться в экосистему. Разумеется «порядка много не бывает», но чтоб ему соответствовать, сначала нужно его понять или выработать. И вы принимаетесь конструировать ваши гайды, чтоб определить тот порядок. А затем конструируете и проектный UI Kit. Без которого сейчас не делается ни один более или менее серьезный проект.

Время боя

И вот ваш арсенал заряжен и вы направляете его на «боевой проект». Но после нескольких выстрелов, у вас наступает легкий мандраж, относительно того, что ваша тяжелая артиллерия не настолько гибка и подвижна. Это мысли просто оккупируют разум. Есть понимание, что все идет как надо, логично и прогрессивно, но неприятное ощущение того, что где-то вы налажали, нервно зудит, плавно сводя с ума.

Снова параметры

После погружения внутрь себя, внутри интерфейса и анализа проблемы вы начинаете слышать трезвые голоса, указывающие, что основная задача- сделать экосистему гибкой к изменениям. И решается это все некими интерфейсными зависимостями, вынесением изменяемых частей в переменные, еще более жесткими гайдами, и структурными правилами формирования интерфейса. Теперь вы чувствуете себя «интерфейсным богом». И осознаете, что «правильный» UI не может рождаться вне браузера, так как появляется множество цепочек зависимых параметров. По сути вы разработали ваш собственный UI фреймворк «идеально» заточннный под ваши задачи и проекты.

UI фреймворк

Если отбросить шелуху, то ваш UI процесс это обработка и классификация данных по определенным параметрам, руководствуясь логикой и закономерностью. Ваш результирующий интерфейс не имеет совершенно никакой ценности (сейчас я имею ввиду непосредственно саму «материю», не опираясь на исследования, опыт и тд. Пока у UX-ов не пошла пена изо рта) и совсем неважно, сколько времени вы потратили на его воспроизведение. Важнее то, насколько проработано ваше ядро и как быстро и гибко бы сможете воспроизвести точно такое же и еще сотню подобных, в плане самой мануфактуры. Тогда процесс приятно переходит от бесконечного рефакторинга к последовательным улучшениям.

Естественное улучшение

В определенный момент интерфейс проекта достигает момента, когда его перестает лихорадить. Своего рода cтабильная версия. И тогда требуется точечное улучшение. Тут важно не закопаться в локальных правках. Если у вас появляется нужда, внести много стилистических локальных правок в какой-то компонент, это сигнал, который может означать две вещи:

  1. 1. Либо вы занимаетесь «кастомщиной», в следствии вкусовщины, и не совсем хорошо осознали ваш UI.
  2. 2. Ваш базовый Kit не достаточно гибкий для того, чтобы позволить внести разумные модификации в компонент.

Осознанный UI – это, когда вы с каждой итерацией, учитесь находить все больше параметров и начинаете их упорядочивать. А потом выстраиваете алгоритмы для их улучшения.

Design must be killed

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

Роль и тип данных

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

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

Аскетичность в дизайне

  • Радикальный минимализм, как высшая степень логичности. Так как все параметры подконтрольны.
  • Конструкции в соответствии с методологией, для переиспользования и масштабирования.
  • Логично раздробленный контент, готовой визуализации.

Убиваем эмоции в дизайне

Явные «вульгарные» эмоции должны быть начисто искоренены в дизайне. Это единственный способ сделать интерфейс эффективным. Все должно подчиняться логики и системности, а пользователь и реакция интерфейса должны быть взаимообучаемы.

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

Алгоритмы

Когда ваш интерфейс причесан, осталось еще пол шажка для того, чтоб вы перестали думать материями (макетами/экранами) и подняться на еще более высокую абстракцию. Начать думать алгоритмами, через которые будут проходить ваши дизайн сущности. Алгоритмический дизайн это следующая ступень, которая сбрасывает все ограничения, делающая ваш интерфейсы гибче, точнее. Фактически ваше интерфейсное ядро это API, которое вы прогоняете через какие-то процессы, получая новые, гибридные комбинации и выдаете восхитительный результат.

Естественная потребность массовости

После прохождения всех кругов «автоматизированного ада», вы понимаете, что ваш подход настолько хорош, насколько вы могли от него ожидать. И у других участников секты он тоже хорош. Но у вас нет точек соприкосновения и это угнетает настолько, что вы готовы взять чужой подход и адаптировать его под себя, просто для того чтобы быть частью чего-то большего, чем просто ваши проекты. (подробнее об этом в «БЭМ одержимость. Последствие параметрического дизайна»)

2016

С параметрическим дизайном трудно смириться, особенно если вы еще из разряда староверов и ваши «религиозные» дизайнерские барьеры сковывают вас. Не откажу себе в удовольствии, лишний раз, искусить и порекомендую почитать предновогодний @cssanderhood (вел Андрей Ситник) 24.12.2015 о ближайших тенденциях, вроде медиа-запросов, зависящих от контейнеров (а не от размера экрана), оберток задающих поведение внутренним блокам и тд. Спросите себя, насколько готова ваша среда для проработок таких интерфейсных решений.

Смерть жутко интересна

Закончу пост тоже фразой Григория Бакунова: «Все разработки связанные со смертью какой-то профессии — жутко интересны». Но на самом деле, дизайн бессмертен — так как это слишком широкое понятие. Но все попытки его убить, выталкивают его на невероятно новый уровень…

Читать дальше

Ask me anything

Can you introduce yourself?

My name is Mikhail Koloskov. I am from Saint-Petersburg (Russia). My current position is UI Engineer. I work at the product company. Here I can not only develop my own skills but also bring new fresh ideas in the work process.

I was hired as a HTML coder. Not too long ago I had a chance to work on different projects, using different skills and had an opportunity to challenge myself at the different positions. Currently I am working on developing the interface by using the living style of guides and components.

I concentrate my job on developing the main product of this company (desktop and mobile versions). It is a great opportunity for the future and experience in the field of the product designer.

What is your approuch about?

I am evangelist of Design in the Browser. It helps to connect different designers/developers and allows to use the eco system by adding new technologies in the base stack.

Ideas of design unification keep my mind occupied. I really avoid "hell of customizing". It helps me to make my process clean. It's actually strong side of my thinking. I feel comfortable by using this approach because all of my UI really ready for scale at any time.I don`t want to find something new helpful services and change my native tools at this time. I am going to boost(force) my approach to the next level after including some "killing" features.

I am not a big fan of UX. I think only tests can show the right way. Don't be talk about it. My opinion is very long about it.

I don't want to create an art, I want to make interfaces. I try to connect guides and prototypes using frontend technologies. Its my self-expression. I am trying to keep outside artist inside me. I don't like the artist side in engineering process.

What are your hard skills?

I don't try much of prototyping tools. Because I have a deep understanding of HTML/CSS and basics of JavaScript. I use some steroids like preprocessors, task runners and etc. I got understanding about responsive, quirks of screen, behavior of elements in different environment. And how to make engineering well.

What are your soft skills?

I am not afraid of getting the new responsibilities.

I am a team player. I can see strong side of people around me. I love to inspire and motivate people to do fantastic UI projects.

What is your strong side as a designer?

For me the most important part of design is efficiency. I don`t like to do something for fun. I try to do useful staff.

You should have not only good taste, also you must get perfect engineering thinking. It makes your UI better.

Collaboration is good but designer should be strong/confident member of team.

What is perfect UI for you?

I think perfect UI design consists of 3 main parts: visual part, structure and file architecture. It allows to make you UI reusable.

What is your daily routine?

I try not to deep to daily routine. I meet with more and more challenges every day. Instead of doing huge amount of crazy work I optimize my process.

I always incorporate with many different skills to reach a better results and to make a good assets for next steps of the development

What is your plan for the future?

Right now I invest my time to BEM methodology. Because it's really good for making logic and scale-able interfaces by working in a huge team. It is really incredible.

I don't like to invest my time to get the result (do everything for finish project). Because it's very simple and unscale-able (non profitable). I prefer to invest my time to the process, making it's flexible. Because I am really confident that good design can be available and fast making.

I grind my craft every day. I expect a lot of team work with some strong designers.

I don't want to work on manager's position because Regular management often ditch any project. Regarding modern practice, I think that management is old school sh*t.

I want to invest time for increasing my skills. I do a lot of things every day and It helps people to get more clear opinion about me.

Sometimes I like to promote myself. I really want to start writing English version of my blog http://koloskov.kz. I want to get new professional connections with awesome designers/developers. Get more inspirations and provide my vision on "UI making"

I think design is kind of fun but on the other hand it is the main craft (deal) of my life. I am going to be more productive as a designer.

Feel free to write me on twitter @koloskof

Читать дальше

Вскрытие магии или дизайн масштабируемых проектов (Часть2)

Реорганизация команды

На самом деле невероятно трудно реорганизовать устоявшуюся команду, озадачить всех новыми обязанностями и сказать, что теперь будет по-другому. Здорово, когда все сами осознают слабые места процесса и готовы меняться. Для того чтоб все закрутилось, лучше всего использовать промежуточные звенья в виде гибридных спецов.

Этапы

Работая на “конвейере”, я был в недоумении, насколько раздроблены дизайнерские мощности у “звездных” проектных команд, но окунувшись в обдуманный дизайн и проанализировав основные этапы, я пришел к аналогичному разделению. Их оказалось 6, но это не имеет прямое отношение к количеству участников на проекте. Скажу, что для хорошего темпа, качества и прогресса нужно как минимум 4 (дальше в зависимости от проекта, ожидаемой скорости и слаженности спецов). У нас интерфейсные мощности на каждом проекте существенно меньше, но часть участников очень гибридны и способны видеть результат в целом. Но не стоит рассчитывать на удачу и все-таки избавить команду от перегорания. Скажу по себе, у нас все движется в большей степени благодаря энтузиазму.

Вот основные этапы, которым мы следуем:

AI/UX

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

Elements/Images/Illustrations

Подготовка кирпичиков для строительства.

Prototyping

На этап прототипирования уже идут реальные конструкции, предусматривается структура, тех. характеристики и особенности устройств экранов.

UI/Motion

Непосредственное аккумулирование предыдущих этапов в понятный для восприятия вид, проработка динамики и поведения.

Components/Motion

Формирование интерфейсной архитектуры, библиотеки компонентов, написание анимации на CSS.

Development

Сборка. Подготовка интерфейса для дальнейшей работы и непосредственно работа фреймворком.

Навыки

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

База, которая необходима для команды:

  • HTML/CSS/JS (базовый минимум)
  • Основные принципы БЭМ методологии (без тех деталей)
  • Sketch
  • Совсем скоро будет включен инструмент для динамики

Так же нужно четко отладить обмен знаниями, опытом внутри, чтоб приравнять общие силы и просто начать распределять роли.

Преимущества

Дело не в преимуществе, а в том, что прокачка себя и процесса просто необходима, чтоб поддерживать работоспособность хотя бы на прежнем уровне (реагируя на новые требования)

Трудности

  • Относительно высокий порог входа
  • Адаптация нового участника команды (3–4 месяца

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

Ликвидируем любые намеки на клиентский подход

Необходимо разделить проекты на сервисы и контентные (поддерживаемые / не поддерживаемы интерфейсной командой). Это поможет лучше спланировать ресурсы.

Каждый поддерживаемый проект это отдельная “компания” со своей командой, оптимизированной под эти нужды, а не несколько участников, выдернутые из общей кучи, для цикла работ.

Общая методология, как фундаментальная база для того, чтоб при работе на новом проекте, участнику нужно было только вникнуть в предметную область и особенности, а не вникать в то, как устроена вся работа.

Роли

Понятие “статуса” спецов не актуально. И я совершенно не верю в вертикальную систему — корпоративщину. Но мне часто хватает участника команды внутри проекта, типа “консультанта”. У которого есть хорошая база и опыт, компетентность в проекте. Который способен посмотреть на процесс в общем. Четко спланировать задачи и действия других участников для повышения эффективности. (Мне, да и думаю всем, этого очень не хватает. Приходится отрываться от задач, заниматься анализом/исследованием проблем, багов + поиском инструментов/решений. Что, мягко говоря, не продуктивно).

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

Платформы

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

Убеждение

Попросить месяцы времени на эксперименты очень дико звучит для большинства менеджеров и если в вашей команде проблемы с убеждением лучший способ, запилить небольшую связку и показать наглядно. У нас с этим проще, так как все были заинтересованы и поддерживали процесс. Но экспериментальных месяцев у нас все же не было.

Модернизация

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

Читать дальше

Вскрытие магии или дизайн масштабируемых проектов (Часть1)

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

Технологии

Методология верстки

На тот момент наша команда верстальщиков была еще совсем не большой. Но у каждого были свои особенности/стиль верстки и разные инструменты. Это усугублялось грузом в виде старых поддерживаемых проектов. Учитывая небольшую и готовую к переменам команду, мы начали процесс притирки. Не буду углубляться в детали. Хоть на то время нам явно не хватало верстальщеских мощностей, но тот количественный и личный состав был именно тем, что надо. Так у всех был опыт, доля экспертности в смежных областях и нужный азарт.

В итоге была выбрана методология многослойного CSS, основанная на БЭМ. Не обошлось конечно без пары напряженных код ревью, но в целом синхронизация произошла на том уровне, чтоб можно было не бояться масштабироваться. На самом деле, этот процесс не останавливается и сейчас, с учетом добавления новых участников в команду и внедрение технологий. Но это уже логичное развитие.

Препроцессор Sass + Bourbon

Пробовали все, но остановились на Sass. Различия между всеми были не настолько критичны для нас и по сути на том этапе мы могли взять любой. Но Less уже умирал, Stylus только оживал, а Sass был проверенным и дико популярным (Я очень падок на популярность, за что меня чаcто “ругает” команда). Про PostCSS тогда еще не слышали, но сейчас его уже трудно игнорировать. В качестве библиотеки примесей взяли Bourbon.io вместо Compass (нам он пришелся больше по душе)

Документация

Документация. Её роль трудно переоценить. Особенно когда идет становление процесса. Честно признаться, нам сильно повезло и мы долго не парились по этому поводу. Не потому что мы халатно к этому отнеслись, а просто альтернатив практически не было. Насколько я знаю, их и сейчас нет. А SourceJS идеально вписывался под наши требования. Нам достаточно было увидеть небольшую демку еще тестовой версии, чтоб убедиться в её крутости. Конечно настройка ее заняла достаточное количество разработческих ресурсов.

Гайды и элементы

Следующий этап синхронизации был более сложен. Так как он вовлекал дизайнеров. Но инициативность была ответной. Я помню, как получил графический файлик от дизайнера с несколькими кнопками и контролами. Я непременно заверстал это, добавив еще элементов и типографику. Дальнейшее развитие этого уже было вопросом времени.

Структуры еще не было но нужно было обозначить кирпичики.

Гайды и элементы

Мы разбили весь интерфейс на мелкие оставляющие:

  1. 1. Цвета (базовые + цвета проектов в связке с Sass переменными. Тем самым мы имеем достаточно небольшое и самое нужное количество цветов, а все остальное это производные от них через Sass. И для новых проектов нам достаточно указать основную переменную цвета, а все производные от нее генерируется автоматически)
  2. 2. Типографика (спасибо Горбунову, мы тщательно изучали его статьи)
  3. 3. Инпуты и текстовые поля
  4. 4. Чекбоксы и радио (знаю что есть много споров на этот счет, но но мы не смогли перешагнуть через элементарную эстетику, поэтому все мы их все таки стилизовали)
  5. 5. Селекты (ситуация аналогичная)
  6. 6. Списки

Косметики

Это те свойства, которые мы можем применять в любых компонентах и элементах на любом проекте.

  1. 1. Внутренние и внешние отступы с шагом
  2. 2. Display (block, inline-block, inline)
  3. 3. Отступы внутренние и внешние (с шагом)

Архитектура

На первый взгляд все довольно просто понятно и логично. Есть проект, внутри папка компонента, в которой лежит разметка, стили, js и изображения, но был один нюанс в том, что проектов у нас не один и не два, как минимум старт начался с 4 одновременно. В них было много общего, но также было много различий, мы хотели максимально избежать дублирования кода. Сделать какую-то общую эко-систему, но всё же иметь возможность безболезненной модифицировать каждый проект по отдельности. После пары недель обдумывания, выкристолизовалась явная структура всей системы. Несомненное в течении нескольких месяцев после этого мы не раз все допиливали, пробегаясь по проектам. Мы сделали общий кит (для всех проектов), составляющие которого потом импортировались из проектов и уже там переопределялись.

Общий кит

                    kit/
                       ├── base
                       │   ├── fonts
                       │   ├── index.html
                       │   ├── stylesheets
                       │   │   ├── lib
                       │   │   │   ├── bourbon
                       │   │   │   └── custom
                       │   │   │       ├── lib-1
                       │   │   │       ├── ...
                       │   │   │       └── lib-4
                       │   │   ├── sass
                       │   │   │   ├── _base.sass
                       │   │   │   ├── base_.sass
                       │   │   │   ├── _cosmetic.sass
                       │   │   │   ├── cosmetic_.sass
                       │   │   │   ├── _variables.sass
                       │   │   │   ├── _mixins.sass
                       │   │   │   └── _icons.sass
                       │   │   └── css
                       │   │       ├── base.css
                       │   │       └── cosmetic.css
                       │   └── js
                       │       ├── lib
                       │       │   ├── lib-1
                       │       │   ├── ...
                       │       │   └── lib-4
                       │       └── custom
                       │           ├── lib-1
                       │           └── lib-2
                       └── components
                           ├── index.html
                           └── stylesheets
                                ├── sass
                                │   ├── _components.sass
                                │   └── components_.sass
                                └── css
                                    └── components.css
                  

Кит проекта

Сюда импортируются составляющие кита и переопределяется здесь, в зависимости от требований проекта.

                    project/
                       ├── base/
                       │   ├── index.html
                       │   ├── stylesheets/
                       │   │   ├── sass/
                       │   │   │   ├── base.sass
                       │   │   │   ├── _variables.sass
                       │   │   │   ├── _mixins.sass
                       │   │   │   └── _icons.sass
                       │   │   └── css/
                       │   │       └── base.css
                       │   └── js/
                       │       └── main.js
                       └── components/
                           └── stylesheets/
                               ├── sass/
                               │   └── components.sass
                               └── css/
                                   └── components.css
                  

Директории компонентов

Тут все просто, это изолированный самодостаточный кусок, который может реиспользоваться и модифицироваться.

                  project-1/
                     └──component-1/
                        ├── index.html
                        ├── stylesheets/
                        │   ├── sass/
                        │   │   └── component-1.sass
                        │   └── css/
                        │       └── component-1.css
                        └── js/
                            └── component-1.js
                  

Вся экосистема

Структурно вся эко-система выглядит примерно так.

                    eco-system/
                       ├── kit/
                       │   ├── base/
                       │   │   ├── fonts/
                       │   │   ├── index.html
                       │   │   ├── stylesheets/
                       │   │   │   ├── lib/
                       │   │   │   │   ├── bourbon/
                       │   │   │   │   └── custom/
                       │   │   │   │       ├── lib-1
                       │   │   │   │       └── lib-2
                       │   │   │   ├── sass/
                       │   │   │   │   ├── _base.sass
                       │   │   │   │   ├── base_.sass
                       │   │   │   │   ├── _cosmetic.sass
                       │   │   │   │   ├── cosmetic_.sass
                       │   │   │   │   ├── _variables.sass
                       │   │   │   │   ├── _mixins.sass
                       │   │   │   │   └── _icons.sass
                       │   │   │   └── css/
                       │   │   │       ├── base.css
                       │   │   │       └── cosmetic.css
                       │   │   └──  js
                       │   └── components/
                       ├── project-1/
                       │   ├── base/
                       │   │   ├── index.html/
                       │   │   ├── stylesheets/
                       │   │   │   ├── sass/
                       │   │   │   │   ├── base.sass
                       │   │   │   │   ├── _variables.sass
                       │   │   │   │   ├── _mixins.sass
                       │   │   │   │   └── _icons.sass
                       │   │   │   └── css
                       │   │   │       └── base.css
                       │   │   └── js/
                       │   │       └── main.js
                       │   ├── components/
                       │   │   └── stylesheets
                       │   │        ├── sass/
                       │   │        │   └── components.sass
                       │   │        └── css/
                       │   │            └── components.css
                       │   ├── component-1/
                       │   │   ├── index.html
                       │   │   ├── stylesheets/
                       │   │   │   ├── sass/
                       │   │   │   │   └── component-1.sass
                       │   │   │   └── css/
                       │   │   │       └── component-1.css
                       │   │   └── js/
                       │   │       └── component-1.js
                       │   ├── ...
                       │   └── component-24/
                       ├── ...
                       └── project-8/
                  

Интеграция

Для начала нужно просто разметить основной каркас, а затем наслаждаться процессом интегрирую компоненты в сетку.

Что дальше?

Дальше будет все более плотная интеграция с front-end процессом и повышение доступности/скорости для UX набросков. Это поможет стереть жесткие грани и заняться инженерией.

Кину для затравки несколько “инструментов”, которые нас уже ждут: #BEMJSON #BEMCOMPONENTS #Protein.io #FramerJS

Читать дальше

Подсел на верстку

Периодически меня спрашивают о том, как и с чего начать в верстке/дизайне. У меня всегда было два основных принципа на этот счет. Совершенно открыто спрашивать то, чего не знаю и с удовольствием делиться тем, чем я могу быть полезен. Буду рад поделиться тем, как я неумело стартовал, что мной движет сейчас и какой вектор задан на будущее.

Каждый раз, когда я садился редактировать этот пост, меня начинала захлестывать новая порция мыслей и эмоций. Поэтому я решил, что подводить итог не логично и решил оставить пост открытым. Своего рода «дневник наблюдений». С помощью которого, в хронологическом порядке можно проследить за моим образом мышления на этапах развития.

Прощупывал почву

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

Веб разработка затянула меня намного позже и я еще не знал как занашиваться, поэтому пошел напролом и начал с программирования. На 3-м уроке я понял, что с алгоритмическим мышлением у меня проблемы и бросился в совсем другую сторону — Дизайн. Я успешно прошел курсы, затем несколько часов практики. Абсурдность рисования psd я осознал еще тогда (4 года назад). Но не хватало опыта и хотя бы минимальной экспертности предложить альтернативу.

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

Первый раз потрогал фриланс

Фриланс я начал применять на себе с первых дней, как начал делать какие-то осознанные вещи. Дикого успеха не получилось, тем более тогда для меня понятие фриланс, как и для многих дилетантов в этом деле, ассоциировалось только с сайтом free-lance.ru . Меня смущал дикий уровень, даже я бы сказал не знакомый уровень конкуренции и мизерная оплата. Массы, голодные до работы, c достаточно «хреновым», но огромным портфолио и готовыми работать за копейки. После такого рабского зрелища я подумал, что ловить мне там особо то и нечего. И занялся дальнейшей самопрокачкой.

Нишевание

Меня реально вставляло, что я делаю. Я прогрессировал довольно быстро. Я делал много не особо нужных действий, которые можно расценить как ошибки и в тоже время, это здорово пригодилось. Для меня, наверное, как и для многих, года 4 назад, не было особо четких разделений в разработке. Я эксперементировал с дизайном, верстал не понимая зачем. Затем шла череда каких-то блогов, непонятных проектов. А на SEO я залипал вообще по тяжелому. Бесконечная оптимизация и без того ужасных сайтов. Просмотр канала MegaIndex был для меня регулярной процедурой. Меня дико пёрла вся эта тема. Но гадость всего была в том, что я не мог нормально сфокусироваться на конкретной нише. И от этого я испытывал дискомфорт. Понятно, что соседу я мог сказать, что я делаю сайты. Но в нормальной тусовке спецов, позиционировать себя веб-мастером было все равно, что сказать «я туповатый студент, который нахватался верхушек веба и корчит из себя спеца».

На место мой мозг встал только после того, как я переехал в Питер. Этот город, как зоопарк из разработчиков, дизайнеров и прочих персонажей. Главное было не стать жертвой. Мои амбиции зашкаливали, поэтому меня трудно было чем-то особо смутить. Хотя знаний и опыта особо не было. Нужна была «боевая среда». Я раскинул мозгами о том, что может быть моим основным козырем, и из всего, что я умел делать по-немногу, в верстке я соображал лучше, чем во всем остальном. Буквально на втором собеседовании я попал в студию к полным фанатикам.

Боевое крещение

Эти ребята были реально включенными на верстку. Вся фирма затачивалась, как аутсорсинговое агенство. Они верстали для реально топовых, на тот момент, Российских студий. Требования к коду были максимально жесткими. А для меня, новичка, плавающего в основах, это был реальный марафон. Но меня продолжала привлекать вся это айтишная движуха, я даже не скажу, что я просто работал. Тот момент моей жизни можно было охарактеризовать так «верстать, есть, спать». Но, к сожалению, парни не умели делать бизнес выгодный всем. Зарплата была по-проектная, сотрудники работали за мелкие подачки. В таком режиме я смог проработать около трех месяцев. Но ни капли не жалею об этом. На месте новичков, я был бы готов сам платить, чтоб пройти боевую школу. После такой школы меня, конечно, ничто не могло напугать, работы я не боялся. Так резво стартовал мой верстальщеский путь. Дальше была работа в студии и масса другого опыта, но не буду вдаваться в биографические подобности. За это время я обращал и продолжаю обращать внимание на разные детали. Вот несколько тем:

Хороший план залог хорошей работы

Долгое время я сильно пренебрегал дисциплиной. Но как показывает практика, великие дела это не внезапная вспышка, a стабильная и методичная работа, выпущенная, как джин из бутылки в нужный момент. К тому же концентрация мысли разрывает мозг при формулировании, но помогает точно действовать при реализации. Так, что планирование, определенный распорядок и постоянство в делах приковывает все больше моего внимания.

Менеджеры

Мое участие на том или ином проекте и весь сценарий действий, обычно курирует менеджер. С этими ребятами рабочие отношения разнятся. Некоторые реально могут подталкивать к эффективным действиям, другие заставляют долбиться в стену. Основная мотивация для плохого менеджера — не отгрести от начальства, для хорошего — аккумулировать силы, максимально, эффективно и ювелирно решить задачу. Хороший менеджер имеет возможность продавить подход. Если учитывать высочайшее качество, как не оспоримый факт, а отличное команду, как основной инструмент, менеджеру остается балансировать временем.

Мотивация

Органически не воспринимаю инструменты мотивации. Так как большинство отличных спецов, в ней не нуждаются и работают с максимальной отдачей. Часто менеджеры любят искушать дополнительными бонусами, но к большей продуктивности это не ведет. А только подталкивает к сомнительным схемам, которые ведут к провалу.Рецепт выхлопа достаточно незамысловатый:

  • Учет пожеланий спецов при распределении задач и проектов
  • Более, чем приемлемые условия для работы и отсутствие материальных причин заглядывать на фриланс
  • Не мешать

Мое мнение о продуктивности

Держу максимальный темп в те моменты, когда меня прёт. И удерживаю средний, но стабильный темп работы, когда ничего не хочется делать. Не верю в пляски с бубном вокруг терминов, состояния потока и прочей маркентингово-окультической хрени. Есть два состояния — прёт и не прёт. Но работать надо всегда, чтоб не стать «желе». Особое состояние в пятницу вечером, когда от утомления мозги на пределе, и после того как все дела отпадают, ловлю приятный момент, чтоб кинуть, на еще кипящие мозги, полезную работу. Так сказать работа на угасании. А иногда запал начинается с вечера воскресенья и тогда стартую неделю уже разгоряченный.

И все-таки главное топливо продуктивности, мощные и цепляющие задачи, совпадающие с личными интересами и амбициями.

Заведомо проигрышная позиция

Люди умирают в 25, а попадают в могилу в 75 — чья-то цитата, которую я увидел в книге «Сомнение» Славы Баранского, правда не помню Автора.

Моя так называемая «смерть» произошла немного раньше. Чуть больше года назад, я почувствовал ту самую, ужасную, безысходную «стабильность», в самом отвратительном ее проявлении: 9 часов ада, за зарплату далекую от хорошей, хроническая утомляемость, сомнительные перспективы роста. Часто после этого люди любят менять специализацию, но обычно это признак слабости характера. К которой я отношусь с пренебрежением и долей отвращения. И на пике усталости, меня как будто переклинило.

Смысл в том, чтоб максимально повысить собственную заинтересованность, именно в рабочее, самое, продуктивное время, а не истязать себя вечерними пытками после работы, чтоб приглушать амбиции.

Слышал о старом методе пыток, когда заставляют делать бесполезную работу — перекатывать камень. Свой камень (в виде идиотского проекта, c халатным менеджерским отношением) я катал пол года по 8-9 часов. И приложу максимальные усилия, чтоб не оказаться под пытками снова. Полностью согласен с фразой одного из сотрудников яблочной компании: «В условиях жестких делэдлайнов настоящие иновации невозможны».

Техника «Съешьте на завтрак лягушку», не мой случай. В эффективные часы я вы выполняю те дела, которые меня просто тащит делать, эти удивительные часы продуктивности, дают максимальное количество полезной работы. А тянущиеся дела, долгое время, либо отпадут сами собой, либо достигнут критичности и обратят на себя внимание. Размениваясь на тягомотину, я всегда рискую отстать в самом важном.

«Если ты не воплощаешь свою мечту, ты воплощаешь мечту кого-то другого». Не нужно понимать это в лоб. Это не значит что, нужно немедленно кидаться пилить свой стартап. Сейчас у меня нет такой навязчивой идеи. Но это не значит, что я поставил крест на своей мечте.

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

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

Читать дальше

Дизайн в браузере

Для прогрессивной визуальной разработки нельзя просто внедрить пару тройку фишек. Нужно радикально изменить сознание и фундаментально поменять подход. Я не буду разбивать процесс на избитые заезженные этапы. Опишу более свежо. Две основных составляющих агрессивно нового подхода: «Дизайн в Браузере» и «Автоматизация фронт-энда».

Начнем с первого — «дизайна». Тут проблема в отношении к дизайну как к статической .psd. По ощущению это должно было потерять свою актуальность в тот момент, когда появился адаптив, добавилась динамика и доработка на живую макета стала привычным делом. Теоретически смерть статичных .psd-шек наступила вместе с отходом табличной верстки. Зачем пытаться оживить то, что отслужило?! Тогда это было актуально, так как фактически в таблицу запахивалась картинка макета, только в нарезанном виде. Сейчас же макет выполняет роль ориентира. В большинстве случаев мы не вырезаем ни пикселя. А просто держим макет открытым в соседнем окошке. Для того, чтобы написать всю эту «красоту» кодом.

Дизайн меняется

Сегодня получать картинку с огромным описанием поведения, которое «дизайнеры» определили на глаз в инструменте крайне отдаленном от веба, глупо и неразумно. Макет, вышедший с экрана дизайнера может поменяться по пути к верстальщику. И вы получите огромное количество комментариев и пожеланий, которые невозможно отразить на картинке. Альтернативный подход — разрабатывать дизайн непосредственно в родной среде, то есть в браузере. Видно, как стремительно набирает популярность такой подход.

Кто использует прогрессивный подход?

Ребята на питерском WSD достаточно наглядно показали свои живые прототипы финансовых аппликаций.

Буквально в начале месяца был отличный доклад Антона Виноградова @awinogradov из Альфа-лаб на BEMup, где он буквально за несколько минут оперативно набросал верстку приложения Яндекс.такси

Ну и конечно, ждем связку внутренних продуктов ребят из «Одноклассников» Lego + SourceJS Насколько я понял из небольшой демки в скринкасте от Роберта @operatino интерфейс будет собираться из подготовленных, сверстанных и задокументированных блоков. А пока можно навести порядок, используя документацию верстки на SourceJS. Полезная привычка, которая окупается сполна.

И, конечно же, доклад Ильи Пухальского @pukhalski Rest in PS. Очень здорово и наглядно разъяснил аналогичную тему.

Это самое заметное, что видел за последнее время. Плюс несколько моментов, обсуждаемый в частных беседах. Этих аргументов и примеров вполне достаточно, чтобы понять превосходство такого подхода. Остается попробовать и вряд ли вы вернетесь обратно к старому «пещерному ремеслу» вычиканивания .psd.

Переход в «правильную» среду

Разработка веб-дизайна в инструментах для него не предназначенных — отчаянный и тупиковый подход. Если отбросить дрибббльную эйфорию, я не знаю, насколько конкретно могу назвать дизайнерами тех, кого принято считать таковыми в не совсем заметных агентствах. Это, как правило, «персонажи», на которых сваливают непосильные обязанности. В общем, они рисуют весь внешний вид, не всегда опираясь на логику, и команда слепо верит на слово. Часто они лезут не в свою область, пытаясь опровергнуть привычное поведение. Но при этом верстальщик должен им отправить макет, который они пристально осматривают и говорят правки. Самое абсурдное, что за эталон в сравнении берут свой .psd файл. Который часто противоречит здравой логике. Глупая ситуация, не так ли?

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

С толку сбивает огромное количество разношерстных инструментов, которые используются для визуальной части: Axure, Sketch, Photoshop и еще несколько менее известных вещей уже на любителя.

С анимацией дела обстоят гораздо печальней. Тут о привязке к среде вообще речь не идет. Над анимацией извращаются в редакторах для видео, или фигачат несколько картинок, чтобы склеить в .gif. Но в итоге все переписывается на HTML/CSS. Не сильно ли трудозатратный процесс с размазанными промежуточными этапами?!

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

Как внедрить в работу

Есть вариант сделать все довольно безболезненно. Для этого стоит отбросить клише в виде «дизайнер — проектировщик, ..., верстальщик». А использовать сильные навыки участников команды. Базовые этапы выглядят так:

1. Разработка общих гайдов

Базовые элементы, которые нужно стилизовать: заголовки, h1 h2 h3, абзацы, ссылки, списки, таблицы, копки, инпуты, селекты и.т.д. Основные стили мы можем сложить в базовый CSS файл. Он будет всегда лежать в нашем стартовом ките.

2. Логические независимые блоки

Обычно это 20–30 размеченных основных блоков. C которых можно легко стартовать. В дальнейшем, пополняя библиотеку, делая ее более масштабной и удобной. Штурмовать каждый новый проект с таким арсеналом будет все приятней. К примеру, это может быть форма регистрации/авторизации, комментарии и другие часто встречающиеся в ваших проектах блоки. Все они аккуратно докумментируются, что позволяет с легкостью их переиспользовать и модифицировать.

Мы делаем:

  • набросок версткой структуры блока
  • общую стилизация, учитывая гайды (1 этап)
  • разные состояния и анимацию.

3. Сама структура сетки

Берем во внимание поддерживаемые устройства и медиа-запросы. Упор идет на продумывание базового фундамента. Для любителей адаптива это будет максимально полезно, так как есть возможность сфокусироваться на каркасе, это даст большую осмысленность. Как вариант, продумать качественную сетку (возможно, взять готовое решение и доработать по необходимости).

4. Интеграция

Здесь не нужно много думать над разработкой. Мы просто интегрируем заранее подготовленный модули (2 этап) в наш каркас (3 этап). Достаточно сделать пару небольших допилов и восторгаться результатом. Так сказать, ощутить всю магию модульного подхода.

Фанатики продавят идею

Понятно, что стартовать меняя привычную систему в целом либо страшно, либо влом. Но есть масса ребят, пропагандирующих и наслаждающиеся методологией. Масса — это сила, которая толкает вперед. Так что процитирую одного дизайнера: «велкам в секту». И поменьше вам статики.

Читать дальше

По пояс в прототипировании

Вникаю в тему

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

UX + UI

Отлично, когда человек может думать наперед, собрать в кучу несколько факторов и выдать нужный результат. Но спецам, вникающим в отрасль со старта, это не по силам. И в реальности, такая разбивка жестко прослеживается:

  • Ребята, заточенные на дрибббл, с шикарными конструкциями, приятными эстетически. Но в отрыве от реальности. Так сказать интерфейс ради интерфейса.
  • Теоретики. Любители строить гипотезы, давать экспертную оценку. Отчаянно пытающиеся понять пользователя. Но не представляющие реализацию.

И очень заметно как тех или других, узко занишеванных спецов, пытаются озадачить и теми, и другими задачами. Иногда дело намного хуже, когда не опытные, но уже «звездные» спецы пытаются взять ношу не по плечу. Я лично всегда за инициативу и очень уважаю правильную активность, но прототип это фундамент и если он не достаточно хорош, то дом (DOM) качественный не построить, не говоря о масштабируемости.

В качестве альтернативного выхода логичней объединять в группы разных спецов: Теоретик(UX) + Практик(UI). Распределение обязанностей всегда ведет к прогрессу, конечно при условии тесного взаимодействия.

Уровень детализации

По этому поводу я слышу много разных мнений. Возьмем два совсем разных варианта:

  • Те самые квадратики. Я не считаю прототип квадратиками чем-то ужасным. Дело совсем не в них. Основная «боль» не в том, что проектировщик просто выбрасывает элементы на рабочее пространство, а в том, что логика совсем не включается. Нет никакой заточенности веб, просто холст с нужными фигурками.
  • Максимально детализированные прототипы. Те, которые настолько вылизаны, что воспринимаются как конечный дизайн. Мне некоторые из них дико нравятся. Бывали даже случаи, когда четкие, монохромные прототипы выглядят гораздо круче стилизованного решения. Сама проблема в том, что иногда дизайнеры становятся заложниками таких навязанный решений. И испытывают большие затруднения при дальнейшей работе над интерфейсом. Хотя вопрос достаточно дискуссионный.

На мой взгляд, правда, как и всегда, где-то по- середине. Идеальный вариант, когда в прототипе очень хорошо проработана конструкция ,как общего шаблона, так и каждого компонента, но нет перебора в стилях.

Сила верстки

Не секрет, что базовые знания HTML/CSS это тот фундамент, который должен знать каждый специалист, чья работа связана с веб разработкой. Я лично убедился в том, что работа идет эффективней и проще с проектировщиками/дизайнерами, имеющими хотя бы общее понимание о процессе верстки. Это сильно меняет их мышление и логику.

Огромный толчок, при разработке прототипа, дает внедрение в команду верстальщика. У меня лично есть полная одержимость «Дизайном в браузере», но для тех, кто не готов морально или еще на пути к этому, можно просто добавить участника способного это сделать. Включение верстальщика в команду поможет избежать жестких ошибок, тем более, если проектируется адаптив. Мне нравиться вариант дублирования компонентов Sketch <=> HTML/CSS, как скачек в сторону интерактивных прототипов. А в перспективе использование инструментов вроде Lego.

Web интерфейсы и интерфейсы мобильных приложений

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

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

Читать дальше

Боль дизайна крупных проектов

Боль

Как не странно, но по самому процессу разработки визуальной части мы в компании отстаем как минимум на года 2-3. Во-первых, классическая, изолированная, универсальная модель: Проектирование — Дизайн — Верстка. Во-вторых, один и тот же подход остается как для страниц мелких акций (заглушек), так и для масштабных сервисов вроде, где трудно предугадать сценарий развития. Но мы метем все под одну гребенку. Я лично не знаю в нашей компании персонажа, который глобально бьется над улучшением процесса и самой системы разработки визуальной части. В основном звучат умелые фразы, по поводу сроков и складывается впечатление, что все мастера по тайм менеджменту. Многие из резких фраз, как «Процент времени», напрочь убивают всю логику, и наивно полагаться на сохранение продуктивности на том же уровне. Когда разрабатываешь крупный проект, 5-7 глобальных переключений в день на другие задачи, полностью парализуется и сбивает весь процесс разработки основного проекта. Ну, впрочем, это менеджерская магия с выгодой в одну сторону.

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

Теперь о вытекающее из этого «боли».... Ситуация, которая сейчас выглядит так:

Дизайн

Явные ошибки конструкции

Железобетонная структура, совсем не гибкая, хорошо сделанная композиционно, но не предусматривающая изменение. Дизайн меняется. Но если нет закономерностей и правил (а их у нас нет), то базовые ошибки на этапе конструкции усугубляются с каждым новым элементом в разы.

Внешняя стилизация, по вкусу

Согласен, что чисто эстетически, некоторые вещи могут смотреться очень даже здорово. И массу лайков на Дрибббле соберут без затруднений. Но если это их конечная цель. У нас же вразрез другая задача.

Понятно, что в рамках огромной компании у дизайнеров есть заказчик, который примет решение. Но это не должно идти в разрез с общими принципами работы веба, предвзятым отношением, личной «вкусовщиной».

Верстка

Думаю, уже сложилось понимание, что на этом этапе работа далеко не «сахар». Мы получаем сомнительный каркас, не гибкую структуру, макет с эстетическими эффектами, не предусматривающий ресайз ... Такой макет затруднительно реализовать даже на полном стеке веб инструментов, а у нас еще и отнимают половину из них, заставляя поддерживать IE8.

Gracefull degradation

Дизайнеры ориентируются на фишки 2014 года, а верстальщики должны впаять это в браузер 2009. Думаю, вы понимайте временную пропасть. Если приблизиться к дизайну, то вы можете поэкспериментировать, открыв даже самые крутые сайты 2009 года. Технологически опираясь на IE8, глупо говорить о тандеме с современным дизайном.

Разработка багами

Я прикалываюсь: «мы 20% пишем код и 80% пишем костыли и баги». Изобретая оригинальный, новый подход «разработка багами» для любителей острых ощущение. Но начинать 10-й проект с таким подходом, близко к шизофрении.

Заденем опять наших экспертов по тайм менеджменту. Когда они говорят, что есть зазор по времени на доработку. Но этот зазор далеко не в пять раз больше, учитывая 20% эффективной работы с нашей стороны.

Тестирование. Судный день

У нас тестировщики это не те ребята, которые пишут тесты на интерфейс, а откликиватели сайта, своего рода MonkeyTesting, только в живом исполнении. После чего выставляется кучу тикетов, что все работает не так, дополненные личным пожеланием. И начинаются локальные допилы. И мы понимаем, что с самого первого этапа проект сделан не под те задачи и не были учтены принципы, по которым это тестируют. Перепил начинается на лету рукам разработчиков. Про дизайнерскую эстетику мы забываем, она просто выпадает из игры. Вcе это кочует из проекта в проект и с каждым новым безысходность умножается.

Лечение

Определив диагноз, всплывают очевидные решения. Нам нужно наладить максимальное взаимодействие между всеми участниками команды отвечающей за визуальную часть (проектирование, дизайн, верстка), но всем нужны общие ориентиры и инструменты.

Опираясь на лучшие практики, мы начинаем налаживать свою экосистему, учитывая наши особенности:

Гайды

Сборка базовых стилей, с которых будет начинаться любой новый проект. По необходимости, он может дорабатываться и всегда находиться в актуальном и боевом состоянии, как внешне, так и под капотом (я имею ввиду- код). Состав примерно такой:

Типографика (шрифты, размеры)

  • Заголовки
  • Абзацы
  • Ссылки

Цвета

Базовые цветы Цвета для продуктов (у нас несколько разных продуктов внутри одной компании). Хотим избежать 10 практически идентичных цветов, одинаковых визуально, но отличающихся кодом в макетах, поэтому включаем возможные цвета в гайд...

Кнопки

  • Все состояния кнопок (default, hover, pressed)
  • Вариации (к примеру с иконкой или без) или размеры (small, large) и.т.д

Инпуты (Samsung не в лучшей форме)

Обозначить эталонный вид форм -одна из моих самых маниакальных фантазий. Знаете, как у любого разработчика есть «бзык», который не дает спать по ночам. У меня это без сомнений — формы. Они буквально меня сводили с ума, к сожалению, не в лучшем смысле. Есть детали, по которым сразу видно — на сколько проработан макет. И формы это явный индикатор. Хоть у нас с ними был полный бардак, но даже у передовых сайтов, таких как Samsung дела бывают намного хуже. Даже в top Awwwards часто появляются проекты, у которых ситуации с формами- плачевна.

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

Прелоудеры

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

Source

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

Пример использования:

Допустим есть задача сделать блок формы регистрации. Из каких элементов она состоит:

  • Заголовок
  • Текст инпут
  • Чекбокс
  • Кнопка
  • Ссылка
  • Иконка

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

Работа в таком процессе даст нам больше логики и понимания, существенно повысит процент полезной работы (которую не нужно переделывать), накопление продуктов нашей работы в общую базу и аккумулирование мощности для новых проектов.

Каркас

У нашей команды сложилось общее понимание по сетке и адаптиву. Выглядит примерно так:

  • Полный адаптив

    Точки перелома (Медиа-запосы): Cмартфоны Ширина окна (девайса) < 768px Ширина контейнера < 768px
  • Планшеты

    Ширина окна (девайса) > 768px Ширина контейнера = 750px
  • Десктопы

    Ширина окна (девайса) > 992px Ширина контейнера = 970px
  • Широкоформатники

    Ширина окна (девайса) > 1200px Ширина контейнера = 1170px

Разбивка на версии

В тех случаях, когда контент специфичный, много функционала и нет возможности использовать одну разметку, мы делаем две версии:

  • Десктопы/Широкоформатники + перестройка под Планшет (12 колонок)
  • Мобильная версия (отдельная версия) + (своя сетка в 6 колонок)

Анимация

Неизбежная составляющая дизайна, которую мы не можем игнорировать и которой придается большая значимость. Нам нужно внедрять это аккуратно, не навешивая на нее функциональную часть. Учитывая, что все должно работать в приемлемом виде в старых браузерах. В перспективе она будет так же документироваться в Source. Возможно сделать перераспределение ролей в виде Interaction Designer-а. Так как тут нужна гибридная связка в виде Технических знаний + Динамичного дизайна (microinteractions).

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

P.S.

Большинство из этих проблем я описывал в статье «Дизайн в браузере». Но «староверов» и консерваторов такой скачек может морально травмировать, поэтому по желанию можно причесать процесс без радикальных мер и использовать как промежуточно-подготовительный этап для неизбежного «Дизайна в браузере».

Читать дальше

Должен ли дизанер кодить

Воспаленный вопрос, который особенно последние пару лет сводит с ума как самих дизайнеров, так и коллег по цеху. Чтоб не было недопонимания я объясню, кого в этом посте я буду называть дизайнерами. Возьмем классический минимальный костяк: Дизайнер — Верстальщик — Программист. Как правило в этой цепочке Дизайнер именно тот персонаж, с которого начинается непосредственно сама разработка. Все начинается со структуры блоков, расположение их на холсте. 960px по центру на двенадцать колонок или что-то похожее. Все строго по сеточке. И пошло творение. Иногда это превращается в фанатизм и переходит все границы. Конечно это можно выложить на dribbble и behance, но ведь PSD это не конечный продукт. Приведу пример того, что мягко говоря бесит верстаков:

  • Кастомный скролл, не забывать про кросбраузерность и кросплатформаенность
  • Кастомный селект
  • Клевые шрифты, которыйх нет в Google Web fonts нужно генерить или изощрится с CuFon. Резултат может огорчить.
  • Горизонтальный градиент у резиновых блоков
  • Нужно помнить, что контент может меняться не так как вы бы этого хотели и блоки могут тянуться.
  • Резиновый макет нужно продумывать на минимальной ширине
  • Тени с рваным краем
  • Функционал на ховер

Список можно продолжить как минимум на несколько десятков. Ну я думаю моя мысля понятна.

Кросбраузерность

Согласитесь CSS3 творит чудеса. Лично я был в восторге, когда первый раз попробовал применить тень, градиенты и еще несколько эффектов, буквально пару строками простого кода. Ну это же просто мелочь по сравнению с трансформацией и анимацией. Вот эти вещи по-настоящему передают всю красоту и ювелирность CSS3. И было бы глупо не насладиться этой радостью. Дизайнер рисует дизайн продумывает шикарную анимацию, которую где-то подсмотрел плюс добавил что-то от себя. Макет согласовали. Менеджер в восторге. Передает макет на верстку. Весртальщик в шоке. Сто слов мата и боль. Кросбраузерность, для дизайнера понятие расплывчатое. И ювелирность CSS3 превращается в велосипед на JavaScript. Довольно жалкое зрелище наблюдать над тем как дизайнер объясняет какую CSS3 анимацию использовать. И та движуха, которую он придумал в своей голове должна быть правильна понята и реализована верстальщиком. Согласитесь это мягко говоря неправильно.

Адаптив

Статичные скриншоты вымирают. Для адаптива их актуальность и вовсе падает. Макет с 3-4 изображениями разной ширины (эмулирующий разные разрешения) теряют свою ценность. Так как за частую адаптивная, сверстанная версия выглядит совсем иначе, чем на макетах и за частую приходится перерабатывать целиком структуру. Каждый разработчик адаптива думаю знает, что дизайн нужно тестить на разных разрешениях в процессе работы, а не когда он уже завершен. Чего не могут себе позволить дизайнера рисующие статику в фотошопе. Гораздо удобней начинать разработку сразу на HTML/CSS. Конечно как вариант можно сделать продуманный адаптивный прототип в Axure7 или Sketch3. Это вполне приемлемо. Но если есть возможность, то лучше лишний раз не брезгать кодом.

Графика

Очень радует прогресс графики в вебе. Она развивается динамично и правильно. Я имею в виду, что мы все меньше элементов в вебе реализовываем с помощью нарезанных изображений. А создаем графику кодом. Если объективно посмотреть, то из всей графики, которую мы вынуждены вставлять как jpg/png это фотографии. А все то, что касается интерфейса, более изящно создается с помощью CSS3 и JavaScript. Активно входит в работу SVG. Еще не до конца вошедшая в широкое пользование технология, но потенциал то огромен. Недавно наткнулся на проект snapsvg.io и честно говоря был вдохновлен такому подходу реализации графики. Как не крути, а типичное понимание отрисовки графики в редакторе уходит в прошлое. Уже понятен вектор развития. И вполне очевидно, что без кода тут не обойтись.

Схемы, графики, диаграммы

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

Codepen вместо Dribbble

Все мы люби dribbble. И мы видим как дизайнеры желающие показать живость своей работы делают гифки с анимацией. К примеру видим изображение формы авторизации. И старательны дизайнер склеивает в gif разные ее состояния. Фокус текстового поля, ховер на ссылку, клик на кнопку, прелоудер на отправку и так далее. Его старания похвальны. Но форма это же не иллюстрация, там не нужно особого художества. А смотреть ролик как работает форма немного глупо. Другое дело когда дизайнер может накидать несколькими строками кода на codepen.io и есть возможность посмотреть интерактив, так сказать «потрогать форму», подправить на ходу если нужно. Этот способ на много гибче, понятней и логичней. К тому же есть возможность показать интерактив.

Вначале код

Стал популярен подход, когда сначала верстается основная разметка без изящества. А потом, когда сверстаны основные блоки, все стилизуется. Очевидно есть сильные плюсы в таком порядке реализации. Но эта тема для отдельной статьи, которую я обязательно опубликую с личным опытом и примерами. Я все чаще слышу о потребности дизайнеров широкого профиля. Спрос на занишеванных специалистов наплодил много людей узкого профиля, но кто-то должен собирать всю конструкцию и видеть более обширную картину. А рисовать статичные картинки в фотошопе выдавая за макет, тупиковый вариант. Профессиональное, глубокое понимание дизайна возможно только если мыслить на языке его реализации.
Читать дальше