Главная страница
Библиотека (скачать книги)
Скачать софт
Введение в программирование
Стандарты для C++
Уроки по C#
Уроки по Python
HTML
Веб-дизайн
Ассемблер в среде Windows
ActiveX
Javascript
Общее о Линукс
Линукс - подробно
Линукс - новое
Delphi
Паскаль для начинающих
Турбопаскаль
Новости
Партнеры
Наши предложения
Архив новостей





Урок 7. Работа над дизайном

Основные беды работы с заказчиком (с точки зрения веб-дизайнера) следующие:
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. И еще много раз тестировать, потому что даже эти знания не спасают от обнаружения новых неожиданностей.

 

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

 

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

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

 

Проектирование

Если не знаешь, зачем сайт и куда его применить — не делай его совсем. Это, пожалуй, ключевое правило проектирования сайта. Потому что во всех остальных случаях есть материал, идеи и хотя бы приблизительное представление, как воплотить идею в жизнь.
После того, как идея появилась и в достаточной мере оформилась, а материалы оказались подготовленными, следует решить кроссворд.

Кроссворды, как известно, обладают одной особенностью: все без исключения должно встать на свои места так, чтобы не осталось пустых мест. В случае с разработкой сайта действует такое же правило: все компоненты сайта должны вступать между собой в такие отношения, чтобы не оставалось смысловых пробелов. Чтобы ничего не было упущено, но и слишком многого бы не получилось.

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

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

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

 

В сторону смысла: форма и содержание
Понятия «форма» и «содержание» появились очень давно. Аналогично, важность разграничения формы и содержания тоже была осознана давным-давно. Тем не менее, при создании веб-страниц принцип такого разграничения проводится далеко не всегда.

Типичный пример — редизайн. Первый (штатный) дизайнер делает сайт, состоящий из 214 страниц в формате .html, в каждом из них пишет навигационное меню, а стили в связанном CSS-файле описывают только цвет ссылок и нулевые отступы по краям страницы.
На каждой странице он заголовки выделяет не тэгом <h1>, а сочетанием тэгов <b> и <font size=+4>, причем не всегда закрывает их. Потом дизайнер увольняется. Шедевр висит на сервере два года, а потом руководству сообщают, что сайт не соответствует современным требованиям, плюс к тому — на нем нельзя оставить отзыв, сделать заказ и отправить письмо. Руководство раскошеливается и приглашает веб-дизайнера со стороны. Тот смотрит файлы сайта и ужасается. Потому что переделать это невозможно: проще сделать заново.

 

Почему так происходит? Потому что первый дизайнер брал страницы одну за другой и просто вставлял новый текст вместо старого. Потому что он не смотрел вперед и не думал, что сайт нужно будет переделывать: например, добавить пару разделов (из-за чего 214 раз придется переписывать фрагмент кода, отвечающий за навигацию).

Изменить раздел логотипа (аналогичный объем переделок). Он не думал, что любой поисковой системе будет сложно автоматически вычленить заголовок страницы из массива текста, не размеченного логически. Он вообще не осознавал, что фрагменты веб-страницы могут обладать семантикой.
Не думал, что можно разметить их не формальными тэгами (которые только изменяют внешний вид), а логическими. Дело в том, что если вид заголовков, размеченных парой тэгов <h1>...</h1>, разонравился, его можно изменить правкой всего одной строки в CSS-файле, а не редактировать 214 страниц. Аналогично, если есть семантически схожие блоки текста, их можно оформить парой <span class = "...">...</span> и придумать имя класса, который будет описан в том же CSS-файле.

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



     
 

Библиотека программиста. 2009.
Администратор: admin@programmer-lib.ru