so, zu dem Thema gibt ja ne Menge im Netz, nur sind viele der Informationen leider alt, oder es wird nur über Flash und seine schlecht Suchbarkeit geschimpft, gewettert und vorgeschlagen doch einfach HTML zu nutzen statt Flash…. was einem als Flash-Entwickler auch nicht weiterhilft. Daher nun eine kurze Übersicht, was Stand der Dinge ist und was sich gearade getan hat.

Adobe arbeitet nun zusammen mit den Suchmaschinen Google und Yahoo:

Adobe hat extra für die beiden Großen unter den Suchmaschinen einen speziellen Flash-Player entwickelt, der diesen hilft die bisher für die Suchmaschinen undurchsichtigen Flash-Seiten zu durchlaufen ähnlich wie es ein normaler Anwender auch tun würde.

Hier mehr zu der neuen Entwicklung (direkt von Adobe und Google):

• http://www.adobe.com/devnet/flashplayer/articles/swf_searchability.html
• http://googleblog.blogspot.com/2008/06/google-learns-to-crawl-flash.html

Google hat den neuen Flash-Player bereits in Verwendung und durchsucht bereits erfolgreich Flash-Webseiten.

So, nun ist für uns natürlich folgendes interessant:

Was müssen wir tun, damit unsere Website für Google durchsuchbar ist?

So: Adobe sagt dazu: “Nichts!” Google kann nun sogar dynamisch nachgeladene Inhalte crawlen. Aber, selbstverständlich kann Google nur lesen, was Text ist. Also keine Bilder, keine gerasterten Texte und auch keine Videos interpretieren. Aber Google kann auch Links in Flash-Applikationen folgen und dort weiterlesen, also die Flash-Website durchstöbern. Das tolle ist, dass aber auch dynamisch geladene Inhalte wie z.B. XML eingelesen werden kann (da ist bisher Google ausgestiegen).

Ein weitere Problem bei kompletten Flash-Websites ist das Deep Linking. Hierfür ist es sinnvoll die Location-Zeile oben im Browser anzupassen, also es ermöglichen mittels Parameterübergabe den Flashfilm in einem bestimmten Zustand zu laden (hierzu gibt es eine Flex Komponente - für die Programmierung vielleicht auch meinen Beitrag zum State-Pattern ansehen, der sollte hierzu auch sehr nützlich sein..). Damit kann die Seite in bestimmten Zuständen aufgerufen werden. Das ist zum einen gut für den Anwender (er kann direkte Links zu “Unterseiten” verschicken), zum anderen gut für die Suchmaschine. Es kann mittels einer Sitemap sicher gegangen werden, dass alle Bereiche der Website für den Such-Bot sichtbar werden. Für Google handelt es sich somit um einen zusammengehörenden Satz an Websites (auch wenn diese nur aus einem einzigen Flash-Film besteht).

Hier noch ein paar Tipps für Sitemaps: http://www.sitemaps.org/faq.php

Fazit:

Google und bald auch Yahoo können nun Texte in Flash-Seiten indizieren. Das ist ein super Fortschritt und ermöglichet es Flash-Entwicklern endlich wieder ruhigem Gewissens Flash-Seiten zu verkaufen… Dennoch sollte man stets überlegen, welchen Mehrwert ich duch die Umsetzung in Flash bekomme. Nicht jede Seite MUSS mit Flash umgesetzt werden. Oft reicht eine kleine, feine XHTML, CSS Website. Manchmal ist es auch Sinnvoll auf eine Mischform zu setzten (Website, Navigation etc. aus purem XHTML, Gimmics, Videos, Animationen mit Flash ergänzen…..

So, das Ganze soll nun nicht der erhobene Zeigefinger am Ende sein, sonder nur mein kleines feines Fazit - eine Zusammenfassung, was ich aus der Geschichte und den Recherchen für mich rausgezogen habe.

PS: (Gerade habe ich - nach dem ganzen Einlesen - eine neue Website mit einem für mein Gefühl sinnvollem Mix aus HTML und Flash entworfen, wenn diese fertig ist und online steht, dann werde ich sie hier verlinken….)

So, der Hype von Multitouch ist ja bereits in aller Munde. Aber gute und sinnvolle Anwendungen lassen noch immer auf sich warten… Nichts desto trotz gibt es auch ein paar Anwendungen, die von der neuen Multitouch-Technologie profitieren und wirklich coole Szenarien für eine solche Technologie aufweisen.

Eine hiervon ist das Projekt “City Wall” (http://citywall.org/). Das Projekt in Helsinki ist eine öffentliche Kollaborations-Plattform. Dank der Multitouch Displays können mehrere Anwender simultan an der 3D Oberfläche arbeiten und interagieren.

Hier kann man das ganze kaufen und selbst tolle Anwendungen basteln: http://multitouch.fi

Bleibt also nur zu hoffen, dass man bald einen geeigneten Kunden findet, den man für die neue Technologie begeistern kann um selbst ein Projekt mit den neuen Screens realisieren zu dürfen, denn für den “normalen” Geldbeutel sind die Displays leider noch nicht geeignet.

So, das 2te Pattern, dass ich hier vorstellen möchte ist das Observer-Pattern.

Beim State-Pattern handelt es sich, wie auch bei dem zuvor vorgestellten State-Pattern, um ein sogenanntes “behavioural Pattern”. Das bedeutet es regelt das Verhalten eurer Applikation. Das Observer-Pattern wird oft auch “Publish-Subscribe” genannt. Mit zu Hilfe nahme des Pattern ist es möglich, das mehrere Objekte sich bei einem Objekt “anmelden” um weiterhin bei Änderungen dieses zweiten Objektes informiert zu werden. Konkret: Es können sich beispielsweise UI-Klassen bei einem Controller anmelden. Dieser kann fortan bei jeder Änderung am Datenmodell die UI-Klassen benachrichtigen, so dass diese sich wiederum updaten und den neuen Inhalt anzeigen können. Der große Vorteil ist, dass mittels des Observer-Patterns ebenfalls eine hohe Austauschbarkeit der UI-Komponenten (der Observer) erlangt wird, da die Applikation (der Controller) nichts über die konkreten Observer weiss, sondern nur weiß, dass diese gerde benachrichtig werden wollen, und wie er diese benachrichtigen kann. Eine hohe Austauschbarkeit wiederum fördert auch eine gute Wartbarkeit und Änderbarkeit - genau das, was von den meisten Applikationen immer erwartet wird.

Vorteile:

• Unabhängigkeit von Observern zur Applikation (Applikation kennt nur das Interface)
• Einfaches broadcasting an alle angemeldeten Observer
• Schnelle Austauschbarkeit von UI-Elementen

Nachteile:

• weiss ich leider keine (vielleicht dass man das mit dem update sauber durchziehen muss, aber das ist ja implizit, sonst muss man das Pattern ja gar nicht verwenden)

Das Pattern:

Das Pattern besteht aus 2 Basisklassen: dem Interface Observer und der Klasse Observable. Das Interface Observer muss später von allen Klassen, die “Beobachter” sein wollen, also die auf Nachrichten von der Applikation hören wollen implementiert werden. Die Klasse Observable ist die Basisklasse für die verteilende Klasse. Sie beinhaltet die Methoden zum hinzufügen und benachrichtigen von Observern.

Die Initialisierung funktioniert beim dem Observer-Pattern nun folgendermaßen:

1. erstelle eine Instanz von MyApplication
2. erstelle eine Instanz von myObserver (übergebe die Application), so dass der Observer die Application kennt.
3. registriere myObserver bei der Application myApplication.addObserver(this);

Jetzt können Mitteilungen in der Application mittels notifyObservers(…) an alle sich bisher registrierten Observer gebroadcasted werden. Vor allem OHNE dass die Application die konkreten Observer kennt!!! Warum ist das so toll? Na ganz einfach. Der Kern eurer Anwendung kennt das UI nicht, daher kann das UI super einfach ausgetauscht werden. das neue UI muss sich nur als Observer registrieren und bekommt wieder alle Änderungen der Applikation mitgeteilt und kann, wenn es möchte darauf reagieren..

Nun noch die Frage, wer triggert ein update? Dieses triggert die Application. Meist jedoch ausgelöst durch ein User-Event, also eine Eingabe in einer der UI-Klassen. Diese wiederum können den Aufruf einfach an die Application weiter delegieren. Diese kann dann z.B. die Datenbank, das Modell o.ä. befragen, updaten… und dann mit den neuen Daten dem UI ein update schicken. - Super, oder?

Beispiel:

So, wem das noch zu abstrakt war, hier ein Beispiel, wie das Ganze real ausschauen könnte. Die Klassen Observer und Observable sind gegeben. Die Konkreten Ausprägungen wähle ich nun jedoch folgendermaßen:

Die broadcastende Instanz ist mein ApplicationController. Dieser ist Sub-Klasse von Observable, er erbt also die Fähigkeit Observer zu sich hinzuzufügen und alle Observer zu benachrichtigen. Meine Observer sind einmal die Navigation (NavigationUI) und die Breadcrumbs (BreadcrumbsUI). Diese bekommen bei der Initialisierung den ApplicationController übergeben. Sie haben also alle ein Attribut myApp. Alle Observer rufen initialisieren sich nun mittels myApp.addObserver(this) sich bei dem Controller.

So, die Applikation ist aufgesetzt. Nun kann der Controller mittels notifyObservers(….) alle registrierten Instanzen benachrichtigen. Merke: Die Kommunikation geht lediglich über die Methode update(), die alle Observer implementieren müssen. Der Conroller kennt also keine Klasse NavigationUI oder BreadcrumbUI, sondern nur das Interface Observable. Somit kann ich jederzeit z.B. die Breadcrumbs weglassen, oder sie durch die Klasse NewBreadCrumbsUI austauschen. Diese muss dann lediglich wieder Observer implementieren und sich bei dem Controller als Observer anmelden - FERTIG!

Download:

So, wer das Ganze selbst erleben möchte, der kann sich hier den Beispiel-Code als Download auf den Rechner laden. (Dieses Beispiel zeigt mittels Traces den Aufruf von einem Update und die Reaktion der UI-Komponenten)

Initialisierungs-Code:

Zum Initialisieren des Beispielcodes könnt ihr folgenden Zeilen verwenden:

----------------------------------------------------------------------

//Initialisierung
var appControler:ApplicationController = new ApplicationController();

var naviUI:NavigationUI = new NavigationUI(appControler);

var breadCrumbsUI:BreadcrumbsUI = new BreadcrumbsUI(appControler);

trace("----------");

//erstes Benachrichtigen der Controller…

appControler.notifyObservers("loaded...");

trace("----------");

//noch ein 2tes Benachrichtigen aller Controller

appControler.notifyObservers("menu changed...");

trace("----------");

----------------------------------------------------------------------

- Viel Spass damit!

Ich möchte euch hier das State-Pattern näher bringen und es gleich auch anhand eines AS3.0 Beispieles praktisch erklären.

Das State-Pattern ist ein “behavioural Pattern”. Das bedeutet es regelt den Ablauf, bzw. kann den Ablauf / das Verhalten für unsere Anwendung steuern. Wann immer wir sogenanntes zustandsbedinges, komplexeres Verhalten haben, sprich eine Anwendung z.B. auf selben KeyUp-Event ander Reagieren soll, je nachedem wo ich mich gerade befinde kann das State-Pattern in Punkto sauberer Programmierung uns wahrhaftig unterstützen. Die Vorstufe für das State-Pattern ist eine Zustandssteuerung durch Fallunterscheidung - sprich durch verschlungene If… else… Konstrukte. Man setzt mehrere Flags und guckt dann, wie man reagiert. Das Problem hierbei ist einerseitz die Übersichtlichkeit, andererseits die Wartbarkeit (guckt euch so ne 3-Seiten lange If-Else-Abfrage mal nach einem Jahr an und versucht zu verstehen, wann ihr in welchen Fall gelangt… ).

Vorteile auf einen Blick:

• einfache Strukturierung komplexem Verhaltens
• Übersichtlichkeit durch Aufteilung in mehrere Klassen
• Verbesserte Wartbarkeit auch nach längerer Projekt-Abstinenz
• Hinzufügen eines neuen Zustandes ist super-einfach (nur neue Klasse schreiben)

Die Kehrseite der Medallie:

• es entstehen mehr Klassen
• hinzufügen einer neuen Methode bedeutet overhead (alle States updaten)

So, nun zur Lösung des Problems: Wer hätte das gedacht - hier taugt das Statepattern!!! Hier erzeugt man nun für jeden Status, indem sich das Programm befinden kann eine seperate Klasse. In diesen sind die einzelnen Codefragmente (die sind zwischen If-Else-Blöcken stehen würden) in die verschiedenen Klassen ausgelagert. Dies steigert die Lesbarkeit eures Codes und die Findbarkeit von Fehlern.

Hier einmal der Grundaufbau, wie das Pattern strukturiert ist. Zum einen Gibt es die Klasse ClassX, die unsere Applikation darstellt. Diese wiederum hat ein Attribut “state”, welches vom Typ State ist und immer den aktuellen Zustand des Programmes repräsentiert. Die wahre Klasse “State” ist jedoch nur abstakt, von ihr können also keine direkten Instanzen erzeugt werden. Sie dient jedoch als Schablone für die weiteren State-Klassen, die von ihr erben (StateA, StateB,…. StateX). Das Prinzip ist nun folgendes. Im ersten Schritt muss die KlasseX beim initalisieren in einen Start-Zustand versetzt werden, z.B. this.state = new StateA();. Nun wird, ggf. op1 auf der aktuellen state instanz getriggert, was wiederum in unserem Beispiel zu Beginn die op1() von der Klasse StateA ist. Wenn diese Operation den Zustand nicht ändert gibt sie einfach wieder StateA zurück. Sollte sie den Zustand wechseln wollen gibt die Methode einfach ein neues Zustandsobjekt, beispielsweise new StateB() zurück. Damit befindet sich ClassX nun im Zustand B, ohne das diese irgendwas damit zu tun hatte, oder dies auch nur mitbekommen hat. ihr ist das total ega. Sie triggert einfach nur Methoden an ihren State. Was die dann zur Laufzeit damit machen, das ist ihnen überlassen und steht NUR ind den States selbst. => die Komplexität wird also aus der KlasseX ausgelagert und übersichtlich in die verschiedenen Status-Klassen verteilt.

Beispiel:

So, wem das noch zu komplex und zu Abstrakt war, hier ein Beispiel, wie das ganze in der Realität aussehen könnte. Nebem wir ein kleines Jump`n Run Game. Hier Haben wir meist eine Keyboard- oder Joystick-Steuerung, die je nachdem in welchem Modus die Figur sich gerade befindet verschieden Reagiert. Sprich: Befindet sich der Character auf festem Boden kann er rennen. Ist er gerade im Wasser kann er schwimmen. Befindet er sich im super-speed-Modus kann er super-schnell rennen etc…. Eurer Fantasie wie immer auch hier keine Grenzen gesetzt. So das ganze nun im State-Pattern gesprochen: Wir haben ein Game. Diese kann sich in mehreren Zuständen befinden. Der Einfachkeit halber habe ich mir mal 3 Modi ausgedacht: RunState, SwimState und PauseState. Je nachdem in welchem Modus der Anwender sich befindet hat das drücken z.B. der Pfeiltasten andere Funktionalität (im Pause-Modus z.B. kann der Anwender nichts drücken, ausser wieder “P” um die Pause aufzuheben).

Oben im Bild das ganze mal grafisch darsgestellt, wie das Pattern in der konkreten Ausprägung für das Game aussieht. Wir haben also eine Klasse Game, die z.B. die GUI initialisiert etc… Diese wiederum hat ein Attribut “state” vom Typ State. Die Klasse State ist übrigens in unserem Fall nicht abstrakt, denn das gibts ja in AS3.0 nicht, ist aber

Download:

Hier der Beispiel-Code zum Download
(Ach ja, das ist kein fertiges Spiel, sondern nur Traces, die das Ganze als Ausgabe simulieren)

Initialisierungs-Code:

Zum Initialisieren des Beispielcodes braucht ihr folgenden Zeilen:

------------------------
this.addChild(g);

g.startGame();

-----------------------

- Viel Spass damit!

Wie man seine über das Geschäftsjahr hinweg sich stetig ändernden Geschäftsdaten anschaulich visualisieren kann zeigt uns hier Coca-Cola (Coca-Cola-Geschäftsdaten 2007). Sehr überzeugend und SEHR Anschaulich kann man hier z.B. das verhalten der Besucherzahlen auf den verschiednenen Webseiten über das Jahr hinweg beobachten.

Z.B. sieht man hier dass Coke-Zero - welches ja erst im Laufe des Jahres eingeführt wurde sofort die Aufmerksamkeit der Webbesucher aufs ich gezogen hat, was aber auch einen Zurückgang der Visits der Hauptseite im Jahresverlauf mit sich gebracht hat. Der Anwender kann den Verlauf schön über den Zeitregler am unteren Rand steuern und so genau den Verlauf der Visits beobachten.

Erstellt wurde das ganze übrigens von der deutschen Argentur “Scholz und Volkmer” aus Wiesbaden.

Eine schöne, feine Demo für die Lösung einer komplexen Suche befindet sich hier: Elastic Lists Demo. Die komplexe Liste aller Nobelpreisgewinnern ist hier komfortabel mittels verschiedener Parameter (Facets) einschränkbar. In jeder Facette sieht man schön die dazugehörigen, möglichen Filtermöglichkeite, sowie auch deren quantitative Auswirkung auf die Ergebnisliste. Der Anwender sieht also bereits vor der Selektion, wie er seine Auswahl damit beschränkt. Der quantitative Aspekt wird ebenfalls in der Höhe der Listen-Elemente wiedergespiegelt.

Den momentanen Status, also die momentane Selektion ist farblich (grün) hervorgehoben, wodurch der Anwender gut sehen kann, wo er sich befindet, bzw. welche Parameter momentan die angezeigte Liste definieren. Durch wiederholtes clicken auf einen gewählten Parameter kann diese Selektion auch wieder aufgehoben werden.

Fazit: Ein wie ich finde sehr gut durchdachtes, schönes Beispiel einer Multi-Faceted-Search!

Da ja nicht jeder, der gerade “zufällig” eine Menge Daten zur Visiualisierung auf seinem Rechner bereithält auch programmieren kann, haben sich in paar Jungs bei IBM eine schöne Plattform ausgedacht, bei der jeder sein Datenset in eine schöne Visualisierungsform bringen kann. Hier kann man mehr oder weniger automatisiert schöne, die Möglichkeiten von Excel sprengende, Visualisierungen erstellen. Das Ganze ist im Web unter http://services.alphaworks.ibm.com/manyeyes/app erreichbar.

Einfach das Datenset aufbereiten, Visualisierungart aussuchen und Daten hochladen => fertig.

Anhand einiger Beispiele kann man hier auch nette Visualisierungen von Daten sehen. Hier ein schönes Beispiel für verschiedene Auswertungen über Italien (Population etc.): Italien-Beispiel

Willkommen zu meinem Blog. Ich hoffe ich finde die Zeit hier regelmäßig Interessante Artikel zu den Themen Flash, Flex, Userinterface Design, Interaktionsdesign und so weiter einzustellen…

Viel Spass damit,
Anneke.