"Гляделка" (или "Scrutinizer" в оригинале) — это AIR-приложение от самих StomperNet — "самих", потому как авторитет этих людей в среде интернет-маркетинга огромен. На них молятся манимейкеры всей планеты; а русский перевод и транскрипция их очередного популярного видео "Назад в будущее — Перспективы Web 2.0" вышел очень быстро.
Что же это за приложение такое, Scrutinizer? Это помощник тем, кто хочет вдумчиво сконструировать свой сайт, чтобы пользователям в удовольствие и авторам польза.
В основу работы Scrutinizer заложен один из принципов работы глаза — а именно разделение поля зрения на центральное и периферийное. Технически, это приложение имеет всего две ключевые функции: 1. Загружает в свой браузер указанную веб-страницу. 2. Визуализирует эту страницу в режиме симуляции глаза — применяя эффект Blur к некоей области вокруг курсора мыши (радиус настраивается вращением колеса).
Эти две базовые функции открывают широкий спектр применений Гляделки: от изучения поведения пользователя на сайте (для тестировщиков интерфейсов) до исследования контраста страниц (для веб-дизайнеров). Читайте "10 способов использования Гляделки". А установить это чудо мысли можно отсюда.
Что в этом важно для меня и для флэш-индустрии вообще? Scrutinizer иллюстрирует простую идею: новое и клевое быстро возникает там, где появилась возможность легко модифицировать старое. В данном случае старым был браузер без блюра.
Домашнее задание: найдите в браузере недостающую функцию, реализуйте ее в AIR-приложении с помощью его встроенного HTML-компонента, станьте мегапопулярными и заодно немного заработайте.
Update 1: Похоже, ребята стащили мышку Mus2 у студии Лебедева и вставили ее в картинку. Update 2: Ссылку на Гляделку прислал мне judgefrog.
Flash SEO, или поисковая оптимизация флэш-приложений — старая проблема для многих разработчиков и веб-мастеров. Чтобы решить ее, был разработан деже метод дублирования флэш-контента в текстовом (XML / XHTML) виде.
Сейчас ситуация меняется в лучшую сторону. Один из ведущих разработчиков Google Мэтт Каттс (Matt Cutts) в интервью заявил, что Google перешел к использованию официального Macromedia Flash Search Engine SDK. Этот фреймворк позволяет разжимать swf-файлы, разбирать их содержимое и индексировать его на сервере.
Google начал использовать этот официальный поисковый SDK по флэш-контенту. Таким образом, разработчики могут сами с помощью этого же поискового SDK тестировать свой флэш-контент на "искабельность" и видеть его так, как увидит его Google.
Хорошая новость, но до окончательного решения проблемы пока далеко. Во-первых, Macromedia Flash Search Engine SDK на данный момент не умеет искать тексты во флэш-контенте, созданном для Flash Player 9. Во-вторых, задача поиска контента флэш-приложений, как и проблема поиска контента AJAX-приложений, намного шире, чем задача индексации одного исходного файла. Нужно индексировать также подгружаемые файлы и данные, которые чаще всего и являются основным содержимым флэш- и флекс-приложений.
Это весьма серьезные проблем, но сейчас важно то, что стратегический поворот в нужную сторону состоялся: Google использует интегрированный инструмент поиска по флэш-контенту; нет сомнений, что вслед за Google и другие поисковики перейдут к его использованию; таким образом, решение насущных проблем поиска по флэш-контенту теперь находится в руках компании-поставщика самой флэш-технологии, Adobe. Следовательно, задача индексации флэш-содержимого теперь будет решаться централизовано.
Ваш ход, Adobe.
Текстовое содержимое и важные для пользователей значимые данные флекс-приложения по умолчанию спрятаны от поисковых роботов в глубинах бинарного кода swf-файла, поэтому они не появляются в результатах поиска даже по самому релевантному к ним запросу. Это нехорошо. Пользователи должны находить ваше приложение по его контенту — потому что ваш продукт действительно содержит эти данные, но робот Google не отображает их на странице результатов. Если вы хотите, чтобы ваше приложение находилось через Гугл, то сами должны позаботиться об эффективном способе предоставления Гуглу нужной информации.
Как включить ваш флэш-продукт в число достойных обитателей СЕРП'а — страницы с результатами поиска?
Джош Тиньяла из Yahoo! Flash Platform в своей статье “Как сделать ваше горячее RIA дружественным к поисковым движкам” разбирает такой способ поисковой оптимизации флеш-приложений. Он основан на использовании XML-данных в качестве контента страницы и XSL-трансформации. Джош анализирует пример успешной реализации этого подхода Тедом Патриком во флекс-приложении Flex Directory — списке компаний, предоставляющих услуги по Flex-разработке. Это работает. Гугл находит приложение Теда и выдает хорошо оформленный результат поиска по запросу "Flex directory". Приложение Теда идет вторым номером сразу после какой-то дорвей-заглушки.
Идея проста: предоставьте чистые текстовые данные (XML) поисковому роботу, а браузеру пользователя отдайте их же, предварительно трансформировав с помощью XSL. Так пауки Гугла получат свои тексты, а браузеры — свои пользовательские интерфейсы, построенные точно на этих же текстах. Все честно, гибко и search-engine friendly!
XSL-трансформация применяется к исходным XML-данным флекс-приложения как таблица стилей таким образом:
<?xml-stylesheet type="text/xsl" href="http://directory.onflex.org/template002.xsl"?>
Способность браузера манипулировать XML-данными через XSL — ключ к решению проблемы. Заглянув в XSL-файл, вы обнаружите, что в нем хитрый Тед заменяед XML-контент очень простой HTML-страницей, которая внедряет SWF-файл Flex-приложения при помощи знакомого нам SWFObject. Он передает флекс-приложению URL страницы при помощи FlashVars, и приложение загружает свой XML без XSL-трансформаций, точно так же, как и робот-поисковик:
var so = new SWFObject( "http://directory.onflex.org/template002.swf" , "fxtxsl" , "100%" , "100%" , "9" , "#191919"); so.addParam( "scale" , "noscale" ); so.addVariable("xmlurl", document.location ); so.useExpressInstall( "http://directory.onflex.org/expressinstall.swf" ); so.write( 'flexcontent' )
Как увидеть исходный XML-код нам, скромным обладателям браузеров? Так же, как и исходный код любой HTML-страницы — через соответствуюющий пункт меню браузера. Правый клик не даст эффекта — вы будете кликать по флекс-приложению....
Этот же подход вполне применим и для приложений Silverlight / AJAX. Которые как всегда "забудут" поблагодарить флэш-платформу за протоптанную дорожку.
И поскольку эта уже давно витающая в воздухе идея до сих пор не приобрела широкой популярности, первые применившие ее Flash / Flex разработчики получают кокурентное преимущество перед остальными, что начнут применять ее позже.
Есть смысл подумать над (полу) автоматизацией этого процесса за счет создания соответствующих шаблонов для Flex Builder'а.
В комментариях к записи хитрого Теда небезызвестный Даг Маккун сказал, что поскольку XML и XHTML — близнецы-братья, а исходный XML-контент приложения и так уже ближе скорее ко второму из них, то для пущей поисковой оптимизации есть смысл описывать контент при помощи стандартных тэгов — заголовков нескольких уровней, абзацев, выделений и т.д. Ведь Гугл так любит хорошо структурированные документы, а флэш-аппликации при разборе XML все равно, как называется тэг, лишь бы структура была соблюдена. На это Тэд ответил: отличная идея.
Запускай робота!
Google PageRank™ любого сайта, доступному по двум доменам -- основному и www (как flash-ripper.com и www.flash-ripper.com) -- делится на две части: одна достается основному домену, а другая -- дополнительному www. Это происходит потому, что в интернете есть ссылки как на основной домен сайта, так и на дополнительный. В результате сайт недополучает совершенно законную часть принадлежащего ему PR. Это касается практически любого современного сайта.
Исправить эту ситуацию совершенно легальным и более того - рекомендуемым самим Google способом можно, воспользовавшись так называемой "постоянной переадресацией", или переадресацией 301.
Для этого нужно, чтобы ваш Apache поддерживал Mod-Rewrite (на моем domen.com.ua" включен) и чтобы в файле .htaccess, лежащем в корне вашего сервера, были такие строки:
Options +FollowSymlinks RewriteEngine on rewritecond %{http_host} ^www.mysite.com [nc] rewriterule ^(.*)$ http://mysite.com/$1 [r=301,nc]
В результате ваш сервер будет по запросу www.mysite.com отдавать всегда просто mysite.com и последний заберет всебе всех посетителитей, все ссылки и весь Google PageRank™.
Можно поступить наоборот - перенаправлять с домена mysite.com на www.mysite.com:
Options +FollowSymlinks RewriteEngine on rewritecond %{http_host} ^mysite.com [nc] rewriterule ^(.*)$ http://www.mysite.com/$1 [r=301,nc]
Как реализовать Redirect 301 для IIS, PHP, Coldfusion, ASP, ASP .NET, JSP (Java), CGI Perl и Ruby on Rails: How to Redirect a Web Page (301 Redirect)"
Редирект 301 как бы говорит: "moved permanently", такой здесь больше не живет, но я знаю его новый постоянный адрес, вот он.
Проверить сайт на редирект 301 можно здесь.
Есть еще один вариант - указать Гуглу основной (канонический) домен свего сайта.
Отличная приблуда, сделанная на флэше -- позволяет сравнивать Гугловский PR сайтов при различных комбинациях связывания этих сайтов друг с другом:
Есть и демка (прямо в приложении: Google Pagerank Decoder) и страница с базовой справкой: Google PageRank Decoder Support.
Разработка Ripple Framework от Питера Холла предназначена для того, чтобы сдружить Флэш-контент с поисковыми машинами интернета. Ripple состоит из ActionScript-классов, включаемых во флэш приложение и Javascript-кода, включаемого в каждую XHTML-страницу.
Идея Ripple заключается в том, чтобы представить флэш-контент в привычном для поисковиков XHTML-виде. Иными словами -- организовать эффективное внешнее XHTML-представление всех данных, содержащихся во флэш-сайте (приложении, игре, баннере) и обеспечить связь между внешним представлением и реальными данными. Как по кругам на воде можно узнать, куда был брошен камень, так и по XHTML можно найти породивший его Flash.
После применения Ripple каждая XHTML-страница содержит небольшой Javascript-код, который перенаправляет пользователя к главной странице, содержащей флэш-приложение. В запрос перенаправления включается также URL перенаправялемой страницы, и флэш загружает данные в соответствии с полученным запросом. Таким образом, можно ссылаться на любую флэш-страницу, ссылаясь на ее XHTML-отображение. При этом google проигнорирует Javascript и получит чистый XHTML, а у реального пользователя Javascript сработает и в браузере отобразится нужное место флэш-сайта.
В задачи Ripple не входит рендеринг или специальная обработка XHTML-кода. Только данные. Но, поскольку XHTML-структура не является идеальным отображением структуры флэш-данных, то в приложение включен также XML-файл-дескриптор, содержащий выражения XPath, объясняющие ActionSctipt-классам, входящим в Ripple, как получать данные их XHTML. Дескриптор связан с каждой XHTML-страницей тэгом link. В вашем ActionScript-коде вам не нужно работать с дескиптором и используемом в нем XPath -- вся дескрипция происходит автоматически. В своем коде вам только нужно сслаться на данные по их идентификатору.
link
Главный ActionScript-класс Ripple называется DocManager. Он и управляет загрузкой данных в приложение. Чтобы эффективно использовать Ripple, нужно структурировать данные в соответствии с требованиями класса DocManager -- таким образом, они все смогут быть загружены с его помощью.
Интересно? Читайте дальше здесь: описание Ripple Framework.
Также: примеры использования Ripple, исходный код Ripple.
Совсем древнее: 17-20.09.2002, 23-30.09.2002, 01-04.10.2002, 07-11.10.2002, 14-19.10.2002, 20-26.10.2002, 27.10-02.11.2002, 04-08.11.2002, 11-16.11.2002, 18-23.11.2002 25-30.11.2002, 02-07.12.2002, 09-14.12.2002 Сайт заработал 17.09.2002