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


Поэтому я бы хотел уделить внимание некоторым деталям этого подхода, которые будет полезно узнать человеку, который создает флеш-сайты. Поскольку я буду попутно приводить объяснения - как именно реализовать то или другое из описанного - видимо, этот текст будет интересен флеш-разработчикам в большей степени, чем кому либо другому.


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


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


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


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


Так как у нас 3 уровня вложенности - прикидываем дефолтное расположение страниц - и присваиваем каждой переменную вида "1/2/3" - где 1 - это индекс одной из главных страниц, 2 - индекс вложенной страницы первого уровня, с которой мы попали на текущую - которая и есть номер 3. Проще всего присваивать эти переменные прямо при построении главной навигации. Это просто, но это только 10 процентов от того, чо нам предстоит сделать. Если мы хотим без проблем перейти со страницы "2/5/12" на страницу "4/1/2", нам надо создать такой механизм навигации, который будет считывать текущий путь, в обратной очередности проиводть сопутствующие навигации действия - открывание вложенных меню, анимацию появления страниц и так далее - а затем делать все тоже самое с "нуля" - пока мы не окажемся на странице, которую мы хотим открыть. Каждое действие пользователя должно проходить такой путь - даже если он переходит с одной товара на другой внутри одной страницы одного раздела - в этом случае система должна принимать, но игнорировать те участки искомого пути, которые идентичны текущему - т.е уже открыты. Как именно построить такой механизм я рассказывать не буду - это долго, беспредметно, сугубо профессионально и неуниверсально. Универсальность заканчивается на принципах: отрывать действия от событий, чтобы их можно было вызвать в любой момент, строить и оптимизировать конвееры исполняемых операций, которым можно будет посылать список требующих поочередного выполнения действий, следить, чтобы все это не тормозило - а именно, не запускать одновременно ВСЁ, что можно - на то у нас и существуют пути, чтобы спокойно по очереди все открыть-закрыть. Дальше идет область применения вашей фантазии.


Построив навигацию по такому принципу, мы получаем несколько очень важных преимуществ:


- во-первых, мы можем в любой момент в любом месте сайта повесить ссылку на любое другое место - нам достаточно будет просто послать в функцию, осуществляющую контроль над открытием и закрытием уровней искомый путь "a/b/c"


-во-вторых, мы можем легко привязать сайту дополнительный функционал - допустим, поиск: послав запрос на сервер по keywords нам достаточно будет разбить полученный xml, состоящий из путей вида "1/2/3" (который также легко генерится ), быстренько выстроить в ряд кнопки и присвоить каждой - нужный путь.


Поиск - еще одна важная деталь, присутствие которой на флеш-сайте во многом смягчает критику посетителей по поводу его usability и позвляет посетителем расслабиться и получать удовольствие от летающих звезд, видео-плейбеков, потрясающих пружинящих контакт-форм и прочих прелестей, которые нам предоставляет flash.


-в-третьих, мы можем - также без особых усилий - привязать наш сайт к навигации броузера - кнопкам back и forward например. Описание механизма работы perma links можно найти на сайте flashguru.co.uk - так показан пример из страницы с двумя фреймами - в кратце принцип таков: основной swf лежит в одном фрейме, вспомогательный - в другом. При навигации первый посылает некую переменную, соответствующую искомой странице на php-скрипт, который перегружает фрейм с вспомогательным swf - присваивая ему параметром эту переменную - после чего вспомогательный swf по local connection передает эту переменную обратно в главный - и тот осуществляет переход на следующую страницу. Таким образом мы получаем document.history со всеми посещенными страницами сайта - и можем соответственно пользоваться навигацией back и forward для перемещения по нему. Надо ли говорить, что если мы строим сайт по схеме, предложеной выше - то нам понадобится лишь пропустить нашу систему навигации еще одним звеном через local connection - чтобы все наши "a/b/c" записыавлись в историю броузера. И не надо мне рассказывать, что это ненажедно, медленно, муторно итд - я делал это много раз и знаю, о чем говорю. Тем более, что интеграция с навигацией броузера - одно из тех негласных требований к современному флеш-сайту, о которых я говорил в самом начале.


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


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


Продолжение следует


Автор : Дмитрий Щипачёв (Король)