Веб-дизайн

Функциональность и контент

На уровне набора возможностей мы переходим от абст­рактного вопроса «Зачем мы делаем этот сайт?», который задавали себе на уровне стратегии, к новому вопросу: «Что мы собираемся создать?».

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

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

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

Язык этой главы по большей части является языком раз­работчиков программного обеспечения. Однако изложен­ное здесь в той же степени применимо и к контенту. При разработке контента определение требований часто не включается в формальную процедуру, типичную для раз­работки программ, однако основные принципы остаются теми же. Чтобы понять, какую информацию должен доне­сти контент сайта, разработчику контента предстоит побе­седовать с людьми или изучить исходные материалы, будь то база данных или коробка с газетными вырезками. Этот неформальный процесс сбора требований к контенту на са­мом деле не так уж радикально отличается от того, что де­лают разработчики, проводя мозговой штурм с участием
заинтересованных сторон и изучая имеющуюся докумен­тацию. Цели и подходы в обоих случаях одинаковы.

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

Процесса. Будут ли элементы содержимого сайта автомати­чески переупорядочиваться в соответствии с предпочте­ниями каждого пользователя? Система управления кон­тентом должна уметь предоставлять данные в таком не­простом режиме.

Функциональные требования со своей стороны влияют на контент. Потребуются ли инструкции на экране настроек? Как насчет сообщений об ошибках? Все это кто-то должен написать. Каждый раз, когда я вижу на веб-сайте сообще­ние типа «Исключение: передана пустая строка», я пони­маю, что в готовом продукте остался текст предупрежде­ния, вставленный кем-то из программистов в качестве за­глушки, и произошло это потому, что в требования к кон­тенту никто не добавил сообщения об ошибках. Огромное количество якобы высокотехнологичных проектов могло бы стать радикально лучше, если бы кто-нибудь из их раз­работчиков взял на себя труд пристально посмотреть на контент приложения.