В прошлый раз я пытался разобраться с картами сайтов. Речь шла не об xml sitemap для поисковиков и не об оглавлениях сайтов для посетителей. Под картами сайтов подразумевались рисунки с подписанными квадратиками (страницами) и соединяющими их линиями (ссылочными связями).
В комментариях возникла путаница, и все виды карт слились в одну. Как оказалось, это размытое представление иногда приводит к поразительным результатам.
Подсказка: по большинству квадратиков и кружочков на схемах по двум только что упомянутым ссылкам можно кликать.
Кстати, с точки зрения пользователя такое решение бесполезно.
Четких ответов на основные вопросы найти так и не удалось. Зато я заметил схожие мысли у других разработчиков: сложно сказать, что делать с большими сайтами, какие связи не рисовать.
Вывод из этой истории?
При проектировании не нужно сильно рассчитывать на карту сайта. На начальном этапе она помогает описать будущую систему, но долго поддерживать ее в актуальном виде смысла нет.
Как и что рисовать? Делайте, как подсказывает сердце :)
Дмитрий Сергеев, 26 лет, разрабатываю сайты на Drupal, управляю интернет-проектами
Комментарии
grimskin, 13.05.2007 03:49
"поддерживать ее в актуальном виде смысла нет" - а вот это очень зря.
давайте так - называем это дело как и положено, макетом, и получаем очень полезный документ как для аналитика/архитектора/разработчика/менеджера работающего с заказчиком, так и для заказчика (если таковой есть), т.к. рядовой заказчик гораздо лучше воспринимает простые квадратики/стрелочки в комплекте с комментариями чем тот же UML, и чем просто текст. кстати, если на небольших проектах можно без него обойтись, то на больших проектах макет обязателен.
проблем вида "какие связи рисовать" на самом деле тоже нет.
разбиваете сайт на части - по доступу, по функционалу и пр. - и отображаете каждую часть отдельной схемой. по-умному это называется декомпозицией http://ru.wikipedia.org/wiki/Декомпозиция.
общие связи (т.е. наличиствующие для каждой страницы в рассматриваемой части) естессно не рисуем, а, как я уже упоминал, описываем текстом. все остальное - рисуем. при хорошей декомпозиции у вас не будет схем перегруженных связями. даже, я бы сказал, не будет схем, на которых линии связей будут пересекаться :)
в итоге получаем документ, который полностью описывает функционирование системы со стороны пользователя и на основании которого, можно уже, например, описывать use-case -ы.
Дмитрий Сергеев, 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 (не касаясь вопросов работы с шаблонами представлений)...
kodji, 16.05.2007 19:15
в крупных компаниях занимающихся веб-разработками разделение контент-менеджера, программиста, дизайнера и верстальщика нередко. Но даже выполняя одну функцию необходимо разбираться "хотя бы на уровне пользователя" в соседствующих. Иначе каши не сваришь. А вообще вы отошли в обсуждениях от темы, как мне кажется.
Поддержка и развитие карты сайта, разработанной перед его созданием - я такое явление встречал пока только в автоматически создаваемых картах в составе небольших 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
Карта сайта физически может и не связана с сайтом, если только она не размещена на этом сайте : ). Но, карта сайта это инструмент, необходимый для создания сайта. В процессе разработки сайта его карта может меняться только в случае плохой, недостаточной подготовки создания сайта. И уж если в процессе разрабботки сайта всё-таки приходится изменять его карту, то на вопрос: стоит ли синхронизировать чертеж с тем, что получается на самом деле - ответ только один - не просто стоит, а необходимо! А на счёт выбросить карту по окончянии разработки... Это помоему неправильно, карта эта в любом случае не помешает, места много не займёт, а вот проанаизировать свою работу поможет.
Гость, 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
Карту сайта надо отдать заказчику сайта, что бы в случае необходимости он мог обратиться к другому разработчику. А другой разработчик не тратил бы времени на исследование этого сайта.
kodji, 16.05.2007 23:56
как правило так и происходит (по крайней мере в моей практике) - карту составляют чтобы определиться с количеством работы на начальном этапе. а потом карта не нужна.
Gray, 23.05.2007 03:40
Карта не нужна, если сайт сразу получился таким каким хотелось бы. А если вы учли не все пожелания заказчика? Не важно по чьей вине (вы не поняли или заказчик плохо объяснил). Да и для развития сайта карта необходима. А если сайт делает не один разработчик? И вообще, если карту сайта сделать трудно, то за сайт лучше и не браться.