Підготовка
Минулого тижня мені довелося побувати на конференції Webshaped та прослухати лекцію Стівена Хея про організацію адаптивного робочого процесу. Розмова наша піде не про неї, скажу тільки, що метод Стівена нагадав мені про те, яким я користуюся сам. Це і спонукало мене розписати деякі міркування щодо організації робочого процесу, про те, як він змінився за останні два-три роки і як він може еволюціонувати у майбутньому.
Приблизно три чи чотири роки тому — коли я робив в основному сайти зі статичною шириною — мої проекти проходили кілька етапів у порядку, вказаному нижче, який виглядав як типове потокове виробництво. При такому підході залишалося мало часу для оцінки якості, і клієнт отримував, як правило, каркас або майже закінчений макет у Photoshop.
Така модель більш-менш виправдовувала себе раніше, проте тепер перед нами постає одна проблема. Поточне складання не виправдовує себе при створенні адаптивного дизайну. Фактично подібний метод ніколи не був оптимальним для веб-дизайну, але оскільки я, як і решта, звик виконувати дії в певному порядку, ми ніколи не ставили його під сумнів.
Новий шлях
Ось порядок, у якому працюю над адаптивним дизайном (зображено нижче). Я мав нарис Марка Болтона про організацію роботи, а також презентацію Стівена Хея як джерела при роботі над цією статтею. Мій новий план є більш гнучкою моделлю, ніж потоковий. Далі я докладно розберу кожен із його етапів, але зараз розглянемо їх коротко.
Процес починається з аналізу контенту, що вимагає ретельного обмірковування. Після підготовки чорнового варіанта контенту, я перетворюю його на HTML прототипи, завантажую їх у мобільний браузер і дивлюся, як цевиглядає. Більшість малюнків візуального дизайну я роблю до і після створення прототипу. Відразу після створення перших ескізів я зазвичай беру HTML-прототип і починаю додавати CSS, щоб одразу побачити, як виглядають мої ідеї. Весь процес відбувається в послідовності, яка зазвичай виглядає так: ескіз -> прототип -> дизайн -> тест -> обговорення - повторюється до тих пір, поки не з'являться результати. Порядок дій може змінюватися і не завжди бути таким прямолінійним, але мені хотілося для ясності спростити діаграму.
Підготовка
Перший етап має на увазі збір інформації, знайомство з клієнтом та іншу дослідницьку роботу. Метою тут є зрозуміти суть бізнесу клієнта, оцінити можливі труднощі та завдання проекту. Без належних знань майже неможливо зрозуміти чого клієнт насправді хоче і що йому потрібно.
На цьому етапі я ставлю безліч питань як: «Навіщо люди заходитимуть на ваш сайт?», «Яких основних цілей ви намагаєтеся досягти?», «Хто ваші головні конкуренти?». і тому подібні. Ви можете знайти ідеї питань з анкет інших дизайнерських студій:
Планування здійснюється з знань, отриманих першому етапі. На цій стадії я зазвичай починаю з базового концепту, після чого переходжу до розділів користувача та інформаційної архітектури. Також я працюю над створенням та позиціонуванням елементів контенту, які після цього можуть бути ранговані за рівнем важливості. На підставі цього розподілу ми можемо перейти до роботи над HTML каркасом для них. Два ці кроки абсолютно ідентичні описаним Стівеном етапам робочого процесу «Розподіл контенту» та «Створення референтного каркасу».
Текстовий дизайн
«Текстовий дизайн» у цьомуУ цьому випадку передбачається, що ми перетворюємо (упорядковуємо) весь контент веб-сайту на текстову форму. Це один з найбільш важливих етапів всього процесу і, в той же час, ймовірно, найчастіше недооцінюється. Я говорю так, тому що, на мою думку, немає жодного сенсу рухатися далі, якщо у нас немає справжнього контенту. Саме заради нього люди відвідують веб-сайт, саме з контенту має починатися весь процес.
Я часто виконую цей етап у HTML без використання стилів, оскільки в цьому випадку ми одразу можемо бачити, як контент вписується в одну вузьку колонку та в якому порядку розташовується. Крім цього, як правило, саме у такому вигляді сайт відображатиметься на екранах мобільних пристроїв.
Не забувайте, що це не обов'язково має бути фінальне виправлення, ми зможемо внести необхідні зміни під час роботи над прототипом. Також цей крок можна виконувати за допомогою текстових документів, отримуючи майже ідентичні результати.
Робота над ескізами ведеться постійно, але стає особливо важливою перед початком роботи з браузером. Свої начерки я найчастіше перевіряю, використовуючи HTML-дизайн, створений на попередньому етапі (що зводиться до простого додавання кількох CSS правил до коду).
Витративши трохи часу на ескізи, ви вбережете себе від годин роботи за комп'ютером. Ви збережете не лише час, а й урятуєте себе від непотрібних хвилювань. Коли страшний монстр «творчої кризи» добирається до вас, він неминуче залишає після свого відходу руйнівне насіння невпевненості в собі. Я закликаю всіх вас почати працювати над ескізами, як важливою складовою своєї роботи, ви побачите, як скоро скоротиться час вашого перебування в ступорі на краю порожнечі.
Раннє прототипування в HTML/CSS необхідно, якєдиний спосіб побачити поведінку шаблонів при зміні розміру екрана. Також це дозволяє мені показати клієнту сайт на початкових етапах роботи, а також відреагувати на проблеми з дизайном, які можуть виникнути.
На відміну від Стівена, я не починаю працювати над остаточною графікою до створення діючого прототипу дизайну. Корисно насамперед дізнатися, як усе працює — чи не працює за різних умов та розгорток, а також продемонструвати прототип клієнту. Однак я завжди використовую справжній контент, щоб адекватно оцінювати макет та приймати рішення.
Нижче розташована діаграма відповідності пристроїв, зроблена мною на основі презентації Прагматичний адаптивний дизайн Стефані Рігер та статті Проста діаграма пристроїв у Metal Toad. Я зробив її, тому що мені здалося, що перша вже сильно застаріла, а друга повністю упускає з поля зору пристрої на базі Symbian, досить популярні у нас:
Візуальний дизайн
Цей крок, що повторюється, відбувається на етапах до і після прототипування. Я, як і раніше, воліють використовувати Photoshop для створення більшості елементів дизайну, проте останнім часом все більше вдаюся до допомоги браузера. Особливо це стосується друкарні, працювати з якою поза браузером досить складно (Втім, я помітив, що коли я переходжу в браузер зарано, все виходить якимось плоским, похмурим і громіздким).
Найбільш важливим моментом тут є використання інструменту, який не обмежує вашу творчість. Це може бути браузер, Photoshop, Fireworks, inDesign або інша програма, з якою вам комфортно працювати.
Початок випробувань на ранніх етапах роботи врятує вас від проблем надалі. Просто погляньте на діаграму відповідностіпристроїв, додайте до уваги всі примхи браузерів і ви почнете розуміти, чому практично неможливо створити гнучкий сайт, не випробувавши його попередньо на безлічі існуючих пристроїв. У тестування слід також включити випробування користувача, так як це найпростіший спосіб перевірки юзабіліті прототипу, яка все ще може вимагати доопрацювання.
Найчастіше я тестую сайти на особистій техніці, проте іноді буває недостатньо і потрібно перевірити прототип на чомусь новому, відправитися прямо в магазин і провести там польові випробування. За це грошей не беруть, принаймні поки що.
Обговорення
Обговорити з клієнтом дизайн після кожного циклу. Подайте йому діючий HTML прототип і демонструйте роботу на існуючих пристроях. Як казав Марк Болтон, уникайте "Фінального Одкровення".
Повторення циклу
Ексіз -> Прототип -> Дизайн -> Тест -> Обговорення
Доки не запрацює.
Висновок
Немає ідеального плану робіт. Те, що годиться мені, може підійти не кожному, і я відчуваю, що зміни, які я вніс до нього, це лише початок перетворень. Описані мною етапи найкраще підходять для створення веб-сайтів (великих і малих), однак можуть вимагати невеликих коригувань при створенні веб-додатків, які відрізняються в чомусь за своїми функціями (що залежить, зрозуміло, від типу програми).