Skip to content

Interaktive Webseiten und deren Probleme

Früher war alles einfach und langweilig. Wenn zum Beispiel Daten für die Erfassung einer Person eingegeben werden mussten, haben wir eine Form erstellt, in diese Form haben wir Namen-, Vornamen- und Adresseingabefelder reingefummelt und einen Submit-Button angezeigt. Der geplagte Anwender hat die Daten in die Felder eingegeben, das Ganze mit Submit bestätigt und auf die Fehlermeldungen vom Server gewartet.

Was ist daran falsch?

Aus Sicht des Programmierers war alles super. Wir hatten es einfach und der Datenfluss war 100% unter Kontrolle. Die Kommunikationsmuster können wir uns noch sehr gut vorstellen. Der Anwender ist mit dem Programmfluss geschaltet und er muss seine Arbeitsweise an das Programm anpassen.

Wie bitte? Der Anwender muss sich anpassen?

Hm... Da ist glaube ich das Problem. Der Businessprozess sieht unter Umständen überhaupt nicht vor, dass der Anwender auf die Antwort vom Server warten soll. Vielleicht will der Anwender gleich mit dem Bearbeiten von Kundeninformationen, wie Lieblingsfarbe und Lieblingsauto weiter machen. Und er möchte gar nicht auf den Server warten. Viel schlimmer noch. Der Anwender wird genötigt zu warten und wird aus seinen Gedankengängen herausgeworfen. Und das ist nun wirklich schlecht.

Rettung naht mit AJAX usw.

Jaja, wir kennen das. Dann bauen wir halt was Modernes ein und kommunizieren asynchron. Wir lassen den Anwender weiter machen und alles ist prima. Aber jetzt kommt unser Problem der neuen Welt.

Wie informieren wir unseren Anwender?

  • AJAX in rot und blau
Wir überlassen also die Korrektur und Testerei der eingegebenen Daten unserem asynchronen Prozess. Der macht das prima und unser Anwender tippt fröhlich weiter. Mitten in der Eingabe der Lieblingsfarbe poppt aber eine Fehlermeldung auf die da sagt: "Bitte geben Sie einen Namen ein". Und der Anwender wird aus seinem Businessprozess und seinen Gedanken herausgeschleudert. Na schön, da er sowieso direkt zum Namen zurückgeführt wird (der Fokus ist wieder auf dem Namensfeld) gibt er den Namen halt ein. Blöd ist nur, dass er mittlerweile aber auch noch eine falsche Farbe eingegeben hat, da die Applikation ihn ja aus seiner Farbeingabe herausgerissen hat. Also kaum ist er mit dem Namen fertig, oder er tippt noch am Namen rum, poppt schon wieder eine Fehlermeldung auf: "Bitte geben Sie eine korrekte Farbe ein". Oha! Wir haben hier wohl was falsch programmiert gelle? Klar, solche Probleme muss man schon irgendwie anders lösen. Aber bevor man an eine hoch interaktive Webseite herangeht, sollte man sich darüber im Klaren sein.

War's das schon?

Nein, es gibt noch tollere Probleme. Stellt euch vor wir sitzen in einer größeren Firma, oder wir arbeiten sogar an verschiedenen Standorten (was im Web ja gewünscht ist) und zwei Editoren arbeiten zur Zeit am gleichen Datensatz. Der Eine will die Lieblingsfarbe der Person ändern, da eine E-Mail vorliegt ,in der der Kunde sagt, dass seine Lieblingsfarbe rot sei, und gleichzeitig ruft der Kunde einen zweiten Mitarbeiter an und sagt, seine Lieblingsfarbe sei doch blau. Beide Mitarbeiter tippen also an der Farbe herum. Und was geschieht nun? Der Mitarbeiter mit der roten Farbe editiert einen veralteten Datensatz. Da er ein wenig länger braucht, wird zuerst die blaue Farbe der Telefonanfrage abgespeichert und dann die rote Farbe. Beide Editoren sehen unter Umständen nicht, dass der andere Editor auch auf dem Datensatz sitzt. Also wird die Eingabe noch komplexer.

Wie kann dass gehen?

Tja, während ein Editor die Farbe der E-Mail bearbeitet, muss der Datensatz für Veränderung gesperrt werden. Auch in einer wunderbaren AJAX-Superdupper-Anwendung. Der zweite Editor, muss z.B. die Möglichkeit haben den ersten Editor zu informieren, dass neue Informationen vorliegen. Oder es muss eine Prioritätendefinition vorhanden sein. Telefonbesprechungen müssen vor E-Mail Besprechungen gesetzt werden. Oder es muss beschrieben werden, wer wann was wieso gemacht hat. Weiterhin wäre es doch toll, wenn der Editor, der die E-Mail bearbeitet hat, über die Änderung informiert würde. Das könnte so ablaufen, dass gerade geänderte Werte ihm noch einmal vorgelegt werden. Beispielsweise, falls innerhalb der nächsten zehn Minuten ein Wert von einer anderen Person geändert wurde, wird dieser Wert nochmals zur Überprüfung angezeigt.

Fazit

Sobald wir eine tolle, blinkende, asynchrone Eingabemöglichkeit für unsere Benutzer erstellen, begeben wir uns auf gefährliches Gebiet. Die Nebenläufigkeiten von asynchronen Eingaben sind extrem komplex und müssen im Einzelfall genau analysiert werden. Interaktive und an den Geschäftsprozess angepasste Webapplikationen sind klasse. Aber die Schwierigkeiten und Gefahren sind ungleich höher als bei einer Einwegkommunikation. Natürlich können dort auch solche Gefahren lauern, der Prozess ist jedoch einfacher zu verwalten.

Trackbacks

Keine Trackbacks

Kommentare

Joscha am :

Joscha Klar, ideal und perfekt ist sehr schwierig für den Programmierer. Es kann schon komplex genug sein, synchrone Zugriffe bei vielen Usern zu handeln.
Meine Vision ist trotzdem das Laden zu überwinden. Das Web soll flüssig werden. Nicht zwingend durch langsame Flash schwarz nach schwarz Überblendungen, die die Wartezeit verkürzen sollen, aber durch intelligentes und vorausschauendes Vorladen von Inhalten. Mein Traum ist, dass das Web wie ein Buch ist, ich schlage auf, bin irgendwo, dann zoomt man irgendwo rein, mehr und mehr Informationen umfliegen einen und dann geht es vielleicht wieder raus. Oder mitten durch die Information durch. Informationen in 3D vielleicht...

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Gravatar, Twitter, Favatar Autoren-Bilder werden unterstützt.
tweetbackcheck