Процесс

Процесс

0.3

Flash). В таких условиях тестирование приобретает особую важность. При программировании же тесты важны в двух случаях: во время на­писания кода при «обкатке» его в условиях, приближенных к реаль­ным (на домашнем или тестовом сервере) и после размещения проек­та на рабочем сервере. Файлы конфигурации (например, .htaccess на сервере Apache), переменные окружения, пути к файлам, работа мо­дулей (например, количество переадресаций в модуле mod_rewrite) и прочие нюансы могут различаться на тестовом и реальном серверах. Все эти факторы делают постоянное тестирование совершенно необ­ходимым.

Рассмотрим, как может протекать процесс создания сайта в ус­ловиях, когда все функции (дизайнер, кодер, программист и т. п.) вы­полняет один и тот же человек.

Грамотное проектирование определяет, сколько времени будет затрачено на создание сайта, переделку его под влиянием заказчика, со­ветчиков и здравого смысла, а также на редизайн и изменение структуры в дальнейшем. Важно представить себе каждый из последующих про­цессов и понять, что и в какой последовательности нужно делать. Перед началом работы нужно задать себе ряд вопросов (насколько длинным будет ряд — зависит от добросовестности разработчика) и максимально подробно ответить на них.

Для чего нужен этот сайт? Нужен ли он вообще?

Какая информация будет представлена на нем? Много ли ее там будет?

Как лучше логически разделить разные порции этой информа­ции на группы, чтобы посетитель без ошибок понял, в какой группе ему стоит искать нужное?

Что в нем будет особенного по сравнению с подобными сущест­вующими? Если ничего, то все же почему он имеет право на существо­вание? А если есть особенное, то почему бы не сделать это лейтмотивом работы?

Для кого создается ли этот сайт? Для самой широкой аудитории (тогда эксперименты с интерфейсом и дизайном должны будут свестись к минимуму), для молодежи (приветствующей эксперименты и обожа­ющей игры) или для бизнес-аудитории (для которой важнее всего опе­ративный доступ к удобно рубрицированной и правильно дозирован­ной информации)?

Какого рода информацию будет искать посетитель на этом сайте? Нужно ли будет на нем что-то искать?

Как помочь ему, если он сразу не нашел нужную информацию?

Нужно ли снабжать его обилием дополнительной информации? Будет ли дополнительная информация подгружаться на ту же самую страницу в указанное место или потребует загрузки дополнительной страницы (страшно представить — в новом окне)?

Вводная часть

Нужна ли на сайте декоративная и иллюстративная графика? В каком объеме? Могут ли стратегически важные ссылки или фрагмен­ты изображения быть решены в виде изображений?

Нужен ли на сайте флэш? Почему без него нельзя обойтись? Ка­кие функции он будет выполнять?

Нужна ли на сайте анимация?

Что стоит вынести на передний план, что дать анонсами, а что вообще спрятать на внутренних страницах сайта?

Как именно информация будет разнесена на разные страницы? В чем логика такого разделения? Может ли сайт быть размещен только на одной странице с динамически подгружаемыми блоками информа­ции? Что будет, если у пользователя будет отключен JavaScript?

Будет ли на сайте время от времени изменяющаяся информация? Насколько часто она будет меняться? В каком виде лучше сделать архив старых сообщений (новостей, постов, объявлений), нужно ли его делать вообще?

Как лучше организовать архив основных материалов? Все ли нужно держать на виду или часть стоит опускать за пределы видимос­ти при помощи ссылок («Все материалы по теме», «Остальные статьи», «Отчеты за прошлый год», «Новости за прошлую неделю»)?

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

Насколько обширной будет система статистики? Будет ли она регистрировать (помимо общего количества посетителей) ежедневную и постраничную посещаемость? Будет ли фиксироваться география пользователей и время, проводимое ими на каждой из страниц?

Что на сайте должно быть необычно? Где именно можно проявить новаторство? Не повредит ли новаторство работе с сайтом как с инстру­ментом получения информации?

Что будет, если посетитель отключит активные сценарии, табли­цы стилей, изображения, плагины (флэш и Java) или все вместе?

Как содержимое сайта будет смотреться на экранах разной ши­рины?

Как удобнее сделать меню доступа к остальным страницам?

Как разграничить функциональные (на запуск сценариев) и на­вигационные (на другие страницы) ссылки? Как разделить ссылки, от­крывающие страницу в новом или том же самом окне?

Какие технологии будет удобнее всего использовать при создании сайта? (Речь идет не о том, что разработчик лучше знает фотошоп, чем остальные растровые программы, и поэтому будет пользоваться имя для всех операций, а о том, что в каждом случае он сознательно выбирает

22

Процесс

0.3

Инструмент, пригодный в данной ситуации.) Есть ли смысл скрывать от посетителей то, что сайт написан на PHP, а не на Perl’e?

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

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

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

Вопрос: «Какой дизайн нужен для данного сайта?» — можно пос­тавить и по-другому. Нужно понять, что будет на веб-странице, а затем решать, как это будет выглядеть. Потому что, только располагая каки­ми-то объектами, можно решать, как их располагать. С другой стороны, ничего не мешает придумать идею для сайта до того, как разработчик точно решит, какие разделы будут присутствовать на сайте. Если при­ветствуется творческий подход, то заранее рожденная идея даже помо­жет создать концепцию всего сайта в целом.

Вводная часть

В таких случаях незаменимым средством оказывается мозговой штурм. Он помогает найти самые неожиданные ассоциации к заданной теме. Например, слово «навигация» пришло из мореходной термино­логии; отсюда вывод: навигационное меню делаем в виде штурвала или карты. Платные материалы («товары») группируем в рубрике «трюм», а раздел «карта сайта» оформляем в виде развернутого свитка навигаци­онной карты. Страницу поиска оформляем в виде «марса» (места, откуда в средневековом мореходстве наблюдали за горизонтом), функциональ­ную ссылку «Добавить в Избранное» (или «Поставить закладку») снаб­жаем пиктограммой якоря, а раздел «Персонал» — тельняшками или бескозырками. В этом случае появляется выдержанность идеи оформ­ления сайта. Конечно, если сайт нейтрален по тематике либо относится к мореходному делу. Вопрос, нужно ли подобным образом оформлять сайт, посвященный недвижимости в Подмосковье, не возникает.

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

Например, я чаще всего делаю наброски и макеты в графических редакторах. В силу привычки думать, что называется, «с карандашом в руке», набросать примерную схему будущего дизайна, одновременно продумывая детали, удобно в какой-нибудь векторной программе (на­пример, в Creature House Expression или Macromedia Freehand). А вот уже окончательный макет логичнее готовить в растровом редакторе (Adobe Photoshop как общепризнанный стандарт, но возможен и дру­гой — вопрос вкуса, привычек и конкретных задач), поскольку основой для внешнего вида сайта будут (помимо разметки на HTML и CSS) как

24

Процесс

0.3

Раз растровые изображения. Распространенные растровые редакторы дают как минимум две возможности, чтобы нарезать из макета изоб­ражения, которые в дальнейшем будут загружаться с веб-страницей (встроенная технология разделения на фрагменты и последующего эк­спортирования в отдельные изображения, которая, например, в фото­шопе называется Slices — «ломтики», а в Jasc Paint Shop Pro — очень похоже, Image Slicer, и — вторая возможность — элементарное выделе­ние, копирование и вставка в нужного размера файлы, сохраняемые для веб-страниц).

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

Наиболее же неприятным этапом чаще всего оказывается согла­сование вариантов дизайна с заказчиком. Очень редко встречаются иде­альные заказчики, полностью довольные предоставленным макетом. Основные беды работы с заказчиком (с точки зрения веб-дизайнера) следующие:

1. Я не знаю, чего хочу..

2. Вот это левее подвиньте, это перекрасьте в синий цвет, фоном по­больше фигур вставьте, шрифт какой-нибудь менее строгий под­берите.

3. Хочу так же, как у вон той фирмы.

4. Понимаете, я тоже веб-дизайном занимаюсь.

5. Хочется, чтобы как у всех.

С первой бедой можно справиться, приведя множество аргумен­тации с непонятными терминами и уверениями, что сейчас так модно и что это будет работать. Но примерно в 50% случаев. С остальными бе­дами бороться очень тяжело. С шаблонным мышлением, на мой взгляд, вообще бороться почти невозможно — если только использовать какой - то нешаблонный метод.

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

Вводная часть

Не, что у каждого браузера есть свои специфические условия, при кото­рых тот или иной фрагмент кода будет работать некорректно. Например, все верстальщики знают, что при указании фонового изображения средс­твами CSS в скобках нельзя использовать кавычки. То есть нужно пи­сать background:URL(image. gif) вместо логичного background: URL("image. gif") — потому что браузер Microsoft Internet Explorer в среде операционной системы MacOS, встречая эти кавычки, отказы­вается работать дальше. (Правда, все также знают, что на «макинтошах» сейчас все больше используют Safari и Mozilla Firefox, а также изредка Camino — все три построены на других «движках»; но по традиции кавы­чек не ставят.) Еще все знают, что Netscape 4 перезагружается при измене­нии размеров страницы пользователем. Всем известно, что священные тексты спецификаций HTML и CSS разработчики всех браузеров тракту­ют несколько по-разному (и только к выходу IE 7, Firefox 2 и Opera 9 вой­на конфессий приняла более спокойное течение), и что рамки (указанные как «border») браузеры Opera и Firefox будут помещать снаружи блока, а Internet Explorer — внутри. Остается держать в уме не только специфи­кации, но и таблицы несовместимостей браузеров с точки интерпрета­ций тэгов HTML и свойств CSS. И еще много раз тестировать, потому что даже эти знания не спасают от обнаружения новых неожиданностей.

Программирование может протекать не только параллельно верс­тке страниц, но даже параллельно разработке дизайна и рождению идей дизайна сайта. Смысл в том, что структура сайта разрабатывается в са­мом начале, а грамотное построение структуры сайта — как раз задача программиста.

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

26