Журнал Компьютерра - Журнал «Компьютерра» №32 от 06 сентября 2005 года

На следующем этапе за дело берется специалист по проектированию пользовательских интерфейсов. Его задача - спроектировать максимально прозрачную, доступную и понятную структуру проекта для конечного потребителя продукта - не для заказчика, а именно для посетителей ресурса, которые будут пользоваться им для решения своих задач. Под системой взаимодействия нужно понимать не только удобство пользования (часто по ошибке называемое «юзабилити»[На самом деле, этот термин более общий: «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, по заявлению разработчиков, - поддерживает!» Такие высказывания абсолютно бессмысленны. У разработчика есть выбор в инструментарии, а вот конечному пользователю нет никакого дела до инструментов, которыми был реализован данный проект. Пользователь хочет, чтобы все работало на том ПО (в данном случае браузере) с которым он привык обращаться, а как это работает, ему знать не хочется - он пользователь! Дорогие разработчики, переходя на новые стандарты, десять раз подумайте: стоит ли игра со стандартами свеч, потраченных на «просвещение» пользователей. Возможно, старые протоптанные дороги приведут, как ни странно, к более качественному исполнению заказа.