"Журнал «Компьютерра» №32 от 06 сентября 2005 года" - читать интересную книгу автора (Компьютерра Журнал 604)

ТЕМА НОМЕРА: Главное - Порядок

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

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

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

Если у вас возник вопрос, связанный с веб-программированием (PHP, Perl, JavaScript), обращайтесь на форумы WebMastak.com или на форум WebScript.Ru (forums.webscript.ru), - кто-нибудь, разбирающийся в той теме, которая вас интересует, обязательно откликнется и поможет решить вашу проблему. Проверял на себе не раз.

Неплохой форум по Perl располагается на сайте Perl.dp.ua. На сайте много интересных материалов в разделе «PERLеводы» - переводы англоязычных статей.

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

На следующем этапе за дело берется специалист по проектированию пользовательских интерфейсов. Его задача - спроектировать максимально прозрачную, доступную и понятную структуру проекта для конечного потребителя продукта - не для заказчика, а именно для посетителей ресурса, которые будут пользоваться им для решения своих задач. Под системой взаимодействия нужно понимать не только удобство пользования (часто по ошибке называемое «юзабилити»[На самом деле, этот термин более общий: «usability» (англ. «удобство пользования») - это не только удобство пользования сайтом, но и степень соответствия содержимого сайта потребностям целевой аудитории, организация системы обратной связи с посетителями и др.]), но и общую ясность, легкость восприятия. Сюда в первую очередь нужно отнести максимально четкую группировку контента по разделам, рубрикам, блокам и т. п. Кроме того, нужно ясно представлять технические аспекты реализации системы навигации проекта - лишь тогда можно переходить к следующему этапу (поэтому дизайнеры всегда должны быть в курсе последних технологий для реализации своих красивых задумок).

На RealCodingсобрана информация о HTML, CSS, JavaScript, PHP, Perl, WAP, а также учебники по этим темам. На форумах forums.realcoding.net много интересных сообщений, присланных посетителями сайта.На Codenet веб-разработкам посвящен довольно большой раздел , касающийся PHP, ASP, Perl, Apache, Microsoft IIS, SSI, Java, JavaScript, VBScript - и это далеко не полный перечень. На форуме forum.codenet.ru вы можете задать вопрос, который, возможно, войдет в перечень вопросов и ответов (FAQ), публикуемых на www.codenet.ru/webmast/faq. А еще на сайте имеется довольно интересная рассылка. Советую подписаться.

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

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

Далее наступает пора технического воплощения. Его длительность зависит от объема актуального контента проекта. Тут может быть задействовано большое количество работников (даже внештатных): от html-кодеров до flash-технологов, программистов и пр. Целесообразность применения той или иной технологии обсуждается как на внутренних дискуссиях, так и с заказчиком.

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

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

Много людей последнее время стараются гнаться за модой, за последними стандартами, правилами. В мире веб-разработок существует один весомый игрок по имени W3Org. Эта организация разрабатывает новые стандарты для многих технологий, применяемых в веб-строительстве: html, css, DOM, xhtml и многих других. Некоторые разработчики слишком ревностно относятся к появлению новых стандартов, норм и технологий и стараются при первой же возможности выдать заказчику проект с применением всех этих разработок. Бывает наоборот, заказчик требует, чтобы его проект «был на самом острие технологий». Но появление новых стандартов не означает однозначное их соблюдение пользовательскими клиентами (браузерами). Мир разработки ПО достаточно консервативен, особенно в области веб-клиентов. Часто приходится слышать от разработчиков ворчание в духе: «браузер XXX настолько плох, что не поддерживает последнюю спецификацию CSS 3.0, а вот бета-версия YYY, по заявлению разработчиков, - поддерживает!» Такие высказывания абсолютно бессмысленны. У разработчика есть выбор в инструментарии, а вот конечному пользователю нет никакого дела до инструментов, которыми был реализован данный проект. Пользователь хочет, чтобы все работало на том ПО (в данном случае браузере) с которым он привык обращаться, а как это работает, ему знать не хочется - он пользователь! Дорогие разработчики, переходя на новые стандарты, десять раз подумайте: стоит ли игра со стандартами свеч, потраченных на «просвещение» пользователей. Возможно, старые протоптанные дороги приведут, как ни странно, к более качественному исполнению заказа.