Twórcy flash’a o czymś nie pomyśleli.

Niestety tak się stało, że twórcy z Macromedii nie zadbali o kompatybilność i dostępność swojej technologii dla crawlerów, trudność wynika z tego iż dynamiczna i mocno interaktywna strona jest dużo trudniejsza w interpretacji od statycznego html’a (bądź nawet semi statycznego, generowanego dynamicznie). Sprawa od samego początku nie została rozwiązana i jak widać jeszcze przez spory okres czasu nie będzie flasza przyjaznego dla google. I jak sądze z tego powodu Flash dostaje karniaki na każdym kroku, dalej zobaczmy co możemy z tym fantem zrobić.

Za co jesteśmy (nie)wdzięczni deweloperowi przeglądarki IE?

W roku 2006 wyszła nowa wersja przeglądarki Microsoft’u (IE) zawierająca aktualizację zwaną “Eolas”, która zapobiegała uruchamianiu aplikacji Flash na bazie Active-x podczas ładowania strony i wymagała aktywacji poprzez kliknięcie na obiekt interaktywny. Eolas był znienawidzony przez twórców stron wykorzystujących omawianą technologię, gdyż ich strony były martwe w przeglądarkach IE, a do tego wyświetlały okropne komentarze “Kliknij, aby aktywować kontrolkę”.

Wymagania jakie musimy spełnić aby bezpiecznie korzystać z Flash.

Aktualnie można nasze wymagania uznać za marzenia ściętej głowy, ale skoro jesteśmy profesjonalistami i nasze wizje chcemy realizować z zachowaniem standardów to wymieńmy jakie punkty chcemy spełnić:

• czysty kod
• przyjazność wyszukiwarkom
• dostępność (usability), różne przeglądarki, urządzenia przenośne
• semantyka, zachowanie standardów
• poprawne wyświetlanie pod przeglądarkami IE

Programowanie Flash przyjazne wyszukiwarkom (SEO friendly).

Dobrym pomysłem na obejście problematyki niedostępności flash’a na naszej stronie jest użycie funkcji JavaScript’u zwanej SWFObject();, która to sprawdza czy przeglądarka wyświetlająca jest w stanie obsłużyć treść interaktywną. Jeśli napotykamy na problemy to stosujemy div z alternatywną treścią o tej samej (lub możliwie zbliżonej) funkcjonalności zakodowanej za pomocą statycznego kodu (x)html. W obszarze wspomnianego alternatywnego div’a możemy swobodnie zawrzeć linki, tekst oraz obrazy jakie pierwotnie miały być udostępnione z użyciem animacji. Jeśli natomiast obsługa flash jest dostępna nasza funkcja modyfikuje strukturę dokumentu (DOM) tak aby wyświetlała zawartość prezentacji i wydaje się, że wybrneliśmy z opresji.

Mogło by się wydawać, że ta technika nie jest do końca właściwa, jednak stworzony przez W3C (World Wide Web Consortuim) WAI (Web Accessibility Initiative) dopuszcza a nawet wskazuje słuszność takiego rozwiązania. Wdrażając treść alternatywną dla objektów flash pozwalamy crawler’om oraz użytkownikom, dla których treść interaktywna jest niedostępna korzystać z całej funkcjonalności stony. Wiecej szczegółów w dokumentacji: elementy multimedialne powinny posiadać dostępne wersje alternatywne. Zalecana jest również ostrożność stosowania tej metody ze względu na możliwość traktowania zdwojonej treści jako sposób cloaking’u, aby temu zapobiec należy starać się o wierne odpowiadanie obu treści (mają przedstawiać to samo).

Praktyka – użycie funkcji SWFObject();

Nasza metoda jest rozwijana przez Geoff Sterns’a w postaci skryptu SWFObject.js, który służy SEO-zoptymalizowanemu osadzaniu elementów flash w kodzie strony. Jeśli już umieściłeś na serwerze kod skryptu oraz zainkludowałeś do zawartości dokumentu możemy przejść do praktyki. Poniżej najprostszy wariant kodu:

<script type=”text/javascript” src=”swfobject.js” mce_src=”swfobject.js”>

</script>
<div id=”flashcontent”>

Tutejsze instrukcje zostaną zastąpione elementem flash.

</div>

<script type=”text/javascript”>
var so=new SWFObject(“movie.swf”, “mymovie”, “400″, “200″, “8″, “#336699″);
so.write(“flashcontent”);
</script>

–

W pojemniku <div id=”flashcontent”>[...]</div> zawarty będzie nasz obiekt interaktywny, który będzie automatycznie zastępowany przez treść alternatywną w przypadku wykrycia problemów z obsługą flash’a.

Argumenty jakie przekazujemy do naszego objektu za pomocą funkcji SWFObject:

• swf – ścieżka do pliku swf oraz jego nazwa
• id – ID objektu lub znacznik embed
• width – szerokość osadzanego elementu
• hight – wysokość elementu
• version – wymagana wersja Adobe Flash Player’a
• background-color – wartość heksadecymalna koloru tła.

Opcjonalnie może zawierać również:

• quality – jakość z jaką zalecasz odtwarzanie elementu, domyślnie jest wysoka (hight)
• xiRedirectUrl – przekierowanie dla użytkowników, którzy korzystają z szybkiej aktualizacji
• redirectUrl – przekierowanie dla tych, którzy z pewnych powodów nie chcą aktualizować wersji flash playera
• detectKey – klucz z jakim będzie wykrywana wersja naszego skryptu.

Uwagi.

Jeśli stosujesz opisane rozwiązanie optymalna kolejność postępowania powinna obejmować jako pierwsze udostępnienie treści alternatywnej a następnie zastosowanie docelowego objektu interaktywnego. Jednak życie uczy nas, że właściwe drogi realizacji są bardzo nieprawdopodobne i chcesz zastosować ten wybieg jako ratunek dla już istniejącego elementu (flash). Jest na to rada, ale do tego jeszcze wrócę.

Odnośnie oczekiwań jakie możemy mieć względem stosowania tego typu wybiegu należy pamiętać, że nie uzyskamy pewności poprawnego pozycjonowania naszej strony, jedyna pewność to ta, że usuwamy niedogodności i czynimy naszą treść dostępniejszą. Solidna optymalizacja i odrobina cierpliwości może przynieść oczekiwane rezultaty lecz nie musi.

Strony w pełni zbudowane w oparciu o flash’a.

W przypadku stron zbudowanych w pełni na technologii flash sytuacja jest nieco gorsza, aby nie powiedzieć, że beznadziejna. Możemy jednak zapewnić możliwie dobre funkcjonowanie strony pod kątem zasad SEO stosując pewne metody.

Jeśli stworzymy dla każdej z podstron zamienniki w czystym (x)html’u i pozwolimy na pertraktowanie wyświetlania treści jak w poprzednio opisanej metodzie, jesteśmy o krok dalej. Dodatkowo możemy porcjować elementy flash i umieszczać osobno na każdej podstronie tak aby zapewnić dostęp crawler’om i użytkownikom nie mogącym wyświetlać animacji.

Jest również możliwość stosowania skryptów PHP aby zamiennie serwować pierwotną treść w czystym kodzie (x)html oraz animacji alternatywnie od sytuacji. Jeśli wszystko oprzeć o wykorzystanie bazy danych (np. MySQL) do przechowywania elementów interaktywnych możemy liczyć na dosyć dobrą optymalizację wyświetlania treści w odniesieniu do szybkości funkcjonowania.

Zakończenie.

Temat optymalizacji daje pole do szerokiej dyskusji i szukania wielu rozwiązań, dlatego ten post nie wyczerpuje w pełni tematu. Jeśli uznam, że będzie to wskazane w następnej części opiszę kolejne metody dla twórców stron opartych na treści interaktywnej flash.

~Michał Kowalski 2008