Mittwoch, November 28, 2007

"Dienst oder Dienstmerkmal nicht möglich."

Letzte Woche war ich auf der USAB 2007 (Usability & HCI for Medicine and Health Care; HCI steht für Human Computer Interaction) und begeisterte mich an der Keynote von Harold Thimbleby, der an der Swansea University (UK) lehrt. Thema: "User-Centered Methods are Insufficient for Safety Critical Systems". Irgendetwas hat er in mir losgetreten, und seitdem laufe ich etwas aufgeweckter durch die Gegend, was die Gestaltung von Mensch/Computer-Schnittstellen betrifft. Zwei Beispiele aus den letzten Tagen:

Flughafen Frankfurt am Main. Ich bin eben gelandet, bin zum Ausgang raus und steure die Automaten an, um mein Parkticket für das Auto zu bezahlen. Ich schiebe die Parkkarte in den Automaten, das Geld hinterher, bekomme die Parkkarte zurück und realisiere erst in dem Moment, dass ich eine Quittung über die Parkgebühr benötige. Schnell noch die Quittungstaste gedrückt -- die mir den Dienst verweigert. Ihr fehle eine Parkkarte! Also schiebe ich die Parkkarte wieder in den Automaten in der Hoffnung, nachträglich eine Quittung anfordern zu können. Geht nicht, "Parkgebühren bezahlt". Mir bleibt nichts anderes übrig als mich an der Ausfahrtschranke an den Parkwächter zu wenden und ihn um eine Quittung zu bitten. Der Vorgang dauert etwa 3-4 Minuten, wobei der Parkwächter sich einmal am Rechner vertippt, um festzustellen, ob meine Karte bereits bezahlt ist.

Verblüffend, wie die Entwickler der Bezahlautomaten das Szenario der nachgeforderten Quittung schlicht ignoriert haben, gell? Vor mir war ein Mann beim Parkwächter an der Reihe, der überraschenderweise exakt dasselbe Problem hatte. Vermutlich kommt das an einem Flughafen wie Frankfurt etliche Male am Tag vor. Wie kann man sowas übersehen?

Gestern. Ich rufe meine Frau im Büro an. Die Leitung ist besetzt. Ein Stimme fragt mich, ob ich gerne den automatischen Wiederwahl-Dienst bei Freiwerden der Leitung nutzen möchte. Ich möge dazu "Ja" in den Hörer sprechen. Ich sage "Ja" und bekomme zu hören: "Dienst oder Dienstmerkmal nicht möglich."

Warum in aller Welt bekomme ich eine Option angeboten, die nicht ausgeführt werden kann? Kann der Computer das nicht vorher ermitteln und mir den Service nur anbieten, wenn er verfügbar ist? Gut möglich, dass mir jetzt ein Software-Entwickler lang und breit erklären kann, warum das so sein muss. Die Software könne das nicht vorher erkennen. Das war ein Punkt in Thimblebys Keynote: Ist ein schlechtes Design eine Entschuldigung? Wenn eine Software nicht vorher ermitteln kann, ob sie dem Nutzer ein Leistungsmerkmal anbieten kann oder nicht, dann ist sie schlecht entworfen.

Haben Sie ähnliche Erfahrungen gemacht? Wenn Sie mögen, berichten Sie mir davon!

Samstag, November 24, 2007

User, Domain and Realization Models

In my previous post on "Modeling Illusions" I distinguished between the illusion, manifested by a domain model, and the model that does the trick, the realization model. The interesting question is: How do these two models relate to each other?

If I managed to explain things well, you should have understood that both models implement the same interface and that they behave exactly the same for an external observer. Otherwise, it would be useless to talk about an "illusion". From the outside, there is no way to tell which model is actually operating "behind the wall". From this viewpoint, both models are interchangeable.

Note that this statement highlights a very crucial point. If you cannot say what's behind the wall, you experience and develop a consistent mental model of the interface and it's behavior from the outside. We call this mental model the user model of the interface.

So we are having three models: From an external viewpoint, we have a user model a user associates with the interface; it is the user's perception of the illusion. Behind the wall, from an inner perspective, the interface is either implemented by a domain model, describing the illusion from an inner perspective, or by a realization model, an alternative description for the illusion.

The relation between the models is as follows: In terms of size, better: information content, the following formula holds:

user model <= domain model < realization model

Ideally, the user model and the domain model match. However, the realization model must be "bigger" than the domain model. Both, the domain model and the realization model, must have the capability to generate the same external user experience. But there must be more to the realization model. Otherwise why should you call it a realization? You could also say that the realization has more information content than the domain model by definition.

From a software engineering standpoint, the realization model should be developed in such a way that it can be easily verified against the domain model(!). It should be easy to show that the state model the realization model implements includes the state model of the domain model. Alas, this is not standard practice. Only very few software engineers know and understand the cascade of these three models: user model (external interface experience), domain model and realization model (alternative interface implementations). To distinguish and actually use domain and realization models is a very powerful technique to manage complexity. This technique is, however, of limited use, when there is no way to show that the realization model actually realizes the domain model.

There are some techniques around to keep the realization and the domain model "in sync". One is to use generative techniques to generate the realization model out of the domain model (catchword "Domain Specific Modeling"). Another is to use Aspect-Orientation, which enables a designer to add realization aspects to an domain model. Formal methods may help prove that the realization model is consistent with the domain model. So there are some important tools around in the toolbox of a software engineer.

By the way: User models are crucial in (User) Interface Design!

Montag, November 19, 2007

Modeling Illusions

A very important tool in software engineering (SE) is modeling illusions. In SE, engineers most often focus solely on realizations not illusions. However, illusions are the magic to create self-contained worlds (or domains), to separate design spaces and thereby simplify design. Modeling illusions is an art which is rarely understood and applied.

What do I mean by illusions? Let me give you some examples: Look at your desktop on your computer screen -- it's an illusion. There is no desktop in your computer. See the little small icon you call a dustbin or trash can? It's an illusion. Take a screwdriver and open your computer; you won't find a dustbin in there. Your files on your hard disk are organized in directories which are nested in a hierarchy. It's an illusion. Your hard disk actually has multiple platters and read/write heads, and each platter is organized in tracks and sectors (see also "How Hard Disks Work"). You work with databases, handle tables, keys, relationships? The world implied by SQL is an illusion. Look at any serious, high-performance database implementation. It's about B-trees and similar stuff.

The essence is: You have to distinguish an illusion from it's realization. What they share and have in common is the (user) interface. It's the interface that creates an illusion!

You got it? What I'm after is the following:

Any interface creates an illusion. A software engineer should describe the illusion from two different viewpoints: One model describes the elements of the illusion, how they can be used, how they relate and interact and so on. It's a domain model of the illusion. The other model describes how the illusion was done; it unveals the trick of the "magician". It's a realization model of the illusion. Others might also call it an "implementation model".

My point is: Software Engineers usually miss the point to consider each model as a model in it's own right. They are sloppy with the domain model but careful with the realization model. This is bad, because domain models are one of the most valuable modeling techniques to reduce complexity for system's understanding. A domain model can be taken as serious as a realization model and being made executable. Then, you have a choice: You can look at your interface and work either with an executable model of the illusion or you can look at your interface and work with an executable model of the illusion's realization, thereby looking behind the scenes. The domain model lets us ignore the complexities of the realization; but the domain model is complete and creates a self-contained illusion. It is as if the magic were true. The realization model opens up a new level of complexity.

Let me give you a final example -- it also complements my criticism on "The law of leaky abstractions":

What kind of illusion does TCP create for you? The TCP user interface provides a connection-oriented communication service. It creates the illusion of a reliable connection to communicate data with someone else (you asked to accept the connection beforehand). That's the illusion.

If we look at how the trick is done, the realization, we see a state machine realizing a nice rendezvous with a remote state machine sending IP datagrams back and forth. These two state machine implement the so-called TCP protocol. TCP relies on IP.

If you do socket programming (that's using TCP connections, for the ones who do not know), the socket library of your favorite programming language offers you to work with the illusion of a TCP connection. Beyond that socket libraries fall short of the notion of a connection. Nobody really cares about a rock-solid domain model of TCP, they all do in Unix/Linux and Windows is creating realizations. In a rock-solid domain model a TCP connection would be associated with some statistic properties. You could ask the connection about some statistic properties: How reliable is the connection, how many data packages got lost and had to be retransmitted etc.? If a domain model of TCP were carefully done and accessible in socket libraries, nobody would be so naive to believe that TCP would come at no costs and actually be 100% reliable. If you abstract these details away, you might do so for the purpose of simplification, but you should know what you're doing.

Donnerstag, November 15, 2007

E8 und die "Theory of Everything"


Das lässt Sie sicher auch stutzig werden, wenn Sie hören, jemand habe die "Theory of Everything" gefunden -- auch wenn es dabei "nur" um Physik geht. In der Tat suchen die theoretischen Physiker nach so einer Theorie, die alle physikalischen Phänomene unter einen Hut bringt. Klingt hart und ziemlich schwer.

Nun will ein Surfer (nein, so ein Wasser-Surfer, der in Hawaii surft) genau diese Theorie gefunden haben, so berichtet der Telegraph in "Surfer dude stuns physicists with theory of everything" (Roger Highfield, 6:01pm GMT 14/11/2007). Klar, so mal eben beim Surfen drauf gekommen! Unsinn. Doch wenn Sie den Artikel weiter lesen, dann wird die Sache schon ernster. Da ist ein Fachmann am Werk. Das mit dem Surfer verkauft sich halt ein bissel besser. Unser "Dude" Garrett Lisi scheint's drauf zu haben. Quellensuche.

Lisis Artikel hat den schlichten, anspruchsvollen Titel "An Exceptionally Simple Theory of Everything", Sie können ihn bei arXiv.org runterladen. Ich verstehe darin zwar ehrlich gesagt kein Wort, aber das Ganze wirkt solide, ist sehr schön geschrieben (lesen Sie mal Einleitung und Schluss) und hat das Entscheidende, was so eine Theorie braucht: die Theorie macht Vorhersagen, die sie falsifizierbar, sprich widerlegbar machen. Lisi zeigt einen Weg auf, wie die vier fundamentalen Grundkräfte (die starke und schwache Wechselwirkung, die elektromagnetische Kraft und die Gravitation) in eine mathematische Struktur namens E8 abgebildet werden können. Bei dieser Abbildung bleiben ein paar wenige Plätze "unbesetzt". Lisi sagt damit neue Phänomene (Teilchen) voraus, womit seine Theorie entweder bestätigt oder ad absurdum geführt werden kann.

Jetzt bin ich doch gespannt, was die anderen "Surfer" (genau, die Physiker) dieser Welt dazu zu sagen haben. Ist unser Universum wirklich E8?

Wollen Sie meine Meinung dazu hören? "E" ist der fünfte Buchstabe im Alphabet. "E" mal 8 macht 40. Die Antwort auf alles lautet aber 42. Ich fürchte, Lisi muss nachbessern ;-)

Update: Ich scheine mit "E" * 8 = 40 <> 42 nicht allein zu sein, wie ich gerade in einem anderen Blog entdecke. Nur gibt es Leute, die solche Kritik (da sie vielleicht davon etwas verstehen) besser ausdrücken können. Letztlich bin ich jedoch ahnungslos. So ist das, wenn ich nicht über Informatik schreibe. Spaßig finde ich solche Sachen trotzdem. Es ist dem Glauben an den Fortschritt geschuldet.

Donnerstag, November 08, 2007

Mini-Laptops

Seit über zwei Monaten sind Zimtsterne, Marzinpankugeln und all die vielen Weihnachtsleckereien in den Supermärkten zu haben. Mir ist es unergründlich, warum die Marktstrategen glauben, uns auf einer monatelangen "Freßspur" zum Fest führen zu müssen.

Allmählich erinnern auch die PC-Hersteller an das große Fest. Heute schon gewünscht? Ich bin vor zwei, drei Tagen auf den Eee PC von Asus gestoßen. Irgendwie macht mich das Ding an. Klein, portabel, WLAN, alle wichtigsten Anwendungen dabei, USB- und Beamer-Anschluss. Kleine Tastaturen stören mich nicht. Der Preis macht Appetit! Damit können sich auch viele Studierenden einen kleinen aber feinen Rechenzwerg leisten. (Zur Software-Entwicklung ist der Laptop sicher weniger geeignet und man muss sich vermutlich auf sehr einfache Werkzeuge beschränken.) Das Gerät wäre mir ein schöner Reisebegleiter. Die ersten Testberichte klingen auch gut, siehe z.B. bei heise mobil. Lieber noch hätte ich einen XO Laptop, der mir brillant konzipiert zu sein scheint und den ich allein deshalb gerne einmal genauer unter die Lupe nehmen möchte. Doch es wird vermutlich schwer sein, in Europa an solch ein Gerät zu kommen.

Nun bin ich gespannt, mit welchen Konkurrenzprodukten andere Hersteller im "Mini-Laptop-Segment" aufwarten werden. Denn noch hat's ja ein bissle Zeit mit dem Wünschen.

Update 19. Nov.: Wie spannend, die Preise für ähnliche Produke beginnen zu purzeln, siehe "VIA und FIC wollen beim EeePC-Preis mithalten" (heise news, 2007-11-18).

Donnerstag, November 01, 2007

Hey Django!

Wie lässt sich zügig eine webbasierte Anwendung entwickeln, die auf einer relationalen Datenbank aufsetzt?

Da ich gerade ein Projekt betreue, bei dem es genau auf diese beiden Punkte ankommt (webbasiert und datenbankgetrieben), gab ich mir selber einen Tag, um mir eine "moderne" Entwicklungsumgebung und ein "modernes" Framework anzuschauen. Der erste Kandidat: Zoho Creator; der zweite: Django.

Zoho ist eine Firma, die sich -- wie einige andere auch -- dem Nachbau von Desktop-Software auf rein webbasierter Basis widmet, meist ergänzt um Features zur Kollaboration. Darunter finden sich Nachbauten von Word und Excel, eine Projektmanagement-Software, ein Wiki. Meine Aufmerksamkeit erregte jedoch bereits vor einiger Zeit ZOHO Creator, eine vollständig browserbasierte Entwicklungsumgebung zum Bau von Datenbank-Anwendungen. Zoho wirbt mit einer kinderleichten Programmierung, die selbst Amateuren Erfolge bescheren soll.

Dieses Versprechen kann Zoho Creator nicht einhalten. Der Einstieg gelingt zwar schnell, aber ich verzweifelte schon an relativ einfachen Problemen. Die erzwangen das Verlassen der visuell-orientierten Programmierumgebung (die wirklich fein gemacht ist!). Der Wechsel ins "Free-flow Scripting" erwies sich aufgrund einer mageren Dokumentation als Frust- und weniger als Flow-Erlebnis. Nach drei Stunden gab ich auf.

Django reiht sich ein in die Schlange der Frameworks, die "Ruby on Rails" gleich eine ungekannte Leichtigkeit der Webprogrammierung proklamieren. Meine Wahl fiel auf Django, da ich eine exzellente Dokumentation vorfand und mit einer mir vertrauten Programmiersprache operieren wollte. Django läuft unter Python.

Der Einstieg quälte sich etwas dahin, da es eine Menge Lesematerial zu verdauen gilt -- die Intros sind sehr gut und aktuell. Ich wurde jedoch skeptisch, da ich vieles "fressen" musste ohne es zu verstehen. Dann, nach zwei Stunden, als mein Datenbankschema endlich stand, durfte ich die Vorzüge erfahren, die "late binding"-Programmiersprachen mit sich bringen: Änderungen am Code übernimmt der Webserver automatisch; man kann unmittelbar am Browser den Erfolg der Bemühungen austesten. Die Entwicklung wird flüssig, man hat permanentes Feedback. Nach etwas mehr als einem halben Tag hatte ich einen guten Teil des Projekts umgesetzt. Von Null! Das nenne ich "Flow-Scripting". Allerdings muss man sich mit Python auskennen, sonst steht man bei Fehlermeldungen etwas verloren da.

Interessant ist, dass man bei Django sehr deklarativ programmiert (wie auch bei Ruby on Rails). Man beschreibt, konfiguriert, hat funktional so gut wie keine Zeile programmiert und bekommt ein vollständiges Administrations-WebInterface "geschenkt". Ähnlich deskriptiv geht im Grunde auch Zoho Creator vor -- nur mangelt es dem Produkt entweder an Reife oder an Dokumentation.

Mein Resümee: Zoho Creator macht vor, wie man ausgezeichnete interaktive Oberflächen mit Ajax-Technologie entwickeln kann; da kann sich manch andere Firma ein Scheibchen von abschneiden. Frameworks wie Django oder "Ruby on Rails" zeigen, wie flüssig und leicht die Entwicklung von webbasierten Anwendungen von der Hand gehen kann. Das ist weniger eine Frage der IDE als vielmehr des Frameworks.