Любой сайт – это прежде всего информативный ресурс. А для того чтобы информация легко воспринималась, ее необходимо грамотно структурировать, классифицировать и т.д. Особенно если речь идет о больших объемах данных. Концепция, в соответствии с которой содержание данного конкретного ресурса обрабатывается и представляется посетителю, называется информационной структурой сайта.
К сожалению, многие разработчики слишком легкомысленно подходят к вопросу разработки информационной архитектуры сайта. Так в просторах сети появляются ресурсы, в которых нет ни четкого разграничения разделов, ни логичной и очевидной системы размещения информации. Работать с такими сайтами трудно, поддерживать информацию на них в актуальном состоянии – еще труднее.
Эти проблемы, а также вывод дополнительной сопутствующей информации, соответствующей тематике страницы, легко решаются с помощью грамотного проектирования информационной архитектуры.
Например, если книжный интернет-магазин спроектирован профессионально и правильно, посетитель на странице с книгой также сможет увидеть сведения об авторе, отзывы, рецензии, краткие описания книг, близких к данной тематике, и прочую информацию, которая может быть ему полезна.
Не устанем повторять, что именно налаженная и очевидная взаимосвязь между материалами является главным преимуществом интернет-ресурсов перед печатными изданиями. А спроектировать сайт, который будет демонстрировать высокое качество связности разделов, можно только с помощью аппарата реляционной теории.
Совместная работа с заказчиком: моделирование информации
Практически в любом ВУЗе, где готовят специалистов в области ИТ, читают курс «Основы базы данных». Однако не всем слушателям удалось его усвоить в силу тех или иных причин. Кто-то не разобрался в сложностях реляционной теории, кто-то не нашел общего языка с преподавателем. А некоторые просто не оценили степени важности данной дисциплины для своей дальнейшей работы.
Мы постарались еще раз пересказать ее основные постулаты простым неакадемическим языком, сосредоточившись лишь на тех аспектах, которые касаются проектирования структуры для Битрикс.
Роль заказчика в процессе проектирования
В различных пособиях для менеджеров проектов читателя буквально через страницу призывают к правильному целеполаганию и мотивации, убеждая, что это уже полдела.
Безусловно, бриф – это важнейшая составляющая работы. Однако это лишь начальный, а не финальный этап сотрудничества с заказчиком. В брифе просто невозможно вместить все важные аспекты дальнейшей работы. В тоже время ТЗ, как правило, слишком сложно и запутанно составлено. Вникать в каждую его деталь в ходе обсуждения невозможно.
Ключевой этап работы с заказчиком – составление инфологической, а далее – даталогической модели будущего ресурса. Впрочем, при построении последней участие заказчика не всегда требуется. Если клиент недостаточно разбирается в вопросах оптимизации производительности системы, без него вполне можно обойтись.
Однако создать информационную архитектуру сайта без тесного взаимодействия с заказчиком нереально – будь вы трижды профессионал. Как будет выглядеть это взаимодействие? Оно будет заключаться в совместном времяпрепровождении возле монитора, достаточно большого для комфортной работы, в ходе которой вы будете рисовать в MS Visio. И провести таким образом вам придется вместе с клиентом не один рабочий день, о чем следует заблаговременно его предупредить. Скорее всего, время от времени придется брать паузы для того, чтобы обдумать наиболее сложные задачи. Они позволят вам набело дорисовать то, что вы лишь набросали совместно с заказчиком. Для заказчика такие перерывы необходимы прежде всего для того, чтобы проконсультироваться со своими специалистами, пересмотреть документацию и просто «перезагрузиться» после новой и потому достаточно сложной для него деятельности.
Предполагается, что вы профессионально работаете в Visio – иначе вы рискуете утомить заказчика. Впрочем, для того чтобы рисовать ER-диаграммы, нужно в совершенстве владеть не столько навыками рисования, сколько основами реляционной теории, которые мы и осветим чуть позднее.
Разумеется, не всякий заказчик согласится с тем, что в рисовании ER-диаграмм требуется его участие. Бытует мнение, что заказчик должен предоставить разработчику подробное ТЗ, а на его основе уже и рисуются ER. Однако такой подход неверен, и вот почему:
- Построить ER-диаграмму в голове и описать ее словами в ТЗ не способен ни один человек. И ваш заказчик – не исключение.
- Если ТЗ не подвергается тщательной модерации технического специалиста, оно обычно пестрит совершенно необязательными связками и деталями, среди которых упускаются действительно важные моменты. Заказчик может какие-то вещи понимать на уровне интуиции, но не в силах описать их словами.
- Разработчик, вероятнее всего, не является специалистом в сфере деятельности заказчика. Поэтому его ER-диаграмма будет красивой и правильной, но далекой от суровой реальности.
- Даже при грамотном и понятном ТЗ при переносе его в структуру БД появится множество разночтений. ER-диаграмма всегда читается однозначно.
При создании традиционных приложений, предполагающих использование БД, необходимости в создании ER-моделей, как правило, не возникает. В web-программировании – в том числе на базе Битрикс – с этим ситуация обстоит весьма плачевно. Вероятно, причина этого заключается в том, что традиционным программистам привычнее думать абстрактно, тогда как web-разработчики воспринимают информацию визуально.
Итак, любой более или менее сложный сайт – это в первую очередь система обработки, предоставления и хранения информации. Ее продумывание – ключевая задача любого программиста. Именно структура информации, а не карта сайта, в первую очередь влияет на функциональность и развитие ресурса.
Прежде чем приступить к созданию сайта, необходимо дифференцировать статику и динамику и продумать структуру БД для динамичной части.
Бывает, что разработчики все-таки создают нечто, напоминающее ER-модель. Однако она отображает лишь то, что заказчик отметил в ТЗ. А заказчик, как мы уже напоминали, не является техническим специалистом. При этом все атрибуты и связи проектировщики отобразить даже не стараются, полагая, что в процессе работы диаграмма будет подвергаться постоянным изменениям. Безусловно, так оно и будет. Ведь любой проект динамичен, и в ходе его реализации будут всплывать все новые и новые требования. Тем не менее, их количество, равно как и количество исправлений и переделок в дальнейшем, можно существенно сократить уже на стадии старта, если с самого начала предельно точно определиться, что именно придется вынести на сайт. И большинство новых требований в ходе работы будут связаны не с тем, что заказчик и проектировщик друг друга недопоняли, а с динамикой самих бизнес-процессов заказчика.
Итак, мы полагаем, что создание ER-диаграммы, отображающей все атрибуты, сущности и связи на начальной стадии проектирования – важнейшее условие разработки качественного ресурса. В дальнейшем ER-модель ляжет в основу структуры раздела, макетов страниц и URL-адресов.
Проектировать информационную архитектуру сайтов можно различными способами. Так, например, в UML особый акцент делается на объектной природе данных. IDEF1X сосредотачивается на реляционной природе, хотя объектный подход в рамках IDEF1X также возможен.
IDEF-методология, если верить Википедии, нацелена прежде всего на эффективный информационный обмен между всеми участниками процесса. Она лежит в основе реинжиниринга бизнес-процессов.