Не рассчитывайте на карту сайта

Дмитрий Сергеев, 13.05.2007 12:03

Честная карта, отражающая всё как есть на самом деле, -- это очень здорово. Тут и спорить нечего.

Однако, на некотором этапе разработки, когда карта уже многое отражает, доведение ее до совершенства становится очень сложным делом. А тем более поддержание в актуальном виде.

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

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

Кстати, декомпозиция убивает наглядность. Понимать многоуровневые схемы могут далеко не все.

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

grimskin, 13.05.2007 15:18

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

Дмитрий Сергеев, 13.05.2007 16:27

То есть такая карта типов получается? Тогда со связями проблем не будет :)

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

Вернемся к гипотетической карте этого блога. В прошлый раз речь шла о трех страницах: общая лента, лента категории и отдельная запись.

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

Получили карту из одной страницы с тремя текстовыми комментариями:
* про постраничный вывод,
* про фильтр по категории,
* про фильтр до отдельной записи с добавлением блока комментариев.

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

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

grimskin, 13.05.2007 17:31

ну, вообще-то, я ленты с категорями не отделял от главной :) она и есть отфильтрованная общая.

а вот страница с постом не является "сильно отфильтрованной общей" т.к. имеет расширенный функционал и выводит совсем другие данные, отличные от ленты.

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

p.s. rss и карту для гугли я не рассматриваю, просто чтобы не усложнять, они в данном случае не принципиальны :)

Дмитрий Сергеев, 13.05.2007 18:03

Хорошо, не буду спорить. Но всё-таки с точки зрения посетителя блог состоит не из двух страниц :)

Я не против абстракций, но иногда соотношение "1 пост = 1 страница", отраженное на карте сайта, имеет смысл. Пусть это и называется как-нибудь по-другому. Хотя xml sitemap называется картой сайта.

grimskin, 13.05.2007 19:13

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

Дмитрий Сергеев, 13.05.2007 19:50

Про второе, всё верно :) Но и карта, которую в самом начале рисует разработчик, может быть разной, как я понимаю.

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

grimskin, 13.05.2007 20:37

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

~xXx~, 15.05.2007 00:19

))))

Дмитрий Сергеев, 13.05.2007 21:18

Если смотреть на контент-менеджмент широко и включать в него информационную архитектуру, то наверное да :)

Junior, 15.05.2007 13:22

Не согласен. Программист тоже может верстать, но это не его профиль.

Контент-менеджер, имхо, должен:

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

Дмитрий Сергеев, 15.05.2007 15:02

Согласен.

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

~xXx~, 15.05.2007 17:43

все верно... по мне, так контентщик в чистом виде должен скорее совмещать навыки написания текстов и их грамотной верстки, подготовки изображений для веб и, по возможности, уметь управлять структурой сайта посредством CMS (не касаясь вопросов работы с шаблонами представлений)...

Дмитрий Сергеев, 16.05.2007 19:36

Мне кажется, мы обсуждали карту сайта, как элемент документации. То есть она никак физически не связана с самим сайтом. Просто чертежи на бумаге или в Visio.

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

Ну и grimskin говорит, что схему нужно обновлять. А я в принципе согласен, но не исключаю и другой возможности: можно использовать карту на начальной стадии проектирования, а потом выбросить ее.

~xXx~, 17.05.2007 00:30

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

Дмитрий Сергеев, 17.05.2007 00:44

Кстати, да. Если в договоре упоминается тз с картой сайта, то для ее обновления придется сделать что-нибудь юридическое :) И думаю, это не так уж хорошо -- спроектировать сразу всё как надо невозможно. Ловушка для заказчика и оправдание для исполнителя.

~xXx~, 17.05.2007 00:58

ТЗ по-любому включает в себя карту сайта, так как многие разделы сайта обслуживаются кастомными модулями, прописанными ниже по тексту ТЗ (а далеко не все CMS способны весьма вольно работать с шаблонами представлений в плане подключения любых модулей в любые области шаблона страницы). + карта сайта регламентирует последующее контент наполнение в рамках договора.

~xXx~, 17.05.2007 01:00

ЗЫ

структура сайта как правило формируется на уровне коммерческого/тендерного предложения. а потому на момент подписания договора проект уже имеет конечную смету.

grimskin, 17.05.2007 01:39

ну спроектировать все как нужно не проблема :) а вот спроектировать это так, как это хочет заказчик - это уже да, проблематично.

~xXx~, 17.05.2007 10:29

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

вот как раз нормальных проджектов то и дефицит на рынке. как правило в результате задачи проджекта решает по сути аккаунт-менеджер.... (

Gray, 23.05.2007 03:20

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

Mr. X, 23.05.2007 16:55

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

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

Дмитрий Сергеев, 23.05.2007 16:58

Ха-ха. Забыл залогиниться :) Предыдущий коммент -- мой.

~xXx~, 24.05.2007 01:43

мысль - если карта сайта меняется на этапе сборки сайта, то кто мешает модернизировать CMS на предмет экспорта в тот же csv той самой текущей карты с сохранением иерархии и указанием используемых в разделе программных модулей?

Дмитрий Сергеев, 24.05.2007 11:21

Хорошо бы CMS specific модуль, чтобы нюансы учитывал и отрисовывал карту аккуратно. Можно поискать что-нибудь подобное в составе пакетов, направленных на автоматизрованное производство документации.

Gray, 23.05.2007 03:30

Карту сайта надо отдать заказчику сайта, что бы в случае необходимости он мог обратиться к другому разработчику. А другой разработчик не тратил бы времени на исследование этого сайта.

Gray, 23.05.2007 03:40

Карта не нужна, если сайт сразу получился таким каким хотелось бы. А если вы учли не все пожелания заказчика? Не важно по чьей вине (вы не поняли или заказчик плохо объяснил). Да и для развития сайта карта необходима. А если сайт делает не один разработчик? И вообще, если карту сайта сделать трудно, то за сайт лучше и не браться.