Mikhail Koloskov
Mikhail Koloskov
HTML-developer. Design in the Browser fanatic.

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

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

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

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

С 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% эффективной работы c нашей стороны.

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

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

Вначале код

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

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