Новый стиль работы
Вы рано или поздно столкнетесь с ситуацией, с которой столкнулись мы, работая над этой книгой. Заказчик изменит свое мнение, и все придется менять вслед за ним. Но теперь данные на Web-узле стали динамическими. Он стал гибче, но и сложнее, после того, как мы перешли от многих статических страниц всего лишь к трем динамическим.
Как вы узнаете из последующих глав, содержание Web-узла выводится в табличную структуру. Пожалуй, единственное, что не претерпело существенных изменений, так это панель навигации в верхней части страницы. Но все равно, теперь эта панель не переводит пользователя со страницы на страницу, а загружает нужные данные в созданные заранее шаблоны. Это очень эффективный метод создания Web-страниц.
Но самое главное для нас, разработчиков, состоит в том, что изменился порядок и способ работы.
Теперь дизайнеру недостаточно разрабатывать узел с помощью набора рисунков, приходится также создавать и базу данных. Мы поговорим об этом подробнее в следующей главе. Но для нас оказалось неожиданностью, насколько легко дизайнер воспринял эту перемену и стал мыслить категориями содержания, попадающего в табличную структуру.
На первый взгляд могло показаться, что теперь Джордан, программист, указывает Крису, дизайнеру, как создавать рисунки. Ниже Крис и Джордан объясняют, что на самом деле их роли не изменились, но возникли новое понимание и новый способ взаимодействия.
Говорит Джордан: "На самом деле роль Криса не изменилась. Он, как и раньше, создает рисунки для узла. Просто эти рисунки не появляются на экране, пока программа их не вызовет. Главное изменение произошло с панелью навигации. Она появляется на каждой странице. Панель навигации осуществляет ссылку на страницу, но я отвечаю за то, чтобы в нужный момент эта страница существовала".
Крис соглашается с этим: "Моя роль, действительно, не изменилась. Я по-прежнему разрабатываю модель узла с новым динамическим содержанием и делаю для этого рисунки. Гораздо больше меня занимает проблема физической удаленности. Хотя это и не очень сложно, но иногда мешает. Если бы мы с Джорданом работали в одном офисе, многие проблемы мы могли бы обсудить за чашкой кофе".
Распределение обязанностей
Сделать статический Web-узел динамическим – не такая простая задача. Если вы занимаетесь планированием узла, то важно своевременно сделать правильный выбор модели – статической или динамической, – что лучше подходит для вашей задачи. Принимайте это решение во время планирования, тогда вам удастся избежать многих проблем. На этом этапе еще можно достичь тонкого баланса между дизайном и программированием, когда дизайнер и программист могут разговаривать друг с другом непосредственно.
С точки зрения программиста и разработчика базы данных правильное распределение ролей требует полного понимания намерений дизайнера. Джордан говорит об этом так: "Крис может не согласиться со мной, но мне кажется, что моя роль в этом процессе сложнее. Я должен так написать программу, чтобы она как бы не существовала для пользователя. Для пользователя все должно выглядеть так, как будто Web-узел представляет собой набор HTML-страниц. Поэтому я должен приспосабливать свои программы к дизайну Криса. Это не так просто, особенно если речь идет о создании Web-приложения. Очень часто нам (разработчикам базы данных и программистам) приходится сначала делать программу, а потом нам дают рисунки, к которым мы должны эту программу приспособить. Это не облегчает нашу задачу".
Крис возражает: "Это в значительной степени зависит от того, на какой стадии процесса мы находимся. Я понимаю, что Джордану было нелегко. Я тоже сталкиваюсь с подобными проблемами, потому что все мои заказчики имеет огромные Web-узлы, связанные с базами данных. Выбрать способ, как соединить все это вместе, я имею в виду красивые картинки и информацию из базы данных, – очень сложная задача. И ее решение зависит от того, с какой стороны ее рассматривать, с точки зрения дизайнера или программиста. И то и другое может быть очень трудным. Поэтому Джордан, наверное, прав в том смысле, что его работа была тяжелее моей, поскольку ему приходилось подстраивать динамические данные под мой дизайн".
Фактор клиента
Мы не делаем динамический Web-узел, если клиент не просит нас об этом. Интересно, что в данном случае создание динамического сайта оказалось таким же новым делом для клиента, как и для разработчика. Процесс оказался слишком сложным из-за нашего клиента. Он хотел, чтобы посетители задерживались на его Web-узле. Он хотел интенсивного обмена данными. Он хотел, чтобы его бизнес процветал, но не хотел изучать новую область. Но, как мы уже много раз говорили на страницах этой книги, это проще сказать, чем сделать. Умение слушать клиента – это одно из самых важных требований при создании Web-узлов.
Часто ситуация осложняется по вине клиента. Они хотят, чтобы на их узле решалась некоторая специфическая задача. Джордан говорит, что если кто-то и нуждается в обучении, то это в первую очередь разработчики Web-узлов. Мы должны лучше вслушиваться в то, что говорит наш клиент. Когда он говорит о том, что ему нужен динамический Web-узел, мы должны понимать, что на самом деле ему нужно, чтобы посетители покупали его товар или пользовались его сервисом. И это наша задача – найти способ сделать так, чтобы между заказчиком и разработчиком установилось максимальное взаимопонимание.
По мнению Криса, привлечение клиента к процессу планирования узла дает многие преимущества.