Windows Developer

Kolumne: Olis bunte Welt der IT

Tipps für ein gelungenes Softwaredesign: Der Wert von Erwartungen
Keine Kommentare

Entwickler und Anwender können verschiedene Vorstellungen von gutem Softwaredesign haben, dementsprechend flexibel sollte das Design gehalten werden. Was das praktisch bedeutet, erläutert er in dieser Ausgabe seiner Kolumne „Olis bunte Welt der IT“.

In den letzten Monaten habe ich mich mit Blazor beschäftigt, dem neuen Framework von Microsoft. Vielleicht heißt es heute auch Razor Components, wer weiß das schon so genau. Oder vielleicht heißt die eine Hälfte Razor Components und die andere Blazor? Es ist auch möglich, dass ein Teil davon oder auch beide beim Release von .NET Core 3 dabei sein darf oder dürfen. Mal sehen.

Microsoft ist nicht besonders gut darin, Erwartungen zu managen, wie man auf Neudeutsch sagt. Vor Kurzem sind endlich ein paar Blogposts publiziert worden, aus denen anscheinend die Strategie in Hinsicht auf Blazor hervorgeht. Ich sage „anscheinend“, weil es leider auch in der Vergangenheit schon ähnliche Blogposts gab, deren Inhalt sich später eben doch wieder als falsch herausstellte. Abwarten ist angesagt! Leider ist das nichts Neues. Vor vielen Jahren gab es vielversprechende Ansagen zu Silverlight und der DLR, bevor man sich für Version 1 eben doch allein auf die Konkurrenzsituation mit Flash einstellte und die DLR plötzlich irrelevant war. Ruby für die DLR? Ja, auch mal gehört …

Hoffentlich geht Blazor nicht den Weg von Silverlight. Ich denke nicht, dass es das tun wird, denn die Technologie ist erstens hinlänglich schwammig definiert und zweitens zum Teil auf der Basis von WebAssembly gebaut, also einer unabhängigen Plattform. Der Teil, der nicht auf WebAssembly basiert, läuft als höchst merkwürdiges architekturelles Konzept auf dem Server – man wird sehen, ob sich das in Anwendungskonzepten irgendwo gewinnbringend einbauen lässt. Den Teil mit WebAssembly finde ich durchaus interessant; ich habe dazu einige Trainingsvideos erzeugt, die Sie bei YouTube finden können.

An die Erwartungen denken

Nun soll es in diesem Artikel gar nicht weiter um Blazor gehen, und auch nicht spezifisch um Microsoft. Die Sache mit den Erwartungen liegt mir am Herzen! Wann immer wir etwas hören oder lesen, entwickeln unsere Köpfe automatisch Erwartungen. Zum Teil basieren diese direkt auf dem, was wir gehört oder gelesen haben. Zum anderen Teil jedoch werden Erwartungen impliziert, wir nehmen einfach an, dass die eigentliche Information oder Ankündigung nur Sinn macht, wenn gewisse andere Annahmen ebenfalls zutreffen. Wenn Sie wollen, lesen Sie noch einmal die Absätze oben und denken dabei über Erwartungen nach.

BASTA! Spring 2020

Dr. Holger Schwichtenberg

Von .NET Framework zu .NET Core migrieren oder nicht migrieren, das ist hier (nicht die einzige) Frage!

mit Dr. Holger Schwichtenberg (www.IT-Visions.de/5Minds IT-Solutions)

Rainer Stropek

C#-8- und .NET-Core-3-Workshop

mit Rainer Stropek (software architects/www.IT-Visions.de)

Adrienne Tacke

Azure Automation: The Good Parts

mit Adrienne Tacke (Adrienne Tacke)

Ich finde es bemerkenswert, wie das instinktive Verhalten, das wir Menschen an den Tag legen, wenn es um Erwartungen geht, gelernt oder beigebracht werden kann. Denken Sie einmal an das Stoppschild. Jeder Erwachsene weiß, dass man mit dem Auto, Motorrad oder gar Fahrrad an einem Stoppschild auf jeden Fall vollständig anhalten muss. Ich könnte qualifizieren „jeder Erwachsene mit einem Führerschein“, aber ich glaube tatsächlich, dass auch die meisten Menschen ohne Führerschein an dieser Grundweisheit teilhaben. Jeder kennt aus der Kneipe Anekdoten wie diese: „Stockduster war’s, drei Uhr morgens mitten in der Pampa, ich brems‘ am Stoppschild und bleib halt fast komplett stehen, und dieser Polizist springt plötzlich aus dem Gebüsch fünf Meter daneben und das war’s dann, Knöllchen und zwei Punkte!“

Was kann man daraus herleiten? Stoppschilder haben eine klare Bedeutung, stehen aber leider im wirklichen Leben fast immer ohne offensichtliche Erklärung da. Der Autofahrer erwartet, dass solche Schilder nur dort aufgestellt werden, wo es einen triftigen Grund dafür gibt. Man erwartet, Scharen von kleinen Kindern, alten Leuten oder wandernden Kröten zu sehen, wenn man korrekt am Stoppschild anhält und „eintausend, zweitausend“ zählt. Vielleicht sollte ich sagen „man erwartete als Führerscheinneuling“, denn leider ist es oft so, dass Stoppschilder missbraucht werden und an Stellen aufgestellt, wo es vielleicht für zwei Stunden am Tag gefährlich zugeht, aber bei Weitem nicht immer – oder gar einfach da, wo sich die Stadt großes Einkommen durch Strafgelder verspricht. Jeder junge Autofahrer macht diese Erfahrung und ist letztlich desillusioniert; das Vertrauen in die korrekte Verwendung des Brachialmechanismus Stoppschild ist gebrochen. Fortan macht man’s wie alle: Man simuliert das Anhalten je nach Verkehrslage und An- oder Abwesenheit sichtbarer Überwachung, und die Erwartung besteht im Weiteren hauptsächlich darin, irgendwann einmal wegen unzureichender Bremsmotivation straffällig zu werden.

Erwartungen an die Software

Zwischen diesen generellen Überlegungen zu Erwartungen und der Thematik der Softwareentwicklung gibt es zunächst einen ganz offensichtlichen Bezug. Dieser ist überall zu beobachten, wo Benutzerschnittstellen gebaut werden. Auch hierbei gilt es, Erwartungen von Benutzern zu verstehen und zu befriedigen. Dies sollte eigentlich offensichtlich sein, ist es aber angesichts alltäglicher Software anscheinend nicht. Dabei sind grundlegende Benutzererwartungen eigentlich sehr einfach: Wenn etwas auf dem Bildschirm mit der Maus angeklickt oder mit dem Finger angefasst wird, erwartet der Anwender umgehend eine Reaktion seitens der Software. Außerdem sollte ein Benutzer jederzeit den Eindruck haben, dass er weiß, was die Software gerade tut. Bereits diese beiden Grundanforderungen sind für manchen Entwickler ganz klar zu komplex. Aus persönlicher Erfahrung muss ich sagen: „Was macht der denn jetzt schon wieder?“ ist mein meistverwendeter Ausruf der Verzweiflung beim Umgang mit Allerweltssoftware – ob auf dem PC, im Web oder auf Mobilgeräten. Das Einfügen geeigneter Schimpfworte in Ihr gedankliches Bild überlasse ich Ihnen, denn Sie sind mit der Problematik bestimmt ebenso vertraut wie ich.

Hier ein praktischer Rat zu Softwarentwicklung und -tests: Bedienen Sie das eigene Werk einfach mal wie ein Endanwender. Schreiben Sie auf – oder zeichnen Sie auf Video auf –, was Ihnen dabei unangenehm erscheint, wo Sie eventuell länger als notwendig nachdenken mussten, um eine Funktion richtig zu nutzen. Noch besser: Beziehen Sie andere in diese Auswertungen mit ein, zwecks gnadenloser Objektivität. Dabei wird die resultierende Zusammenstellung von Kritikpunkten gewöhnlich sehr oberflächlich ausfallen. Das ist nicht schlimm, denn so arbeiten echte Anwender auch. Ich habe schon oft solche Listen geschrieben, für Kunden oder auch als Feedback für die Macher irgendeiner App auf meinem Telefon. Manchmal sieht das einfach so aus:

  1. Wenn ich einen Artikel anklicke, braucht die App meist ein paar Sekunden, um die Detailansicht zu öffnen. Leider kann ich erst dann den Zurückbutton klicken, wenn der Vorgang abgeschlossen ist. Die Ladezeit selbst dürfte gern beschleunigt werden, aber richtig unangenehm ist es, wenn ich versehentlich einen Artikel in der Liste selektiere und die Navigation nicht sofort abbrechen kann.
  2. Es kommt vor, dass das Scrollen in der Artikelliste stockt und die App für Sekunden gar nicht bedienbar ist.
  3. Mehrfach habe ich beobachtet, dass Artikel aus meiner Favoritenliste spurlos verschwunden sind.
  4. Es ist ebenfalls mehrfach vorgekommen, dass ein Artikel in meiner Favoritenliste gegen den automatisch gelieferten Ersatzartikel getauscht worden ist.

An den Ergebnissen solcher Analysen ist besonders interessant, wie unterschiedlich Anwender und Entwickler die einzelnen Punkte einschätzen könnten. Oberflächlich betrachtet handelt es sich bei allen Beispielpunkten um Beschreibungen von Fällen, wo eine Erwartung des Anwenders nicht erfüllt worden ist. Der Anwender erwartet, dass die App immer, und immer schnell, auf Interaktion reagiert. Er erwartet, dass irrtümliche Bedienung einfach und ohne Verzögerung korrigiert werden kann. Die Favoritenliste wird vom Anwender als persönlicher Datenspeicher gesehen und jegliche automatischen Änderungen sind unerwartet.

Ein funktionierender Undo-Button ist eine bessere Idee als eine Reihe von Sicherheitsabfragen!

Aus Entwicklersicht stellen sich die vier Punkte möglicherweise ganz anders dar. Punkt 1 ist sicherlich ein Mangel in der Benutzerführung; es könnte sein, dass dieses Szenario in der Planung nicht berücksichtigt wurde. Punkt 2 hingegen ist sicherlich ein Bug, der genauer analysiert werden muss, da ein technischer Grund nicht allein aus der Beschreibung abzulesen ist. Die Punkte 3 und 4 könnten womöglich darauf hinweisen, dass die App etwas durchaus Vorgesehenes tut, das aber für den Anwender unverständlich bleibt. Dieses Problem könnte zu beheben sein, indem in der Benutzerschnittstelle entsprechendes Feedback angezeigt und somit die Erwartungshaltung des Anwenders modifiziert wird.

Bessere Software für den Anwender

Ich glaube persönlich, dass wir alle wesentlich bessere Software bauen können, wenn wir mehr darauf achten, was der Anwender will. Wir könnten auf diese Weise auch bekannte Probleme lösen, die sich im Anwenderverhalten gebildet haben, ähnlich dem langsamen Durchfahren am Stoppschild. Zum Beispiel wissen wir alle, dass dem Klischee entsprechend die meisten Anwender Sicherheitsabfragen gewöhnlich ignorieren. Es gibt da anscheinend eine spezielle Synapse, die bei den Worten „Möchten Sie wirklich…“ sofort den Mausklick auf JA oder OK auslöst. Noch schneller geht lediglich die Bestätigung von Lizenzbedingungen oder EU-Cookie-Warnungen. Der Anwender nimmt sich nicht die Zeit, „Sind Sie sicher, dass ‚format c:‘ der Schritt der Wahl ist“ zu lesen, sondern vertraut der Abkürzung, die sein Hirn auf der Stelle anbietet: „Klicken Sie OK, um die Software weiter zu benutzen.“ Warum ist das so? Ganz einfach: Weil der Mechanismus des modalen Dialogs über derartig lange Zeit missbraucht worden ist, dass der Anwender keine Geduld mehr hat, ein echtes Verständnis für die gegebene Problematik zu entwickeln. Es gibt Software, die modale Dialoge wie diesen anzeigt: „Der Export ist fertig“; da brauchen wir uns über das wenig überlegte Anwenderverhalten nicht zu wundern.

Wenn wir nun einen Anwender fragen: „Sag mal, wie soll ich dir denn bitte eine Meldung anzeigen, die wirklich wichtig ist?“, dann wird der Anwender vermutlich vorschlagen, dass dies in einer Form geschehen sollte, die folgenden Regeln gehorcht:

  1. Die Meldung muss unübersehbar sein
  2. Die Meldung darf nicht gerade der noch wichtigeren Arbeit im Weg sein.
  3. Wenn die Meldung versehentlich weggeklickt oder falsch beantwortet wird, muss es möglich sein, etwaige unangenehme Konsequenzen wieder rückgängig zu machen.

Denken Sie da mal drüber nach … Ich habe das getan und bin zu der Ansicht gekommen, dass Punkt 3 eigentlich der wichtigste ist. Wenn ich davon ausgehe, dass dieser Punkt unumgänglich notwendig ist, komme ich zu einer neuen Frage: Wozu brauche ich eigentlich wichtige Meldungen in meiner Software? Was wollen wir denn den Anwender dauernd fragen? Kein Wunder, dass die meisten Meldungen im Anwenderhirn sofort in „Soll ich meine Arbeit tun?“ umgestellt werden! Ein funktionierender Undo-Button ist eine so viel bessere Idee als eine Reihe von Sicherheitsabfragen – wir wissen, wie man Undo-Buttons programmiert. Also los! Irgendwann dachte man vielleicht noch, dass das Löschen großer Datenmengen beim Undo eine Ausnahme rechtfertigen sollte – aber selbst das ist heute in den meisten Fällen eine haltlose Ausrede.

Nun gibt es zum Thema Erwartungen noch mehrere andere Perspektiven mit Bezug zur Softwareentwicklung. Ich schlage noch einmal die Brücke zu Blazor. Nachdem ich besagte Videos publiziert hatte, gab es dort Kommentare zur neuen Technologie. Diese waren sehr unterschiedlich, aber doch oft vorhersehbar: „Oh je, ein neues Silverlight“, „Super, alles in C# jetzt, ich hasse JavaScript“ oder auch „Kann ich das auch mit WebServices machen?“.

Da haben wir also den Skeptiker, der jeder neuen Microsoft-Idee pauschal abwehrend gegenübersteht. Dann den Verfechter der bekannten Theorie „Gestern war alles besser, Neuerungen sind Teufelswerk“ (auch bekannt als „nach Cobol die Sintflut“) und letztlich eine fehlerhafte Einordnung der neuen Technologie seitens des „Erst fragen, dann denken“-Pragmatikers. Wenn mein Tonfall in den letzten Sätzen abwertend klang, soll das als zusätzlicher Beweis dienen: Der Umgang mit Erwartungen ist schwierig! Manche Programmierer wollen gern dauernd was Neues, egal wie gut das Alte funktionierte; andere wollen dieselben Werkzeuge möglichst für immer verwenden. Ich selbst habe die Erwartung – oder zumindest die Hoffnung – dass der Wert der übergreifenden Perspektive jederzeit akzeptiert wird!

Fazit

Unterschätzen Sie nicht den Stellenwert von Erwartungen aufseiten Ihrer Anwender. Wenn Sie können, schreiben Sie Software genau entlang dieser Erwartungen und lassen Sie Ostereier die einzigen Überraschungen bei der Bedienung Ihrer Programme sein! Andererseits versuchen Sie selbst, sich in Flexibilität zu üben, als Anwender, und erst recht als Entwickler. Nur so können wir in Zukunft Software schreiben, die objektiv besser ist als die von gestern.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -