Die gefundenen L\u00f6sungen m\u00fcssen auf ihre Realit\u00e4tsn\u00e4he gepr\u00fcft werden. Dies beinhaltet selbstverst\u00e4ndlich, dass die modellierte L\u00f6sung auch wirklich funktioniert. Aber auch andere Aspekte sind wichtig: Wird der Nutzer die Software auch wirklich so nutzen, dass das Problem gel\u00f6st wird? Wird dies in angemessener Zeit m\u00f6glich sein? Sind hierf\u00fcr ausf\u00fchrliche Schulungen notwendig? Neben der Effektivit\u00e4t der L\u00f6sung ist somit auch immer ihre Effizienz in Bezug auf ihre Benutzbarkeit zu beachten.<\/li>\n<\/ol>\nUnser Vorgehen bei Tweedback<\/h2>\n
Die ersten drei Schritte macht jeder Software-Entwickler intuitiv richtig. Das Problem ist vor allem der vierte. Auch wir sind bei Tweedback sauber der Vorgabe gefolgt: Wir haben das Problem analysiert, modelliert und eine L\u00f6sung auf dem Modell erarbeitet.<\/p>\n
Wir haben uns bewusst gemacht, welche Probleme es in Vorlesungen gibt und detailliert beschrieben, welche Fragestellungen bei Studenten aufkommen. Anschlie\u00dfend haben wir die Dozenten betrachtet und uns mit dem Problem auseinandergesetzt, dass diese sich nicht auf Feedback-Bildschirme konzentrieren k\u00f6nnen, sondern Auf-einen-Blick-\u00dcbersichten ben\u00f6tigen.<\/p>\n
Das Problem mit dem vierten Schritt<\/h2>\n
Das Ergebnis war eine detaillierte Vorstellung von Nachrichten, die zwischen Studenten und Dozenten ausgetauscht werden m\u00fcssen. Diese gilt es nun ein- und auszugeben. Folglich versucht man m\u00f6glichst knappe und intuitive Darstellungsm\u00f6glichkeiten und Eingabemasken zu entwickeln.<\/p>\n
Was an sich nicht verwerflich klingt ist aber schnell falsch gemacht: Man baut auf sein eigenes Wissen um Programm- und Nachrichtenstruktur. Man kennt die einzelnen Funktionen des Programmes und bildet diese auf knapp bemessene Formulare ab. F\u00fcr die Direktevaluierung fragt man sich vor allem eines: W\u00fcrde ich Funktion x auf der Programmoberfl\u00e4che finden? Diese Frage unterstellt aber, dass der Nutzer um Funktion x wei\u00df. Dies ist aber vor allem am Anfang keineswegs der Fall.<\/p>\n
Nicht \u201eWie mache ich was?\u201c, sondern \u201eWas kann ich machen?\u201c<\/h3>\n
Und hier ist vor allem der vierte Schritt wichtig: Man muss sich bewusst werden, wer in welcher Situation mit der Oberfl\u00e4che arbeiten muss. Es geht darum zu erkennen, was ein Nutzer von einem Programm erwartet. Da er keinerlei Vorwissen \u00fcber interne Abl\u00e4ufe und Funktionen mitbringt, sucht der Nutzer auf der Oberfl\u00e4che nach M\u00f6glichkeiten, seine Erwartungen umzusetzen. Dabei gilt es ihn an die Hand zu nehmen und M\u00f6glichkeiten aufzuzeigen.<\/p>\n
Wir wussten um unsere Konzepte: Wir haben die Formulare zur Teilnahme an einer Veranstaltung und Erzeugung neuer Veranstaltungen nebeneinander gestellt. Wir wussten, wann welches zu nutzen ist. Die Frage, ob jeder Nutzer \u00fcberhaupt den Unterschied versteht, stellt man sich hingegen nicht mehr. Auch unsere n\u00e4chste Darstellung war f\u00fcr uns klar: Man kann bereits dargestellte R\u00fcckmeldungen anderer unterst\u00fctzen. Folglich sucht man diese M\u00f6glichkeit in der darstellenden Feedback-Wolke. Wei\u00df ein Nutzer allerdings nichts von dieser M\u00f6glichkeit, wird ihm diese auch verborgen bleiben.<\/p>\n
Erwischt man sich bei solchen Problemen, redet man sich schnell damit raus, dass es sich nur um einen Prototypen handele. Aber das versch\u00e4rft das Problem: Man gew\u00f6hnt sich an ein Konzept und h\u00e4lt es f\u00fcr selbstverst\u00e4ndlich. Bei der Implementierung m\u00f6chte man schnell und effizient arbeiten, man m\u00f6chte fertig werden. Daher ist es aber gerade so wichtig, dass eine effiziente Darstellung des Programms und seiner Funktionen m\u00f6glichst fr\u00fch zu durchdenken und zu implementieren. Es sind vor allem Details, die bei der Fertigstellung gerne mal vergessen werden.<\/p>\n