Динамические страницы во Flash MX
Ранние версии Flash позволяли разработчику создавать динамические страницы, но для этого он должен был использовать специальное приложение — Generator.
Во Flash MX есть возможность создавать динамические страницы непосредственно, и это открыло для разработчиков новый мир. Но как случается со всяким новым средством, оно не только создает новые возможности, но и порождает новые проблемы.
Динамические Web-страницы во Flash нужны тем клиентам, которые должны постоянно обновлять содержание своих Web-узлов. Во Flash MX для этого есть широкий набор средств, которые позволяют не только генерировать динамический текст, как это было в ранних версиях, но и создавать динамически рисунки и даже звук МРЗ.
Главное преимущество состоит в том, что размер файлов SWF стал меньше, уменьшилось время загрузки, и многие элементы страницы теперь могут загружаться на лету, незаметно для пользователя. Если вы правильно спланировали свой узел, то пользователь сможет смотреть Flash-ролик почти сразу после подключения. А если подойти к этому творчески, то пользователю может казаться, что каждый раз он просматривает новый ролик.
Второе важное преимущество состоит в использовании баз данных и обработке полученных данных. Нет сомнения в том, что через некоторое время Flash MX станет самым популярным Internet-приложением. Теперь пользователям не нужно переходить со страницы на страницу при работе с Web-приложением. Хотя классические Web-приложения были большим шагом вперед, все же они не полностью использовали возможности современных компьютеров.
Flash MX сделало в этом смысле большой шаг вперед. Пользователь может оставаться на одной и той же странице, вызывая различные ресурсы в фоновом режиме. Он может делать покупки в сети, при этом не переходя со страницы на страницу, как приходилось ему делать на обычных HTML-узлах. Новые свойства Flash позволят пользователю рисовать на экране, причем все нарисованное может быть сохранено и впоследствии превращено в ролик Flash. Короче говоря, возможности его безграничны. Мы, наконец, приблизились к тому, чтобы работать с настоящим приложением, вместо того чтобы загружать последовательность страниц, как это было раньше.
Достоинства и недостатки элементов навигации, созданных во Flash MX
Мы вполне могли бы создать нашу панель навигации с помощью Flash MX. Мы много говорили об этом в самом начале работы над проектом, но, в конце концов, отказались от этого, и в этом разделе Джордан попытается объяснить, почему мы приняли именно такое решение.
Я создал две панели навигации на основе графики, которой пользовался Крис. Эти файлы вы можете найти в папке с упражнениями к главе 18 на Web-узле этой книги. Конечно, эти панели не закончены.
В первом файле, FlashNavl, используется рисунок, импортированный из Fireworks MX. Для того чтобы добиться того же эффекта, что и у Криса, файл бы растеризован, и в результате был получен файл приблизительно того же размера, что и GIF-рисунок Криса. Естественно, там не было ни символов, ни ссылок, так как иначе размер файла увеличился бы довольно значительно.
Второй файл, FlashNav2, использует импортированную из Fireworks MX графику, но с сохраненным свойством редактирования. Большая часть эффектов Криса сохранена в виде векторов. Хотя это помогло уменьшить размер файла, все же это ухудшило его качество. Я думаю, что можно найти золотую середину, но все равно, вряд ли размер файла может быть значительно меньше, чем у GIF-файла.
Кроме того, сыграл свою роль урбанистический вид рисунка. Вы помните, что для нас это было очень важно. Не имеет большого значения, если мы сэкономим несколько килобайт. Если при этом мы потеряем нужный вид, то лучше пожертвовать объемом. Вся борьба за снижение объема будет пустой тратой сил, если заказчик останется недовольным рисунком.
У обоих экспортированных файлов есть общая проблема: кирпичи выглядят слишком гладкими. Это одна из причин, по которой Крису пришлось отказаться от использования JPG. Если мы откажемся от сжатия, размер файла значительно увеличится. Если мы применим сжатие без потери информации, то все равно размер останется слишком большим. И даже при таком сжатии качество кирпичей не достаточно высоко. Только GIF-файл дает нам шероховатые кирпичи, но во Flash MX мы этого не добьемся.
Если бы мы сделали весь узел во Flash MX, то он имел бы совсем другой вид. Он слишком напоминал бы мультипликацию. Поэтому, пытаясь добиться реалистичного вида кирпичной стены, нам пришлось делать ее в Fireworks MX.
Этапы
Этапы
Создание панели навигации для JCT
JPG или GIF
Реализация решения использовать GIF-формат
Почему мы не сделали человечка во FreeHand
Достоинства и недостатки элементов навигации, созданных во Flash MX
Отличия меню Fireworks и Flash
Динамические страницы во Flash MX
Новый стиль работы
Резюме
Этапы
Мы рассмотрели много вопросов, связанных с созданием разных элементов страниц, начиная с планирования содержания и заканчивая созданием графических рисунков. В оставшейся части книги мы рассмотрим, как собрать материалы в динамические Web-страницы; таким образом, наша работа подошла к некоторому важному этапу.
На этом этапе работы нам не помешает взглянуть на проделанный путь. Мы можем оценить принятые ранее решения и подумать о том, не могли ли мы сделать это более эффективно. До сих пор мы много внимания и сил уделяли созданию средств навигации. Панель навигации появляется у нас практически на каждой странице Web-узла JСТ. Мы приняли несколько важных решений относительно этой панели, но теперь хотим повторить эти размышления вместе с вами.
Нельзя не вспомнить о том, что само появление и дальнейшее развитие пакета Macromedia Studio MX представляют собой этапный момент в технологии создания Web-узлов — переход от статических Web-страниц к динамическим. Web-узел JCT по своей природе является статическим и фактически представляет собой набор нескольких десятков страниц. На каждую из них можно попасть с помощью некоторого элемента навигации, кнопки или меню, с которым связана заданная наперед ссылка. Динамическая часть нашего узла представляет собой всего три страницы, на которых с помощью элементов навигации мы сообщаем серверу, какое содержание нам нужно, и это содержание попадает из базы данных в заданное место на странице. В этой главе мы также поделимся с вами своими соображениями и об этом.
В предисловии к этой книге мы вспоминали знаменитую фразу "Мы больше не в Канзасе, Тотошка". Эту фразу произносит девочка Элли, когда ее домик, подхваченный ураганом, оказывается заброшенным в неведомую страну. Во многих отношениях бизнес разработчиков Web-узлов претерпел похожий перелом. Мы занимались созданием статических узлов, но изменились запросы потребителей, изменился рынок, и теперь мы создаем динамические Web-узлы в новых, незнакомых нам условиях. Изменилась технология, появились новые средства, возникли новые роли в команде разработчиков, изменилось также отношение к этому процессу как заказчиков, так и разработчиков.
Все это породило множество новых интересных вопросов, которые мы не раз обсуждали на страницах этой книги. Двое из авторов этой книги уже некоторое время занимаются созданием динамических Web-узлов и поэтому не раз пытались вынести на обсуждение вопросы, связанные с распределением ролей, взаимодействием с заказчиком, а также проблемы сложности, повторного использования и управления динамическим содержанием.
JPG или GIF
Все рисунки, которые мы использовали в панели навигации Web-узла JCT, могли бы быть рисунками в формате JPG. Решение сделать их в формате GIF было вызвано борьбой за малый размер файла.
За исключением фона в виде кирпичной стены и градиента в логотипе, все остальные детали выполнены в простых цветах и прекрасно поддаются сжатию в формате GIF. В частности, ботинки и брюки человечка-талисмана — это главные кандидаты на то, чтобы сжать их в формате GIF, потому что они сделаны в одном цвете. В отличие от этого, кирпичи в стене не подойдут для GIF-сжатия, поскольку они имеют неподходящую ориентацию. Дело в том, что GIF-сжатие хорошо выполняется в том случае, когда пиксели одного цвета повторяются в одной строке рисунка (по горизонтали). Кирпичи в стене, с их изменяющимся по горизонтали цветом, представляют трудно разрешимую задачу для сжатия в формате GIF. Подробное обсуждение проблемы сжатия рисунков вы найдете в главе 21, посвященной оптимизации рисунков.
Понятно, что нет смысла применять в одном рисунке разные системы сжатия; это не приведет к успеху в борьбе за размер файла.
Кирпичный фон, логотип и большая часть талисмана будут лучше и четче выглядеть в формате JPG. В общем случае, при работе с рисунками вроде фотографии, такими как кирпичи с их сложно меняющимися цветами, формат JPG дает лучшие результаты, чем сжатие в формате GIF.
Художественные соображения
Как ни странно, но решение использовать формат GIF было подкреплено еще и соображениями художественного плана. Если вы вспомните обсуждение планирования узла, приведенное в главе 1, то там было сказано, что наш Web-узел должен иметь урбанистический вид, быть выполненным в стиле "хип-хоп", напоминать городское граффити и т.п. Сохранение рисунков в формате GIF делает их более резкими и четким, что вполне укладывается в наш художественный замысел и придает им особый стиль.
Крис, наш художник, говорит, что выполненные им рисунки были созданы под впечатлением городского граффити. Он говорит, что в некоторых районах Вашингтона можно встретить рисунки на стенах, которые отличаются от остальных. И хотя основной массе Вашингтонского граффити далеко до Нью-Йоркского, все же можно встретить рисунки, при взгляде на которые становится жалко, что эти парни тратят время и силы на вандализм.
Кроме того, здесь есть еще один интересный эффект. Если установить высокую степень сжатия GIF-рисунка, то некоторые пиксели начинают как бы распадаться на отдельные точки. В результате мы получили то, что художники называют счастливой случайностью, или даже озарением. Неумышленно мы создали в рисунке именно нужный нам эффект. При общем взгляде на рисунок отделенные друг от друга точки создают особое восприятие поверхности, и она начинает выглядеть резкой и четкой. В логотипе эффект GIF-сжатия тоже создает эффект разделения, что с точки зрения художника напоминает рисунок мелом.
Это и есть одна из тех редких ситуаций, когда формальное снижение качества рисунка приводит к тому, что он выглядит лучше с точки зрения художника, особенно по сравнению с плавным стилем, который так хорошо передает фермат JPG-рисунка. В этом случае резкие края и слишком сильно сжатые пиксели — это совсем не плохо.
Новый стиль работы
Вы рано или поздно столкнетесь с ситуацией, с которой столкнулись мы, работая над этой книгой. 'Заказчик изменит свое мнение, и все придется менять вслед за ним. Но теперь данные на Web-узле стали динамическими. Он стал гибче, но и сложнее, после того, как мы перешли от многих статических страниц всего лишь к трем динамическим.
Как вы узнаете из последующих глав, содержание Web-узла выводится в табличную структуру. Пожалуй, единственное, что не претерпело существенных изменений, так это панель навигации в верхней части страницы. Но все равно, теперь эта панель не переводит пользователя со страницы на страницу, а загружает нужные данные в созданные заранее шаблоны. Это очень эффективный метод создания Web-страниц.
Но самое главное для нас, разработчиков, состоит в том, что изменился порядок и способ работы.
Теперь дизайнеру недостаточно разрабатывать узел с помощью набора рисунков, приходится также создавать и базу данных. Мы поговорим об этом подробнее в следующей главе. Но для нас оказалось неожиданностью, насколько легко дизайнер воспринял эту перемену и стал мыслить категориями содержания, попадающего в табличную структуру.
На первый взгляд могло показаться, что теперь Джордан, программист, указывает Крису, дизайнеру, как создавать рисунки. Ниже Крис и Джордан объясняют, что на самом деле их роли не изменились, но возникли новое понимание и новый способ взаимодействия.
Говорит Джордан: "На самом деле роль Криса не изменилась. Он, как и раньше, создает рисунки для узла. Просто эти рисунки не появляются на экране, пока программа их не вызовет. Главное изменение произошло с панелью навигации. Она появляется на каждой странице. Панель навигации осуществляет ссылку на страницу, но я отвечаю за то, чтобы в нужный момент эта страница существовала".
Крис соглашается с этим: "Моя роль, действительно, не изменилась. Я по-прежнему разрабатываю модель узла с новым динамическим содержанием и делаю для этого рисунки. Гораздо больше меня занимает проблема физической удаленности. Хотя это и не очень сложно, но иногда мешает. Если бы мы с Джорданом работали в одном офисе, многие проблемы мы могли бы обсудить за чашкой кофе".
Распределение обязанностей
Сделать статический Web-узел динамическим — не такая простая задача. Если вы занимаетесь планированием узла, то важно своевременно сделать правильный выбор модели — статической или динамической, — что лучше подходит для вашей задачи. Принимайте это решение во время планирования, тогда вам удастся избежать многих проблем. На этом этапе еще можно достичь тонкого баланса между дизайном и программированием, когда дизайнер и программист могут разговаривать друг с другом непосредственно.
С точки зрения программиста и разработчика базы данных правильное распределение ролей требует полного понимания намерений дизайнера. Джордан говорит об этом так: "Крис может не согласиться со мной, но мне кажется, что моя роль в этом процессе сложнее. Я должен так написать программу, чтобы она как бы не существовала для пользователя. Для пользователя все должно выглядеть так, как будто Web-узел представляет собой набор HTML-страниц. Поэтому я должен приспосабливать свои программы к дизайну Криса. Это не так просто, особенно если речь идет о создании Web-приложения. Очень часто нам (разработчикам базы данных и программистам) приходится сначала делать программу, а потом нам дают рисунки, к которым мы должны эту программу приспособить. Это не облегчает нашу задачу".
Крис возражает: "Это в значительной степени зависит от того, на какой стадии процесса мы находимся. Я понимаю, что Джордану было нелегко. Я тоже сталкиваюсь с подобными проблемами, потому что все мои заказчики имеет огромные Web-узлы, связанные с базами данных. Выбрать способ, как соединить все это вместе, я имею в виду красивые картинки и информацию из базы данных, — очень сложная задача. И ее решение зависит от того, с какой стороны ее рассматривать, с точки зрения дизайнера или программиста. И то и другое может быть очень трудным. Поэтому Джордан, наверное, прав в том смысле, что его работа была тяжелее моей, поскольку ему приходилось подстраивать динамические данные под мой дизайн".
Фактор клиента
Мы не делаем динамический Web-узел, если клиент не просит нас об этом. Интересно, что в данном случае создание динамического сайта оказалось таким же новым делом для клиента, как и для разработчика. Процесс оказался слишком сложным из-за нашего клиента. Он хотел, чтобы посетители задерживались на его Web-узле. Он хотел интенсивного обмена данными. Он хотел, чтобы его бизнес процветал, но не хотел изучать новую область. Но, как мы уже много раз говорили на страницах этой книги, это проще сказать, чем сделать. Умение слушать клиента — это одно из самых важных требований при создании Web-узлов.
Часто ситуация осложняется по вине клиента. Они хотят, чтобы на их узле решалась некоторая специфическая задача. Джордан говорит, что если кто-то и нуждается в обучении, то это в первую очередь разработчики Web-узлов. Мы должны лучше вслушиваться в то, что говорит наш клиент. Когда он говорит о том, что ему нужен динамический Web-узел, мы должны понимать, что на самом деле ему нужно, чтобы посетители покупали его товар или пользовались его сервисом. И это наша задача — найти способ сделать так, чтобы между заказчиком и разработчиком установилось максимальное взаимопонимание.
По мнению Криса, привлечение клиента к процессу планирования узла дает многие преимущества.
Фактор сложности
Создание динамического Web-узла — сложный процесс. Нужно создать базу данных и содержание. Программисты должны убедиться, что содержание из базы данных попадает на страницы. Программисты на ColdFusion MX должны обеспечить, чтобы содержание попадало на отведенное ему место и выполняло предписанную задачу. Иногда оказывается, что разумнее и удобнее нанять профессионала, чем делать все самому. Ниже Крис и Джордан обсуждают вопросы сложности создания динамических Web-узлов.
Джордан говорит, что этот процесс больше нельзя трактовать, как шоу одного исполнителя. К сожалению, не все дизайнеры понимают это. Многие верят в то, что все могут сделать сами. И в результате этого сложность задачи возрастает многократно.
Теперь этот процесс не отличается принципиально от любого другого процесса в мире компьютерных технологий. Мы не можем знать всего, и это очень хорошо. Если бы нам пришлось научиться всему сразу, мы бы сошли с ума. Джордан говорит, что ему иногда приходиться любительски заниматься дизайном, но не потому, что в этом есть необходимость, а потому, что это ему нравится. У него есть много дизайнеров, которых он может привлечь к работе. Если ему подворачивается большой проект, то он всегда приглашает кого-то из дизайнеров, а сам занимается программированием, потому что это он любит делать больше всего.
То же самое может сказать любой художник. "Много лет назад я решил заниматься тем, что у меня хорошо получается, и избегать того, в чем я чувствую себя неуверенно, — говорит Крис. — Все это полностью относится к созданию динамических Web-узлов. Я понимаю основные принципы работы базы данных, но если вы попробуете заставить меня собрать все это вместе, то у меня ничего не выйдет".
Так можно ли найти универсальное решение? Крис считает, что не только можно, оно просто лежит на поверхности. Все это не так сложно, как может показаться непрофессионалу. Мы сами делаем веши сложными, если обращаемся с ними неправильно.
Управление содержанием
Более современный подход к разработке Web-узлов, естественно, порождает у команды разработчиков новые проблемы управления содержанием. Во многих отношениях способность менять содержание в зависимости от обстоятельств является одновременно и преимуществом, и недостатком. Джордан занимается этим уже много лет, и он хочет поделиться своими соображениями.
Дизайнеры — народ очень специфичный. Они раздражаются, когда кто-то пытается вмешиваться в их работу. Они начинают нервничать, когда клиент говорит, что хотел бы иметь возможность менять текст страницы в любой момент и с минимальными затратами. Трудно винить их за это. Некоторые дизайнеры пытаются рационализировать свою работу и решить данную ситуацию, вручив заказчику копию программы Dreamweaver MX. Трудно придумать более пагубное заблуждение.
Нет ничего страшнее, чем заказчик, который решил, что может сам заняться дизайном только потому, что раздобыл соответствующую программу. Хуже может быть только заказчик, который решил заняться программированием по той же самой причине.
Давайте рассмотрим Web-приложение Content Management System (CMS), которое предназначено для того, чтобы изменять содержимое Web-узла, не влияя на его дизайн.
Приложение для управления содержанием должно работать в согласии с дизайном, а не разрушать его. Дизайнер работает с CMS аналогично тому, как он работает со статической страницей.
Динамическое содержание не должно в принципе отличаться от статического текста. Клиент должен иметь возможность изменять содержание своих страниц с максимальной легкостью. Если он решил что-то обновить на своем Web-узле, то изменения должны быть видимы немедленно после щелчка на кнопке Update.
Если вы имеете дело с графикой, то сделайте так, чтобы клиенту нужно было копировать рисунки только в одно место на Web-узле. Если вы используете ColdFusion MX, защитите это место с помощью файла Application. cfm так, чтобы каждый, кто пытается изменить этот файл, был немедленно перенаправлен в другое место.
Если удастся, скройте от клиента физическое расположение этого места. Кроме того, не рассчитывайте на то, что ваш клиент знает язык HTML. Дизайнер сам должен позаботиться о форматировании текста, даже если он позволяет клиенту вводить текст самостоятельно. Использование CSS очень удобно в этом смысле, потому что вы можете задать формат обычным образом, и при этом нет существенной разницы между статическим и динамическим содержанием.
Создавайте систему на основе модулей и держите содержание подальше от элементов, определяющих способ вывода. При этом дизайнеру нет нужды иметь дело с программами.
Для модульного программирования очень удобно приложение ColdFusion. Самые разные элементы Web-узла можно сохранить в одном файле Application.cfm. Этот файл загружается каждый раз при обращении к странице ColdFusion MX.
Отличия меню Fireworks и Flash
Возможность создавать выпадающие меню во Flash и в Fireworks — большое преимущество обоих приложений. Но у вас может возникнуть вопрос: зачем использовать Flash, если это можно сделать с помощью Fireworks (и наоборот).
Создание меню во Flash достаточно удобно, если вам нужно простое стандартное меню. Кроме того, они имеют еще некоторые преимущества, которые мы обсудим в главе 23.
Flash-меню очень хороши, если вы предусмотрели на своей странице достаточно места, чтобы эти меню могли развернуться. Если места на странице мало, то меню будут обрезаны.
Flash-меню используются так же, как и обычные меню. Вы, скорее всего, сгруппируете подобные пункты в одном меню, как и ожидает от вас пользователь. Это диктуется здравым смыслом, и так принято делать в любом интерфейсе.
Создание меню с помощью Fireworks MX имеет некоторые преимущества, главным из которых является то, что в этом случае не требуются надстройки. Кроме того, вам не придется резервировать лишнее место на странице, как пришлось бы делать в случае использования Flash.
Пункты меню в Fireworks являются слоями изображения на экране. В отличие от Flash-меню, они располагаются поверх содержимого страницы. Эти меню создаются быстро и легко, намного легче, чем во Flash MX.
Однако тут есть один нюанс, и это касается слоев вообще: если у вас в области содержания есть SWF-файл, или QuickTime, или Real Media, или Windows Media Player, или форма, то меню в этом месте обрезается. Перечисленные выше файлы имеют преимущество на экране, так как их содержимое динамически обновляется. Броузеры постоянно обновляют их содержимое, поэтому все, что вы пытаетесь вывести поверх, затирается.
Выпадающие меню в Fireworks создавать очень легко, но делать это нужно осторожно. Если вам удастся убедить вашего клиента в том, что нет никакой беды, если выпадающее меню закроет на некоторое время часть содержимого страницы, то вы сможете сэкономить много места на экране, организовав интерфейс в виде меню. И в самом деле, в последнее время меню все чаще встречается на современных Web-узлах.
И, наконец, помните об общих правилах создания меню. Мы сами убедились, в том числе и на собственных ошибках, что самое лучшее меню должно быть коротким и понятным. Если под названием категории раскрывается слишком длинный список с элементами выбора, то таким меню пользоваться неудобно.
Почему мы не сделали человечка во Freehand
Крис хочет объяснить, почему мы не воспользовались FreeHand для создания образа человечка-талисмана. Итак, говорит Крис.
Ох, друзья, на эту тему можно было бы написать отдельную книгу.
Прежде всего, талисман был нарисован в традиционном стиле художников, т.е. я не достаточно ловко управляюсь с табло для рисования, поэтому делал все с помощью бумаги, пера, красок и сканера.
Я знаю многих художников-иллюстраторов и мультипликаторов, которые довольно ловко управляются с таким табло, но лично я не считаю его удобным инструментом. Поэтому я пользуюсь технологией, вызывающей сегодня у многих улыбку, — я рисую вручную, потом сканирую все это и помещаю в Photoshop. Там я разделяю рисунок на слои и раскрашиваю его. Я освоил эту технику, еще когда работал в газете и выполнял для нее цветные рисунки-карикатуры. Я так много лет провел за этим занятием, что сегодня не вижу смысла отказываться от привычного стиля, кроме того, он прекрасно себя оправдывает.
В главе 11 мы подробно рассмотрели технику раскрашивания рисунка с помощью Fireworks MX. Это объясняет, почему у меня вошло в привычку работать в таком стиле, и, кроме того, я вполне доволен результатами.
Если бы мы решили делать наш узел на основе Flash, то, наверное, я бы импортировал рисунок во FreeHand и раскрашивал его там. Но я не сделал этого, потому что не люблю простых цветов.
Если бы раскрашивали рисунок для Flash, то я бы избегал сложных переходов цвета и теней. Тогда нам можно было бы воспользоваться для раскрашивания Flash MX.
Есть старый трюк, позволяющий обходить цветовые ограничения, присущие Flash MX. Если вы обратите внимание на старые мультипликации, то заметите, что в них мало персонажей, имеющих цветные тени. В большинстве своем они выполнены в виде ограниченных областей чистого цвета.
Пожалуй, если бы с самого начала мы решили оставаться в рамках Flash, то я бы именно так и сделал: нарисовал человечка как набор фигур из чистого цвета, и результат был бы, пожалуй, не хуже. Но все же мне больше по душе тонкие переходы цвета, которые мы создали в Fireworks MX. А в следующий раз я обязательно попробую поэкспериментировать.
Реализация решения использовать GIF-формат
В книгах, подобных этой, всегда приводится много советов типа "сделай то, сделай это", но не всегда приводится обоснование таких советов.
Как вы видели, было много технических и эстетических причин использовать формат GIF, но главное слово все же оставалось за художником, который сидит за компьютером и рисует то, что считает нужным. В этом разделе наш художник Крис хочет объяснить, как он принял решение использовать именно этот формат.
Как уже говорилось, было достаточно причин, по которым я решил использовать GIF-формат. Мне хотелось бы подробно рассказать, как я пришел к этому решению. Для этого я сделаю сравнение двух версий панели навигации Web-узла JCT, выполненных в разных форматах.
На рис. 1-8.1 вы видите примеры обеих панелей навигации. Верхняя была сделана в формате JPG с коэффициентом качества 75%. Нижняя — это рисунок в формате GIF с использованием 128 цветов.
Рис. 18.1. Две версии панели навигации. Для полноценного сравнения вы можете посмотреть их на Web-узле этой книги
Мой взгляд притягивается к нижнему рисунку. Версия JPG выглядит так, как будто на ней есть легкая вуаль. Красные элементы слов выглядят более резко на рисунке в формате GIF. Аналогично, голубой цвет выглядит более чистым. И вообще, рисунок в формате JPG кажется грязноватым.
Но, кроме всего сказанного, между этими двумя форматами есть еще несколько очень тонких, на первый взгляд незаметных различий. Эти тонкие различия показаны на рис. 18.2. Я специально выделил несколько фрагментов в разных форматах, чтобы показать разницу. Эти фрагменты обозначены буквами А, В, С и D.
Рис. 18.2. В масштабе 100% разница почти незаметна
На первый взгляд разницу заметить очень трудно. Рисунки действительно похожи. Но так это выглядит только при рассматривании их в масштабе 100%. Вот почему я никогда не сравниваю результаты работы в таком масштабе.
Но если вы увеличите масштаб изображения, то разница становится заметной. Я буду сравнивать эти рисунки именно в таком увеличенном масштабе.
Фрагмент А вверху выглядит идеально для JCT, так как переход красного, оранжевого и желтого градиентов выглядит более плавно, чем в соответствующем фрагменте GIF-формата внизу. GIF-версия кажется шероховатой, а переходы цвета в градиенте — грубыми.
Так почему же я не сохранил логотип JCT в JPG-файле?
Версия логотипа JCT в формате JPG выглядела недостаточно в стиле граффити, и это не соответствовало моим целям. Обычно мне не нравится грубый переход цветов в формате GIF, и я сохраняю файлы в формате JPG. Однако в данном случае мы решили придерживаться стиля граффити, а для этих целей нам нужно было создать стиль меловой росписи.
Рис. 18.3. Увеличив масштаб отображения, мы видим разницу в рисунках
То же самое можно сказать о тенях. Тени в формате GIF выглядят резкими, и в них как бы появляется некоторая текстура. В версии JPG тени выглядят мягкими, и это плохо ассоциируется с граффити, которое обычно выполняется баллончиком с краской.
Кирпичный фон во фрагменте В также не соответствует стилю.
Вы когда-нибудь пробовали на ощупь край кирпичной стены? Если пробовали, то знаете, какой он шероховатый и жесткий. В нем определенно присутствует текстура. В версии JPG-рисунка это не ощущается. Но в GIF-версии возникает ощущение текстуры, особенно вдоль диагональных линий.
С другой стороны, версия JPG фактически напоминает своей мягкостью рисунок пастелью. В ней не ощущается жесткой текстуры, которая присуща кирпичной стене. Если погладить ее руками, то кажется, что рукам это будет приятно. Но это не должно быть так. Кирпичная стена должна быть жесткой, такой, чтобы хотелось держать руки от нее подальше.
На принятие решения также повлияли блики во фрагменте С. Я уже говорил, что цвета в GIF-файле выглядят не так, как в файле JPG. Это хорошо видно во фрагменте С. В файле JPG красные части имеют некоторый налет бордового, что делает весь рисунок темным. И хотя мы старались придать всему рисунку стили городского граффити, мы не хотели делать рисунок грязным. Для этой цели лучше всего подходил формат GIF.
А как насчет желтого ореола вокруг букв? Опять таки, шероховатость формата GIF работает здесь на нас. Желтый ореол в версии GIF выглядит слишком мягким, напоминающим пастельные краски. А нам нужен стиль росписи из баллончика с краской, нечто резкое и созданное как бы на лету.
Несмотря на то что в баллончике тоже содержится краска и сжатый воздух, рисунки, выполняемые с его помощью, выглядят не так, как сделанные пульверизатором. При быстром проведении линий рисунок баллончиком имеет повышенную насыщенность в середине линий и резкие концы. В JPG-рисунке желтый ореол выглядит так, как будто он сделан пульверизатором. Он имеет мягкий фон, и кажется, что на его создание было потрачено много времени. Но это совсем не то, что зритель привык видеть в искусстве граффити.
Файлу формата GIF присущи все свойства, которые мы привыкли видеть на рисунках, выполненных с помощью баллончика, — края резкие, штрихи обрывистые. Это особенно заметно во фрагменте В.
Говоря о человечке-талисмане, я, вместо того чтобы делать сравнение разных версий файла, просто перечислю элементы (в порядке убывания важности), которые, на мой взгляд, делают формат GIF особенно предпочтительным.
Яркие тона лучше передаются в GIF-формате. Файл формата JPG получается немного сдвинутым в сторону желтого цвета.
Его ботинки имеют ярко-красный цвет в GIF-файле, как и должно быть, в то время как в JPG-файле они бордового цвета.
Складки на его джинсах более четкие в формате GIF, а в формате JPG они сливаются с голубым.
Его джинсы более яркие в GIF-формате, а в JPG они несколько темные.
Пряжка пояса в формате GIF ярко-желтая, а в JPG — почти белая.
В этой главе мы рассмотрели
В этой главе мы рассмотрели различные важные этапы создания Web-узлов.
Завершив создание материалов для Web-узла JCT, мы переходим от работы с содержанием к собственно созданию узла. На этом этапе вы должны остановиться и пересмотреть пройденный путь, чтобы определить, что вам удалось хорошо, а что не очень.
Мы объяснили вам, почему при создании элементов навигации мы использовали рисунки в формате GIF, а не более естественные рисунки JPG-формата. Мы рассмотрели технические и творческие аспекты такого решения.
В данной главе мы также рассказали о достоинствах и недостатках использования Flash MX для создания динамического Web-узла, в частности возможности совместного использования Flash MX и Fireworks MX для создания выпадающих меню.
Переход к созданию динамических Web-узлов все еще остается непростым делом, и так будет продолжаться до тех пор, пока разработчики и заказчики не выработают новый совместный подход к этому процессу. Крис и Джордан поделились своим многолетним опытом при обсуждении этих непростых проблем.
Что же будет дальше? Вы узнаете, как создавать страницы с динамическим содержанием с помощью Dreamweaver MX.
Создание панели навигации для JCT
Соберите в одной комнате трех разработчиков Web-узлов, и вы получите три разных мнения о вашей работе. Обычно каждое высказывание начинается словами: "А я бы это сделал не так..." и развивается у всех по-разному.
Это же можно сказать и о панели навигации JCT, которую можно было бы сделать как в виде GIF-, так и в виде PNG-рисунка.
Когда создается художественный рисунок или фотография, художнику неизбежно приходится думать о том, на каком устройстве это будет воспроизводиться. Для художника, работающего с печатными изданиями, выбор не так уж велик, поскольку существуют всего два формата, предоставляющие высокое качество для печатной продукции, — TIF и EPS. Если рисунок предназначается для использования в Web-пространстве, у вас тоже есть всего два варианта — GIF или JPG, — но в этом случае результаты предсказать немного сложнее.
Когда Web-художник готовит рисунок, на его решение влияют
качество изображения на экране;
размер файла.
Как правило, с этим противоречием приходится сталкиваться всем дизайнерам. Представьте себе рычажные весы. На одном плече — качество, на другом — объем файла.
На концах рычагов находятся сверхвысокое качество и неприемлемо большой файл. Сдвиньте немного объем файла к центру весов, и на столько же сдвинется качество в сторону ухудшения. Аналогично, при изменении качества изменяется объем файла. Самое трудное в работе дизайнера — найти этот баланс между объемом и качеством. И, кстати, это проявляется не только в рисунках.
Нам не раз приходилось встречать заказчиков, которые считают, что знают про Web довольно много. Но, как правило, эта их вера основана только на том, что они умеют рассматривать Web-страницы. Они смотрят на чей-то Web-узел и говорят разработчику: "Ну почему бы вам не сделать вот так же для нас?" или "Вот это то, что нам нужно!" Но они не понимают, что за привлекшей их простотой стоит много труда, иногда даже больше, чем за сайтом с интенсивным использованием Flash-анимации или видео QuickTime. Качество Web-узла не возрастает с увеличением интенсивности медиа-приколов. При этом увеличиваются только количество затраченного времени и объем информации.
