Entwicklung einer Software zum Interpretieren von Zeugnisnoten für Oberstufenschüler

Inhaltsverzeichnis

1. Einleitung
   1. Ziele dieser Arbeit
   2. Ähnliche Projekte
      1. Der Große Abirechner
      2. AbiGrade: Der neue Abiturrechner für Niedersachsen
   3. Vorgehen
2. Analyse
   1. Problem- und Aufgabenanalyse
      1. Hintergrundinformationen
      2. Kernproblem
      3. Aufgabenmodell
   2. Benutzeranalyse
      1. Unterschiede je nach Schulleistung
      2. Beratungspersonal
      3. Personas
   3. Kontextanalyse
      1. Technischer Kontext
      2. Sozialer Kontext
      3. Organisatorischer Kontext
   4. Use Cases
3. Konzeption
   1. Priorisierung der Features
   2. Benutzungsschnittstelle
      1. Anforderungen
      2. Bestandteile und Aufbau
   3. Papierprototypen-Tests
      1. Ergebnisse
   4. Systemarchitektur
      1. Events in JavaScript
      2. Abstraktion der Berechnungsregeln
   5. Name der Anwendung
4. Realisierung
   1. Technische Umsetzung
      1. Nutzungsschnittstelle
      2. Persistierung
   2. Entwurfsentscheidungen
      1. Visueller Minimalismus
      2. Kurze oder lange Fachbezeichnungen
      3. Gestaltung der Auswahlmenüs
   3. Rückblick auf die Feature-Liste
   4. Nutzerfeedback während der Umsetzung
5. Dialogbeispiele
6. Evaluation
   1. Evaluation anhand von Kriterien der Dialoggestaltung
   2. Evaluation anhand der Personas
7. Zusammenfassung und Ausblick
   1. Zusammenfassung
   2. Offene Punkte
   3. Ausblick

• Literatur
• Anhang

1. Vorgespräch Oberstufenkoordinator
2. Online-Umfrage
   1. Fragebogen
   2. Statistische Daten
   3. Rohdaten
3. Papierprototypen
   1. Skizzen
   2. Prototypen
      1. PC-Prototyp
      2. Mobil-Prototyp
   3. Szenario
   4. Testprotokolle

Dieses Werk steht unter der Creative Commons Attribution Share-Alike 4.0 Lizenz. Das bedeutet, dass es mit wenigen Einschränkungen kopiert, verteilt und für jegliche Zwecke genutzt werden darf, solange der Name des Autors (Julian Fietkau) als Urheber genannt wird und auf diesem Werk aufbauende Arbeiten unter der gleichen Lizenz veröffentlicht werden. Von der CC-Lizenz ausgenommen sind die Abbildungen 1 und 2, bei denen es sich um Zitate nach § 51 Abs. 1 UrhG handelt. Weitere Infos:

Zusammenfassung

Gegen Ende der Schullaufbahn stellt sich bei vielen Schülern verstärkt das Bewusstsein ein, dass die Zeugnisnoten (insbesondere der Abiturschnitt) einen starken Einfluss auf ihre Karrieremöglichkeiten haben. Die Gesetze und Regeln, nach denen die Punktzahlen miteinander verrechnet werden, sind jedoch komplex und für viele Schüler undurchsichtig. Insbesondere ist es schwierig, bei einem noch nicht abgeschlossenen Abitur die bereits vorhandenen Noten zu interpretieren und mögliche Probleme frühzeitig zu erkennen.

Im Rahmen dieser Bachelorarbeit wird zur Unterstützung der Beratung an einer ausgewählten Schule ein System umgesetzt, das den Schülern bei dieser Aufgabe unter die Arme greift. Aus partiell vorliegenden Noten werden möglichst viele relevante Informationen gewonnen, aufbereitet und den Schülern dargestellt. Für diese Aufgabe findet ein Entwicklungsprozess gemäß User Centered Design statt.

Stichwörter: User Centered Design, mobile Interfaces, Schulen, Schüler

Abstract

During the final years at the gymnasium – Germany’s highest tier of secondary education – many students become increasingly aware of the extent that their grades (particularly the final Abitur grade) influence their career opportunities. Unfortunately, the laws and regulations concerning the aggregation of all the different grades are complex, sometimes even prohibitively opaque. In particular, it is difficult to interpret the existing grades and detect potential problems while the Abitur is still in progress.

In this bachelor’s thesis, an effort is made to support the student consultation at one German school by implementing a system that is capable of assisting students with this task. Relevant information is drawn from partially available grades, processed and presented to the students. To that end, a development process in accordance with User Centered Design takes place.

Keywords: User Centered Design, mobile interfaces, schools, students

1. Einleitung

Der organisatorische Ablauf der gymnasialen Oberstufe in Niedersachsen ist durch rechtliche Rahmenbedingungen grob strukturiert und durch das Unterrichtsangebot der jeweiligen Schule ausgestaltet. Die Schülerinnen1 belegen über vier Halbjahre eine gewisse Anzahl benoteter Kurse, aus denen sich am Ende zusammen mit den Abiturprüfungen die Abiturnote ergibt.

Gerade im letzten Teil der Schulzeit bildet sich bei vielen von ihnen ein verstärktes Bewusstsein für die Relevanz ihrer schulischen Leistung für ihre zukünftige Laufbahn. Die Kriterien zur Berechnung der Abiturnote sind jedoch sehr komplex. Deshalb bietet das Gymnasium Johanneum in Lüneburg eine Beratung an. Typische dort besprochene Fragen sind etwa folgender Art:

• Ich habe drei von vier Halbjahren abgeschlossen. Was wäre meine Abiturnote auf der Grundlage der bisherigen Leistung, und was ist die beste noch erreichbare Note? Wie stehen meine Chancen, an meiner Wunsch-Uni (NC: 1,6) zugelassen zu werden?
• Ich bin schon durch zwei Kurse gefallen. Worauf muss ich achten, um nicht meine Zulassung zum Abitur zu verpassen? Erfülle ich bereits die Kriterien der Fachhochschulreife?

Die Beratung erfolgt durch den Oberstufenkoordinator, der in den betreffenden Sachzusammenhängen geschult ist. Weil der Aufwand dieser Betreuung hoch ist und der Betreuer noch zahlreiche andere Aufgaben hat, ist die Motivation auf Seiten der Schule groß, Teile der Beratung durch ein technisches System zu unterstützen und zu automatisieren. Weiterhin besteht die Hoffnung, dass damit Schülerinnen zur Selbstreflexion und -organisation angeregt werden können, die die Beratung vor Ort nicht nutzen, etwa weil sie ihre persönliche Situation nicht dem Schulpersonal offenlegen möchten.

Für den Autor dieser Arbeit ergibt sich dadurch die Chance, ein gebrauchstaugliches interaktives System mit überschaubarem Funktionsumfang zu entwerfen, zu testen und zu entwickeln.

1.1. Ziele dieser Arbeit

Vorrangiges Ziel der Arbeit ist die Konzeption und Entwicklung eines Systems zur Beratung von Oberstufenschülerinnen auf Basis ihrer bisherigen Noten. Die Schülerinnen sollen ihre bisher vorliegenden Zeugnisnoten eintragen können, und das System soll diese interpretieren und relevante Hinweise geben. Diese können z.B. sein: aktueller Notenschnitt, best- und schlechtestmögliche Abiturnote, Fachhochschulreife bzw. Abiturzulassung bereits erlangt/noch erreichbar/nicht mehr erreichbar.

Der Einsatzkontext des Systems ist einerseits die Beratung der Schülerinnen durch Schulpersonal vor Ort, andererseits aber auch die Nutzung durch Schülerinnen in Eigeninitiative. In der Beratung werden die nötigen Berechnungen und Schlussfolgerungen bisher jedes Mal von Hand durchgeführt, so dass die Anwendung zu effizienterer Abwicklung und Reduktion von Fehlern führen kann. Die selbständige Nutzung ohne Anleitung kann hoffentlich die Bereitschaft zur Selbstreflexion steigern, indem die Hemmschwelle der persönlichen Beratung nicht länger den ersten Schritt verhindert.

1.2. Ähnliche Projekte

Die Idee, die Berechnung der Abiturnote zu automatisieren, ist nicht neu. Es existieren diverse Webseiten und Tools, die ebenfalls versuchen, dieses Problem zu lösen. Leider sind viele davon veraltet und nicht an die aktuell gültigen Regeln angepasst. Durch die regionale Begrenztheit des Marktes, der sich auf das Land Niedersachsen beschränkt, gibt es keine Produkte von namhaften Herstellern. Stattdessen handelt es sich fast ausschließlich um Hobbyprojekte von einzelnen Entwicklern, die mitunter selbst noch im Schulalter sind. Auffällig aber bei näherer Betrachtung nicht überraschend ist, dass alle untersuchten Produkte kostenfrei verfügbar sind.

Es gibt zu dieser Produktklasse dementsprechend auch keine Marktanalysen oder Untersuchungen zur Bekanntheit verschiedener Produkte, weshalb eine Einschätzung der Bekanntheit nicht empirisch untermauert werden kann. Trotzdem werden in diesem Abschnitt zwei konkrete Angebote genauer beschrieben, welche subjektiv betrachtet recht schnell und häufig genannt werden, wenn man nach einem Abiturnoten-Rechner sucht.

1.2.1. Der Große Abirechner

Der Große Abirechner wurde bzw. wird von Ulrich Große entwickelt und steht auf dessen Webseite (Große, 2004–2014) zum Download bereit (vgl. Abbildung 1).

Diese Implementation liegt als Datei im Microsoft Excel-Format vor. Damit ist der Rechner auf allen Plattformen lauffähig, auf denen Excel verfügbar ist, womit die meisten PCs abgedeckt sind. Die Unterstützung von Tabellenkalkulationen auf Mobilgeräten ist bisher nur unzureichend und die Nutzungsschnittstelle dieses Rechners ist nicht auf Touch-Bedienung oder kleine Bildschirme ausgelegt, somit ist eine nutzergerechte Handhabung des Rechners auf einem mobilen Gerät derzeit nicht möglich.

Das Tool beachtet Belegungsverpflichtungen und weist auf Mindestpunktzahlen hin. Optional werden auch die Mindestwochenstunden überprüft. Mit unvollständigen Daten kann es nur begrenzt umgehen: Liegen einige Noten noch nicht vor, muss die Nutzerin entweder plausible Werte erfinden oder überall die Mindestpunktzahl eingeben, wobei dadurch in beiden Fällen jeweils unterschiedliche Verfälschungen im Ergebnis entstehen.

Die Ergebnisse können mit der Speicherfunktion von Excel gesichert werden. Eine nachträgliche Anpassung ist nur eingeschränkt möglich. Das Tool bringt dazu den Hinweis an, im Zweifel lieber mit einer neuen Kopie des leeren Formulars von vorne zu beginnen.

Der Große Abirechner beherrscht in der aktuellen Version die Berechnungsregeln für das Abitur in Niedersachsen seit der Abitur-Reform 2011. Es steht ein Regelsatz für die Regelungen bis einschließlich 2013 und einer für die ab 2014 zur Verfügung.

Abbildung 1: Gesamtansicht des Excel-basierten Tools „Der Große Abirechner“ (Große, 2004–2014). Zu sehen sind ein Eingabeblock für persönliche Daten, für Fächerwahl sowie Zeugnisnoten, eine Zwischenzusammenfassung, ein weiterer Block für Prüfungsnoten sowie eine Gesamtzusammenfassung und rechts im Bild einige tabellarische Hintergrundinformationen.

1.2.2. AbiGrade: Der neue Abiturrechner für Niedersachsen

Unter dem Namen AbiGrade wurde 2009 eine weitere Anwendung zur Berechnung der Abiturnote in Niedersachsen veröffentlicht (vgl. Abbildung 2). Die dazugehörige Webseite ist inzwischen nicht mehr verfügbar (Autor unbekannt, 2009–2010), AbiGrade kann jedoch weiterhin an diversen Stellen im Web gefunden und heruntergeladen werden. Leider ist zu der Anwendung kein Autor namentlich genannt. In Anbetracht der nicht mehr vorhandenen Webseite und der alten Programmversion liegt der Schluss nahe, dass das Projekt inzwischen verwaist ist und nicht mehr gepflegt wird.

AbiGrade basiert auf dem .NET-Framework von Microsoft und ist damit unter allen modernen Versionen von Microsoft Windows lauffähig, abgesehen von den Versionen für Smartphones und einige Tablets. Eine Nutzung auf mobilen Geräten ist nicht vorgesehen. Jedoch ist die Schnittstelle visuell und interaktiv so gestaltet, dass eine Umsetzung in ähnlicher Form auf modernen Tablets wohl durchaus nutzergerecht möglich gewesen wäre, wenn die unterliegenden Technologien durch Alternativen ausgetauscht würden, welche die Verwendung von mobilen Geräten erlauben.

In AbiGrade gibt es zwei Hauptansichten: eine Eingabemaske für alle Zeugnisnoten der Oberstufe sowie die Prüfungsnoten, auf der auch gleich die wichtigsten Ergebnisse angezeigt werden, und einer zweiten Ansicht mit einer großen Umrechnungstabelle für Abiturnoten sowie eine Möglichkeit zur Berechnung der noch zu erbringenden Punktzahl für eine Wunsch-Abiturnote.

Das Tool bietet eine Speicherfunktion, welche allerdings lediglich einen Screenshot des Programms und der Rechenergebnisse erzeugt und als Grafik abspeichert. Eine nachträgliche Veränderung oder Ergänzung von gespeicherten Daten ist nicht möglich. Die Anwendung beherrscht lediglich die 2010 noch gültigen Regelungen für die gymnasiale Oberstufe, so ist z.B. noch eine Schulzeit von 13 Jahren vorgesehen und das Punktesystem funktioniert anders. Damit hat AbiGrade für den heute relevanten Nutzerkreis faktisch keinen Wert mehr.

Abbildung 2: Die zwei Hauptansichten der Anwendung „AbiGrade“ (Autor unbekannt, 2009–2010). (a) In der Standardansicht werden sämtliche Noten eingetragen und das Gesamtergebnis angezeigt. (b) In der zweiten Ansicht ist eine Umrechnungstabelle für Zeugnispunkte und Abiturnoten aufgeführt. Außerdem gibt es dort die Möglichkeit, zu einer Wunschnote die noch fehlenden Punkte auszurechnen.

1.3. Vorgehen

Für die Konzeption der Anwendung wird ein Prozess gewählt, der an User Centered Design (Norman & Draper, 1986) angelehnt ist. Dabei werden die späteren Nutzer in den Gestaltungsprozess frühzeitig empirisch eingebunden, damit gewährleistet ist, dass die fertige Anwendung tatsächlich nützlich ist und den realen Anforderungen entspricht.

Zur Organisation der konstruktiven Umsetzung des Systems wird eine schlanke Variante des Feature Driven Development (Palmer & Felsing, 2002) genutzt, in deren Zentrum die Orientierung an und Priorisierung von einzelnen Funktionalitäten (statt z.B. Architekturbausteinen) steht. Auch dies soll die Konzentration auf die Perspektive der Nutzer erleichtern und dazu führen, dass zügig Programmversionen entstehen, die ausprobiert und eingesetzt werden können.

Die beiden Vorgehensmodelle lassen sich sehr gut miteinander zu einem Gesamtmodell (vgl. Abbildung 3) kombinieren.

Abbildung 3: Dieses Vorgehensmodell verbindet Schritte aus UCD und FDD miteinander und stellt den organisatorischen Ablauf des Projekts dar. Die Darstellung ist angelehnt an Roenspieß (2009, S. 20).

Der erste Schritt ist eine empirische Erhebung per Online-Fragebogen, um die technischen Voraussetzungen bei den Schülern zu klären (z.B. wie viele Schüler tatsächlich im Alltag mit Smartphones umgehen, wie viele mit Desktop-Rechnern etc.) und Anforderungen an den Funktionsumfang zu ermitteln. Dies dient der Benutzer- und Kontextanalyse des UCD, deren Ziel es ist, ein realitätsnahes Bild sowohl von den Wünschen und Arbeitsgewohnheiten des Nutzerkreises als auch vom organisatorischen und technischen Kontext zu gewinnen. Diese empirischen Ergebnisse dienen gemeinsam mit den Erkenntnissen aus einem persönlichen Gespräch mit dem Oberstufenkoordinator als Grundlage zur Erstellung mehrerer Personas in Anlehnung an Cooper (1999).

Danach wird eine Planung für den Funktionsumfang des Systems durchgeführt. Ein Gesamtmodell und eine Feature-Liste werden entwickelt, die Features werden priorisiert. Diese Schritte gehören zum FDD. Aufbauend auf den empirischen Erkenntnissen wird ein Plan für die zeitliche Struktur der Entwicklung erstellt. Ausgehend vom Gesamtmodell und der Feature-Liste kann die Nutzungsschnittstelle konzipiert werden.

Die Schnittstelle des Systems soll dann zunächst prototypisch entworfen und im Gespräch mit einzelnen Schülerinnen der relevanten Altersgruppe auf ihre Eignung getestet werden. Dies geschieht mit Hilfe eines Papierprototypen und ist wiederum Bestandteil des UCD.

Nach Auswertung dieser Tests soll die Anwendung iterativ umgesetzt werden, wobei die Programmierung der Berechnungslogik durchaus bereits beginnen kann, bevor die Nutzertests für die Schnittstelle abgeschlossen sind. Generell geschieht die Orientierung jedoch anhand der priorisierten Feature-Liste gemäß FDD.

Wenn einige Features einsatzfähig sind, kann Feedback von einzelnen Nutzerinnen eingeholt werden. Dies geschieht jedoch anders als die Prototypen-Tests nicht mehr in einem örtlich festgelegten Rahmen, sondern durch asynchrone Kommunikation (z.B. E-Mail).

Ein ausführlicher Praxistest einschließlich empirischer Evaluation wäre nach Abschluss der Implementation sinnvoll, wird jedoch aus zeitlichen Gründen innerhalb dieser Abschlussarbeit nicht angestrebt.

In Kapitel 2 wird eine ausführliche Anforderungsanalyse beschrieben, in deren Rahmen die fachlichen Aufgaben sowie die Zielgruppe und der Nutzungskontext explizit untersucht werden. Im darauf folgenden Kapitel wird der Entwurf und die Planung für die Realisierung der Anwendung vorgestellt. In Kapitel 4 wird das erstellte System beschrieben und danach in Kapitel 5 mit Hilfe einer Reihe grafischer Dialogbeispielen aus der Anwendung veranschaulicht. Kapitel 6 beinhaltet eine kurze Evaluation, bei der auf die Ergebnisse der vorigen Kapitel zurückgegriffen wird. Schließlich wird in Kapitel 7 eine Zusammenfassung der Arbeit einschließlich offener Punkte gegeben und ein Ausblick auf mögliches Entwicklungspotenzial gewagt.

1: Aus Gründen der besseren Lesbarkeit wird in diesem Text auf die gleichzeitige Verwendung männlicher und weiblicher Sprachformen verzichtet; in der Regel wird die weibliche Schreibweise verwendet. Sämtliche Personenbezeichnungen gelten grundsätzlich für Personen jedweden Geschlechts.

2. Analyse

Damit die Konzeption des Systems den real vorhandenen Anforderungen möglichst genau entspricht, müssen eine Reihe von Analysen durchgeführt werden.

Eine Analyse des Grundproblems und der sich daraus ergebenden Aufgaben bildet die Grundlage für die Festlegung der Funktionalität der Anwendung. Die Personen, die später von ihr profitieren sollen, werden im darauf folgenden Abschnitt genau analysiert und es werden Personas (Cooper, 1999) erstellt, die ihre Anforderungen geeignet zusammenfassen. In Abschnitt 2.3 werden die Einbettung in den sozialen und organisatorischen Kontext sowie die technischen Rahmenbedingungen beschrieben. Schließlich wird eine Reihe von Use Cases beschrieben, die darstellen, welche Aufgaben mit der Anwendung erfüllbar sein sollen.

Die Ergebnisse dieses Kapitels basieren auf zwei zentralen Quellen. Ein Vorgespräch mit dem Oberstufenkoordinator (siehe Anhang A) brachte einen ersten Einblick in die Problemstellung und lieferte Erfahrungen aus der Sicht des Beraters. Eine Online-Umfrage unter Schülern des Johanneums (detailliert wiedergegeben in Anhang B) diente der Erkenntnisgewinnung über die Vorstellungen und Wünsche der Schülerinnen, über ihre fachlich relevanten Gewohnheiten und Eigenschaften sowie über ihre Nutzungsgewohnheiten hinsichtlich PCs und Smartphones. Die Umfrage wurde gegenwärtigen und ehemaligen Oberstufenschülerinnen und -schülern des Johanneums zugänglich gemacht, von denen insgesamt 26 sie vollständig beantwortet haben. Die verschiedenen Ergebnisse dieser Umfrage finden sich in allen Analysekategorien dieses Kapitels wieder.

2.1. Problem- und Aufgabenanalyse

In diesem Abschnitt wird die Grundproblematik erarbeitet, bei der die Anwendung Unterstützung leisten soll. Dazu sind zunächst relevante Hintergrundinformationen zusammengetragen. Weiterhin wird dargestellt, welchen Stellenwert die relevanten Aufgaben für die beteiligten Akteure haben und welche Ziele sie damit verfolgen (die Benutzeranalyse wird dann in Abschnitt 2.2 detaillierter beschrieben). Aus dem fachlichen Grundproblem wird ein schematisches Aufgabenmodell extrahiert, das als wichtigster Anhaltspunkt für die Struktur der Programmabläufe in der fertigen Anwendung dient.

2.1.1. Hintergrundinformationen

Das Schulsystem wird am Beispiel des Johanneums beschrieben, die Gesetze und Rahmenbedingungen gelten jedoch in der Regel auch für andere Schulen in Niedersachsen. Die detaillierten rechtlichen Rahmenbedingungen sind in der Verordnung über die gymnasiale Oberstufe (Niedersächsisches Kultusministerium, 2011) dargestellt.

Ein Abiturjahrgang am Johanneum Lüneburg umfasst ca. 80–100 Personen. Die meis- ten von ihnen besuchen das Johanneum seit der fünften Klasse, einige wechseln auch von einer anderen Schule dorthin. In den allermeisten Fällen wird die Oberstufe – also die 11. und 12. Klasse, nach dem G8-Modell – komplett am Johanneum absolviert, da thematische und organisatorische Zusammenhänge einen Schulwechsel innerhalb dieser Phase sehr schwierig gestalten.

Die Oberstufe besteht aus vier Halbjahren, die oft mit 11-1, 11-2, 12-1 und 12-2 gekennzeichnet werden. In jedem Halbjahr werden Kurse belegt, wobei ein Kurs einem Schulfach entspricht. Zu Beginn der Oberstufe werden fünf Prüfungsfächer gewählt. Drei davon sind vierstündige Kurse (d.h. vier Schulstunden pro Woche) auf erhöhtem Niveau (entspricht in etwa den früheren Leistungskursen), die zwei weiteren sind vierstündi- ge Kurse auf grundlegendem Niveau. Diese fünf Prüfungsfächer werden mit P1 bis P5 abgekürzt. Die fünf Prüfungsfächer bleiben i.d.R. für die gesamte Oberstufe konstant. Die Abiturprüfungen am Ende der 12. Klasse finden in diesen fünf Fächern statt. Ei- ne bestimmte Menge erfolgreich abgeschlossener Kurse bescheinigt die sog. Fachhoch- schulreife, eine weitere, größere Menge erlaubt die Zulassung zu den Abiturprüfungen („Abiturzulassung“).

Zusätzlich zu den Prüfungsfächern werden diverse weitere Kurse belegt, die zumeist zweistündig durchgeführt werden. Weiterhin gibt es ein Seminarfach, welches durch sei- nen Fokus auf wissenschaftliche Methodenkompetenz einen Sonderstatus innehat. Die Wahl der Prüfungsfächer und der restlichen Kurse erfolgt nicht völlig frei, sondern ist an eine große Menge Regeln und Einschränkungen gebunden, die eine ausgewogene All- gemeinbildung sichern sollen. So gibt es für die Wahl der Prüfungsfächer vorgefertigte Schwerpunkte, die z.B. dafür sorgen, dass sowohl Deutsch als auch Mathematik aus- nahmslos durchgehend belegt werden.

Am Ende jedes Halbjahres bekommt die Schülerin für jeden Kurs eine Note auf einer Skala von 0 bis 15 Punkten, welche sich in Schulnoten umrechnen lassen (vgl. Tabelle 1). Mit einer Punktzahl von 5 oder mehr ist ein Kurs bzw. eine Prüfung bestanden, bei 4 Punkten oder weniger ist man durchgefallen, was für Abiturprüfungen genau so gilt wie für ganze Kurse und einzelne Klausuren. Im Fall eines Kurses, der mit weniger als 5 Punkten abgeschlossen wird, spricht man auch von einem Unterkurs.

Unmittelbar nach dem vierten Halbjahr finden die Abiturprüfungen in den fünf Prü- fungsfächern statt, welche gesondert mit je einer Note versehen werden.

Die Abiturnote ergibt sich aus den Zeugnisnoten aller vier Halbjahre und den fünf Prüfungsnoten. Die Punktzahlen werden zunächst gewichtet und addiert, danach wird die resultierende Gesamtpunktzahl gemäß eines Notenschlüssels in die endgültige Abi- turnote umgerechnet.

2.1.2. Kernproblem

Die endgültige Abiturnote steht erst nach Abschluss der letzten Prüfung fest. Dennoch ist bereits lange vorher interessant, welche Schlüsse sich aus den bereits vorhandenen Prüfungs- und Zeugnisnoten ziehen lassen. Die Berechnung des Notendurchschnitts auf Basis eines Halbjahreszeugnisses ist beispielsweise sehr verbreitet (vgl. Tabelle 11). Theoretisch könnte der Einfluss von teilweise vorhandenen Zeugnisnoten (z.B. nur die der ersten zwei Halbjahre) auf die zukünftige Abiturnote analysiert werden. Aufgrund der Komplexität der involvierten Verordnungen ist dies jedoch von Hand kaum zu bewerkstelligen.

Ein naheliegender Anwendungsfall ist der Ziel-Abiturschnitt. Manche Schülerinnen möchten bspw. an das Abitur ein Hochschulstudium anschließen und müssen dafür einen bestimmten Numerus clausus erreichen (vgl. Tabellen 15–17). Mit geeigneter technischer Unterstützung wäre feststellbar, ob das Ziel mit den bisher vorhandenen Noten noch erreichbar ist.

Dies ist nur eine von vielen Situationen, in denen aus teilweise vorhandenen Noten relevante Informationen gewonnen werden könnten. Weitere werden in Abschnitt 2.4 ausführlich beschrieben. Der einzige große Hinderungsgrund ist die Komplexität der Rechenvorschriften. An diesem Punkt soll die technische Unterstützung ansetzen. In die Anwendung soll eine unvollständige Menge an vorhandenen Noten eingegeben werden können, aus welcher dann automatisiert möglichst viele nützliche Informationen in Form von Kennzahlen (z.B. beste erreichbare Endnote) sowie auch textuellen Hinweisen (z.B. Hinweis auf kritische Kurse, welche unbedingt bestanden werden müssen) extrahiert werden sollen.

2.1.3. Aufgabenmodell

Abgesehen davon, dass das fachliche Kernproblem gelöst wird, soll die Anwendung auch nutzergerecht gestaltet sein. Neben der visuellen Gestaltung und der Umsetzung der Interaktion spielt hierbei auch die Frage der Persistierung eine wichtige Rolle: Wenn die Daten nicht bei jeder Anwendung komplett neu eingegeben werden sollen, müssen die eingegebenen Noten speicherbar sein. Dies sollte jedoch nur in Kontexten geschehen, in denen ein solches Verhalten auch erwünscht ist, z.B. auf dem Smartphone einer Schülerin, jedoch nicht auf dem PC des Beraters, der ständig wechselnde Einzelfälle analysieren und dabei nicht mit dem Datenschutz in Konflikt kommen möchte.

Die Interaktion mit dem System ist im Wesentlichen immer gleich: Es werden vorliegende Zeugnis- und Prüfungsnoten eingetragen und das Ergebnis der Analyse wird zur Kenntnis genommen. Je nach Intention können unterschiedliche Teilergebnisse für die Nutzerin relevant sein. Das Ziel ist, aus den vorliegenden Noten möglichst viele Erkenntnisse zu extrahieren und zu präsentieren.

Ausgehend von dieser allgemeinen Vorstellung und den Erkenntnissen aus dem Vorgespräch (vgl. Anhang A) wurde ein Feature-Brainstorming durchgeführt. Die dabei entstandene Liste möglicher Features bildet die Grundlage für die spätere Empirie (vgl. Tabellen 20–27):

• Berechnung der aktuellen Durchschnittsnote
• Berechnung der besten noch erreichbaren Abiturnote
• Berechnung der schlechtesten noch erreichbaren Abiturnote
• Hinweis auf Erreichung der Abiturzulassung
• Hinweis auf Erreichung der Fachhochschulreife
• Hinweis auf verpflichtende Kursbelegungen
• Hinweis auf kritische Kurse, die unbedingt bestanden werden müssen
• Überwachung der Einhaltung der Mindestwochenstunden

Alle diese möglichen Features sind auf Basis der Verordnungen theoretisch umsetzbar. Im folgenden Abschnitt wird eine ausführliche Analyse der verschiedenen Nutzergruppen beschrieben, die zur weiteren Erläuterung und Strukturierung möglicher Features führen und dieses erste Feature-Brainstorming genauer ordnen wird.

2.2. Benutzeranalyse

Der potenzielle Nutzerkreis für die Anwendung umfasst alle Schülerinnen und Schüler der gymnasialen Oberstufe in Niedersachsen. Die Empirie ist jedoch konkret auf das Johanneum Lüneburg beschränkt, weshalb eine starke Fokussierung auf die dortigen Umstände und Personen stattfindet und andere niedersächsische Gymnasien in dieser Arbeit weitgehend unberücksichtigt bleiben.

Aus dem Vorgespräch mit dem Oberstufenkoordinator (vgl. Anhang A), der aktuell für die Beratung der Oberstufenschülerinnen und -schüler verantwortlich ist, gingen einige Hypothesen über den Nutzerkreis hervor.

Zwar sind viele Oberstufenschülerinnen interessiert an Reflexionsmöglichkeiten und Leistungseinschätzungen wie z.B. ihrem Notendurchschnitt, dies gilt jedoch nicht für alle – manche haben schlicht keinen Bedarf oder kein Interesse. Im Rahmen dieses Projektes war es nicht sinnvoll, diese Schülerinnen in die Zielgruppe aufzunehmen, da die Anwendung für sie nicht relevant ist. Das Ziel ist nicht eine möglichst weite Verbreitung der Anwendung, sondern die bestmögliche Unterstützung derer, die sich Unterstützung wünschen.

Hinsichtlich der Verwendung moderner Technik gibt es in dieser Zielgruppe kaum Probleme. Bei der Online-Umfrage gaben von den 26 Teilnehmenden nur jeweils zwei an, keinen PC bzw. kein Smartphone zu besitzen (wobei der Begriff „Besitz“ im Fragebogen bewusst eher weit gefasst wurde, vgl. Anhang B.1); alle anderen gaben an, sowohl einen PC als auch ein Smartphone zu besitzen. Dabei ist zu bedenken, dass die Umfragemethode evtl. in dieser Hinsicht die Stichprobe verfälscht haben könnte, da versierte Nutzerinnen von Computern und Smartphones ggf. eher bereit sind, an einer Online-Umfrage teilzunehmen. Die Anzahlen der PC- und Smartphone-Besitzer in der Stichprobe sind in Abbildung 4 dargestellt.

Abbildung 4: In diesem Venn-Diagramm ist dargestellt, wie viele Schülerinnen und Schüler in der Umfrage angegeben haben, einen PC bzw. ein Smartphone zu besitzen.

Es liegt nahe, dass die Feature-Anforderungen sich im Laufe der Zeit wandeln. Die Frage nach kritischen Kursen und Belegungsverpflichtungen ist höchstens so lange interessant, wie es noch Wahl- und Wechselmöglichkeiten gibt oder noch die Gefahr des Nichtbestehens gegeben ist. Stehen die Abiturprüfungen unmittelbar bevor, werden dagegen Hinweise bezüglich der Abiturnote wertvoller. Da jedoch an der Umfrage im Wesentlichen Personen aus dem aktuellen Abiturjahrgang teilgenommen haben, die sich also zeitlich an der gleichen Stelle befinden, lassen sich solche Aussagen mit den vorliegenden empirischen Daten nicht belegen.

Im vorigen Abschnitt wurde bereits eine erste Liste möglicher Features dargestellt. In der Online-Umfrage wurden die Oberstufenschülerinnen darum gebeten, die Features hinsichtlich ihrer Wichtigkeit zu bewerten (vgl. Tabellen 20–27). Diese Priorisierung bietet wertvolle Hinweise darauf, welche Features für große Teile der Zielgruppe besonders interessant sind. Die zusammengefassten Ergebnisse sind deshalb in Tabelle 2 dargestellt.

2.2.1. Unterschiede je nach Schulleistung

Laut Aussage des Oberstufenkoordinators fallen diejenigen, die aus eigenem Antrieb die Beratung aufsuchen, in zwei distinktive Gruppen: Einige bewegen sich an der Leistungsspitze und sind interessiert an Optimierungspotenzialen und Möglichkeiten zur weiteren Steigerung, andere bewegen sich eher im unteren Bewertungsbereich und sorgen sich z.B. um die Abiturzulassung. Dies ist zunächst ein subjektiver Eindruck.

Zusätzlich zu den im vorigen Abschnitt thematisierten Fragen zur Wichtigkeit der Features wurden die Teilnehmenden der Online-Umfrage nach einer groben Selbsteinschätzung hinsichtlich ihrer eigenen Leistung gefragt (vgl. Tabelle 19). Interpretiert man die zwei Skalen als intervallskalierte numerische Variablen, lässt sich die Korrelation zwischen der Wichtigkeitsbewertung verschiedener Features und der Selbsteinschätzung statistisch untersuchen.

Tatsächlich ist auf Basis der vorliegenden Daten bei einigen Features ein Zusammenhang nachweisbar (vgl. Tabelle 3): Für leistungsstärkere Schülerinnen ist die beste noch zu erreichende Abiturnote ein plausibles Ziel und deshalb relevant, während die schlechteste erreichbare Note und Dinge wie die Erreichung der Fachhochschulreife gedanklich kaum eine Rolle spielen. Dagegen ist für leistungsschwächere Schülerinnen die bestmögliche Note unrealistisch und deshalb uninteressant, wogegen die Fachhochschulreife ein wichtiger Meilenstein sein kann und kritische Kurse durchaus öfter geistig präsent sind.

2.2.2. Beratungspersonal

Eine Nutzergruppe, die sich von den Schülerinnen klar abgrenzen lässt, ist die des Beratungspersonals. Derzeit ist der Oberstufenkoordinator der einzige, der die Beratung für Oberstufenschülerinnen und -schüler durchführt, dies könnte sich allerdings theoretisch zukünftig ändern, weshalb in diesem Abschnitt ganz allgemein vom Beratungspersonal gesprochen wird.

Im Gegensatz zu den Schülerinnen würde das Beratungspersonal die Anwendung nicht für den Eigenbedarf verwenden, sondern zum Zweck der persönlichen Beratung. In diesem Kontext findet die Verwendung höchstwahrscheinlich nicht auf einem Mobilgerät statt, sondern auf einem festen PC mit großem Bildschirm, der für mehrere Personen gleichzeitig einsehbar ist.

Für das Beratungspersonal ist ein schneller Überblick wertvoll. Sie sind darin geschult, mögliche Probleme auch eigenständig ohne technische Unterstützung zu erkennen. Deshalb ist es für sie nicht nötig, die dargestellten Informationen mit einsteigerfreundlichen Erklärungen zu versehen. Stattdessen dürfen Hinweistexte potenziell detaillierter sein und können Bezug zu Verordnungen und anderen externen Texten nehmen, soweit für die Beratung hilfreich.

Auf den von Beratungspersonal genutzten Rechnern sollten möglichst keine personenbezogenen Daten gespeichert werden und ein mal eingegebene Zeugnisnoten sollten nicht versehentlich der nächsten zu beratenden Person zugänglich gemacht werden. Eine Persistierung der Eingabedaten ist nur selten sinnvoll. Ein gesonderter Modus für das Beratungspersonal wäre hinsichtlich dieser Anforderungen denkbar.

2.2.3. Personas

In diesem Abschnitt werden drei Personas (Cooper, 1999) entwickelt, die auf den oben dargestellten Nutzergruppen basieren und möglichst viele repräsentative Eigenschaften widerspiegeln. Sie dienen dazu, die zukünftigen Nutzerinnen und Nutzer greifbarer und leichter vorstellbar zu machen. Dazu werden zwei Personas aus der Gruppe der Schülerinnen und Schüler sowie eine Persona aus dem Bereich des Beratungspersonals entworfen.

Miriam Schütz

Miriam besucht die elfte Klasse des Johanneums in Lüneburg. Sie hat sich zu Beginn der Oberstufe für den naturwissenschaftlichen Schwerpunkt entschieden, da sie schon lange sehr interessiert an Chemie ist und nach dem Abitur ein Studium in Lebensmittelchemie absolvieren möchte. Am liebsten möchte sie dazu an die Uni Münster, obwohl es dort jedes Jahr eine große Anzahl Bewerber gibt und sie ein sehr gutes Abitur erreichen muss, um sofort zugelassen zu werden.

Sie ist eine disziplinierte und ehrgeizige Person, kann sich aber auch ihre Zeit so organisieren, dass sie am Wochenende auch mal mit Freunden feiern gehen kann. Ansonsten reist sie in den Ferien gerne um die Welt und ist während der Schulzeit oft damit beschäftigt, in ihrer Freizeit noch weitere Fremdsprachen zu lernen – zuletzt hat sie sich in ein Russisch-Lehrbuch gestürzt. Sie kommt aus einer Familie, in der viel Wert auf Leistung und Erfolg gelegt wird, weshalb sie schon früh in ihrem Ambitionen unterstützt wurde. Sie tritt forsch auf und neigt so manchmal dazu, andere Menschen zu überrumpeln.

Technik ist für sie ein Bestandteil des modernen Lebens, aber selten mehr als ein Mittel zum Zweck. Sie besitzt ein iPhone und einen Acer-Laptop mit Windows 7. Sie ist mit beiden Geräten gut genug vertraut, um ihre E-Mails und soziale Netzwerke stets griffbereit zu haben. Wenn mal etwas kaputt geht, dann bastelt sie jedoch nicht lange sondern überlässt die Reperatur einem technisch versierteren Freund oder gleich den Profis im Fachgeschäft.

Miriam hat stets ein Auge auf ihre Zeugnisnoten und ärgert sich, dass das Berechnungssystem für die Abiturnote so kompliziert ist. Sie hat sogar schon ein mal begonnen, die Regelungen zu recherchieren, hat aber nach einer Stunde genervt aufgegeben. Eine technische Unterstützung zur Selbstreflexion anhand ihrer Noten würde sie regelmäßig nutzen. Insbesondere interessiert sie natürlich, wie ihre Chancen stehen, mit ihrem Abi die Zugangsvoraussetzung für Münster zu erfüllen.

Thomas Möller

Thomas besucht die zwölfte Klasse des Johanneums in Lüneburg. Er hat sich damals zu Beginn der Oberstufe für einen sprachlichen Schwerpunkt entschieden, da ihm Englisch ziemlich gut liegt und er in Deutsch irgendwie schon immer gute Noten hatte, obwohl es ihn gar nicht so sehr interessiert. Gegen Ende des elften Schuljahres hat er in Erwägung gezogen, vorzeitig von der Schule abzugehen und eine Ausbildung als Tischler zu beginnen, auf Anraten seiner Lehrer und seiner Familie hin möchte er nun aber doch das Abitur abschließen. In den Unterrichtsdiskussionen ist er meist besser als in Klausuren, deshalb machen ihm die Abiturprüfungen große Sorgen.

Er lebt gerne in den Tag hinein und packt oft spontane Gelegenheiten beim Schopf. In der Freizeit genießt er öfters gutes Essen und guten Alkohol. Er macht zwar keinen organisierten Sport, ist aber sehr viel zu Fuß und mit dem Fahrrad unterwegs. Seine Freizeit verbringt er gerne mit Freunden, allerdings zieht es ihn auch immer mal wieder in die Schreinerwerkstatt seines Onkels, wo er mit Holz arbeitet und diverse kleine Skulpturen oder Möbel herstellt. Er hat einen großen Freundeskreis und eine noch größere Menge an Leuten, die ihn nicht wirklich kennen aber trotzdem sympathisch finden.

Obwohl es sie schon einige Jahre gibt, ist er sich noch nicht so sicher, was er von Smartphones halten soll. Bisher reicht ihm sein altes Nokia-Handy, unterwegs braucht er keinen Internetzugang. Zuhause hat er einen PC, den er mal selbst aus Komponenten zusammengebaut hat, der aber inzwischen etwas in die Jahre gekommen ist. Er benutzt ihn für Schularbeiten und spielt gelegentlich ein paar ältere Spiele darauf.

Thomas ist sich eigentlich recht sicher, dass er das Abitur schaffen sollte. Er hat allerdings noch nie versucht nachzurechnen, seine Abinote erfährt er schließlich früh genug und er gibt so oder so sein Bestes. Allerdings kommt er nicht so richtig mit seinem Mathelehrer klar und hätte schon einmal fast den Kurs in den Sand gesetzt. Er erinnert sich dunkel, dass man Mathe im Abi nicht loswerden kann, und hat deshalb ein wenig Angst. Diese verbannt er jedoch meistens in seinen Hinterkopf. Wenn er die Möglichkeit hätte, ohne riesigen Aufwand und ohne die bohrenden Blicke des Schulpersonals mal seinen aktuellen Stand zu überprüfen, würde er sie bestimmt nutzen. Besonders das mit Mathe würde ihn interessieren, was denn wohl passieren würde wenn er da tatsächlich durchfällt. Aber auch sonst wäre es bestimmt mal spannend, eine Rückmeldung zu bekommen, worauf er achten sollte.

Gunda Steinbiss

Gunda ist Lehrerin für Physik und Sport am Johanneum, von ihren Schülern wird sie „Frau Steinbiss“ genannt. Der Name ist an dieser Stelle kein Programm, denn Gunda ist eine sehr soziale und lockere Lehrkraft, die viel lacht und ihre Schützlinge mit ihrem mütterlichen Charme motiviert. Sie ist direkt nach ihrem Referendariat ans Johanneum gekommen und fühlt sich auch sehr wohl. Dass sie nun zusätzlich zu ihrem Unterricht noch die Beratung der Oberstufenschülerinnen und -schüler übernehmen sollte, das fand sie zwar zu Anfang lästig, inzwischen hat sie aber Gefallen daran gefunden und die Tätigkeit erfolgreich in ihren Arbeitsalltag integriert.

Sie hat recht schnell festgestellt, dass sich eine offene Sprechstunde zeitlich nicht lohnt, auch weil die Stundenpläne gerade in der Oberstufe sehr individuell sind. Stattdessen gibt sie den Schülerinnen und Schülern die Möglichkeit, über das Sekretariat einen Termin bei ihr zu machen. Sie trifft sich dann in ihrem Büro mit der Person und spricht alle wichtigen Details durch. Die meisten Leute, die zu ihr kommen, haben eine oder zwei konkrete Fragen. Trotzdem verläuft das Gespräch oft so, dass sie sich gemeinsam die Zeugnisnoten ansehen und durchsprechen, welche Kurse welche Relevanz haben und wie die Noten miteinander verrechnet werden. Sie ärgert sich insgeheim, dass die Kultusminister ständig am Schulsystem herumreformieren müssen, ist aber ihren Schützlingen zuliebe immer auf dem neuesten Stand.

Sie besitzt ein Android-Smartphone von Samsung und ein Sony-Laptop, mit denen sie insgesamt gut zurechtkommt. Sie weiß wie man Programme installiert und hört viel Musik, sowohl daheim als auch unterwegs. Auf der Arbeit hat sie einen Büro-Rechner mit eingeschränkten Berechtigungen (das weiß sie, weil die Administratoren ihr verboten haben, ihren Media Player zu installieren). Sie ist nicht allzu passioniert was Technik an sich angeht, hält es aber für wichtig, mitzubekommen was die Jugendlichen im Alltag so bewegt.

Für ihre Beratungstätigkeit würde sie sich freuen, wenn sie weniger von Hand rechnen und vergleichen müsste. Sie hat zwar noch nie etwas sehr Wichtiges vergessen oder übersehen, hat aber große Ehrfurcht vor dieser Gefahr, weil sie weiß, dass man sich auf ihre Kompetenz verlässt. Sie ist routiniert, hätte aber nichts dagegen, sich einen Teil der Routinetätigkeiten abnehmen zu lassen. Jede gesparte Zeit käme dann schließlich wieder ihrem eigentlichen Beruf zugute.

2.3. Kontextanalyse

Neben den individuellen Eigenschaften der Nutzer ist auch der technische, soziale und organisatorische Kontext entscheidend für die gelungene Gestaltung einer Software-Lösung. Alle drei genannten Facetten werden in diesem Abschnitt nacheinander untersucht.

2.3.1. Technischer Kontext

Wie bereits in Abschnitt 2.2 festgestellt wurde, ist die große Mehrheit der Zielgruppe sowohl mit PCs2 als auch mit Smartphones vertraut. Auch hinsichtlich der schwer einschätzbaren Zukunft der Computer wäre eine Anwendung ideal, die auf einer möglichst großen Vielfalt an Geräten lauffähig ist.

Zwischen PCs und Mobilgeräten gibt es schon von Seiten der Hardware ergonomische Unterschiede. Eine gute Nutzungsschnittstelle für ein Smartphone-Display mit Touch-Funktion ist anders gestaltet als eine nutzergerechte Schnittstelle für einen PC (Nielsen & Budiu, 2012).

Für Anwendungen, die auf verschiedenen Geräteklassen lauffähig sein sollen, ist nicht nur die Schnittstelle relevant, sondern auch der technische Unterbau. Moderne Geräte enthalten die verschiedensten Prozessoren und sonstige Hardware, so dass nicht einfach der selbe Binärcode überall ausgeführt werden kann. Neben der Möglichkeit, verschiedene Binärcodes zu pflegen, ist die Wahl einer geeigneten plattformunabhängigen Laufzeitumgebung eine attraktive Möglichkeit. Über viele Jahre hat Java (heute Eigentum von Oracle Inc.) diese Funktion sehr gut erfüllt (Hamilton, 1996). In den letzten Jahren und bis heute haben sich allerdings auch Bestrebungen entwickelt, Web-Technologien (HTML, CSS, JavaScript usw.) als Basis für plattformunabhängige Anwendungen nutzbar zu machen.

Web-Technologien erlauben bedingt durch ihren eigentlichen Einsatzzweck – die Darstellung von Hypertext-Dokumenten im World Wide Web – eine sehr detaillierte und trotzdem flexible visuelle Gestaltung. Die Möglichkeiten zur Dynamik und Interaktion sind in der jüngeren Vergangenheit extrem vielfältig geworden (vgl. Benedetti & Cranley, 2011). Gerade für den konzeptuell vergleichsweise einfachen Einsatzzweck dieser Arbeit eignen sich moderne Web-Technologien exzellent.

Viele moderne Web-Anwendungen sind als Client-Server-Architekturen umgesetzt. Der Web-Browser auf dem lokalen Gerät verbindet sich mit einem geographisch potenziell weit entfernten Server, welcher für die Datenpersistierung und alle wichtigen Teile der Anwendungslogik verantwortlich ist. Auf dem Client findet dann im Wesentlichen nur noch die Darstellung und die Interaktion statt. Solche Anwendungen sind ohne Internetverbindung nicht nutzbar.

Damit die Anwendung auch bspw. in einem Gebiet mit ungenügender Netzabdeckung nutzbar ist, muss sie vollständig lokal lauffähig sein. Dies ist für Web-Anwendungen seltener als die Alternative, aber nicht unmöglich. Der konzeptuell überschaubare Funktionsumfang und die geringe grundlegende Komplexität des Anwendungsproblems, machen es möglich, die Anwendung als vollständig lokal gespeicherte Web-App auch auf leistungsschwächeren modernen Mobilgeräten lauffähig zu machen. Dadurch, dass nach der einmaligen Installation keine Datenübertragung mehr über das Internet stattfindet, fallen damit auch gleich eine Reihe von Datenschutzproblemen weg: Lediglich das Auslesen gespeicherter Daten durch unbefugte Software und die Gefahr des Diebstahls oder Verlustes des Geräts an sich bleiben als Datenschutzgefahr bestehen.

Zusammengefasst ergibt sich, dass aus den Technik-Nutzungsgewohnheiten der Zielgruppe der Bedarf hervorgeht, unterschiedliche Geräteklassen von Smartphones und anderen Mobilgeräten bis zu Laptops und Desktop-Rechnern nutzbar zu machen. Moderne Web-Technologien bieten dafür einen guten Kompromiss zwischen Portabilität und Funktionalität, der für diese Anwendung mehr als ausreicht.

2.3.2. Sozialer Kontext

Der Einsatzzweck dieser Anwendung ist primär auf einzelne Nutzerinnen ausgelegt. Es gibt weder Bedarf noch wesentlichen Spielraum für vernetzte oder kollaborative Funktionalitäten. Viele Nutzerinnen werden die Inhalte als privat werten.

Dennoch kommt es auch vor, dass Leute untereinander ihren Notendurchschnitt auf freiwilliger Basis vergleichen. Das ist ein Hinweis darauf, dass der soziale Kontext nicht von vornherein ausgeblendet werden sollte. Es stellt sich jedoch die Frage, inwieweit eine technische Unterstützung an dieser Stelle sinnvoll ist.

Unabhängig davon, ob zur Berechnung eine Software verwendet worden ist, lassen sich Notendurchschnitte und Abiturprognosen im direkten persönlichen Gespräch mitteilen und vergleichen. Eine technische Unterstützung könnte darin bestehen, zwischen zwei lokal verbundenen Geräten die relevanten Daten auszutauschen und automatisiert zu vergleichen. Weiter gedacht könnte sich die Anwendung auch mit gängigen sozialen Netzwerken verbinden und die Möglichkeit bieten, das Ergebnis der Analyse dort Freunden und Verwandten mitzuteilen. Sogar eine Vergleichs- und Wettstreit-Plattform im Sinne von Gamification (Deterding, Dixon, Khaled & Nacke, 2011) wäre theoretisch denkbar.

Ideen dieser Art bringen wiederum eigene Probleme hinsichtlich Konnektivität und Datenschutz mit. Zudem wäre der technische Aufwand der Umsetzung signifikant. Aus diesen Hinderungsgründen und weil soziale Funktionalitäten dieser Art nicht zum Kernkonzept gehören, werden sie im Rahmen dieser Arbeit nicht weiter verfolgt (in Abschnitt 7.2 wird die Idee allerdings noch mal aufgegriffen).

Eine weitere Problemstellung des sozialen Kontextes sind geteilte Geräte, d.h. PCs oder Smartphones, die von mehreren Personen zu verschiedenen Zeitpunkten verwendet werden.

Die grundsätzliche Annahme der Anwendung ist, dass ein Gerät einer Nutzerin entspricht. Viele Geräte haben sog. Multi-User-Fähigkeiten, sorgen also eigenständig dafür, dass verschiedenen Personen jeweils eigene Nutzungskontexte zur Verfügung stehen. Obwohl eine Anwendung in der Regel trotzdem nur ein mal auf dem Gerät installiert sein muss, können verschiedene Nutzerinnen sie unabhängig voneinander verwenden und haben dabei jeweils nur Zugriff auf ihre eigenen Daten.

Mitunter werden auch Geräte geteilt, die nicht über diese Fähigkeit verfügen, oder sie wird nicht genutzt. Dann gibt es keine technische Möglichkeit, zwischen den verschiedenen Nutzerinnen zu differenzieren. Für diese Anwendung wäre hier die fälschliche oder versehentliche Persistierung der eingegebenen Daten ein potenzielles Problem. Möglichkeiten zur externen Lagerung der Daten (etwa per Import/Export von einem Speichermedium) oder zur Zugangsbeschränkung (z.B. Passwortschutz) könnten hier Abhilfe schaffen. In Anbetracht der vermutlich eher kleinen Zielgruppe mit diesem Problem werden allerdings auch diese Funktionen so niedrig priorisiert, dass eine Umsetzung im Rahmen dieser Arbeit pragmatisch betrachtet ausgeschlossen ist.

2.3.3. Organisatorischer Kontext

Der Kontext „Schule“ bietet einige organisatorische Rahmenbedingungen, die evtl. relevant für dieses Projekt sind. Das ergibt sich schon allein daraus, dass die Schule offiziell die Noten vergibt und verkündet, die die Anwendung verarbeiten soll.

Am Ende jedes Halbjahres erhalten die Schülerinnen und Schüler ein Zeugnis, in dem ihre Kurse und deren Noten aufgelistet sind. Zur Verwaltung dieser Daten hat die Schule ein bestehendes IT-System. Eine Anbindung an vorhandene Komponenten könnte bedeuten, dass Noten einfach auf Basis eines Namens automatisch geladen werden könnten, so dass die langwierige Eingabe wegfallen würde.

Eine Anbindung an bestehende IT-Systeme wurde jedoch bereits früh in der Entwurfsphase dieser Anwendung ausgeschlossen (vgl. auch Anhang A). Gründe hierfür sind einerseits technischer Natur – Programmierschnittstellen für Import und Export von Daten sind gerade bei hochspezialisierter Software wie solcher zur Verwaltung von Schulen oftmals unterspezifiziert oder überhaupt nicht vorhanden – und andererseits auch rechtlich ggf. schwierig, da personenbezogene Daten grundsätzlich vor unbefugten Zugriffen geschützt werden müssen. Die rechtlichen Hürden wurden für diese Arbeit zwar nicht detailliert recherchiert, aber es ist trotzdem schnell offensichtlich gewesen, dass eine Anbindung an vorhandene IT den Aufwand nicht rechtfertigt.

Es ist auch die Schule, die den Rahmen für die bereits mehrfach thematisierte Beratung stellt. Letztlich ist es auch wieder die Schule, die profitiert, wenn bei der Beratung durch die Automatisierung von Arbeitsschritten Zeit eingespart wird. Die Entscheidung, welche Auswirkungen das haben soll, ob deshalb die Beratungszeit knapper gestaltet, gleich behalten oder sogar ausgebaut werden soll, fällt abstrakt betrachtet der Schule zu. So oder so stellt die technische Unterstützung von Routinetätigkeiten für das Beratungspersonal eine Entlastung und Zeitersparnis dar. Die Entscheidung, wie damit umgegangen werden soll, liegt jedoch außerhalb der Fragestellung dieser Arbeit und wird deshalb nicht weiter thematisiert.

2.4. Use Cases

Die unabhängig vom späteren konkreten Design der Anwendung formulierten Use Cases basieren auf den vorhergegangenen Analysen. Sie beschreiben eine Auswahl möglicher zielgerichteter Handlungen, welche die Nutzerinnen der Anwendung durchführen können (Jacobson, Christerson, Jonsson & Övergaard, 1992). Diese Liste umfasst deshalb nicht die gesamte Funktionalität der späteren Anwendung (so werden z.B. keine Interaktionen aufgeführt, welche nicht bewusst oder geplant durchgeführt werden), soll jedoch den Anspruch erfüllen, alle wichtigen zentralen Aspekte zu enthalten.

Diese Use Cases basieren unter Anderem auf dem Feature-Brainstorming, das in Abschnitt 2.1 beschrieben wurde. Zwei der acht möglichen Features (vgl. Nr. 6 und Nr. 8 in Tabelle 2) werden hier nicht mehr aufgegriffen, da sie nach der genaueren Analyse nicht mehr ins Konzept passen: Der „Hinweis auf verpflichtende Kursbelegungen“ ist nur vor Beginn der Oberstufe relevant, wenn die Kurse gewählt werden, und der aus der Komplexität der entsprechenden Regelungen hervorgehende Aufwand wiegt mehr als der zeitlich zweifelhafte Nutzen. Die „Überwachung der Einhaltung der Mindestwochenstunden“ hat sich mit der Wahl der Kurse ebenfalls weitgehend erledigt. Ausgehend von dem Standpunkt, dass die Anwendung zur Leistungsreflexion dient und nicht zur Kurswahl, passen diese zwei Punkte nicht ins Konzept. Dass sie in der Umfrage zu den am unwichtigsten bewerteten Features gehören (siehe Tabelle 2, vgl. auch Tabellen 25 und 27), erleichtert die Entscheidung.

Alle verbleibenden Use Cases haben Gemeinsamkeiten hinsichtlich der Interaktion. Egal wofür die Anwendung verwendet wird, in jedem Fall werden alle vorhandenen abiturrelevanten Noten eingetragen und das Analyse-Ergebnis gelesen. Die Unterschiede liegen in den Zielen.

Use Case 1: Herausfinden des voraussichtlichen Abiturschnitts

Sobald mindestens eine Note eingetragen ist, kann die Anwendung den Durchschnitt der vorhandenen Noten in die Zukunft extrapolieren und angeben, welche Abiturnote entsteht, falls die Noten im Schnitt konstant bleiben. So erhält man eine nützliche Zusammenfassung der bisherigen Leistung.

Use Case 2: Herausfinden der besten noch möglichen Abiturnote

Die beste erreichbare Abiturnote ergibt sich, indem für alle noch nicht vorliegenden Noten das höchste Ergebnis angenommen wird. Diese theoretische Bestnote kann als Motivation dienen, sich weiterhin anzustrengen.

Use Case 3: Herausfinden der schlechtesten noch möglichen Abiturnote

Die schlechteste erreichbare Abiturnote errechnet sich analog zur besten. In einigen Fällen mag diese Zahl als Maß dafür, welches Mindestergebnis bereits gesichert ist (sofern das Abitur nicht vorzeitig abgebrochen wird), interessant sein. Erwähnenswerterweise wurde dieses Feature jedoch in der Umfrage am zweit-unwichtigsten bewertet (vgl. Tabelle 2), was darauf hindeutet, dass der Nutzen in der Realität evtl. gering ist.

Use Case 4: Herausfinden, welche Kurse unbedingt bestanden werden müssen

In manchen Kursen ist es für den Abschluss vertretbar (wenn auch trotzdem ärgerlich), weniger als fünf Punkte zu erzielen. Andere müssen auf jeden Fall bestanden werden, insbesondere wenn bereits Unterkurse vorliegen. Dies sollten Schülerinnen so früh wie möglich erfahren, nicht wenn es bereits zu spät ist.

Use Case 5: Prüfen ob ein bestimmter NC erreicht werden kann

Der Numerus clausus bezeichnet die Mindestnote, die in einem bestimmten Jahr für die Zulassung zu einem Studienfach an einer konkreten Universität benötigt wird. Für die Zukunftsplanung sind diese Zahlen sehr wichtig und viele Schülerinnen fragen sich oft, ob sie eine Chance haben, an ihrer Wunsch-Universität angenommen zu werden. Die Antwort dazu ergibt sich aus der bestmöglichen Abiturnote aus Use Case 2. Ist diese besser als der entsprechende NC, kann dieser noch erreicht werden.

Use Case 6: Prüfen ob Abiturzulassung erreicht ist

Zur Abiturprüfung wird zugelassen, wer (vereinfacht zusammengefasst) die nötige Anzahl Kurse erfolgreich absolviert hat. Dieser Meilenstein hat die Bedeutung, dass nur noch das Bestehen der Abiturprüfungen nötig ist, um den Abschluss zu erreichen.

Use Case 7: Prüfen ob Abiturzulassung noch erreicht werden kann

Falls bereits zu viele Unterkurse vorliegen, die nicht mehr kompensiert werden können, ist die Zulassung zu den Abiturprüfungen unter Umständen nicht mehr erreichbar. Wenn man sich dessen möglichst früh bewusst wird, gibt es noch am meisten Möglichkeiten, den weiteren Ablauf neu zu planen.

Use Case 8: Prüfen ob Fachhochschulreife erreicht ist

Die Fachhochschulreife (eigentlich: der schulische Teil der Fachhochschulreife) berechtigt zum Studium an einer Fachhochschule. Man erreicht sie im Laufe der Oberstufe, ähnlich wie die Abiturzulassung, durch die Erfüllung bestimmter Leistungsauflagen. Wenn das Abitur nicht bestanden oder vor dem Abschluss abgebrochen wird, bietet die Fachhochschulreife evtl. eine Zukunftsperspektive. Wenn sie bereits erreicht ist, dann ist dieser Schritt in jedem Fall möglich.

Use Case 9: Prüfen ob Fachhochschulreife noch erreicht werden kann

Falls die Voraussetzungen für die Fachhochschulreife nicht mehr erfüllt werden können, muss ggf. die Planung für den weiteren Verlauf der Oberstufe angepasst werden. In jedem Fall möchte sich niemand umsonst um ein unerreichbares Ziel bemühen, weshalb auch diese Information möglichst früh erkannt werden sollte.

Use Case 10: Offene Informationsabfrage

Wie oben bereits beschrieben wurde, ist die Interaktion mit der Anwendung eigentlich für alle Use Cases gleich: Die vorhandenen Noten werden eingegeben und man bekommt alle relevanten Analyseergebnise als Rückmeldung ausgegeben. Dies geht natürlich auch, wenn man gar keine konkrete Frage hat, sondern einfach mal schauen möchte, welche Informationen die Anwendung liefern kann.

Use Case 11: Beratung

Für die persönliche Beratung sind, wie in Abschnitt 2.2.2 beschrieben, einige Umstände relevant, die in der Nutzung nach dem Prinzip „Ein Nutzer, ein Gerät“ nicht gelten. Die Beratung und gemeinsame Betrachtung ist jedoch ebenfalls ein relevanter Use Case.

2: Mit dem Sammelbegriff Personal Computer sind hier sämtliche Arten von Desktop-PCs sowie auch großer und kleiner Laptops gemeint. In einigen portablen Geräteklassen verschwimmt die Abgrenzung zu den Mobilgeräten. Insofern als dass eine klare Definition nötig ist, eignet sich evtl. der (per Maus oder Touchpad bediente) Mauscursor als heuristisches Abgrenzungsmerkmal. Letztlich ist die harte Unterscheidung aber für diese Arbeit gar nicht besonders wichtig.

3. Konzeption

Ausgehend von der durchgeführten Analyse soll als nächstes ein Konzept für die Anwendung entstehen.

Die Priorisierung der Features ist der erste Planungsschritt. Dabei wird erneut auf alle empirischen Datenquellen und die bisherigen Analyseergebnisse zurückgegriffen. Insbesondere soll danach auch die Struktur und der Aufbau der Benutzungsschnittstelle geplant werden. Mit einem prototypischen Entwurf ist dann ein Test durch Mitglieder der zukünftigen Nutzergruppe möglich, dessen Ergebnisse zur weiteren Verfeinerung dienen können. Weiterhin wird die geplante softwaretechnische Architektur des Systems dargestellt und in einem kurzen Abschnitt die Benennung der Anwendung thematisiert, bevor Kapitel 4 die tatsächliche Umsetzung beleuchtet.

Zusammengefasst hat die Anwendung vier übergreifende Aufgabenbereiche. Drei davon sind sequenziell: Erstens muss die Eingabe von vorhandenen Noten problemlos und nutzergerecht möglich sein, hierbei wird Nutzerwissen in eine maschinell verarbeitbare Form gebracht. Zweitens muss die Anwendung aus diesen Noten korrekte und relevante Erkenntnisse extrahieren können, dies ist als deterministische Funktion vorstellbar und beinhaltet keine Interaktion mit der Nutzerin. Drittens müssen diese Erkenntnisse verständlich dargestellt werden, also in eine menschenlesbare Form gebracht und visuell aufbereitet werden. Der vierte Aufgabenbereich umfasst die übergreifende Interaktionsgestaltung und Persistierung, hier wird geregelt, wann bzw. auf welches Signal hin der Algorithmus gestartet wird und wie die Eingabewerte sitzungsübergreifend behandelt werden. Dieses Modell ist in Abbildung 5 visualisiert.

Abbildung 5: Dies ist eine schematische Darstellung der Aufgabenbereiche der Anwendung. Eingabe, Verarbeitung und Ausgabe sind jeweils gekapselt und bilden eine klare Sequenz. Übergreifende Aspekte der Interaktionsgestaltung werden gesondert behandelt. Hierbei handelt es sich um eine Visualisierung der verschiedenen technischen Aufgaben der Anwendung, nicht um ein Modell für die Nutzer-Interaktion – letztere wird im Abschnitt 3.2 beschrieben (siehe insbesondere Abbildung 6).

3.1. Priorisierung der Features

Für die endgültige Priorisierung der Features wird insbesondere auf die Ergebnisse aus den Abschnitten 2.1.3 und 2.4 zurückgegriffen, aber auch den Abschnitten 2.2 und 2.3 kommt weiterhin eine große Bedeutung zu.

Zwar sollen die Use Cases aus Abschnitt 2.4 den gesamten benötigten Funktionsumfang abbilden, sie eignen sich jedoch nicht dafür, als Feature-Liste übernommen zu werden. Dafür gibt es zwei vorrangige Gründe: Erstens kann es zwischen Features logische Abhängigkeiten geben, welche einen Einfluss auf die zeitliche Anordnung in der Realisierung haben. Zweitens tauchen einige Randfunktionen in den Use Cases nicht auf, wie z.B. das Abspeichern der eingegeben Daten zur späteren erneuten Nutzung.

Vorab ist anzumerken, dass sich nicht in jeder Feature-Liste im Sinne des FDD die Ein- und Ausgabe wiederfindet, da die Erstellung einer Nutzungsschnittstelle in vielen Fällen keinen großen Programmieraufwand bedeutet und bis dahin ggf. auch mit statisch vorgegebenen Daten gearbeitet werden kann. In diesem Projekt soll jedoch viel Aufmerksamkeit in die Entwicklung des Eingabesystems fließen. Eine gelungene Gestaltung der Eingabeschnittstelle auch hinsichtlich des Verhaltens auf verschiedenartigen Endgeräten ist mit einigem Entwicklungsaufwand verbunden; der gewünschte Fokus auf einen hohen Grad an Interaktivität zur Förderung von explorativer Nutzung hängt von einer entsprechend darauf ausgerichteten Implementation ab. Aus diesen Gründen wird das Eingabesystem nicht nur explizit in die Feature-Liste aufgenommen, sondern sogar vergleichsweise hoch priorisiert.

Im Folgenden wird nun die Feature-Liste erstellt, welche die zu entwickelnden Features in Gruppen zusammenfasst und gemäß ihres geschätzten Wertes für die Zielgruppe priorisiert. Dieses Vorgehen ermöglicht es, dass die Anwendung am Ende der Entwicklungszeit höchstwahrscheinlich nutzbar und nützlich ist, selbst wenn aus zeitlichen Gründen nicht alle Features umgesetzt werden.

Feature Set 1

• Eingabe von Zeugnis- und Prüfungsnoten (alle UCs)

Feature Set 2

• Berechnung der aktuellen Durchschnittsnote (UC 1)
• Berechnung der bestmöglichen Abiturnote (UC 2 & 5)
• Berechnung der schlechtestmöglichen Abiturnote3 (UC 3)

Feature Set 3

• Sichern der Eingabedaten über mehrere Sessions hinweg (alle UCs)
• Löschen der erstellten Sicherung (alle UCs)

Feature Set 4

• Erkennen und Darstellen von kritischen Kursen (UC 4)

Feature Set 5

• Erfüllung der Kriterien zur Abiturzulassung erkennen (UC 6 & 7)

Feature Set 6

• Erfüllung der Kriterien zur Fachhochschulreife erkennen (UC 8 & 9)

Feature Set 7

• Beratungs-Modus mit anders gestalteten Hinweisen (UC 11)

Die Feature-Liste ist eingeteilt in insgesamt sieben Feature Sets, die in ihrer Reihenfolge absteigend priorisiert sind. Feature Set 1 ist grundlegende Voraussetzung für alle danach folgenden Features. Zwar führt die ausschließliche Realisierung von diesem Feature Set noch nicht zu einer nützlichen Anwendung, aber trotzdem wurde die Möglichkeit zur Noteneingabe der Klarheit wegen gesondert aufgeführt. Feature Set 2 enthält erste Analyseergebnisse. Dabei handelt es sich zunächst um einige der von den Umfrageteilnehmenden tendenziell hoch priorisierten Features (vgl. Tabelle 2), die trotzdem von den geplanten Features voraussichtlich eher leicht zu implementieren sind. Feature Set 3 beschreibt Hilfsfunktionen, die für die Kernfunktionalität keine Rolle spielen, aber trotzdem eine Rolle für die Benutzbarkeit der Anwendung spielen und nicht zu spät durchdacht werden sollten. Feature Sets 4 bis 6 drehen sich um weitere Kernfunktionen, die in dieser Reihenfolge priorisiert wurden und das Analyseergebnis weiter anreichern. Feature Set 7 thematisiert das Beratungspersonal und die mit diesem Kontext verbundenen Besonderheiten. Weil alle vorherigen Features einen großen inhaltlichen Nutzen sowohl für die eigenmotivierte Nutzung als auch für die Beratung haben, sind diese Besonderheiten sehr niedrig priorisiert und werden nur umgesetzt, sofern die Zeit ausreicht.

3.2. Benutzungsschnittstelle

Um die Anwendung nutzbar zu machen, benötigt sie eine grafische Nutzungsschnittstelle, welche in diesem Abschnitt konzeptuell erarbeitet werden soll. Zunächst werden die allgemeinen Anforderungen an die Schnittstelle zusammengefasst, welche sich hauptsächlich aus den Analysen aus Kapitel 2 ergeben. Danach werden der Gesamtaufbau und die einzelnen Bestandteile beschrieben.

3.2.1. Anforderungen

Der Einsatzzweck für die Anwendung bringt den Umstand mit sich, dass die Nutzerinnen sie vermutlich nur sporadisch einsetzen. Es gibt über die zwei Jahre der Oberstufe verteilt lediglich vier Zeugnisse und einen Prüfungsblock, so dass zwischen zwei Verwendungsgelegenheiten mehrere Monate liegen können. Außer für die Gruppe des Beratungspersonals ist es deshalb nicht sinnvoll, eine Schnittstelle zu entwerfen, die in hohem Maße auf Lernvorgänge, intensive Beschäftigung und Gewohnheitsbildung angewiesen ist.

Stattdessen sollten typische Kriterien im Vordergrund stehen, die schon von gelegentlicher Nutzung profitieren. Dazu gehört Übersichtlichkeit und Selbstbeschreibungsfähigkeit bis hin zum Minimalismus, aber auch die Vermeidung unnötiger modaler Abläufe, welche das Arbeitsgedächtnis beanspruchen und vom Inhalt ablenken (Raskin, 2000).

Weiterhin sollte für die Verwendung nicht mehr Spezialwissen benötigt werden als unbedingt nötig. Bei der Nutzergruppe ist das Wissen darüber vorauszusetzen, wie Kurse in der Oberstufe grundlegend funktionieren und was für Noten es gibt. Darüber hinaus sollte ein Minimum an Wissen über die Hintergründe vorausgesetzt werden, damit die Anwendung einem möglichst großen Nutzerkreis zugänglich ist.

Ein erklärtes Ziel für die Verwendung der Anwendung ist die stetige Bereitstellung von sofortigem Feedback. Es soll bei der Verwendung nicht das Gefühl aufkommen, dass zuerst sämtliche Daten eingegeben werden müssen, bevor einmalig ein Auswertungsprozess in Gang gebracht wird, der dann das Ergebnis liefert. Stattdessen soll – sofern hinsichtlich der Performanz keine gravierenden Probleme auftreten – mit jeder einzelnen Eingabe das Ergebnis sofort und „live“ aktualisiert werden. Diese Art der Interaktion soll dazu ermuntern, den Möglichkeitsraum spielerisch-explorativ zu erkunden, statt übermäßige Ehrfurcht vor dem Prozess zu haben. Dafür sind kurze, häufige Feedbackzyklen das Mittel der Wahl (vgl. Abbildung 6).

Abbildung 6: Dieses Diagramm veranschaulicht den geplanten Ablauf der Nutzung der Anwendung. Mit jeder eingegebenen Note wird sofort ein aktualisiertes Ergebnis eingeblendet, ohne dass dies gesondert angefordert werden muss. Dieses Verhalten soll zum Experimentieren verleiten und die explorative Nutzung fördern.

3.2.2. Bestandteile und Aufbau

Die wesentlichen zwei Aufgaben der Schnittstelle sind die Eingabe der Noten und die Ausgabe des Ergebnisses der Analyse. Die Eingabe lässt sich sinnvoll weiter unterteilen in die Eingabe der Kursfächer und der dazugehörigen Zeugnisnoten sowie die der Prü- fungsnoten. Die Ausgabe erfolgt als Liste von Fakten und bedarf deshalb keiner weiteren Unterteilung.

Es gibt je eine Zeugnisnote pro Kurs und Halbjahr. In jedem Fall gibt es vier Halb- jahre. Für die Zahl der Kurse gibt es an sich kein festes Maximum, allerdings ergeben sich aus der maximalen Wochenstundenzahl und den Einschränkungen bei der Kurswahl pragmatisch betrachtet eine maximale Anzahl an Kursen, die bei ca. 12–14 liegt. Für die Eingabe der Fächer und der Zeugnisnoten wäre ein stark lenkendes Eingabesystem denkbar, bspw. ein Assistent, der die Daten in einer festen Reihenfolge abfragt. Aller- dings besteht hier die Gefahr einer übermäßigen Modalisierung und Regulierung eines Prozesses, der vermutlich gar nicht so viel mentaler Unterstützung bedarf.

Stattdessen erscheint eine 5×12-Tabelle mit geeigneten Spaltenüberschriften (eine Spalte für die Fächerwahl, vier für die entsprechenden Halbjahre) übersichtlicher und verständlicher. Sie ist noch klein genug, um selbst auf einem Mobilgerät annähernd Platz zu finden, und unterstützt besser darin, die vorhandenen Informationen einzugeben.

Ähnliches gilt für die Eingabe der fünf Prüfungsnoten P1–P5. Die entsprechenden fünf Auswahlfelder nehmen nicht viel Platz ein und sollten deshalb zu jedem Zeitpunkt alle gleichwertig angezeigt werden.

Die Ausgabe wird zunächst so geplant, dass das Ergebnis der Analyse als Liste von Fakten textuell präsentiert wird. Ausgehend von der Feature-Liste lässt sich schätzen, dass die Anzahl der ausgegebenen kurzen Sätze mit hoher Wahrscheinlichkeit im einstelli- gen Bereich liegen wird, weshalb auch hierfür eine überschaubare Menge Platz ausreicht, die ggf. bei Bedarf vergrößert wird.

Die drei Hauptelemente sind zwar unterschiedlich groß, liegen aber alle in dem Bereich, indem sie zumindest auf einem PC immer noch innerhalb eines Anwendungsfensters angezeigt werden können. Auf mobilen Geräten, insbesondere kleineren Smartphones, muss die Anordnung so angepasst werden, dass alle Elemente ausreichend groß sind, um per Touch-Bedienung nutzergerecht manövriert werden zu können. Ein Entwurf für den Gesamtaufbau sowohl für PCs als auch für Mobilgeräte ist in Abbildung 7 zu finden.

Dieser Aufbau ermöglicht auf allen Ziel-Geräteklassen eine Verwendung weitgehend frei von Modi im Sinne von Raskin (2000), welche eine größere mentale Beanspruchung nach sich ziehen würden. Stattdessen bleibt zu jedem Zeitpunkt die Übersicht gewahrt und es gibt nur eine Ansicht auf die Daten.

Abbildung 7: Hier ist der Gesamtaufbau der Nutzungsschnittstelle visualisiert. (a) Der Aufbau für PCs und andere Geräte mit großen Bildschirmen ordnet die Elemente zweispaltig an und erreicht eine rechteckige Darstellung in einem typischen Anwendungsfenster. (b) Der Aufbau für mobile Geräte ist einspaltig, damit alle Elemente groß genug sind um komfortabel bedient zu werden. Zur Navigation zwischen den Bereichen wird gescrollt.

3.3. Papierprototypen-Tests

Die Konzeption der Nutzungsschnittstelle aus dem vorigen Abschnitt wurde in Form von Papierprototypen Nutzertests unterzogen (für detaillierte Informationen siehe Anhang C). Für die PC- und Mobil-Variante der Schnittstelle wurde jeweils ein Prototyp umgesetzt (vgl. Abbildung 8), mit denen Schülerinnen und Schüler des Johanneums (geplant waren n = 4, aus terminlichen Gründen wurden es n = 3) nach einer kurzen Einweisung in die Methodik und einer Anleitung zum Thinking Aloud4 (Lewis, 1982) ein Nutzerszenario durchgespielt haben.

Das Szenario umfasste die Eingabe einiger Zeugnisnoten, die tabellarisch vorgegeben wurden, sowie das Lesen und Verstehen der Ausgabe. Die Eingabe der Noten wurde nur für die ersten zwei Kurse Schritt für Schritt durchgeführt, danach wurde der Prozess durch den Versuchsleiter abgekürzt, da der Ablauf prinzipiell immer gleich ist und der Nutzen für die investierte Zeit nach zwei abgeschlossenen Kursen nicht mehr gegeben gewesen wäre.

Abbildung 8: Dies sind beispielhafte Ansichten der zwei Papierprototypen für die PC- bzw. Mobil-Variante der Nutzungsschnittstelle. Für weitere Bilder siehe Anhang C.2.

3.3.1. Ergebnisse

Der Verlauf der Tests war insgesamt sehr erfreulich (vgl. Anhang C.4). Die Probanden konnten bereits nach kurzer Zeit mit den Prototypen umgehen und das Szenario durchspielen, ohne dass Probleme aufgetreten wären, die ein Eingreifen des Versuchsleiters nötig gemacht hätten. Entsprechend ist das konstruktive Feedback der Probanden auf einem detaillierten Niveau und kann zur weiteren Verbesserung der Details der Schnittstelle genutzt werden.

• Römische Zahlen: Ein wiederkehrendes Problem waren die römischen Zahlen, die im Entwurf zur Kennzeichnung der Eingabeblöcke verwendet wurden. Tatsächlich ist Block 1 die offizielle Bezeichnung für die Zeugnisnoten und Block 2 die für die Prüfungsnoten, dieser Umstand ist jedoch in der Zielgruppe nicht allgemein bekannt. Deshalb, und weil sie in den Prototypen vermutlich visuell übermäßig dominant gestaltet waren, trugen die Ziffern immer wieder zur Verwirrung bei. Auch im Sinne der Übersichtlichkeit erscheint es sinnvoll, sie in der weiteren Realisierung der Anwendung schlicht wegzulassen.
• Elemente außerhalb des Bildschirms beim Mobil-Prototyp: Ein Proband äußerte Bedenken, ob auf dem Mobilgerät ersichtlich sei, dass man nach unten scrollen muss. Tatsächlich fehlt auf heutigen Mobilgeräten normalerweise die stetig sichtbare Scroll-Leiste, die auf Desktop-Systemen unter Anderem dazu dient, dies zu verdeutlichen. Vielleicht gibt es eine geeignete visuelle Kennzeichnung (z.B. einen sanften Verlauf nach schwarz am unteren Bildschirmrand) um zu signalisieren, dass die Ansicht unter dem Rand noch fortgeführt ist.
• Der Sinn des Ergebnisbereichs ist nicht erkennbar, solange noch keine Eingaben vorgenommen wurden: In den Prototypen ist der Ergebnisbereich bis auf das „Informationen“-Symbol komplett leer. Dies führte zu Verwirrung darüber, wozu der Bereich dient. Dies könnte z.B. durch einen textuellen Platzhalter behoben werden. Er könnte etwa lauten wie folgt: „Hier stehen später die Ergebnisse.“ Zwar geht diese Veränderung gegen den visuellen Minimalismus, aber in Anbetracht des Testergebnisses scheint das ein sinnvoller Kompromiss zu sein.
• Speichermöglichkeit: Die Prototypen enthielten keine Möglichkeit zum zielgerichteten Abspeichern der eingegebenen Daten. Für das Szenario war das zwar nicht nötig, aber ein Proband fragte trotzdem danach, wohl auch im Hinblick auf die wiederkehrende Verwendung der Anwendung bei neuen Noten. Das Konzept zur Persistierung verdient in jedem Fall weitere Aufmerksamkeit.
• Spekulative Noten: Ein Proband sprach die Möglichkeit an, Noten einzugeben, die noch nicht feststehen. Es scheint bei einigen Schülerinnen und Schülern so zu sein, dass Noten gerne schon vor der offiziellen Bekanntgabe geschätzt werden (z.B. anhand der Klausurnoten aus dem entsprechenden Halbjahr) und mit diesen Schätzungen schon mal die Konsequenzen exploriert werden. Unklar ist, ob das häufig genug vorkommt, um den Implementationsaufwand zu rechtfertigen. Die Idee ist aufgenommen, es wird jedoch dafür in Anbetracht der ohnehin kurzen Entwicklungszeit keine Anpassung der Feature-Liste vorgenommen.

3.4. Systemarchitektur

In Abschnitt 2.3.1 wurde bereits begründet, weshalb zur Umsetzung der Anwendung Web-Technologien verwendet werden. In diesem Kontext spielt die Wahl eines geeigneten Frameworks eine wichtige Rolle für die spätere Struktur des Programmcodes.

jQuery Mobile (Reid, 2011) ist ein weit verbreitetes, umfangreiches und gut unterstütztes JavaScript-Framework, das auf die Umsetzung von plattformübergreifenden Anwendungen ausgelegt ist, welche nicht nur auf traditionellen Geräten funktionieren, sondern auch auf modernen mobilen Geräten den Erwartungen gerecht werden. Primär erleichtert jQuery Mobile die Implementation von grafischen Nutzungsschnittstellen. Durch die unterliegende Basis von jQuery ist zusätzlich noch eine große Menge weiterer Funktionalität vorhanden, die nahtlos genutzt werden kann.

3.4.1. Events in JavaScript

Widgets und beliebige andere Elemente der Nutzungsschnittstelle können statisch im HTML-Code spezifiziert und üblicherweise mit einer eindeutigen ID versehen werden. Da die Anwendung vollständig auf dem Client läuft und keine Interaktion mit einem etwaigen Server stattfindet, werden die Daten anders als in HTML ansonsten üblich nicht per „Absenden“-Button als HTTP-Anfrage verschickt. Stattdessen werden alle für die Interaktion relevanten Elemente nach ihrer Initialisierung im JavaScript-Code mit einem sogenannten Event Handler verknüpft.

Die UI-Elemente – wie auch noch weitere Komponenten der Anwendung – haben eine standardisierte Schnittstelle für die Bereitstellung und Verarbeitung von Events (World Wide Web Consortium, 1997–2005). Bei der Initialisierung kann im Anwendungscode eine Funktion spezifiziert werden, welche dann an ein bestimmtes Objekt und einen passenden Event Handler gebunden wird. So ist es z.B. möglich, dass ein bestimmter fachlicher Code-Abschnitt jedes Mal ausgeführt wird, wenn sich der Inhalt eines Auswahlmenüs ändert. jQuery erleichtert den Umgang mit Events noch weiter und gestattet bspw. die komfortable Zuweisung eines einzigen Event Handlers an eine bestimmte Menge von UI-Elementen gemäß beliebig spezifizierbarer Kriterien.

Dank dieses Ansatzes entfällt die manuelle Überwachung der Eingabeelemente. Nötig ist lediglich die initiale Bindung der Event Handler, danach kann die Anwendung automatisch mit jeder Dateneingabe die Ergebnisse neu berechnen und anzeigen.

3.4.2. Abstraktion der Berechnungsregeln

Die Regeln, nach denen Noten vergeben und letztlich zur Abiturnote verrechnet werden, bilden den fachlichen Kern der Anwendung und verdienen besondere Aufmerksamkeit hinsichtlich der Architektur.

Einerseits sind sie zu komplex, um sie in einem simplen Datenformat oder einer einfachen deklarativen Sprache angeben zu können. Im Zuge der Berechnung müssen vielerlei Zahlen und Listen geführt und auf verschiedene Weisen verglichen, sortiert und ausgewertet werden. Dafür ist die Komplexität einer vollwertigen Programmiersprache nötig. Statt ohne gute Gründe eine weitere Programmiersprache in das System aufzunehmen, bietet sich die Lösung an, die Regeln direkt ebenfalls in JavaScript umzusetzen.

Andererseits muss dabei beachtet werden, dass die fachlichen Berechnungsregeln nicht unstrukturiert an verschiedenen Punkten im Programmcode verteilt sein sollten. Von Jahr zu Jahr und teilweise sogar von Schule zu Schule gibt es ggf. Veränderungen, die dazu führen, dass für verschiedene Schülerinnen verschiedene Regelsätze gelten.

Die Minimalanforderung ist zwar nur der aktuelle Regelsatz für das Johanneum Lüneburg, aber langfristig muss die Möglichkeit bedacht werden, verschiedene Regelsätze zur Auswahl anzubieten. Daraus ergibt sich, dass die Regeln klar von der sonstigen Programmlogik gekapselt werden müssen, idealerweise in einer eigenen Datei. In einem solchen Regelsatz wird dann spezifiziert, welche und wie viele Kurse bzw. Prüfungen absolviert werden müssen, wie diese benotet werden können und wie sich aus diesen Einzelnoten die Abiturnote ergibt. Wenn das in dieser Form gelingt, kann der Regelsatz zumindest recht einfach durch das Ersetzen einer Datei ausgetauscht werden, selbst wenn die Nutzungsschnittstelle darauf noch nicht ausgerichtet ist.

3.4. Name der Anwendung

In den bisherigen Abschnitten wurde die Benennung der Anwendung nicht thematisiert. Für die Programmierung muss der endgültige Name nicht zwingend bekannt sein, aber für die Veröffentlichung sollte ein prägnanter und leicht zu merkender Name vorhanden sein, um es den Nutzerinnen zu erleichtern, über die Anwendung zu sprechen. Für dieses Projekt gibt es zwar kein Werbe-Budget und kein starkes Bestreben nach möglichst großer Öffentlichkeitswirksamkeit, aber trotzdem sollte der Name nicht unbedacht gewählt werden.

Idealerweise transportiert der Name bereits die wichtigsten Informationen zum Verwendungszweck der Anwendung. Aus ihm sollte hervorgehen, dass sie sich an Abiturienten richtet und dass es sich um ein Werkzeug zur Planung und Selbstreflexion handelt.

Für ähnliche Projekte (vgl. Abschnitt 1.2) scheint sich „Abi-Rechner“ als Sammelbegriff eingebürgert zu haben, weshalb dieser Begriff als Eigenname eher ungeeignet ist. Das größte Abgrenzungsmerkmal dieser Anwendung von anderen Projekten ähnlicher Natur ist die Ausrichtung auf frühzeitige Analyse und den Blick in die Zukunft statt auf rückblickende Verifikation. Deshalb wird unter Erhalt des „Abi“-Präfixes Abi-Planer als Name für die Anwendung gewählt. Zu diesem Namen ist bisher kein anderes Projekt auffindbar.

Der Name mag etwas fantasielos wirken, zeichnet sich dafür jedoch durch ein hohes Maß an Selbstbeschreibungsfähigkeit aus. Er ist nicht auf das Johanneum Lüneburg beschränkt und lässt deshalb Raum für langfristig denkbare Erweiterungen der Zielgruppe (vgl. Abschnitt 7.3).

3: Die schlechtestmögliche Abiturnote wird nur deshalb trotz ihrer niedrigen Priorisierung durch die Umfrageteilnehmenden (vgl. Tabelle 2) hier so früh aufgeführt, weil die berechtigte Annahme besteht, dass die Implementation analog zur bestmöglichen Note sehr schnell möglich ist. Sollte sich diese Annahme als falsch erweisen, kann das Feature nach hinten verschoben werden.

4: Unter Thinking Aloud versteht man eine Methode, bei der Probanden gebeten werden, ihre Gedanken laut auszusprechen, während sie eine zu evaluierende Nutzungsschnittstelle verwenden. Das Ziel dabei ist, möglichst detaillierte Informationen zu den Problemen und Entscheidungsvorgängen des Probanden zu bekommen. Siehe auch Lewis (1982).

4. Realisierung

Dieses Kapitel beschreibt die Realisierung des Konzepts aus Kapitel 3. Dazu werden zunächst interessante Aspekte der technischen Umsetzung beschrieben, wobei jeweils gesondert auf die Nutzungsschnittstelle und die Persistierung eingegangen wird. Danach werden in Abschnitt 4.2 Details benannt, die sich erst im Laufe der praktischen Umsetzung ergeben haben, aber trotzdem erwähnenswert sind. Abschließend folgt dann noch ein Rückblick auf die Feature-Liste und eine kurze Zusammenfassung der Situation hinsichtlich des Nutzerfeedbacks während der Umsetzung.

4.1. Technische Umsetzung

Die technologische Basis einer modernen Web-Anwendung ist zunächst eine traditionelle Webseite. Bei der Entwicklung für das Web gilt normalerweise das Prinzip des Progressive Enhancement: Bedingt durch die heterogenen technischen Fähigkeiten verschiedener Endgeräte soll eine Webseite so strukturiert werden, dass sie auch auf älteren Geräten noch nutzbar ist, auch wenn das Gerät nicht die volle Nutzung aller neuen Technologien erlaubt. Deshalb gibt es in den meisten Web-Standards diverse sog. Fallback-Möglichkeiten, die einen differenzierten Verzicht auf bestimmte moderne Funktionalitäten erlauben, wenn das Gerät sie nicht unterstützt.

Ein Beispiel dafür ist das <noscript>-Element. In Browsern, die kein JavaScript unterstützen oder in denen es aus Sicherheitsgründen deaktiviert ist, wird stattdessen der Inhalt des <noscript>-Elements angezeigt. Bei diesem soll es sich um einen funktionalen Ersatz für die Teile der Seite handeln, die ohne JavaScript nicht funktionieren.

Im HTML-Hauptdokument des Abi-Planers befindet sich aus dem genannten Grund ein solches <noscript>-Element. Weil die clientseitige Berechnungslogik allerdings ohne eine vollwertige Skriptsprache wie JavaScript nicht realisierbar ist, befindet sich im <noscript>-Bereich lediglich ein Hinweis, dass der Abi-Planer nur mit aktiviertem JavaScript funktionsfähig ist.

Ansonsten enthält das statische HTML-Dokument (index.html) nur ein Minimum an übergeordneten Angaben zur Dokumentdarstellung und zu nachzuladenden Dateien. Der Hauptteil der Programmlogik findet sich in der JavaScript-Datei main.js, welche auch weitgehend den Aufbau der Nutzungsschnittstelle steuert.

In main.js wird gleich zu Beginn der mitgelieferte Regelsatz für die aktuell gültigen Vorschriften (rules-johanneum-2014.js) geladen. Auf dessen Basis wird dann die Nutzungsschnittstelle dargestellt und sonstige Inhalte (z.B. Dialogfenster) werden im Hintergrund generiert. Danach steht die Schnittstelle für Nutzereingaben zur Verfügung. Der Regelsatz spezifiziert ein GradeState-Objekt, welches ein Modell der eingegebenen Noten hält. Außerdem verfügt es über Methoden, um seinen aktuellen Zustand in eine Zeichenkette zu serialisieren bzw. den Zustand aus einer zuvor erzeugten Zeichenkette auszulesen. Dies ist hinsichtlich der Persistierung von großer Bedeutung und wird im Abschnitt 4.1.2 aufgegriffen.

Die Zusammenhänge zwischen den wichtigsten Dateien des Systems ist in Abbildung 9 dargestellt.

Abbildung 9: Dieses Diagramm beschreibt die Abhängigkeiten der verschiedenen Systemkomponenten. index.html bildet den Einstiegspunkt und verweist auf style.css sowie main.js. Der fachliche Regelsatz ist in rules-johanneum-2014.js gekapselt und wird nur von main.js referenziert. jQuery und jQuery Mobile bestehen aus mehreren JS- und CSS-Dateien, welche von index.html eingebunden und in main.js verwendet werden.

4.1.1. Nutzungsschnittstelle

Die Umsetzung der Nutzungsschnittstelle erfolgte nah an dem in Abschnitt 3.2 aufgestellten Entwurf. Abbildung 10 gibt einen Gesamteindruck.

Abbildung 10: Dies ist das Aussehen der fertigen Nutzungsschnittstelle. (a) Für Geräte mit ausreichen großen Bildschirmen wurde der zweispaltige rechteckige Aufbau umgesetzt. (b) Für Geräte mit kleinen Bildschirmen wandert die zweite Spalte unter die erste. Außerdem werden die meisten Widgets zur Erleichterung der Touch-Nutzung vergrößert dargestellt.

Die Strukturelemente der Schnittstelle werden im JavaScript-Code dynamisch anhand des Regelsatzes generiert und dem HTML-Dokument hinzugefügt. Für die visuelle Gestaltung wird hauptsächlich CSS verwendet. Die zwei Icons oben rechts werden als Bilddateien im SVG-Format eingebunden.

Im Bereich des Webdesigns hat sich das sog. Responsive Webdesign (Marcotte, 2010) als Ansatz für den Umgang mit verschiedenen Geräteklassen etabliert. Dabei wird in den CSS-Angaben z.B. die Bildschirmbreite abgefragt und die Darstellung der Elemente wird entsprechend angepasst. jQuery Mobile unterstützt Responsive Webdesign sehr gut (The jQuery Foundation, 2013–2014). Dank der mitgelieferten Responsive Grids konnten die zwei Spalten, die sich an die Bildschirmgröße anpassen, sehr leicht umgesetzt werden.

Bei Klick bzw. Berührung eines der zwei Icons oben rechts öffnet sich ein Popup. Das Zahnrad-Icon öffnet ein Einstellungen-Dialog, in dem die persistente Datenspeicherung aktiviert oder deaktiviert werden kann sowie ein Link zur Weitergabe der eingegebenen Daten erzeugt werden kann (ausführlichere Erläuterungen zu diesen Aspekten folgen im nächsten Abschnitt). Das Information-Icon öffnet ein Dialogfenster mit Kontaktdaten und sonstigen Informationen über Abi-Planer.

Wie schon in der Entwurfsphase geplant, gibt es keinen „Auswerten“-Button oder ein sonstiges Signal, das den Analysevorgang startet. Stattdessen wird mit jeder Nutzereingabe eine Analyse durchgeführt und ich Echtzeit angezeigt. So erhalten die Nutzerinnen jederzeit Feedback.

4.1.2. Persistierung

In Kapitel 3 wurden bereits viele Gedanken und Ideen zum Thema Persistierung gesammelt. In diesem Abschnit wird beschrieben, wie die Grundfrage, wie die eingegebenen Daten vor versehentlichem Verlust (oder versehentlicher Speicherung) geschützt werden können, in der fertigen Anwendung beantwortet ist.

Bei jeder Eingabe einer Note wird das interne Modell entsprechend aktualisiert. Anschließend wird der komplette Zustand serialisiert und im Fragmentbezeichner der URL abgelegt. Angenommen, der Abi-Planer sei im Web unter der Adresse http://abi.example.com/ gehostet. Dann könnte die Adresszeile des Browsers nach einigen Eingaben z.B. den Inhalt http://abi.example.com/#zcUBAHi3AwA= haben.

Der ursprüngliche Sinn des Fragmentbezeichners besteht darin, URLs erzeugen zu können, die auf einen bestimmten Punkt innerhalb des Dokuments verweisen. Moderne Web-Anwendungen nutzen ihn teilweise für den Navigationszustand. Der Grund, warum er dafür geeignet ist, liegt im Verhalten der Browser: Wird bspw. ein Lesezeichen erzeugt oder die aktuelle Seite anderweitig gespeichert, bleibt der Fragmentbezeichner erhalten und der Zustand kann wiederhergestellt werden. Statt eines bestimmten Orts in einem Dokument wird er vom Abi-Planer für den Erhalt der eingegebenen Daten genutzt. Über ein Lesezeichen oder über eine textuelle Sicherung der URL kann die Nutzerin die Eingabedaten nicht nur für sich selbst sichern, sondern auch komfortabel auf andere Geräte übertragen oder anderen Personen zur Verfügung stellen. Dies ist insbesondere für die Beratung von Bedeutung, da auf diese Weise ein bereits ausgefülltes Formular komfortabel „mitgebracht“ werden kann, ohne dass die Gefahr einer versehentlichen persistenten Speicherung besteht.

Der Link kann aus der Adresszeile des Browsers oder aus einem dafür vorgesehenen Textfeld im Einstellungen-Dialog kopiert werden. Dort gibt es auch die Möglichkeit, zu der URL einen QR-Code zu erzeugen, der dann ebenfalls zur Übertragung auf andere Geräte dienen kann. Wird der Fragmentbezeichner von der URL entfernt und die Seite neu geladen, sind die Eingabefelder wieder im Ausgangszustand.

Standardmäßig erfolgt keine persistente Speicherung der Daten. Dies ist eine bewusste Entscheidung, die darauf beruht, dass Formulardaten im Web normalerweise nicht automatisch abgespeichert werden. Mit dieser Konvention sollte eine Web-Anwendung nicht ohne gute Gründe brechen, insbesondere wenn es um potenziell vertrauliche Daten geht.

Im Einstellungen-Dialog gibt es eine Checkbox für die persistente Speicherung der Daten, welche standardmäßig nicht aktiviert ist. Wird diese Checkbox von der Nutzerin aktiviert, werden die eingegebenen Noten mit sofortiger Wirkung persistent gespeichert. Auch nach einem Neustart des Browsers oder des Geräts werden sie automatisch wieder geladen. Ist die persistente Speicherung aktiviert, wird der Zustand nicht länger im Fragmentbezeichner gespeichert. Dies dient einerseits als zusätzlicher visueller Indikator, dass der Zustand nicht mehr von der URL abhängt, und schützt andererseits vor einer möglichen versehentlichen Weitergabe der Daten.

Für die persistente Speicherung wird die standardisierte Schnittstelle für Web Storage verwendet. Diese erlaubt eine persistente Speicherung von geringen Datenmengen im Browser, welche vor Zugriffsversuchen durch Skripte auf anderen Domains geschützt sind. Außerhalb der Interaktion mit dem Abi-Planer muss dafür keine explizite Erlaubnis eingeholt werden und es gibt keine irritierenden Warnhinweise.

4.2. Entwurfsentscheidungen

Im Laufe der Umsetzung sind diverse Entwurfsentscheidungen getroffen worden, die zum Zeitpunkt der Konzeption noch nicht bedacht wurden. In diesem Abschnitt werden einzelne interessante Entscheidungen aufgeführt und begründet.

4.2.1. Visueller Minimalismus

Die in den Nutzertests mehrfach kritisierten römischen Zahlen in den Papierprototypen (vgl. Anhang C.4) sind ein Beispiel für ein zwar nicht falsches, aber auch nicht hilfreiches visuelles Element. Im Sinne der in Abschnitt 3.2.1 bereits genannten Fokussierung auf gelegentliche Nutzung und Einsteigerfreundlichkeit wurde die Nutzungsschnittstelle in der Entwicklung ausgehend von den Prototypen bewusst minimalistisch gestaltet.

Die visuelle Gestaltung verzichtet auf unnötige Linien und ablenkende Details und setzt stattdessen auf Negativraum und prägnante Darstellung. Ein gutes Beispiel dafür ist die zeitliche Entwicklung des Prüfungsblocks (vgl. Abbildung 11).

Abbildung 11: Dieses Bild zeigt schematisch die visuelle Gestaltung des Prüfungsbereichs über die Zeit. Zu Beginn gab es noch zu jeder Prüfung die Prüfungsnummer, das Fach und ein zunächst leeres Auswahlmenü für die Note. Im Laufe der Entwicklung wurden zunächst die Fächerbezeichnungen entfernt und schließlich die Prüfungsnummer mit dem Auswahlmenü kombiniert.

Zu Beginn gab es zu jeder Prüfung sowohl ein Auswahlmenü für die Note als auch ein dazugehöriges Textelement bestehend aus der Prüfungsnummer und dem Fach, sofern im Zeugnisnoten-Block bereits angegeben. Das Fach wurde als erstes entfernt, da es sich dabei um eine doppelt vorhandene Information handelte. Die Zuordnung von Prüfungsfächern erfolgt im ersten Block und normalerweise ändern sie sich im Lauf der Oberstufe nicht, weshalb eine zusätzliche textuelle Erinnerung unnötig ist.

In einem zweiten Schritt wurden das Auswahlmenü und die Prüfungsnummer zusammengelegt. Die Prüfungsnummer ist nun der Standard-Inhalt des noch leeren Auswahlmenüs. Dass die Prüfungsnummer nicht mehr zu sehen ist, sobald eine Note eingetragen ist, ist potenziell ein kleiner Nachteil für die Selbstbeschreibungsfähigkeit. Allerdings ist die Anzahl der Prüfungsnoten so klein, dass sie in aller Regel noch immer schnell abgezählt werden können. Auf der anderen Seite gewinnt die Übersichtlichkeit und die Nutzergerechtheit auf sehr kleinen Bildschirmen, weshalb die Entwicklung insgesamt als Gewinn gewertet wird.

4.2.2. Kurze oder lange Fachbezeichnungen

Die Fächer-Auswahl in der linken Spalte erfolgt wie auch die Noten-Auswahl über einfache Auswahlmenüs. Für Geräte mit hinreichend großen Bildschirmen ist es kein Problem, die Fächer dort mit ihren vollen Namen (z.B. „Mathematik“) aufzulisten. Auf kleineren Geräten ist die Situation ggf. anders, es gibt für jedes Auswahl-Widget weniger horizontalen Platz. Aus dieser Situation heraus ergab sich die Idee, statt der ausgeschriebenen Fächer die offiziellen Abkürzungen (z.B. „Mathematik“ → „Ma“) anzugeben.

Bei dem Versuch der Implementation dieser Idee zeigte sich, dass die technischen Mittel des Responsive Webdesign (vgl. Abschnitt 4.1.1) innerhalb der Auswahl-Widgets nicht verwendet werden können. Eine dynamische Anpassung des Widget-Inhalts hätte deshalb unter größerem Implementationsaufwand mit einem Resize-Event verbunden und im JavaScript-Code umgesetzt werden müssen. Bei einem Probelauf wurde das zusätzliche Problem offenbar, dass in einem solchen Fall nicht nur der aktuell dargestellte Inhalt des Widgets abgekürzt würde, sondern auch die Auswahl-Optionen bei Nutzung des Widgets.

Letztlich wurde die Entscheidung getroffen, in den Auswahlmenüs grundsätzlich die ausgeschriebenen Fächer anzugeben. Zwar werden die Bezeichnungen auf kleinen Bildschirmen teilweise abgeschnitten, sie sind aber dann immer noch recht gut unterscheidbar. Der Nutzbarkeits-Gewinn durch die ausgeschriebenen Fächer in den Auswahlmenüs überwiegt das geringere Problem der abgeschnittenen Fach-Bezeichnungen.

4.2.3. Gestaltung der Auswahlmenüs

In den Papierprototypen wurden die Auswahlmenüs jeweils unterschiedlich umgesetzt: Im PC-Prototyp wurden sie als traditionelle Drop-Down-Menüs präsentiert, im Mobil-Prototyp wurden stattdessen modale Dialoge mit größeren Buttons genutzt (vgl. Anhang C.2).

Für die endgültige Umsetzung wurde davon abgesehen, das Aussehen der Auswahlmenüs vorzuschreiben. Stattdessen werden sie als HTML-Elemente auf einem hohen Abstraktionsniveau spezifiziert und es wird dem Endgerät bzw. dem Browser überlassen, wie die Auswahl konkret präsentiert wird. In allen modernen PC-Browsern geschieht dies letztlich dann ohnehin als Drop-Down-Menü. In Smartphone-Browsern wird üblicherweise eine Auswahl-Liste im Vollbildformat präsentiert.

Dadurch, dass dieses Entwurfsdetail dem Gerät überlassen werden kann, ist einerseits Entwicklungsaufwand gespart worden und andererseits ein höheres Maß an Zukunftssicherheit erhalten geblieben.

4.3. Rückblick auf die Feature-Liste

In Abschnitt 3.1 wurde eine Feature-Liste aufgestellt, welche die geplanten Features zu Feature Sets zusammengefasst und in ihrer Reihenfolge priorisiert hat. Die Entwicklungszeit reichte zwar nicht, um alle Feature Sets umzusetzen, aber ein großer Teil der Liste konnte abgearbeitet werden:

Feature Set 1 ✓

• Eingabe von Zeugnis- und Prüfungsnoten

Feature Set 2 ✓

• Berechnung der aktuellen Durchschnittsnote ✓
• Berechnung der bestmöglichen Abiturnote ✓
• Berechnung der schlechtestmöglichen Abiturnote ✓

Feature Set 3 ✓

• Sichern der Eingabedaten über mehrere Sessions hinweg ✓
• Löschen der erstellten Sicherung ✓

Feature Set 4 ✓

• Erkennen und Darstellen von kritischen Kursen ✓5

Feature Set 5 ✓

• Erfüllung der Kriterien zur Abiturzulassung erkennen ✓

Feature Set 6 ✗

• Erfüllung der Kriterien zur Fachhochschulreife erkennen ✗

Feature Set 7 ✗

• Beratungs-Modus mit anders gestalteten Hinweisen ✗

Lediglich die letzten zwei Feature Sets wurden nicht umgesetzt. Die Feststellung der Erreichung der Fachhochschulreife erwies sich als überraschend komplex, diese Anforderung sollte jedoch mit weiterer Investition von Entwicklungszeit lösbar sein. Der Beratungs-Modus aus Feature Set 7 wurde nicht weiter verfolgt.

4.4. Nutzerfeedback während der Umsetzung

In Abschnitt 1.3 wurde in Aussicht gestellt, dass während der Umsetzungsphase informell Feedback von einzelnen Nutzerinnen eingeholt werden würde. Dafür wurde kein formaler Prozess eingesetzt, sondern es gab die Hoffnung, mit den Teilnehmenden der Nutzertests in Kontakt zu bleiben.

Bereits in den Nutzertests war eine Testperson ausgefallen (vgl. Anhang C.4), eine weitere Probandin verneinte die Frage, ob weiterer Kontakt per E-Mail möglich wäre. Somit war die Gruppe der potenziellen Feedback-Gebenden von Beginn an sehr klein. Die verbleibenden zwei Probanden wurden in unregelmäßigen Abständen per E-Mail über den Stand der Entwicklung informiert und hatten jederzeit Zugriff auf eine aktuelle Version des Abi-Planers. Leider gab es von ihnen kein selbst-initiiertes Feedback und auch auf Rückfragen keine verwertbare konstruktive Kritik. Den zwei Probanden soll hieraus kein Vorwurf gemacht werden – schließlich war die Teilnahme freiwillig und unvergütet – aber für den UCD-Teil des Entwicklungsprozesses ist es bedauerlich. Für ähnliche zukünftige Projekte muss hier ein besserer Ansatz gefunden werden.

5: Bei genauerem Studium der relevanten Verordnung ergab sich die Erkenntnis, dass es nur sehr selten isolierte kritische Kurse gibt. Stattdessen gibt es Bereiche, in denen nur eine gewisse Anzahl Kurse mit weniger als 5 Punkten abgeschlossen werden darf. Die Anwendung trägt dem Rechnung.

5. Dialogbeispiele

In diesem Kapitel wird anhand des lauffähigen Abi-Planers ein typischer Programmablauf demonstriert und mit einer Reihe von Screenshots der Anwendung veranschaulicht. In diesem Beispiel liegen der Nutzerin die Zeugnisnoten für die ersten drei Halbjahre der Oberstufe vor und sie möchte einen Zwischenstand erfahren. Wir gehen von der Nutzung eines Desktop-PCs aus, die Dialoge in der Mobil-Version sind bis auf die einspaltige Anordnung und kleine ergonomische Anpassungen identisch.

Beim Start des Abi-Planers ist das Eingabeformular komplett leer (vgl. Abbildung 12). Links sind die fünf Prüfungsfächer und die Ergänzungskurse wählbar, im Rest der linken Programmhälfte können Zeugnisnoten eingetragen werden. Im Beispielszenario liegen noch keine Prüfungsnoten vor, deshalb wird der Block oben rechts leer bleiben. Auch der Ergebnis-Block ist zu Beginn noch leer.

Abbildung 12: Dieses Bild zeigt die Start-Ansicht des Abi-Planers. Es wurden noch keine Daten eingegeben.

Die Reihenfolge, in der die Daten eingegeben werden, spielt für das Ergebnis keine Rolle. Es liegt nahe, Zeugnis für Zeugnis durchzugehen und die Noten somit spaltenweise einzutragen, jede andere Methode funktioniert jedoch genau so gut. Mit jeder Eingabe verändert sich das angezeigte Ergebnis (vgl. Abbildung 13). Die beste bzw. schlechteste erreichbare Note startet bei 1,0 bzw. 4,0 und nähert sich mit jeder eingetragenen Note mehr an die gewichtete Durchschnittsnote an.

Abbildung 13: In diesem Bild sind die Kurse und die bisher bekannten Noten eingetragen worden. Mittig rechts wird das Ergebnis angezeigt.

Die Analyseergebnisse sind vielfältig. Die gewichtete Durchschnittsnote zeigt eine Prognose der Abiturnote, ebenso sind die beste und schlechteste noch erreichbare Note angegeben. Es werden die Einbringungsverpflichtungen aufgezählt, die im vierten Oberstufensemester mindestens noch erfüllt werden müssen, um zum Abitur zugelassen zu werden. Da bisher alle Ergänzungskurse bestanden wurden, fehlt nur noch eine Ergänzungskurs-Note für das Mindestmaß der Abiturzulassung. Der Hinweis, dass in den Prüfungen noch nicht ausreichend Punkte absolviert worden sind, ist in Anbetracht der noch fehlenden Prüfungsnoten nicht verwunderlich.

Dieses Analyseergebnis soll nun abgespeichert und per E-Mail an weitere Personen übermittelt werden – etwa an eine gute Freundin oder an die Eltern. Beides funktioniert über den Einstellungen-Dialog, der über das Zahnrad-Icon in der oberen rechten Ecke erreicht werden kann (vgl. Abbildung 14). Dort kann zunächst das Häkchen gesetzt werden, welches bewirkt, dass die eingegebenen Noten bei der nächsten Verwendung automatisch wieder zur Verfügung stehen. Diese Einstellung ist sofort wirksam und erfordert keine weitere Bestätigung.

Abbildung 14: Hier ist der Einstellungen-Dialog zu sehen, in dem die eingegebenen Daten persistiert oder weitergegeben werden können.

Danach kann der Link aus der Textzeile am unteren Rand des Dialogs kopiert werden. Er wird beim Klicken auf die Zeile automatisch markiert und kann sofort kopiert werden, sei es per Drag & Drop, per Rechtsklick-Kontextmenü oder per Tastaturkürzel. Das Dialogfenster kann danach per Klick auf das „ד oben rechts geschlossen werden.

Der Abi-Planer bietet außerdem die Möglichkeit, den Link direkt in einen QR-Code umzuwandeln um ihn z.B. von einem PC auf ein Smartphone zu übertragen. Diese Möglichkeit wird im Beispielszenario nicht genutzt, wäre aber nur einen Klick entfernt. Abschließend kann mittels eines Klicks auf das „i“-Icon ein Informationsfenster aufgerufen werden (vgl. Abbildung 15). Dieses Fenster zeigt zunächst den Programmnamen und den verwendeten Regelsatz (derzeit noch nicht nutzerseitig wählbar). Es folgt ein Warnhinweis, dass die Entwicklung der Anwendung noch nicht abgeschlossen ist und dass Fehler enthalten sein können, für die keine Haftung übernommen werden kann. Als Urheberrechtshinweis wird eine Kopie der MIT/X11-Lizenz mitgeliefert.

Abbildung 15: Hier ist der Einstellungen-Dialog zu sehen, in dem die eingegebenen Daten persistiert oder weitergegeben werden können.

Damit ist bereits der komplette Funktionsumfang dargestellt. Auf Mobilgeräten funktioniert der Abi-Planer bis auf kleine Gestaltungsunterschiede identisch. Alle zentralen fachlichen Funktionen ergeben sich aus der Hauptansicht heraus, die jederzeit übersichtlich bleibt.

6. Evaluation

Der UCD-Prozess fordert eine primäre Ausrichtung auf die Wünsche und Vorstellungen der Zielgruppe. In der Analyse- und der Konzeptionsphase wurden die empirischen Ergebnisse aus dem Vorgespräch (vgl. Anhang A) und der Online-Umfrage (vgl. Anhang B) umfassend ausgewertet und für die Sicherstellung einer hohen Gebrauchstauglichkeit eingesetzt.

In Abschnitt 1.3 wurde bereits erläutert, dass eine empirische Evaluation der fertigen Anwendung mit Sicherheit ebenfalls sinnvoll wäre, jedoch aus Zeitgründen nicht im Rahmen dieser Arbeit durchgeführt wird. Stattdessen wird in diesem Kapitel eine kurze analytische Evaluation vorgenommen6. Zunächst wird die Anwendung anhand der Kriterien aus der DIN EN ISO 9241-110 (Grundsätze der Dialoggestaltung) untersucht, danach wird ein Rückgriff zu den Personas aus Abschnitt 2.2.3 gemacht und die Nutzung aus deren jeweiliger Sicht beschrieben.

6.1. Evaluation anhand von Kriterien der Dialoggestaltung

Die ISO-Norm 9241-110 definiert sieben Kriterien für nutzergerechte Gestaltung von Dialogsystemen. Im Folgenden wird zu jedem dieser Kriterien beschrieben, wie gut die implementierte Version des Abi-Planers es erfüllt und in welcher Hinsicht ggf. noch Raum für Verbesserungen besteht.

Aufgabenangemessenheit

Die ISO-Norm verordnet für dieses Kriterium einen möglichst genauen Zuschnitt der Funktionalität auf die fachliche Aufgabe und eine Minimierung von aus Nutzersicht unnötigen Interaktionen. Der Abi-Planer wurde anhand der Wünsche der Zielgruppe genau auf die Aufgabe der Noten-Auswertung zugeschnitten, im normalen Nutzungsfluss der Anwendung gibt es keinerlei Interaktionen, die nicht konkret diesem Ziel dienen. Weiterführende Aktionen (Persistierung etc.) sind vorhanden, blockieren jedoch nie die Kernaufgabe. Insgesamt kann dem Abi-Planer ein sehr hohes Maß an Aufgabenangemessenheit zugeschrieben werden.

Selbstbeschreibungsfähigkeit

Den Schülerinnen und Schülern der gymnasialen Oberstufe sind die Grundzüge des Notensystems – welche Noten es gibt und wann man sie bekommt – hoffentlich vertraut. Ein grundlegendes Verständnis ist für die Verwendung des Abi-Planers vermutlich unverzichtbar. Die Anwendung hat glücklicherweise nur wenige Abläufe, die über das Auswählen in klassischen Auswahlmenüs hinausgehen, weshalb nur ein Minimum an technischen Kenntnissen vorausgesetzt wird. Die Noteneingabe ist mit großem Abstand die Interaktionsmöglichkeit, die (im Vergleich mit den zwei Icons oben rechts) am meisten ins Auge fällt und deshalb zum Ausprobieren einlädt. Darauf folgt direkt die Rückmeldung des Zwischenergebnisses durch die Anwendung. Somit sind alle Voraussetzungen für eine gelungene explorative erste Nutzung ohne Anleitung gegeben. Die Selbstbeschreibungsfähigkeit wäre ggf. durch ein explizites Tutorial und weitere schriftliche Erklärungen und Hilfestellungen zum Ablauf der Nutzung noch zu steigern.

Lernförderlichkeit

Ein Ziel der Anwendungsentwicklung sollte sein, den Lernaufwand möglichst gering zu halten, der der produktiven und effizienten Nutzung der Anwendung vorangeht. Dabei können Hilfesysteme eine Rolle spielen, die komplexe und nicht auf Anhieb ersichtliche Prozesse verständlich erklären und kontextrelevante Unterstützungen bieten. Bis auf die zwei kurzen erläuternden Texte im Einstellungen-Dialog enthält der Abi-Planer derzeit keinerlei Hilfesysteme oder Tutorials. Der geringe Funktionsumfang und die Übersichtlichkeit der Anwendung sorgen dafür, dass diese Schwäche nicht sehr ins Gewicht fällt, aber gemessen an diesem Gestaltungskriterium hat die Anwendung deutlich erkennbares Verbesserungspotenzial.

Die Berechnungsregeln für die Abiturnote spielen in der Anwendung eine zentrale Rolle. Derzeit ist bei der Nutzung nur das Ergebnis der Berechnungen zu sehen. Es wäre denkbar, stattdessen auch die zugrundeliegenden Regeln aufzubereiten und verständlich darzustellen, um dem Anwenderkreis die Möglichkeit zur Weiterbildung zu geben. Im Sinne der Lernförderlichkeit wäre das ein lohnenswertes Ziel.

Steuerbarkeit

Die umfassende Steuerbarkeit des Dialogs ist eine große Stärke des Abi-Planers. Jede mögliche Aktion der Anwendung ist eine Reaktion auf eine Nutzereingabe, es gibt keine geführten Abläufe und nur sehr wenige modale Dialoge. Es ist zu erwarten, dass die Anwendung das Gefühl auf Nutzerseite, die Kontrolle zu haben und den Dialog zu steuern, nur minimal beeinträchtigt.

Erwartungskonformität

Die Erwartungskonformität beschreibt die Nähe des Verhaltens der Anwendung zum inneren Modell des Nutzers sowie die interne Konsistenz und Widerspruchsfreiheit der Anwendung. Da der Abi-Planer kein bestehendes technisches System ersetzt, gibt es auf der technischen Ebene keine Erwartungshaltungen. Die Anwendung orientiert sich grob an bestehenden Papierformularen, was das Umdenken erleichtern sollte. Bei der Entwicklung wurde darauf Wert gelegt, dass das Verhalten der Anwendung stets möglichst wenig überraschend ist. Zwar können Erwartungen subjektiv sehr verschieden sein, aber generell betrachtet dürfte der Abi-Planer hinsichtlich Konsistenz mit vorhandenen Strukturen und Modellen auf einem guten Weg sein.

Individualisierbarkeit

Im Einstellungen-Dialog kann die Entscheidung getroffen werden, ob die eingegebenen Daten auf dem jeweiligen Gerät dauerhaft gespeichert werden sollen, um beim nächsten Zugriff wieder zur Verfügung zu stehen. Das ist derzeit die einzige Möglichkeit zur Individualisierung des Abi-Planers. Es wären durchaus weitere Features denkbar, die Individualisierung sinnvoll nutzen, bspw. könnten persönliche Ziele gesetzt und später überprüft werden, oder es könnte Möglichkeiten zur visuellen Anpassung der Anwendung geben, was auch der Barrierefreiheit zugute käme. Im Hinblick auf Individualisierbarkeit gibt es viel Spielraum für Verbesserungen.

Fehlertoleranz

Im Einstellungen-Dialog kann die Entscheidung getroffen werden, ob die eingegebenen Daten auf dem jeweiligen Gerät dauerhaft gespeichert werden sollen, um beim nächsten Zugriff wieder zur Verfügung zu stehen. Das ist derzeit die einzige Möglichkeit zur Individualisierung des Abi-Planers. Es wären durchaus weitere Features denkbar, die Individualisierung sinnvoll nutzen, bspw. könnten persönliche Ziele gesetzt und später überprüft werden, oder es könnte Möglichkeiten zur visuellen Anpassung der Anwendung geben, was auch der Barrierefreiheit zugute käme. Im Hinblick auf Individualisierbarkeit gibt es viel Spielraum für Verbesserungen.

6.2. Evaluation anhand der Personas

Die Personas aus Abschnitt 2.2.3 dienen in diesem Abschnitt als Vertreter für ihre jeweiligen Nutzergruppen. Im Folgenden wird beschrieben, wie sie mit dem Abi-Planer zurechtkommen und in welchen Aspekten evtl. Probleme auftreten. Auf diese Weise wird die Gebrauchstauglichkeit der Anwendung für die entsprechende Nutzergruppe untersucht.

Miriam Schütz

Miriam hat keine Schwierigkeiten, den Link zum Abi-Planer auf ihrem Smartphone oder ihrem Laptop zu öffnen. Dadurch, dass sie viel Erfahrung mit dem World Wide Web hat, findet sie sich sofort zurecht.

Sie ist begeistert von den Prognosen und Analyseergebnissen der Anwendung. Endlich hat sie etwas mehr Gewissheit über die Entwicklung ihres Abiturs. Nachdem sie alle bisherigen Noten eingegeben hat, sucht sie nach einer Möglichkeit, die Daten abzuspeichern. Nach einer kurzen Suche wird sie fündig und speichert ihre Daten auf ihrem Smartphone ab. Schnell findet sie auch den Weg, sie auf ihren Laptop zu übertragen. Ihr einziger offener Wunsch wäre eine Unterstützung dabei, die Daten auf den beiden Geräten synchron zu halten.

Thomas Möller

Das Spannende an diesem Abi-Planer ist für Thomas die Möglichkeit, Gewissheit über seine bevorstehende Abiturzulassung und die Wichtigkeit der Mathe-Noten zu bekommen. Er ist überrascht, wie schnell und flüssig die Anwendung auf seinem PC läuft, obwohl seine Internetverbindung ziemlich langsam ist. Nachdem er ein paar Noten eingetragen hat, fällt ihm die Auflistung der Einbringungsverpflichtungen auf. Auch weist ihn der Abi-Planer darauf hin, dass er innerhalb der Prüfungskurse 1 bis 3 keinen weiteren Unterkurs haben darf – gut zu wissen! Er erfährt auch, dass er alle vier Halbjahre seines Mathe-Kurses ins Abitur einbringen muss, weshalb er sich keine groben Fehltritte erlauben darf.

Nachdem er diese Dinge erfahren hat, schließt er den Abi-Planer wieder. Über das Speichern seiner Daten hat er sich keine Gedanken gemacht, aber es ist für ihn auch nicht nötig, da jetzt alle seine Fragen beantwortet sind. Falls er seinen PC demnächst verkauft, besteht keine Gefahr, dass seine Zeugnisnoten der falschen Person in die Hände fallen.

Thomas denkt nach der einmaligen Nutzung nicht mehr an den Abi-Planer. Er hat seine Aufgabe schnell und zuverlässig erfüllt.

Gunda Steinbiss

Für Gunda ist der Abi-Planer ein Geschenk. Sie erkennt sofort die Möglichkeiten, in ihrer Beratungstätigkeit jede Menge Zeit zu sparen. Bevor sie sich auf die Anwendung verlässt, wird sie noch genauer überprüfen müssen, ob die Ergebnisse auch tatsächlich immer korrekt sind. Zunächst spielt sie aber nur ein wenig damit und erfreut sich an der blitzschnellen Auswertung.

Sie braucht eine Weile, um das mit den in der Web-Adresse gespeicherten Noten zu verstehen, aber nachdem sie das verinnerlicht hat, sieht sie schnell die Vorteile für ihre Arbeit: Ihre Schützlinge könnten damit das in der Beratung erstellte Ergebnis komfortabel mit nach Hause nehmen, oder sie könnten bereits eines zur Beratung mitbringen. Gunda selbst könnte sich eine Datenbank von archetypischen Fällen anlegen um bei Bedarf ein passendes Beispiel griffbereit zu haben.

Sie ist sehr erfreut über diese Möglichkeit zur Arbeitserleichterung. Dummerweise funktioniert der Abi-Planer aufgrund der Sicherheitsbestimmungen noch nicht auf ihrem Büro-Rechner, aber dieses Problem sollte sich durch ein Gespräch mit den Administratoren schnell klären lassen.

6: Idealerweise wäre eine Evaluation dieser Art von einer Person zu erstellen, die nicht selbst an der Entwicklung der Anwendung beteiligt war. Leider bietet die Bachelorarbeit dafür allerdings nicht den richtigen Rahmen, so dass auch die Evaluation vom Autor durchgeführt wird – natürlich mit größtmöglicher emotionaler Distanz.

7. Zusammenfassung und Ausblick

In diesem Kapitel wird zunächst eine Zusammenfassung darüber gegeben, wie die Entwicklung des Abi-Planers verlaufen ist und welche Ziele erreicht bzw. nicht erreicht worden sind. Danach werden offene Punkte beschrieben, die nicht im Laufe dieser Arbeit geklärt worden sind. Am Ende wird ein Ausblick gegeben, der eine mögliche Zukunftsperspektive für den Abi-Planer beschreibt.

7.1. Zusammenfassung

In dieser Arbeit wurde eine Anwendung entwickelt, die es Schülerinnen und Schülern der gymnasialen Oberstufe in Niedersachsen ermöglicht, ihre bisher vorliegenden Zeugnis- und Prüfungsnoten zu analysieren und diverse Erkenntnisse daraus zu ziehen. Der Abi-Planer grenzt sich vor allem durch seinen Fokus auf zukunftsgerichtete Interpretation und Prognosen von anderen vergleichbaren Produkten ab.

Die Entwicklung erfolgte nach einem Prozess, der Anleihen beim User Centered Design (Norman & Draper, 1986) und beim Feature Driven Development (Palmer & Felsing, 2002) macht. Bereits in der Analyse- und der Konzeptionsphase wurde ein hoher Grad der Nutzerzentrierung angestrebt. Dazu wurden ein Vorgespräch mit einem Experten sowie eine Online-Umfrage unter den Schülerinnen und Schülern durchgeführt. Beide Methoden lieferten viele wertvolle Impulse für die Konzeption.

Auf Basis der aus den Analyseergebnissen entwickelten Use Cases wurde eine priorisierte Feature-Liste erstellt und ein Gesamtkonzept entworfen. Die Nutzungsschnittstelle wurde als Papier-Prototyp mit einigen Probanden aus der späteren Zielgruppe getestet. Die Ergebnisse dieser Testläufe trugen weiter zur Verbesserung des Konzepts bei.

In der Entwicklungsphase konnten fünf der geplanten sieben Feature Sets umgesetzt werden. Die Anwendung ist in HTML und JavaScript implementiert, nutzt die Vorteile von Responsive Webdesign und weist auf Smartphones sowie auch auf PCs und anderen Endgeräten eine hohe Gebrauchstauglichkeit auf.

Aus Zeitgründen wurde keine empirische summative Evaluation durchgeführt. Stattdessen erfolgte eine analytische Evaluation anhand der DIN EN ISO 9241-110 sowie anhand von drei zuvor erstellten Personas. Die Ergebnisse dieser Evaluation sind insgesamt als positiv zu werten.

Im Rahmen dieser Arbeit konnte nicht jeder Idee nachgegangen und nicht jede Frage restlos geklärt werden. Entsprechend gibt es diverse offene Punkte, welche im folgenden Abschnitt thematisiert werden. Trotzdem ist das Endergebnis hinsichtlich der Benutzbarkeit und des Funktionsumfangs zufriedenstellend und lässt darauf hoffen, dass die Anwendung den Schülerinnen und Schülern eine nützliche Hilfestellung sein wird.

7.2. Offene Punkte

In diesem Abschnitt werden einige Themen aufgegriffen, die in der Arbeit aus zeitlichen Gründen bzw. wegen ihrer niedrigen Priorität oder wegen ihrer Entfernung vom Thema der Arbeit nicht behandelt wurden. Im Unterschied zu den nicht erfüllten Feature Sets aus dem vorigen Abschnitt handelt es sich hier um Punkte, die schon bei der Planung als für diese Arbeit nicht zielführend eingestuft wurden.

Derzeit ist der einzige unterstützte Regelsatz der für das aktuelle Abitur (Jahrgang 2014 und später, bis zur nächsten Änderung der entsprechenden Verordnung) am Johanneum Lüneburg. Die Kapselung des Regelsatzes ist zwar gegeben, es fehlt jedoch die Wahlmöglichkeit auf Nutzerseite. Für die Erweiterung auf andere niedersächsische Schulen oder sogar andere Bundesländer wurde im Rahmen dieser Arbeit keine Zeit eingeplant. Die minimale Zielsetzung der Arbeit ist damit erfüllt, aber dennoch wird dieses Thema in absehbarer Zukunft bearbeitet werden müssen, wenn der Abi-Planer langfristig nutzbar sein soll.

Im Abschnitt 2.3.2 wurden einige Ideen für soziale Funktionen aufgezählt, z.B. die technische Unterstützung des Notenvergleichs mit anderen Nutzerinnen oder die Anbindung an soziale Netzwerke. Die wesentlichen Gründe dafür, auf eine nähere Betrachtung des Themenblocks in Rahmen dieser Arbeit zu verzichten, lagen im Entwicklungsaufwand sowie in der Datenschutzproblematik, die sich bei der Netzwerkübertragung der Eingabedaten stellt. Eine genauere Untersuchung dieser Funktionen wäre sicher trotzdem interessant. Besonders im Hinblick auf das Datenschutzbewusstsein der Zielgruppe, den Drang zu Wettstreit und Selbstdarstellung sowie andere psychologische Aspekte wären mit hoher Wahrscheinlichkeit interessante Antworten zu erwarten.

Ein weiterer Punkt, der bei der Entwicklung bewusst nicht verfolgt wurde, ist die Möglichkeit zur Nutzung verschiedener Sprachen in der Schnittstelle des Abi-Planers. Zwar haben alle technischen Komponenten, auf denen die Anwendung aufbaut, gute Unterstützung für die verschiedensten Sprachen, aber die Implementation geht derzeit naiv davon aus, dass die Kommunikation ausschließlich auf deutsch erfolgt. Der Hauptgrund dafür ist die regionale Begrenztheit der Zielgruppe: Die Unterrichtssprache am Johanneum Lüneburg ist in der Regel Deutsch, weswegen generell davon ausgegangen werden kann, dass die Nutzerinnen deutsch sprechen. Selbst bei einer Ausweitung der Zielgruppe auf andere niedersächsische Schulen wäre der Anteil der potenziellen Nutzerinnen, die nicht deutsch sprechen, vermutlich immer noch verschwindend gering. Nichtsdestotrotz handelt es sich hierbei um eine Limitation der Anwendung, auch wenn sie in der Praxis derzeit nicht ins Gewicht fällt.

Die implementierte Version des Abi-Planers läuft derzeit über das Web. Sie ist so programmiert, dass auch eine lokale Kopie lauffähig wäre und somit auch ohne Verbindung zum Internet verwendet werden könnte. Dafür gibt es allerdings noch keinen nutzergerechten Mechanismus. Es wäre möglich, den Abi-Planer als installierbare App für mobile Betriebssysteme oder als Installationspaket für PCs anzubieten, diese Möglichkeit wurde jedoch bisher nicht verfolgt.

7.3. Ausblick

Das Ziel dieser Arbeit, eine funktionierende Anwendung für die Beratung und Selbstreflexion von Oberstufenschülerinnen und -schülern umzusetzen, ist erfüllt worden. Die nächste Frage ist, wie und in welcher Form sie am Johanneum Lüneburg tatsächlich zum Einsatz kommen wird. Um diese Frage auszuloten, wird erneut der Kontakt zum Oberstufenkoordinator gesucht werden. Das wird allerdings außerhalb des zeitlichen Rahmens dieser Arbeit stattfinden, weshalb an dieser Stelle noch nicht davon berichtet werden kann.

Angenommen, dass der Abi-Planer eine Zukunftsperspektive in der Praxis hat, sollte weitere Energie in die noch nicht umgesetzten Features investiert werden. Aus Rückmeldungen von Nutzerinnen und Nutzern werden sich mit Sicherheit weitere Verbesserungs- und Verfeinerungsmöglichkeiten ergeben, die dann ebenfalls nach und nach umgesetzt werden könnten.

Langfristig steht weiterhin die Möglichkeit im Raum, den Abi-Planer für andere niedersächsische Schulen nutzbar zu machen. Die Übereinstimmung der Berechnungsregeln ist so groß, dass dies kein allzu schwieriges Unterfangen wäre. Die Übertragung auf andere Bundesländer wäre im Vergleich ein deutlich größeres Problem, sollte aber ebenfalls in Betracht gezogen werden, falls der Abi-Planer von der kleineren Zielgruppe positiv bewertet wird. Prinzipiell wäre es erstrebenswert, einer größeren Zielgruppe die Möglichkeit zu geben, von den Ergebnissen dieser Arbeit zu profitieren.

Literatur

Anhang

A. Vorgespräch Oberstufenkoordinator

Nach einem ersten kurzen Kontakt per E-Mail setzte dieses Gespräch mit dem Oberstufenkoordinator des Johanneums an der Feststellung an, dass eine softwarebasierte Unterstützung der Beratung und Leistungsanalyse von Oberstufenschülern grundsätzlich interessant sei. Bei einem Gespräch unter vier Augen sollte in Erfahrung gebracht werden, welche fachlichen Umstände für den Entwurf relevant sind und wo die Technik zu einer Arbeitserleichterung führen kann.

Das Gespräch fand am 10. April 2013 von 10:00 Uhr bis ca. 10:30 Uhr im Büro des Oberstufenkoordinators statt. Dies sind die Protokoll-Notizen, die als Grundlage für die weitere Arbeit dienten.

B. Online-Umfrage

Die Umfrage zur Nutzererhebung wurde online durchgeführt. Die folgende Darstellung des Fragebogens gibt alle Fragen vollständig wieder. Das Umfragesystem sorgte während des Ausfüllens automatisch dafür, dass die Vorbedingungen für die Fragen 2, 3, 5, 6, 9, 10, 11, 12 und 13 automatisiert überprüft und entsprechend herausgefallene Fragen gar nicht erst eingeblendet wurden.

Diesem Umstand ist auch die auffällige Ähnlichkeit der Fragen 9 und 12 sowie 11 und 13 geschuldet. In diesen zwei Fragenpaaren sind lediglich einige Formulierungen an die zeitlichen Unterschiede zwischen einem abgeschlossenen und einem noch laufenden Abitur angepasst. Die Einblendung der jeweiligen Frage richtet sich nach der Antwort auf Frage 7. Die Antworten sind ansonsten inhaltlich identisch und wurden deshalb bei der Auswertung zusammengefasst.

Von den 29 vorhandenen Datensätzen sind drei unvollständig. Es handelt sich höchstwahrscheinlich um Teilnehmer, die das Ausfüllen des Fragebogens abgebrochen haben. Diese unvollständigen Datensätze sind in den Rohdaten im Interesse der Vollständigkeit mit angegeben (id ∈ {16, 23, 26}), wurden jedoch vor der weiteren Auswertung aus der Datenmenge entfernt. Aus diesem Grund ergibt sich für die gesamte Auswertung in dieser Arbeit ein Stichprobenumfang von n = 26 (statt n = 29).

B.1. Fragebogen

Schülerumfrage zum Abiturnoten-Rechner

Umfrage zur Erhebung der Rahmenbedingungen für ein Abiturnoten-Rechner-Projekt am Johanneum Lüneburg, gerichtet an Oberstufenschüler und Alumni.

Hallo und herzlich Willkommen!

Diese Umfrage dient der Vorbereitung eines Projektes, in dem eine Notenrechner-Software entwickelt werden soll, voraussichtlich als Smartphone-App. Diese soll es Abiturienten z.B. ermöglichen, ihren aktuellen Notenschnitt zu berechnen, sowie auch die beste (und schlechteste) Note, die sie erreichen können. Außerdem soll die Software anzeigen können, welche Noten in welchen Kursen erreicht werden müssen, um das Abitur/die Abiturzulassung/die Fachhochschulreife zu erlangen.

Vielen Dank, dass du dir ein paar Minuten Zeit nimmst, uns deine Wünsche und Vorstellungen mitzuteilen. Außerdem interessiert uns, was für ein Handy bzw. was für einen PC du besitzt.

Die Beantwortung der Umfrage sollte insgesamt nicht mehr als zehn Minuten deiner Zeit beanspruchen. Sämtliche Angaben sind komplett anonym.

Diese Umfrage enthält 17 Fragen.

Fragen zur Technik

In diesen Fragen geht es um deine Nutzungsgewohnheiten mit Computern und Smartphones. Die Antworten helfen uns bei der Entscheidung, auf welche Nutzungsweisen wir besonders achten müssen.

[1] Besitzt du ein Smartphone?

Bitte wähle nur eine der folgenden Antworten aus:

• Ja
• Nein

Unter "Smartphone" verstehen wir alle modernen Handys mit Touchscreen, mit denen man im Internet surfen und auf denen man Apps installieren kann (unabhängig davon, ob du persönlich das auch tust).

[2] Was für ein Smartphone hast du? (Falls du mehrere besitzt: Antworte bitte für das, welches du im Alltag am häufigsten benutzt.)

Beantworte diese Frage nur, wenn folgende Bedingungen erfüllt sind:
Antwort war 'Ja' bei Frage 1 (Besitzt du ein Smartphone?)

Bitte wähle nur eine der folgenden Antworten aus:

• iOS (Apple iPhone)
• Android
• Windows Phone
• Sonstige
• Weiß nicht

[3] Bitte nenne dein Smartphone-Modell möglichst genau. Du musst nicht extra nachschlagen, aber falls du den Namen deines Smartphone-Modells oder die installierte Betriebssystem-Version kennst, kann uns das sehr weiterhelfen. Siehe unten für Beispiele. (Falls du mehrere besitzt: Antworte bitte für das, welches du im Alltag am häufigsten benutzt.)

Beantworte diese Frage nur, wenn folgende Bedingungen erfüllt sind:
Antwort war 'Ja' bei Frage 1 (Besitzt du ein Smartphone?)

Bitte gib hier Deine Antwort ein:

 

Beispiele:

"Apple iPhone 4S"

"Samsung Galaxy Ace mit Android 2.3"

"HTC One X, Android 4.1 mit HTC Sense 4"

"Apple iPhone 4, jailbreak"

"HTC Evo 4G; root; CyanogenMod 10.1.3"

[4] Besitzt du einen PC, mobil (Laptop/Notebook) oder stationär?

Bitte wähle nur eine der folgenden Antworten aus:

• Ja
• Nein

Falls der PC dir nicht offiziell gehört, aber du ihn alleine benutzt und Programme darauf installieren darfst, kannst du hier ebenfalls mit "Ja" antworten.

[5] Welches Betriebssystem läuft auf deinem PC?

Beantworte diese Frage nur, wenn folgende Bedingungen erfüllt sind:
Antwort war 'Ja' bei Frage 4 (Besitzt du einen PC, mobil (Laptop/Notebook) oder stationär?)

Bitte wähle nur eine der folgenden Antworten aus:

• Microsoft Windows 8
• Microsoft Windows 7
• Microsoft Windows Vista
• Microsoft Windows XP
• Microsoft Windows: Sonstige Version
• Apple MacOS X
• Linux
• Sonstiges Betriebssystem
• Weiß nicht

[6] Welchen Web-Browser benutzt du auf dem PC, um im Internet zu surfen? (Falls du mehrere benutzt: Wähle bitte den, den du im Alltag am häufigsten nutzt.)

Beantworte diese Frage nur, wenn folgende Bedingungen erfüllt sind:
Antwort war 'Ja' bei Frage 4 (Besitzt du einen PC, mobil (Laptop/Notebook) oder stationär?)

Bitte wähle nur eine der folgenden Antworten aus:

• Microsoft Internet Explorer
• Mozilla Firefox
• Google Chrome
• Apple Safari
• Opera
• Sonstiger Browser
• Weiß nicht

Fragen zum Inhalt

Diese Fragen drehen sich um dich und deinen Umgang mit deinem Abitur. Denk daran: Es ist alles anonym, du musst uns nichts beweisen und dies ist kein Test. Bitte antworte einfach ganz ehrlich.

[7] Welches Jahr ist dein (ggf. voraussichtliches) Abitur-Abschlussjahr?

Bitte wähle nur eine der folgenden Antworten aus:

• 2012 oder früher
• 2013
• 2014
• 2015 oder später

[8] An welcher Schule wirst du voraussichtlich dein Abitur machen bzw. hast du dein Abitur gemacht?

Bitte wähle nur eine der folgenden Antworten aus:

• Johanneum Lüneburg
• Anderes Gymnasium in Niedersachsen
• Gymnasium in einem anderen Bundesland
• Sonstiges

[9] Welche der folgenden Aussagen treffen auf dich zu?

Beantworte diese Frage nur, wenn folgende Bedingungen erfüllt sind:
Antwort war '2014' oder '2015 oder später' bei Frage 7 (Welches Jahr ist dein (ggf. voraussichtliches) Abitur-Abschlussjahr?)

Bitte wähle die zutreffende Antwort aus:

	Ja	Unsicher	Nein
Ich habe schon mal meinen Notendurchschnitt berechnet.
Ich wüsste gerne jetzt schon, in welchem Bereich meine Abiturnote voraussichtlich liegen wird.
Ich habe mich eigenständig mit Belegungsverpflichtungen, Kurseinbringungen etc. beschäftigt.
Ich habe schon mal ein Beratungsgespräch mit Schulpersonal zu meinen bisherigen Leistungen gemacht.
Ich habe bereits eine sichere Vorstellung davon, was ich nach dem Schulabschluss machen werde.
Ich möchte studieren, und ich habe ein Wunsch-Studienfach sowie eine Wunsch-Universität.
Ich habe mich bereits damit beschäftigt, welchen Abiturschnitt ich für mein Wunsch-Ziel (z.B. numerus clausus an einer bestimmten Uni) brauchen werde.
Ich würde mir mehr Unterstützung bei der Einschätzung meiner bisherigen Schulleistung wünschen.

[10] Welcher der folgenden Sätze entspricht am ehesten deiner Selbsteinschätzung?

Beantworte diese Frage nur, wenn folgende Bedingungen erfüllt sind:
Antwort war '2014' oder '2015 oder später' bei Frage 7 (Welches Jahr ist dein (ggf. voraussichtliches) Abitur-Abschlussjahr?)

Bitte wähle nur eine der folgenden Antworten aus:

• Ich arbeite auf eine gute bis sehr gute Abiturnote hin.
• Ich mache mein Abitur fertig, erwarte aber keine Bestnoten - "Hauptsache durch".
• Falls ich meine Abiturzulassung nicht schaffe, gebe ich mich auch schon mit der Fachhochschulreife zufrieden.
• Ich erwäge die Möglichkeit, die Oberstufe noch vor dem Abschluss abzubrechen und langfristig den zweiten Bildungsweg einzuschlagen (z.B. Abendschule).
• Ich erwäge die Möglichkeit, die Oberstufe noch vor dem Abschluss abzubrechen, und plane keinen weiteren Bildungsweg.

[11] Angenommen, es gäbe eine Software, die dich bei der Einschätzung deiner eigenen schulischen Leistung unterstützen und dir die damit verbundene Rechenarbeit abnehmen soll. Welche Fähigkeiten sollte diese Software haben und wie wichtig sind sie dir jeweils?

Beantworte diese Frage nur, wenn folgende Bedingungen erfüllt sind:
Antwort war '2014' oder '2015 oder später' bei Frage 7 (Welches Jahr ist dein (ggf. voraussichtliches) Abitur-Abschlussjahr?)

Bitte wähle die zutreffende Antwort aus:

	sehr wichtig, würde ich nutzen	schon wichtig, würde ich gelegentlich nutzen	halbwegs wichtig, würde ich mir wohl mal anschauen	eher unwichtig, weiß nicht ob ich es nutzen würde	ziemlich unwichtig, glaube nicht dass ich etwas davon hätte	völlig unwichtig, für mich komplett uninteressant
Berechnung meiner aktuellen Durchschnittsnote
Berechnung der besten noch erreichbaren Abiturnote
Berechnung der schlechtesten noch erreichbaren Abiturnote
Hinweis auf Erreichung der Abiturzulassung (schon erreicht, was ist noch nötig...)
Hinweis auf Erreichung der Fachhochschulreife (schon erreicht, was ist noch nötig...)
Hinweis auf verpflichtende Kursbelegungen
Hinweis auf kritische Kurse, die unbedingt bestanden werden müssen
Überwachung der Einhaltung der Mindestwochenstunden

[12] Welche der folgenden Aussagen treffen auf dich zu?

Beantworte diese Frage nur, wenn folgende Bedingungen erfüllt sind:
Antwort war '2013' oder '2012 oder früher' bei Frage 7 (Welches Jahr ist dein (ggf. voraussichtliches) Abitur-Abschlussjahr?)

Bitte wähle die zutreffende Antwort aus:

	Ja	Unsicher	Nein
Ich habe im Vorfeld des Abiturs bereits selbständig meinen Notendurchschnitt berechnet.
Ich hätte gerne schon früher gewusst, in welchem Bereich meine Abiturnote voraussichtlich liegen würde.
Ich habe mich eigenständig mit Belegungsverpflichtungen, Kurseinbringungen etc. beschäftigt.
Ich habe vor dem Abitur ein Beratungsgespräch mit Schulpersonal zu meiner bisherigen Leistung gemacht.
Ich hatte schon vor dem Abitur eine sichere Vorstellung von meiner Zukunft.
Ich wusste schon vor dem Abitur, dass ich studieren möchte, welches Fach es sein soll und welche Universität.
Ich habe mich bereits vor dem Abitur damit beschäftigt, welchen Abiturschnitt ich für mein Wunsch-Ziel (z.B. numerus clausus an einer bestimmten Uni) brauchen würde.
Ich hätte mir mehr Unterstützung bei der Einschätzung meiner Schulleistung gewünscht.

[13] Angenommen, es hätte zu deiner Schulzeit eine Software gegeben, die dich bei der Einschätzung deiner eigenen schulischen Leistung unterstützen und dir die damit verbundene Rechenarbeit abnehmen soll. Welche Fähigkeiten sollte diese Software haben und wie wichtig sind sie dir jeweils?

Beantworte diese Frage nur, wenn folgende Bedingungen erfüllt sind:
Antwort war '2013' oder '2012 oder früher' bei Frage 7 (Welches Jahr ist dein (ggf. voraussichtliches) Abitur-Abschlussjahr?)

Bitte wähle die zutreffende Antwort aus:

	sehr wichtig, hätte ich genutzt	schon wichtig, hätte ich gelegentlich genutzt	halbwegs wichtig, hätte ich mir wohl mal angeschaut	eher unwichtig, weiß nicht ob ich es genutzt hätte	ziemlich unwichtig, glaube nicht dass ich etwas davon gehabt hätte	völlig unwichtig, für mich komplett uninteressant
Berechnung meiner aktuellen Durchschnittsnote
Berechnung der besten noch erreichbaren Abiturnote
Berechnung der schlechtesten noch erreichbaren Abiturnote
Hinweis auf Erreichung der Abiturzulassung (schon erreicht, was ist noch nötig...)
Hinweis auf Erreichung der Fachhochschulreife (schon erreicht, was ist noch nötig...)
Hinweis auf verpflichtende Kursbelegungen
Hinweis auf kritische Kurse, die unbedingt bestanden werden müssen
Überwachung der Einhaltung der Mindestwochenstunden

Demographische Angaben

Diese Angaben sind nützlich für die statistische Auswertung und helfen uns, unsere Software besser auf die Bedürfnisse der zukünftigen Nutzer einzustellen. Natürlich sind weiterhin alle Angaben anonym.

[14] Alter:

Bitte wähle nur eine der folgenden Antworten aus:

• jünger als 16
• 16 - 17
• 18 - 19
• 20 - 22
• 23 - 26
• älter als 26

[15] Geschlecht:

Bitte wähle nur eine der folgenden Antworten aus:

• Weiblich
• Männlich

Zusätzliche Bemerkungen

Hier hast du noch die Möglichkeit, Dinge zu schreiben, die bisher untergegangen sind.

[16] Gibt es noch etwas, was du uns mitteilen möchtest, und was bisher zu keiner Frage passte? Weitere Wünsche, Anmerkungen?

Bitte gib hier Deine Antwort ein:

 

[17] Gab es etwas an diesem Fragebogen, was schlecht gelungen war oder was du nicht verstanden hast? Falls du beim Ausfüllen an irgendeiner Stelle Schwierigkeiten hattest, bitte beschreibe uns das Problem.

Bitte gib hier Deine Antwort ein:

 

Vielen Dank für die Beantwortung der Fragen! Deine Antworten werden uns eine große Hilfe bei dem Projekt sein. Falls du gerne über den weiteren Verlauf und später über das Projektergebnis informiert werden möchtest, schick einfach eine Mail an [E-Mail-Adresse entfernt] und wir melden uns bei dir.

Absenden der Umfrage.
Vielen Dank für die Beantwortung des Fragebogens.

B.2. Statistische Daten

B.3. Rohdaten

C. Papierprototypen

C.1. Skizzen

Abbildung 16: Diese Entwurfsskizzen waren die ersten Visualisierungen des Konzepts für die Nutzungsschnittstelle. Sie bilden die Vorstufe der Papierprototypen und wurden nicht für Tests eingesetzt.

C.2. Prototypen

C.2.1. PC-Prototyp

Abbildung 17: Dies sind alle Bestandteile des PC-Papierprototypen.

Abbildung 18: Dies ist ein beispielhafter Szenariodurchlauf anhand des PC-Prototypen, zu lesen von oben links nach unten rechts. (a) Startansicht (b) Ein Kurs wurde angewählt, Fach-Auswahl wird angezeigt. (c) Ein Fach wurde ausgewählt. (d) Ein weiterer Kurs wurde angewählt, Fach-Auswahl wird erneut angezeigt. (e) Zwei Fächer wurden bestätigt. (f) Ein Kurssemester wurde angewählt, Noten-Auswahl wird angezeigt. (g) Die entsprechende Zeugnisnote wurde eingegeben. (h) Alle Noten für 11-1 bis 12-1 für die zwei Kurse wurden bestätigt. (i) Das Eintragen der restlichen Kurse und Noten funktioniert analog, wird aus Zeitgründen vom Versuchsleiter abgekürzt. (j) Prüfungsnoten liegen noch nicht vor, Analyseergebnisse werden rechts angezeigt.

C.2.2. Mobil-Prototyp

Abbildung 19: Dies sind alle Bestandteile des Mobil-Papierprototypen.

Abbildung 20: Dies ist ein Beispiel für einen Szenariodurchlauf anhand des Mobil-Prototypen, zu lesen von oben links nach unten rechts. (a) Startansicht (b) Ein Kurs wurde angewählt, Fach-Auswahl wird angezeigt. (c) Zwei Fächer wurden bestätigt, ein Kurssemester wurde angewählt, Noten-Auswahl wird angezeigt. (d) Alle Noten für 11-1 bis 12-1 für die zwei Kurse wurden bestätigt. (e) Das Eintragen der restlichen Kurse und Noten funktioniert analog, wird aus Zeitgründen vom Versuchsleiter abgekürzt. (f) Nach unten scrollen, Prüfungsnoten liegen noch nicht vor, Analyseergebnisse werden unten angezeigt.

C.3. Szenario

Das Szenario war für beide Prototypen identisch. Der Text und der Notenvordruck wurden den Probanden schriftlich vorgelegt.

C.4. Testprotokolle

Proband A

Proband A testete den Mobil-Prototyp.

Proband B

Proband B testete den PC-Prototyp.

Proband C

Proband C testete den Mobil-Prototyp.

Proband D

Proband D hätte den PC-Prototyp testen sollen. Leider musste die Testdurchführung mit Proband D allerdings aus terminlichen Gründen kurzfristig ausfallen.