Создание Flash сайтов дизайн студии ABCname  г. Николаев

     Дискуссия о месте технологии Flash в волшебном мире Интернет велись с момента появления технологии, и были даже не дискуссиями а скорее постоянным нытьем о том, что flash противоречит usability (в понимании традиционного user experience пользователя броузера как интерфейса взаимодействия с веб-контентом), с одной стороны - и растущим количеством Flash сайтов с другой. Flash мог все больше и больше, и требования его противников сменялись с "верните нам кнопку Back" на "Проиндекструйте флеш-сайт", потом на "Сделайте флеш-сайт динамическим", потом на "Где поиск?" - и так далее, или же все одновременно. Все эти пожелания, как и многое другое, составили на данный момент некую догматику требований к современному флеш-сайту - не зафиксированную в документациях и стандартах, но в то же время довольно четкую и универсальную. Возможно, изначальная цель этих требований - максимально приблизить флеш-сайт, как интерфейс и как приложение, к html сайту - и потеряла актуальность, но сам подход, делающий флеш-сайт понятным, удобным, легким в использовании как посетителем, так и владельцем, надежным и интегрированым в html и серверное окружение - стал для создателей флеш-сайтов тем, от чего принято отталкиваться.

     Первое - структура сайта. Глобально сайт (как флеш, так и любой другой) представляет собой некий набор единиц иформации (страницы), связанных между собой ссылками (навигация). Это - тот постулат, от которого мы будем отталкиваться. Поскольку 99 процентов интерактивности на нашем "идеальном сайте" составляет переход от одной единицы информации к другой - очевидно, что от того, как организованы связи между этими страницами зависит очень многое - а именно, возможность или невозможность реализовать тот или иной функционал. Попытки построить логику работы сайта, отталкиваясь от размышлений вида "вот мы зашли на первую страницу/открыли первый уровень главного меню/оказались на странице 'о нас' --- и теперь мы должны отсюда смочь выйти на страницу продукции - поэтому мы тут поставим ссылку" - обычно приводят к созданию html - сайтов с путаной навигацией, что плохо, но не смертельно - потому что в html сайте всегда можно поставить эту злополучную ссылку, потом еще 10 ссылок в разных местах - и будет работать.

     Создание сайта на flash - подход приводит к гораздо более печальным последствиям - мы оказались на странице "о нас", а ссылку на страницу, где помещена история разработки нашего логотипа (разел "работы"/ подраздел "работы для себя - любимых"/ выбор-из-выпадающего-списка "логотипы") - мы поставить не можем, потому, что перед разделом "работы" у нас проигрывается анимация поднимающегося занавеса, после этого выползает боковое меню с клиентами (да - еще надо не забыть убить автивность кнопок главного меню и запустить звук фанфар), опять же этот выпадающий список надо открыть на нужном пункте - в общем, хаос приходит в гости и прочно обустраивается в скрипте (в котором появляется десяток новых условий), дизайне (который мы быстро лишаем поднимающегося занавеса) и голове, которая готовится к коллапсу мозга. Как всего этого избежать и что надо сделать чтобы мы были готовы к любым, самым неожиданным поворотам в структуре контента?

     Ответ - присваивание каждой единице информации своего пути, создание центральной системы навигации, и завязка всего интерактива на неё. Мы не будем заниматься флеш-извращениями вроде создания динамической навигации бесконечной вложенности и применения нашего подхода к ней - не потому, что это гипер-сложно, а потому, что это не имеет отношения к 99 процентам конкретных задач, которые встают перед разработчиком сайта.

     Обратимся к реальности - некая фирма заказывает сайт, с неким количеством уровней структуры информации - пусть этих уровней будет три, чтобы нам было проще - главные страницы [банальные "о нас", "услуги", "продукция", "контакты"], вложенные страницы первого уровня ["бетонные плиты", "кованое железо", "бочки"] и второго уровня ["бочки круглые", "квадратные" "тругольные"]. Раскидав все имеющиеся страницы примерно равномерно по обозримому пространству нашего воображения, мы видим, что не все так просто, как кажется - навигация не получается такой же прямолинейной, как на схеме - (от более крупного к менее крупному и обратно): из "круглых бочек" нам понадобится ссылка на список клиентов, отуда, в свою очередь - на продукцию для конкретного заказчика - и так далее. И это только то, что заказчик написал в ТЗ - вполне вероятно, что за неделю до сдачи проекта, он захочет на КАЖДЫЙ продукт повесить ссылки на ВСЕ продукты для клиента, которые заказал этот продукт. Поэтому правильным подходом будет изначальное обеспечение возможности из любой страницы перейти на любую другую.


     Кроме тех выгод, которые мы получаем при разработке самого флеша, данный подход идеально ложится на окружение, в котором находится сайт - а именно, серверные скрипты, создающие xml-ы для него и на back-end системы, которые наполняют контент. Положим, и на то, и на другое нам - флеш-разработчикам - более или менее наплевать: мы получили xml, а как он сгенерился, через что он прошел - это уже не наши проблемы, наше дело его прочесть и интерпретировать. Тем не менее, существующая система вложенности папок с контентом на сервере - те же самые готовые пути, нам не надо ничего придумывать чтобы как-то обозначить ту или иную информацию.