Создание flash сайтов

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

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

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

---

---

---

Другие статьи по теме:

- Flash причиняет 99% неудобств
- Флэш и функциональность веб сайтов
- Что такое flash?
- Flash неприемлем на 99%
- Flash и его недостатки