Skip to content

Theme Wahlfreiheit für Besucher

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

Ich bin zur Zeit am überlegen, ob ich meinen Blog ein wenig auffrischen soll. Da gibt es Überlegungen wie:
  • Soll ich die Kategorien weiter pflegen?
  • Wieso ist Navigation und Funktion miteinander in der gleichen Liste?
  • Welches Layout sollte ich nun nutzen?
  • Gefällt das alte Design den Kunden mehr als das Neue?
Solche Gedanken hat man ja immer, wenn man eine Webseite neu gestaltet. Und deshalb bin ich auf folgende Idee gekommen:

Lass doch das Design vom Kunden auswählen

In bestimmten Rahmen kann man sich erlauben zwei- oder drei Designs anzubieten. Wenn man auf die Seite kommt, erscheint das aktuelle Design. Wenn man dann ein anderes Design, mit z.B. mehr Funkionalität, haben will, kann man dies auswählen. Das Design wird gewechselt und der Kunde hat andere Möglichkeiten als zuvor.

Ja aber, dann muss man ja Kundendaten speichern!

Wenn man will, dass der Kunde beim nächsten Mal das gleiche Design vorfindet, muss man mindestens einen Cookie auf der Kundenmaschine abspeichern. Oder noch komplizierter: Der Kunde muss sich am System anmelden. Das wäre bei einem normalen Blog oder einer normalen Webseite wirklich ein Overkill. Ich will einfach nur die Wahlmöglichkeit bereitstellen. Wenn ein Kunde dann das Design wechseln will, soll er hierzu eine Möglichkeit erhalten. Falls der Kunde Cookies zulässt, kann man immer noch über eine permanente Umstellung nachdenken.

Ist das nicht eine halbherzige Idee?

Ich denke nicht. Es lässt dem Kunden die Freiheit, zwischen verschiedenen Designs auszuwählen. Vielleicht ist der Kunde heute positiv eingestellt und will eine schöne, leuchtende Darstellung? Vielleicht will er heute nur Text, da er schnell was suchen muss? Wenn man sich den Mehraufwand leisten kann, dann wäre es vermutlich eine gute Idee mehr als ein Design zur Verfügung zu haben.

Getting Things Done Session beim FuCamp in Furtwangen

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

Oha, schon wieder sitze ich beim Oliver Gassner in einer Session :-) Normalerweise laufe ich nicht einer Person bei Barcamps hinterher. Aber heute hatte Oli das Glück oder das Pech, dass er zwei Themen anbot, die mich interessieren. Über seine Blogzerlegung hatte ich heute Morgen ja schon berichtet. Bei dieser Session ging um Selbstmanagement nach der Strategie "Getting Things Done" Ich versuche hier mal ein Life Blogging durchzuführen. Falls die Sätze hier ein wenig willenlos sind, liegt das am direkt runterschreiben und versenden. Er verwies auf ein Buch The art of Stress-Free Productivity von David Allen. Weiterhin verwies er auf das Buch Making it all work. Bei dieser Methode geht es darum die Zeit so einzuteilen, dass für Freizeit auch noch was übrig ist. David Allen sagt, "your brain dosn´t have a brain". Man behält normalerweise seine Aufgaben im Gehirn auf. Im Berufsleben werden alle Aufgaben auch im Gehirn abgespeichert. Dabei wird Stress aufgebaut. Man denkt ständig über das jeweilige Problem, die jeweilige Aufgabe nach. Zu jedem Zeitpunkt erinnert man sich an diverse Aufgaben die man erledigen muss. Man weiss aber noch nicht wann man diese Tasks abarbeiten will. Die Frage, was ist der nächste Schritt, hat man sich nicht gestellt. Todo Listen sind oft lang und veraltet...

Warum ist das so?

Im Vergleich zu früheren Generationen haben wir deutlich mehr Informationen zu verwalten. Oliver erklärt, dass es sich nicht um neue Techniken handelt, sondern ein paar best practise werden hier gebündelt.

Best Practise beim Erfassen:

  • Mach das Hirn leer
  • Alles was rumliegt zusammensammeln und auf einen Stapel legen. (Capture, Erfassen) Dieses Erfassen muss vollständig sein. Wenn das nicht der Fall ist, werden wieder weitere Stapel generiert und nicht abgearbeitet.
  • Schau auch wirklich in die erfassten Listen rein.
  • Möglichst wenig Inboxen, Listen, generieren. Im Idealfall eine Liste, nicht zehn Todo Lists
  • Auch zuhause muss eine Inbox vorhanden sein. Ansonsten läuft das Zuhause zur Inbox voll :-)

Best Practise Bearbeiten (Im Buch Clarifying)

  • Aufräumen und Ordnen der aktuellen Inbox
  • Verteilen der Aufgaben auf die Themen unmittelbar, später oder viel später
  • Frage ist: Is it actional ?
  • Die Frage, ob etwas eingeordnet werden kann, muss in zwei- drei Minuten erledigt werden. Wenn das nicht klappt, dann ist hier ein Problem vorhanden.
  • Die Tasks auf die Termine verteilen (August Sachen in der Inbox August...)
  • Klären was die Elemente in der Inbox betrifft wird an dem Tag an dem sie aktuell werden gesetzt.
  • Falls an dem Tag etwas ca. 2 Minuten benötigt, dann mach es sofort. Damit wird der Verwaltungsaufwand verringert. Denn die Verwaltung dieses Tasks dauert länger.
  • Wenn es länger als zwei Minuten kostet, muss eine "Einkaufsliste" erzeugt werden.
Liste wie die Todo Listen aufgebaut werden, sind im Prinzip eine Einkaufsliste. Hier werden sie Context Listen genannt. Wenn man z.B. zum Metzger geht, dann schreibt man auch nicht auf die Metzgerliste Klopapier, Duschgel usw. Wo können die Tasks erledigt werden.
  • Arbeit Projektleiten, Programmieren
  • Zuhause Malen, Tapezieren, Staubsaugen
  • Unterwegs Fleischkäse, Sprudel, Ladegerät
Liste für z.B. Reifenwechsel:
  • Termin vereinbaren
  • Reifen ins Auto einladen
  • Auto vorführen
  • Auto abholen
  • Reifen einlagern
Die nächste sichtbare Handlung muss definiert werden. Und diese sehr granular. Ansonsten ist sie nicht komplett. Es kommen nur Aufgaben auf die Liste, die an dem Tag auch wirklich gemacht werden. Wenn also "Auto abholen" erst am nächsten Tag fällig sein kann, dann kommt diese Aufgabe am nächsten Tag vor. Die Trennung der Listen (Arbeit, Zuhause und Unterwegs) helfen den jeweiligen Context auf den richtigen Abarbeitungszeitpunkt zu legen. Nicht zu viele Context Listen erstellen. Vermutlich sind drei Context Listen vollkommen ausreichend. Eine Liste "delegiert" anlegen. Darin steht drin was Andere für einen machen sollen. Diese Liste kann man nehmen um andere zu erinnern und nachzufragen. Someday Maybe Liste. Liste für alles, wie z.B. "Welt retten, Wintergarten bauen, Spanisch lernen". Die hilft zum Zwischenspeichern und ist für alles was jetzt einfach nicht gelöst werden kann.

Durchsehen

Alle Listen müssen einmal die Woche durchgeschaut werden. Damit kann man seine Aktionen feiner abstimmen.

Machen

Die Listen müssen natürlich auch abgearbeitet werden :-) Das Abarbeiten wird dann pro Liste (im Context) gemacht. Also Arbeit bei Arbeit, Zuhause dann wenn man daheim ist usw. Die Tasks müssen dann noch nach Prioritäten sortiert werden. Eventuell können hier die Tasks für den jeweiligen Tag noch richtig eingelastet werden. Definition der "Next Action". Noch was: Eine Task in der kein Verb vorkommt ist es wohl ein Projektname und keine Task. Schliesslich ist ein Task etwas bei dem etwas getan werden muss. Verb = Tunwort :-)

Ich sitz gerade auf dem FuCamp beim Oliver Gassner in der Blog-Analyse Session

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

fucamp olivergIch bin heute auf dem FuCamp in Furtwangen. Nachdem ich meine Session Komplexität durchgeführt habe, sitz ich jetzt gerade beim Oliver Gassner in seiner Session. Er nimmt gerade ein paar Blogs auseinander und beschreibt was er so alles an den Blogs gut und schlecht findet. Ein paar Tipps die er zu einem Businessblog gibt:
  • Lieber mal ein paar kleinere Beiträge als riesige Beiträge.
  • Ist der Effekt der größe der Beiträge zu den AdBlogs hinterher wirklich ok? Lohnt sich der Aufwand
  • Verweise auf alle Fälle auf Blogs die auf dich verlinken
  • Wenn du mehrere Autoren hast, dann mach z.B. mit einem Bild klar welcher Autor gerade schreibt.
  • Wenn du einen Businessblog haben willst, dann musst du als Chef auch zeigen dass du willst, dass gebloggt wird. Gib z.B. ein bisschen Bonus (Freier Tag oder so)
Zu Blogs allgeimein: Wenn du das Blog hochbringen willst, vier Artikel am Werktag. Einen großen Beitrag und ein paar Kleinere. Themen von anderen Blogs "abfischen und verlinken" Als letzten Blog hat er diesen miradlo Blog auseinandergenommen. Gute Tipps sind, dass wir zu viele verschiedene Navigations- und Content Elemente in unserer Sitebar verwenden. Vielleicht werden wir hier ein bisschen aufräumen...

Interaktive Webseiten und deren Probleme

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

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.

Programmiergrundlagen sind manchmal gar nicht so "grundlagig"

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

Ich darf immer wieder mal Einsteigern die Geheimnisse der Informatik näher bringen. Jetzt verhält es sich mit der IT so wie bei den Zauberern. Man kann eigentlich gar nicht sehen was da so passiert. Man muss es sich irgendwie "begreifbar" machen. Und dann mache ich manchmal den Fehler und glaube meinen Einsteigern, dass sie alles verstanden haben. Hier ein paar Beispiele: "Programmiergrundlagen sind manchmal gar nicht so "grundlagig"" vollständig lesen

Programmieren lernen am praktischen Beispiel

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

Ich finde Programmierbeispiele häufig ziemlich ungeschickt. Mal sind sie zu groß und zu kompliziert, mal sind sie zu einfach und können später nicht umgesetzt werden. Und da es so viele Programmierbeispiele gibt, möchte ich noch eines hinzufügen :-) Ute hat mich mal gefragt, ob wir eine Newsfunktion erstellen können, mit der man auch ein paar Bilder einfügen kann. Soll heißen, dass aktuelle Informationen auf einer Webseite so lange dargestellt werden, bis sie nicht mehr aktuell sind. Also Weihnachtsgrüße sollen nur automatisch zu Weihnachten erscheinen und kurz vor Ostern können wir die abstellen ;-) Aussehen soll es ihrer Vorstellung nach, in etwa wie folgt:
  • Screenshot Guggat emol Blog Newssystem erstellen

Newsüberschrift Ostergrüße ;-)

Neben dem Bild einer News soll die jeweilige Überschrift einer Meldung oder Neuigkeit stehen und anschließend der dazugehörige Text. Weiterer Text oder die nächste Meldung folgt dann erst danach. [Zumindest in standardkonformen Browsern klappt das... ;-) ]

Dieses Newssystem soll Bilder einpflegen können. Und da wir ja gerne komplizierte Sachen machen, sollen die Editoren, die die Texte schreiben, mit einem vernünftigen Rechtesystem ausgestattet sein.

Kurz gesagt: Wir wollen eine komplette Webapplikation bauen. Und wir sind Wiederholungstäter. In den letzten Jahren haben wir diverse Webapplikationen erstellt. Diesmal gehen wir jedoch einen etwas anderen Weg. Ich habe unter Newssystem erstellen beschrieben, wie das Newssystem aussehen soll und wir diskutieren dort im Internet über die Erstellung. Falls ihr mitmachen wollt, seid ihr herzlich eingeladen. Es geht darum, ein wirklich rundes und großes System zu erstellen mit dem wir später auch noch was anfangen können. Die Entwicklung wird wohl etwas langsamer vorwärts gehen, als wenn ich das Teil alleine schreiben würde. Aber vielleicht erfinden wir hier ein paar schönere und bessere Komponenten bei denen wir alle was lernen?

Architekturmuster und Design Patterns verwenden

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

Wenn man ein Haus baut gibt es bestimmte Regeln an die man sich halten sollte. Beispielsweise wäre es nicht sehr ratsam ein Dach so zu konstruieren, dass das Wasser nicht abläuft sondern zur Mitte des Dachs hinfließt. Ein weiteres nicht ratsames Beispiel wäre es eine Decke so zu konstruieren, dass sie sich nicht selbst tragen könnte. Wenn man dann noch auf die Idee kommt, auf diese Decke einen Stuhl zu stellen, findet man sich höchstwahrscheinlich ein Stockwerk tiefer wieder. Unsere Vorfahren haben also Architekturmuster erfunden. Daneben haben wir vor ein paar tausend Jahren auch noch das Rad erfunden. Wir empfanden das als ziemlich praktisch. Man kann mit so einem Rad die Reibungsverluste beim Schieben verringern. Und heute sagen wir immer wieder mal, dass wir das Rad nicht neu erfinden sollen.

Wie sieht das in der IT aus?

Die IT ist ein relativ neues Themengebiet. Vor ein paar Jahren erfand jeder Entwickler seine Räder jeden Tag nochmals. Irgendwie haben viele von uns, dann viele Stunden verbracht auf Problemen rumzunagen, die es eigentlich schon längst nicht mehr geben sollte. Und genau hier setzen Architekturmuster und Design Patterns an. Wir generieren heute eine Webapplikation, indem wir die Architektur auf den Browser, den Webserver, den Datenbankserver und das Netzwerk verteilen. Wir verwenden Factory Patterns um bestimtme Objekte zu erzeugen. Wir mixen die diversen Observer, Strategy und Composite Patterns und erstellen Model View Controller Patterns. Das einzige Problem mit all den schönen Patterns ist, dass die Dinger ziemlich unverständlich sein können. Wenn ein neuer Entwickler anfängt, ist er mit Schleifen, if-Abfragen und anderen Schweinereien schon ziemlich ausgelastet. Wenn dann noch ein Roland vorbei kommt und ihm sagt "heute bauen wir mal ein Singleton", dann fühlt sich der Anfänger irgendwie nicht wohl. Deshalb habe ich bei guggat emol Blog eine Designpattern Einführung erstellt. Ich werde nicht noch einmal alle Design Patterns, die zur Genüge beschrieben wurden, beschreiben. Ich werde hier die Design Patterns, die ich in den Programmierbeispielen verwende, erläutern. Später werden diese Patterns dann für reelle Aufgaben verwendet. Wer weiß, vielleicht bauen wir in ein paar Jahren weniger IT-Decken die sich nicht selbst tragen können? :-)