Welches Token ist das ’schnellste‘?

Wir programmieren ein Werkzeug für die Interaktion im Hörsaal.
Die Studierenden nutzen für die Teilnahme ihr Smartphone, iPad, NoteBook, etc.
Zur Identifikation wird bei jeder Vorlesung ein neues Token verwendet, welches der Dozent auf der Leinwand präsentiert und die Studierenden dann in ihr Gerät eintippen.
Aus Sicherheitsgründen soll das Token eine Variabilität von etwa 1 zu hundert Millionen besitzen.
Wir haben für das Token drei Möglicheiten zur Auswahl.
Bei allen drei Arten des Tokens haben wir spaces/Leerschläge zur besseren Visualisierung eingebaut, die aber nicht eingegeben werden müssen.
Gross-/Klein-Schreibung ist ebenfalls nicht relevant.

  1. 8 Ziffern:
    Beispiele: 746 495 37; 662 785 28; 968 367 76
  2. 6 Buchstaben:
    Beispiele: duj wjs, hpl qux, gie fvt
  3. 4 Silben (eine Silbe besteht jeweils aus je einem Zeichen der folgenden sets: ‚bcdfghjklmnpqrstvwxyz‘ und ‚aeiou‘):
    Beispiele: ma pe ci ko, zu ku pa wi, yu vo do mi

Wir möchten nun wissen, welches der drei Token von den Studierenden am schnellsten erfasst und im Gerät eingetippt werden kann.

 

Über Styleguides zu Rollen in der Softwareentwicklung

Erst gestern habe ich wieder den Satz gehört „dafür gibt es aber eh einen Styleguide“, was soviel heissen sollte wie „damit wird die Software schon bedienungsfreundlich werden“.
Sehr häufig wird geglaubt, dass ein Styleguide automatisch dafür sorgt, dass die Usability passt.
nun, dem ist nicht so. ein Styleguide sorgt ZUM TEIL für Usability, weil er für einheitlichen Look&Feel und für Konsistenz bei Details sorgt.
In einem Styleguide kann z.B. stehen wie Radiobuttons aussehen und Texteingabefelder funktionieren und all jene Dinge, die in allen Anwendungen gleich sind, wie z.B. ein Anwendungsrahmen, Regeln zum Fenstermanagement etc.

Was aber NICHT im Styleguide erfasst werden kann ist alles andere:

  • der Workflow des Users – bezogen auf die Reihenfolge von Bildschirmen und bezogen auf die Reihenfolge von Feldern oder Feldgruppen
  • welche Infos oder Felder der User zu welchem Zeitpunkt braucht
  • welche er gleichzeitig braucht
  • was er oft benötigt und was nur selten
  • das Wording
  • etc.
    D.h.: auch wenn man einen Styleguide hat, können dabei immer noch völlig unbrauchbare User Interfaces herauskommen.
    Was braucht man also dazu, damit ein gutes User Interface herauskommt?: am besten eine Trennung der Jobs „Usability Experte bzw. User Experience Designer“ und „Entwickler“.
    Beides gleichzeitig kann man IMHO nicht gut machen – Entwickler haben normalerweise schon genug damit zu tun, sich mit ihrer Entwicklungsumgebung herumzuschlagen und leben und denken in den Konzepten der Entwicklungsumgebung. Der Usability Experte dagegen sollte davon unabhängig sein und in den Konzepten und Workflows der User denken können. Klar soll er sich mit Softwareentwicklung auch auskennen, damit er nicht unrealisierbare Vorschläge macht. Irgendwie ist er auch der Vermittler zwischen den Usern und deren Anwendungsbereich und den Entwicklern.

    Benutzeroberfläche ausschlaggebend für Verkauf (Forrester)

    Laut einer Umfrage von Forrester Research zählt – wenig überraschend – die Benutzeroberfläche zu den ausschlaggebenden Faktoren für den Neukauf oder das Upgrade einer Geschäftssoftware.

    Zum Artikel

    Was ich so erlebe wird darunter aber meist nur eine Design-Behübschung verstanden.

    In den wenigsten Fällen wird getestet, WIE benutzerfreundlich, d.h.

    • leicht erlernbar und wiedererlernbar,
    • effizient,
    • workfloworientiert etc.

    eine Oberfläche wirklich ist. Mehr Info: So funktioniert bei uns (und bei den meisten Usability Engineers auf der Welt) ein Usability Test.

    Softwareentwicklungsprozesse sind immer anders ..

    In der Theorie gibt es schöne Vorstellungen von Softwareentwicklungsprozessen, in der Praxis werden diese sehr abwechslungsreich gelebt.

    Z.B. versteht unter einem Pflichtenheft jeder etwas anderes. In manchen Projekten gibt es ein Lastenheft und ein Pflichtenheft, in manchen nur eines davon, manchmal sind im Pflichtenheft schon fertige Screens drin, manchmal nicht.

    Unter einem User Requirements Dokument versteht auch wieder jeder etwas anderes. Usability Fachleute würden darin hauptsächlich die “Enduser” Anforderungen finden wollen, während in der reinen Softwareentwicklung der User hier eher als “Kunde” übersetzt wird. Das macht aber einen ziemlichen Unterschied, vor allem was die Benutzerfreundlichkeit des Endergebnisses betrifft.

    Oft fehlt schon bei der Erstellung des Pflichtenhefts ein klarer Prozess, der z.B. dazu führen sollte, dass nicht nur Wunschlisten gesammelt werden, sondern auch Prioritäten festgelegt werden.

    Aber das sind eben so Traumvorstellungen. Ich erlebe es ja auch selbst, dass Vorgangsweisen in der Softwareentwicklung überall anders sind.

    Gerade war ich in einem Projekt, in dem ein ehemaliger Enduser und ich gemeinsam das Pflichtenheft erstellt haben und wir hatten tatsächlich die Möglichkeit, auch andere Enduser einzubeziehen und mit Prototyp-Screens ganz frühe Usability Tests zu machen. Und weil Usability in dem Projekt groß geschrieben wird, wird der Abnahme-Test ebenfalls Usability Tests beinhalten. Klar, es war nicht alles so optimal, weil eigentlich sollte man ja mit MEHR Usern testen und das möglichst direkt am Arbeitsplatz – aber immerhin – besser als garnichts. Und so ist es ja oft, getreu dem alten Motto “besser wenig Usability als garkeine”. Und wenn man früh im Entwicklungsprozess mit Usability beginnt zählt die Investition ja auch doppelt und dreifach als wenn man zum Schluß noch versucht, Feuerwehr zu spielen.

    In einem anderen Projekt wiederum wurde überlegt, wie man im Unternehmen Usability Engineering etablieren und in den vorhandenen Entwicklungsprozeß integrieren kann. Das sehe ich dann eher in den größeren Unternehmen, die sich die Beschäftigung mit Prozessoptimierungen auch leisten können und wo nicht jeder im Tagesgeschäft untergeht. Bleibt dort nur zu hoffen, dass der neue Entwicklungsprozeß nicht als Papiertiger im Schrank verstaubt, sondern auch wirklich gelebt wird.
    Beide Projekte waren aber wieder mal ein sehr positiver Hinweis darauf, dass sich Usability Engineering weiter etabliert und tatsächlich passiert.