Mikhail Koloskov
Mikhail Koloskov
UI Engineer. Design in the Browser fanatic.

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

Тысячи часов были инвестированы мной вхолостую. Если верить правилу 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

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

На одну зарплату или профессиональная проституция

Фриланс для дизайнера/разработчика — неотъемлемая часть жизни. Я не знаю ни одного спеца, который бы периодически или постоянно этим не занимался. У меня был в этом деле далеко неплохой период. Однако, я имею достаточно четкую позицию по этому поводу.

Профессиональный фриланс

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

Проектная дисциплина

У меня было много рассуждений по поводу « студия или проект ». Я свой выбор сделал. И полностью уверен, что это практически единственная возможность выйти на серьезный уровень. Лишний раз я в этом убедился, услышав такое высказывание на #frontendconfmsk

«Время компаний, занимающихся шабашками, окончилось. Будущее за проектными группами»

Но для того, чтоб это будущее, как-то состоялось, есть пару условий.

  • Либо быть счастливчиком для того, чтоб попасть в проект с отлаженным подходом и четким вектором.
  • Либо параноиком и иметь нереальные амбиции, и иметь волю продавить «правильный» подход.

И первый вариант это не моя история.

Почему я тут затрагиваю тему проектов. Проекты развивают определенный тип мышления, дисциплину и полную отдачу. В то время, как агентский подход развивает только терпимость к конвеерности, работая в агентстве психологически легче фрилансить. Тогда, как при полной отдаче проекту, поддаться искушению практически невозможно. Дополнительных фриланс, это как кредит у самого себя с адскими процентами. Никому не интересен твой 3-й, 5-й, 20-й проект. Всем нужно больше «мяса» пусть даже в одном проекте. Все меньше есть необходимость в простом умении пользоваться большим количество инструментов и собирать на них «Hello world». Чаще нужно понимать всю структуру проекта, вектор его развития и способность анализировать, и принимать решения, опираясь на эти факторы. А для того, чтоб находиться в этом состоянии требуется чистый разум, не помутненный сторонним информационным мусором.

Точка кипения

Я очень четко понимаю, что не всегда основной рабочий проект прёт. Иногда говорят «это просто должно быть сделано», хотя такие провокационные высказывания нужно либо жестко пресекать, либо минимизировать, так как это очевидные сигналы не очевидных проблем. Честно признать, почти год моей жизни и тонна нервов была просто безвозвратно убита на дилетантски организованный проект. C тех пор грамотные менеджеры стали моими кумирами. Каждый день, работая на нем, я испытывал профессиональное истощение. И тут я бросился на фриланс. Причем деньги хоть и важны для меня, но они не всегда были весомым аргументом. Но также была потребность в том, чтоб сделать максимально полезное и на совесть. Делая дополнительно небольшие проекты один за другим в нерабочее время, я понял, что кроме физического истощения и несопоставимой бонусной прибавки, больше ничего не получаешь. И через несколько месяцев такого режима рисковал оказаться «за бортом». Но я не упал в лапы «профессиональной смерти» и решил, что если компания не дает возможность совершенствоваться, нужно сообразить эту возможность самому. Для меня этой возможностью стало погружение и анализ «процесса реализации масштибируемых интерфейсов», который я подогрел порцией самообразования в смежных областях. Но более мощным способом максимально увеличить пользу от своих действий, это, несомненно, Opensource. Участие в Opensource-ных проектах искренний и по-настоящему весомый вклад в любимое дело. И сейчас это, то к чему я стремлюсь.

Воздержание от хаоса

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

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

Чудеса на виражах или корректировка вектора

Мои предыдущие 3 года верстки не могут не повлиять на мой тип мышления и подход к делу. Жесткая систематизация не позволяет мне удариться в фантазии и просто начать рисовать картинки. Оценка эффективности, технической стороны и возможности масштабирования, я считаю, являются обязательными процедурами при реализации любого веб интерфейса. Занимаясь версткой, я плотно взаимодействовал с теми процессами, которые у нас принято называть непосредственно дизайнерскими. Из этого вытекла методология « Дизайна в браузере ». Поэтому вектор сместился в дизайнерскую сторону. Я всегда ставил под сомнение дизайнерские инструменты. Наконец, после смерти psd макетов и резкой смене ориентиров в области реализации дизайна в техническую сторону, я начал чувствовать невероятный потенциал. Это здорово меня бодрит и подталкивает к активным действиям.

UX

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

UI kit

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

Анимация

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

Визуализация данных

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

PostCSS

Несомненно, методология разметки и стилей всегда останется в моей компетенции. Так, как это фундамент для любого веб интерфейса. Я читал несколько статей на эту тему PostCSS., но окончательно к ней подогрел интерес Андрей Ситник на #frontendconfmsk

Sketch и Origami

Хоть я и являюсь ярым сторонником «Дизайна в браузере» ,есть пару инструментов, которые я не могу игнорировать — это Sketch и Origami. Думаю, они станут приоритетными для меня в этом году. Они очень мощны, удобны и дико популярны. Это позволит поработать совместно с некоторыми дизайнерами. Я с нетерпением жду Protein (theprotein.io). Это инструмент ,в докладе Антона Виноградова «Проникновение в дизайн», произвел на меня фантастическое впечатление на #frontendconfmsk и я однозначно буду внедрять его в рабочий процесс.

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

Вторжение в UX

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

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

Затем я попал на движуху IT Global Meetup. Страстная речь Миши Рыжикова и эффект массовости сыграл свою роль. Правда это мероприятия я провел в метаниях между фрон-енд докладами и UX, которые шли одновременно. Но я попал на доклад Никиты Ефимова, точнее на последние 10 минут. Он достаточно уверенно и умело оперировал разными понятиями. И меня сразу подкупило то, что он говорил. Помниться, я задал какой-то вопрос, который меня беспокоил, он был немного оторван от темы доклада, но публика включилась в обсуждение. Пошел активный диалог. Такая открытость и участие публики не могло не радовать. И меня все это подстегнуло копать дальше.

Через некоторое время я уже сидел на курсе по UX от ITmine, который проводил Никита Ефимов. Это было логичное продолжение моей любознательности. Было массу причин попасть на этот курс. Никита был достаточно заметен. До того момента, как я попал на курс я уже слушал пару-тройку его докладов, расспрашивал на интересующие меня темы и получал предельно развернутые ответы с личными примерами и рассуждениями. Степень его погружённость в тему была заразительна.

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

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

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

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

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

После основательной подготовки просто необходимо было проверить себя на деле. И итоговая проверка на прочность была не детской. Нас распределили на боевые проекты. Мне довелось

поработать на амбициозном стартапе Rating.VC. Подход стартапа, более ориентированного на запад, несколько отличался от того, к которому я привык. Но меня такой вызов только подзадорил и мы с командой взялись за дело. За месяц вне рабочего времени грандиозных дел не сделать, но выдать сверстанный адаптивный прототип все-таки удалось. Было здорово взаимодействовать с Александром Лифановым. Он охотно шел на встречу, обговаривая промежуточные этапы. Приятно было выполнить логический кусок работы и помочь команде проекта.

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

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

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

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

UX на деле

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

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

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

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

Анти-тестирование

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

Стратегический дизайн

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

Графика

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

Иллюстрации

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

Фотографии

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

Менеджмент

Выдергивание разработчика на другой проект это экстренное и редчайшее явление, которое менеджеры должны расценивать, как личный косяк и нерациональное использование ресурсов. Так как это дорогая операция в которой тратиться время на то, чтоб разработчик снова погрузился в проект. Около 5 переключений в день между проектами достаточно для того, чтоб окончательно подорвать рабочий темп и демативировать даже самого одержимого разработчика. А систематичное повторении этой операции, через несколько недель приведет к тому, что специалист начнет «улыбаться» hr-ам других компаний. Вот тут останется всего два варианта: крепко подстегнуть рублем (работает далеко не для всех) или перестать извращаться.

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

Как внедрить динамику?

xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx.

Холостая работа. Ликвидация дублирующих друг друга процессов

xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx.

Сильный лидер не мотивирует, а вдохновляет

xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx.

Честность и открытость, дает большой плюс в виде доверия.

xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx.

Хватит мериться ********

xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx.

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

Интерфейсный прорыв

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

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

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

Дневник паранойи

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

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

10 августа 2015

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

4 августа 2015

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

22 июля 2015

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

24 мая 2015

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

6 апреля 2015

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

5 апреля 2015

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

5 апреля 2015

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

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

3 апреля 2015

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

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

Я всегда говорю, что нужно воевать на сильной стороне для того чтоб прогрессировать. Или в компании, которая способна признать свои ошибки и избавиться от пораженной части, чтоб не потерять весь организм.

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

14 марта 2015

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

14 марта 2015

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

13 марта 2015

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

6 марта 2015

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

20 февраля 2015

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

14 февраля 2015

Глубина UX восхищение и пугает одновременно. Иногда кажется, что шмоляем с пушки по воробьям, а иногда, что с рогатки по истребителям.

27 января 2015

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

26 января 2015

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

25 января 2015

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

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

Origami Live и Origami 2.0

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

Чуть больше года назад, мы представили Origami — бесплатный инструмент для проектирования интерактивных пользовательских интерфейсов. Мы использовали его у себя на Фейсбуке, для проектирования многих наших продуктов Instagram, Messenger, Paper, Slingshot, Hyperlapse и Rooms. С момента выпуска Origami, самым важным запросом об улучшении была возможность открывать прототипы на iPhone и iPad так же как и на компьютере.

Сейчас мы с радостью представляем Origami Live for iOS вместе с основной новой версией для Mac Origami Live это новое приложение, которое позволит вам увидеть прототипы на вашем iPhone or iPad. Совместно мы представляем Origami 2.0, которое задет тон для новых фишек, включающие экспорт кода, мощную поддержку жестов, интеграцию со Sketch, режим презентации и другое

Origami Live

Origami Live изменил наш процесс дизайна продуктов в facebook. Это позволило нам взаимодействовать с нашими прототипами на iPhone и iPad пока мы редактируем их. Мы можем быстро опробовать новые идеи — используя мультитач, сенсоры девайса и с легкостью точно их регулировать, без написания кода. Затем мы передаем наш девайс участникам команды или пользователям и тестируем высоко детализированный прототип, который выглядит, как законченный продукт. Когда я работал в дизайнерской команде Paper, почти весь продукт мы проектировали в Origami. Это позволило нам креативить , в противном случае спотыкаться пробуя новые идеи. Для примера, мы хотели улучшить, то как то пользователи видят фото в новостной ленте. В большинстве других лент фотографии масштабируются под размер экрана.

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

xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx.

xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx.

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

Подсел на верстку или эйфория хлеще кокса

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

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

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

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

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

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

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

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

Нишевание

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

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

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

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

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

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

Менеджеры

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

Мотивация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резонанс личности

«Если вы не бренд, вы обычный товар». Котлер

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

Конкуренция. Страх прогресса

xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx.

xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx xxxxxxx xxxx xxxxxxx xxxx.

Неумышленная ограниченность

xxxxx x xxxxxx xxxxxx x xx xxxxxx xxxxxx xxxxxxxxxxxx xxxxxx xxxxxx. x xxxxxx xxxxxx x xx x xxxxxx xxxxxx xxxxxx xxxxxxxxxxxx.

xxxxx x xxxxxx xxxxxx x xx x xxxxxx xxxxxx x xx x xxxxxx xxxxxx xxxxxx xxxxxxxxxxxx.

xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx.

Та самая зона комфорта

xxxxx x xxxxxx xxxxxx x xx x xxxxxx xxxxxx x xx x xxxxxx xxxxxx xxxxxx xxxxxxxxxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx.

Шум стада

xxxxx x xxxxxx xxxxxx x xx xxxxxx xxxxxx xxxxxxxxxxxx xxxxxx xxxxxx. x xxxxxx xxxxxx x xx x xxxxxx xxxxxx xxxxxx xxxxxxxxxxxx.

xxxxx x xxxxxx xxxxxxxxxxxx xxxxxx xxxxxxxxxxxx xxxxxx xxxxxx x xx xxxxxx xxxxxx xxxxxxxxxxxx xxxxxx xxxxxx. x xxxxxx xxxxxx x xx x xxxxxx xxxxxx xxxxxx xxxxxxxxxxxx.

Дорого или бесплатно

xxxxx x xxxxxx xxxxxx x xx x xxxxxx xxxxxx x xx x xxxxxx xxxxxx xxxxxx xxxxxxxxxxxx.

xxxxx x xxxxxx xxxxxx x xx x xxxxxx xxxxxx x xx x xxxxxx xxxxxx xxxxxx xxxxxxxxxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx.

Ментор

xxxxx x xxxxxx xxxxxx x xx x xxxxxx xxxxxx x xx x xxxxxx xxxxxx xxxxxx xxxxxxxxxxxx.

xxxxxx x xxxxxx xxxxx xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx. xxxxxxx xxxx xxxxxxxx xxxxx x xxxxxxxxx xxxxxxx. xxxxxx x xxxxxx xxxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx.

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

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

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

Начнем с первого — «дизайна». Тут проблема в отношении к дизайну как к статической .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 интерфейсы и интерфейсы мобильных приложений

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

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

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

Самопрокачка

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

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

Разработка

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

Английский

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

Спорт

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

Я набросал небольшой MindMap. Более детально, делаю отметки в Wunderlist:

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

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

С головой в проект или нараспашку в студии

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

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

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

Клиенты

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

Код

Разношерстность кода. Я могу судить про фронт-энд (HTML, CSS, JS). Но это то над чем приходится биться и парой загоняет в тупик. На под-проектах встречается код написанный лет пять назад. Конечно тогда никто не слышал о АНБ и модульной системе верстки. Поэтому все зашито на каскад. Плюс к этому всему приложил руки не один верстак. Картина не для нежной психики. Так что рефакторинг неизбежен. В последние проекты внедряем отличную вещь MCSS да и нехитрую, но более обдуманную систему. Это приносит больше логики в верстку. Позволяет притереться с командой и выработать единый стиль.

Управление

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

Карьера

Повышаем планку. Не знаю как в Москве. Скажу про Питер. Если вы не работаете в клевом агентстве вроде Nimax Design или SoftFacade с плотными клиентами, потолок роста будет давить примерно через год. Клиенты те же, практиковать новую технологию не особо получается. Так как это дорого. Если дизайн продать можно, то на практике верстка для заказчика «полного пакета» это какой-то внутренний процесс, не совсем им понятный. И в который им не особо хочется вникать. На прогрессивных проектах этому должно уделяться повышенное внимание, так как это наиболее уязвимая часть при его масштабировании. Тут потерять несколько тысяч посетителей, из-за «поехавшей» верстки на каком-нибудь устройстве, гораздо критичней, чем потерять пару человек на промке, на которые ориентированы большинство рекламно-дизайнерских агентств.

Ставка на будущее

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

Команда

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

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

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

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

Боль

Как не странно, но по самому процессу разработки визуальной части мы в компании отстаем как минимум на года 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 и есть возможность посмотреть интерактив, так сказать «потрогать форму», подправить на ходу если нужно. Этот способ на много гибче, понятней и логичней. К тому же есть возможность показать интерактив.

Вначале код

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