Вы думали, что концептуальный дизайн кончился? Но не тут-то было.
    У нас на повестке дня вопрос номер два: "Как вы думаете, каким образом вы будете реализовывать свои странички - SSI/CGI/PHP? А способ обновления?"
    Вся штука в том, что грамотный ответ на этот вопрос быстро возвращает нас к началу концептуального дизайна. Кстати, в этом ничего страшного нет. Дизайн - это такая штука, когда постоянно возвращаешься к собственным истокам.
    Нет, действительно, способ оперирования со страницами накладывает вполне весомый отпечаток на всю концепцию сайта. Понятно, что самое правильное и безошибочно работающее - это статические страницы. Но вся фишка в том, что когда контент несколько разрастается, то управлять им становится достаточно сложно. А вручную корректировать/добавлять ссылки на десяти станицах (некий минимум) совершенно не прибавляет энтузиазма.
    Поэтому продумать концепцию движка надо заранее. Тут, кстати, есть интересная вещь. Разница хотя и есть, но не такая серьезная, как может показаться с первого или второго взгляда. Расположен движок на том сервере, что и сайт, или на компьютере отдельного Web-Builder`а - разницы с точки зрения отдельного посетителя нет. Посетителю главным делом увидеть хорошо сделанную страницу и прочитать контент, а в всякие разные проблемы Web-Builder`a лезть никто не станет.
    Итак, концепцию движка мы определили. Самое время вернуться и откорректировать концепцию сайта из-за "вновь открывшихся обстоятельств".

    Следующий вопрос - это логическая структура сайта. О физической структуре речь не идет. Благо PHP и CGI позволяют "спрятать" реальный контент так, как удобно создателю сайта и выдать этот самый контент так, как удобно посетителю. Эти причины и немного возвращают нас обратно.
    Из концепции логической структуры попутно возникает пара вопросов, связанных с этой же логической структурой:
- на каком уровне идет каталогизация контента? То есть по каким признакам вы планируете раскидывать контент по различным каталогам (не физическим, а логическим).
- по каким признакам производится рубрикация контента? Рубрикацию нужно продумывать так, чтобы посетителю было удобно (и понятно, что не менее важно) пользоваться меню и рубрикатором. Иной раз, кстати, рубрикатор может отсутствовать. Ну вот, к примеру, если мы поддерживаем непрерывную ленту новостей, то к ней рубрикатор не нужен. А если лента новостей разбита на тематические разделы - тут как ни плачь, а рубрикатор совсем не помешает. Правда, если сайт содержит несколько независимых разделов, то ситуация усложняется, требуя загрузки большего количества мозгов.
    Кроме того, хорошо бы подумать над логической "уровневостью" сайта с точки зрения посетителя. Теоретически говоря, максимальное количество ссылок/кликов мышой с первой страницы до конкретного текста должно быть меньше, но перегружать страницы массивом ссылок - это не дело. Так что вперед - подбирать баланс.
    Разбивать или не разбивать длинные тексты на части? Желательно предусмотреть и тот и другой вариант, внеся в концепцию соответствующие коррективы.

    Еще один вопрос - это концепция навигации. Давайте посмотрим на различные способы навигации:
- одноуровневая - Первая-Текст. Адреса получаются такими: www.server.ru/index.html?anytext. С тем, где найти этот самый anytext, вполне справляется CGI или PHP движок, реально присутствующий на сервере.
- двухуровневая - Первая-Текст. Удобно и логично, но на первую страницу сотню ссылок не впихнешь (я напоминаю, что мы рассматриваем вполне серьезный и постоянно обновляемый контент-сайт). Поэтому более логичны другие способы навигации.
- трехуровневая - Первая-Тема-Текст. Наиболее распространенная схема навигации и достаточно удобная как для разработчика, так и для посетителя.
- многоуровневая - Первая-Тема-Подтема-Текст. Применяется, когда контента - как нерезанных собак, в смысле - много. Вот тут самое главное - правильно произвести классификацию/рубрикацию контента по темам.

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

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

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

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