Подготовка

Миналата седмица случайно бях на конференцията Webshaped и слушах лекция на Стивън Хей за организиране на отзивчив работен процес. Разговорът ни няма да бъде за нея, само ще кажа, че методът на Стивън ми напомни за този, който аз използвам. Това ме накара да нарисувам някои мисли относно организацията на работния процес, как се е променил през последните две или три години и как може да се развие в бъдеще.

Преди около три или четири години - когато правех предимно сайтове със статична ширина - проектите ми преминаха през няколко етапа в реда, посочен по-долу, което изглеждаше като типично производство на линия. С този подход имаше малко време за оценка на качеството и клиентът, като правило, получаваше или телена рамка, или почти завършено оформление във Photoshop.

може

Този модел повече или по-малко се е оправдал преди, но сега сме изправени пред един проблем. Сглобяването с резба не се оправдава при създаването на отзивчив дизайн. Всъщност този метод никога не е бил оптимален за уеб дизайн, но тъй като аз, както всички останали, бях свикнал да правя нещата в определен ред, никога не го поставяхме под въпрос.

Нов начин

Ето реда, в който работя върху адаптивен дизайн (на снимката по-долу). Използвал съм есето на Марк Болтън за организирането на работата, както и презентацията на Стивън Хей като източници за тази статия. Новият ми план е по-гъвкав модел от рационализирания. След това ще анализирам подробно всеки от неговите етапи, но засега ще ги разгледаме накратко.

Процесът започва с преглед на съдържанието, което изисква внимателно обмисляне. След като подготвих черновата на съдържанието, я конвертирам в HTML прототипи, зареждам ги в мобилен браузър и гледам как работи.изглежда. Повечето скици за визуален дизайн се правят преди и след прототипирането. Веднага след първите скици обикновено вземам HTML прототип и започвам да добавям CSS, за да видя как изглеждат идеите ми веднага. Целият процес протича в последователност, която обикновено изглежда така: миниатюра -> прототип -> дизайн -> тест -> обсъждане – повтаря се до получаване на резултати. Редът на операциите може да се промени и не винаги да е толкова ясен, но исках да опростя диаграмата за по-голяма яснота.

може

Подготовка

Първият етап включва събиране на информация, опознаване на клиента и друга изследователска работа. Целта тук е да се разбере същността на бизнеса на клиента, да се оценят възможните трудности и задачи на проекта. Без подходящи познания е почти невъзможно да се разбере какво наистина иска и от какво се нуждае клиентът.

На този етап задавам много въпроси като: „Защо хората ще дойдат на вашия сайт?“, „Какви са основните цели, които се опитвате да постигнете?“, „Кои са основните ви конкуренти?“. и подобни. Можете да получите идеи за въпроси от въпросници на други дизайнерски студия:

Планирането се извършва въз основа на знанията, получени в първия етап. На този етап обикновено започвам с основна концепция и след това преминавам към потребителските секции и информационната архитектура. Също така работя върху създаването и позиционирането на елементи от съдържанието, които след това могат да бъдат класирани по важност. Въз основа на това разпределение можем да продължим да работим върху HTML скелета за тях. Тези две стъпки са идентични със стъпките на работния поток „Разпространение на съдържание“ и „Създаване на референтна телена рамка“ на Стивън.

Дизайн на текст

„Дизайн на текст“ в товаслучай означава, че ние конвертираме (подреждаме) цялото съдържание на уебсайта в текстова форма. Това е една от най-важните стъпки в целия процес и в същото време може би най-подценяваната. Казвам това, защото според мен няма смисъл да продължаваме, ако нямаме истинско съдържание. Заради него хората посещават уебсайта, целият процес трябва да започне със съдържанието.

Често правя тази стъпка в HTML, без да използвам стилове, защото в този случай можем веднага да видим как съдържанието се вписва в една тясна колона и в какъв ред. Освен това, като правило, именно в тази форма сайтът ще се показва на екраните на мобилни устройства.

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

HTML

Скицирането е непрекъснат процес, но става особено важно, преди да започнете да работите с браузъра. Най-често проверявам моите скици, като използвам HTML дизайна, създаден в предишната стъпка (което се свежда до просто добавяне на няколко CSS правила към кода).

„Прекарването на малко време в скициране ще ви спести часове работа с компютър. Ще спестите не само време, но и ще се спасите от излишни грижи. Когато страховитото чудовище „творчески блок“ стигне до вас, то неизбежно оставя след себе си опустошителни семена на съмнение в себе си. Призовавам всички ви да започнете да работите върху скици като важна част от вашата работа, ще видите как времето на престоя ви в ступор на ръба на празнотата бързо ще намалее.

Ранното създаване на прототипи в HTML/CSS е от съществено значение, тъй катоединственият начин да видите поведението на шаблоните е, когато екранът е преоразмерен. Освен това ми позволява да покажа на клиента сайта още в началните етапи на работа, както и да отговоря на проблеми с дизайна, които могат да възникнат.

За разлика от Стивън, аз не започвам да работя върху „окончателна графика“, докато не е създаден работещ прототип на дизайна. Полезно е първо да научите как работят нещата - или не работят при различни условия и разчиствания, както и да демонстрирате прототипа на клиента. Въпреки това винаги използвам автентично съдържание, за да оценя адекватно оформлението и да взема решения.

По-долу е диаграма за картографиране на устройство, която направих въз основа на презентацията на Stephanie Rieger за Pragmatic Responsive Design и статията A Simple Device Diagram in Metal Toad. Направих го, защото ми се стори, че първият вече е много остарял, а вторият напълно пренебрегва устройствата, базирани на Symbian, които са доста популярни при нас:

HTML

Визуален дизайн

Тази итеративна стъпка се случва в етапите преди и след прототипирането. Все още предпочитам да използвам Photoshop за повечето си проекти, но напоследък все повече използвам браузъра. Това важи особено за типографията, с която е доста трудно да се работи извън браузъра (забелязах обаче, че когато превключа на браузъра твърде рано, всичко се оказва някак плоско, скучно и тромаво).

Най-важният момент тук е да използвате инструмент, който не ограничава вашата креативност. Това може да е браузър, Photoshop, Fireworks, inDesign или всяка друга програма, с която се чувствате комфортно да работите.

Стартирането на изпитания по-рано ще ви спести проблеми по-късно. Просто погледнете диаграмата на съответствиетоустройства, вземете предвид всички капризи на браузърите и ще започнете да разбирате защо е почти невъзможно да се създаде отзивчив сайт, без първо да се тества на множество съществуващи устройства. Тестването трябва да включва и потребителско тестване, тъй като това е най-лесният начин да тествате използваемостта на прототип, който все още може да се нуждае от малко работа.

През повечето време тествам сайтове на личната си технология, но понякога това не е достатъчно и трябва да тествате прототипа върху нещо ново, да отидете направо в магазина и да направите някои полеви тестове там. За това пари не се взимат, поне не още.

подготовка

Дискусия

Обсъждайте дизайна с клиента след всеки цикъл. Покажете му работещ HTML прототип и демонстрирайте как работи на съществуващи устройства. Както каза Марк Болтън, избягвайте "Последното откровение".

Повторение на цикъла

Exis -> Прототип -> Дизайн -> Тест -> Дискусия

Докато заработи.

Заключение

Няма идеален работен план. Това, което ми подхожда, може да не подхожда на всеки и смятам, че промените, които направих в него, са само началото на трансформацията. Стъпките, които очертах, са най-подходящи за създаване на уебсайтове (големи и малки), но може да изискват леки корекции при изграждането на уеб приложения, които се различават по някакъв начин в своите функции (което зависи, разбира се, от типа на самото приложение).