Interview mit Tobias Arendt: UX und UI im mBook GL

Die Gestaltung des mBook GL ist nicht nur eine Frage der Optik - die Benutzeroberfläche muss verständlich und einfach zu bedienen sein. Die NutzerInnen sollen sich schnell im mBook zurechtfinden, durch die Kapitel navigieren und wiederkehrende Symbole erkennen können, die bestimmte Funktionen erfüllen. Hinter scheinbar banalen Dingen wie dem Inhaltsverzeichnis stehen also wichtige Überlegungen, die darauf abzielen, unser Produkt möglichst nutzerfreundlich zu gestalten. Das ist eine der Aufgaben von Tobias Arendt. In diesem Interview gibt er einen Einblick in UX und UI des mBook GL und erklärt uns, was diese Begriffe überhaupt bedeuten. 

Zunächst einmal zu den Begriffen: Was bedeuten UX und UI?

UX bedeutet User Experience (dt. Nutzererfahrung). Informationen und Erkenntnisse aus diesem Bereich beinhalten die Ansichten von Menschen über und deren Erwartungen an das System, mit dem sie arbeiten müssen. UI steht für das grafische User Interface. Damit wird die grafische Benutzeroberfläche mit ihren Funktionen bezeichnet. Die UI-Gestaltung soll die sinnvolle Interaktion zwischen Mensch und digitalem System ermöglichen.

Eine der grundlegendsten Dinge ist die Navigation. Die NutzerInnen müssen schnell erkennen, wo sie sich im mBook befinden und wie sie an eine bestimmte Stelle gelangen. Wie funktioniert das im mBook GL?

Die Navigation im mBook teilt sich auf zwei Ebenen auf. Die erste Ebene ermöglicht es den NutzerInnen, möglichst schnell in das gewünschte Kapitel zu gelangen. Dafür gibt es ein Hauptmenü. In diesem sind alle Seiten des mBooks wie in einem Inhaltsverzeichnis aufgelistet. Damit diese, doch recht lange, Liste bei den NutzerInnen nicht den Eindruck zu vieler Informationen hinterlässt, sind die Haupt- und Unterkapitel hinter aufklappbaren Elementen versteckt. Das Kapitel, in dem man sich gerade befindet, ist jedoch initial ausgeklappt. Wenn man also in ein anderes Unterkapitel aus dem gleichen Bereich gelangen möchte, ist es nicht nötig, weitere Bereiche aufzuklappen. Das gilt auch, wenn man nur schnell sehen will, wo in der Gesamtstruktur man sich befindet.

Abbildung 1: Das Inhaltsverzeichnis führt Haupt- und Unterkapitel auf

Die zweite Navigationsebene hilft dabei, innerhalb eines Kapitels möglichst schnell an die gewünschte Stelle zu kommen. Dafür gibt es auf jeder Seite eine Kapitelnavigation. In dieser sehen die NutzerInnen alle Zwischenüberschriften und alle Aufklappkästen innerhalb eines Kapitels. Ein Klick auf den entsprechenden Menüpunkt scrollt die Seite automatisch zur entsprechenden Stelle. Lehrerinnen und Lehrer können so also beispielsweise sehr schnell den gesamten Klassenverband zum gewünschten Material navigieren lassen, ohne dass es zu einem langen Suchen nach der richtigen Stelle kommt.

Abbildung 2: Über die Kapitelnavigation sind Zwischenüberschriften und Kästen leicht zu erreichen.

Wie sind die Kapitel selbst gestaltet?

Bei der Gestaltung der Kapitel war uns besonders wichtig, die Fachinhalte in den Vordergrund zu rücken. Das Design ist also vor allem funktional und soll dabei helfen, sich schnell zurecht zu finden und mit den Inhalten zu interagieren.

Das Layout orientiert sich deshalb stark an einem Drucklayout, das die NutzerInnen z. B. aus (Schul-)Büchern gewohnt sind. Auf der ersten Ebene gibt es vor allem Texte und Bilder, die zusammen mit multimedialen Inhalten wie Audios und Videos einen ersten Teil der Inhalte bereitstellen.

Abbildung 3: Layout der ersten Ebene im Kapitel 4.9: Macht im Mittelalter. Hier wird der Text mit einer Galerie kombiniert, deren Ankerbild auf dieser Ebene zu sehen ist. Zum Ansehen der weiteren Bilder muss die Galerie geöffnet werden.

Zusätzlich enthält das mBook jedoch noch jede Menge weiterer Inhaltstypen und Funktionalitäten, die für die NutzerInnen zugänglich sein müssen. Bilder können beispielsweise für sich alleine stehen oder als Zugang zu einer ganzen Galerie an Bildern dienen, über die eine neue Informationsebene eröffnet wird. Die entsprechenden Galerien sind also textlich als solche gekennzeichnet.

Auffällig sind in jedem Falle die aufklappbaren Kästen, die sich in allen Kapiteln befinden. In diesen Kästen finden sich weitere Informationen zur Erarbeitung der Inhalte des entsprechenden Kapitels. Im Fach Geschichte handelt es sich dabei etwa um Materialien wie Quellen und Darstellungen, die u.a. mit den Lehrtexten korrespondieren. Zudem gibt es in fast allen Kapiteln Aufgabenkästen, in die Antworten hingeschrieben werden können.

Nur für LehrerInnen gibt es ebenfalls aufklappbare Kästen, in denen sie didaktische Informationen, Anregungen für Unterrichtsplanung und -durchführung, Zusatzinhalte oder Lösungsvorschläge finden können. Diese Kästen sind für die SchülerInnen nicht sichtbar.

Abbildung 4:  Ein aufgeklappter Kasten, der eine Darstellung enthält.

Warum gibt es die Aufklappboxen überhaupt? Sehr einfach: Die Kapitel des mBooks dürfen die NutzerInnen nicht mit einer unüberschaubaren Füllen an Informationen überfordern, müssen jedoch trotzdem genügend Material beinhalten, um individuelle Unterrichtsgestaltungen zu ermöglichen. Das ‘Verstecken’ zusätzlicher Inhalte in Aufklappboxen und Bildergalerien hilft also, diese beiden Anforderungen zu erfüllen.

Entwirfst du die Icons ganz nach deinem Geschmack oder gibt es hier Dinge zu beachten?

Bei den verwendeten Symbolen und Icons ist es wichtig, dass diese für die NutzerInnen schnell erkennbar und verständlich sind. Erkennbar bedeutet, dass die Form der Icons genügend Kontraste und individuelle Merkmale aufweist, um sie schnell voneinander zu unterscheiden. Verständlich bedeutet, dass den NutzerInnen nach dem Erkennen des Icons klar sein muss, was ein Klick des Icons auslösen wird.

Bei unseren herkömmlichen Funktionen, wie dem Vor- und Zurückblättern, dem Hauptmenü etc. haben wir deshalb Icons gewählt, die im Internet häufig für diese Funktionen genutzt werden. Das Verstehen erfolgt also in der Regel nicht nur über eine aussagekräftige Form (Pfeil nach rechts), sondern auch über gelernte Bedeutungen (Zahnrad, das zu den Einstellungen führt).

Problematischer ist es, wenn man ganz neue Icons entwickeln muss. Unser Icon für die Magic Toolbar hat eine klar erkennbare Form (man verwechselt es nicht mit einem anderen Icon), das Verständnis der Funktion (Aufrufen inklusiver Inhalte) muss jedoch erst von den NutzerInnen gelernt werden. Die auffällige Farbe und die Hervorhebung durch den Schatten sorgen dafür, dass die NutzerInnen mit dem Icon interagieren. Durch die Interaktion wiederum kommt es zu dem gewünschten Lerneffekt. Und wenn die NutzerInnen das Icon an einer anderen Stelle sehen, beispielsweise im Hauptmenü, verstehen sie, dass es dort wohl auch entsprechende Zusatzmaterialien gibt.

Abbildung 5: Das Icon für die Magic Toolbar hebt sich von den übrigen Elementen ab. Durch das Anklicken öffnet sich die Toolbar über dem jeweiligen Element, in diesem Fall über der Zwischenüberschrift. 

Welche Programme nutzt du für die Gestaltung des mBook GL?

Wenn es um die reine Gestaltung der mBooks geht arbeite ich mit Adobe XD. Das Tool ist speziell für die Gestaltung von Weblayouts entwickelt und harmoniert gut mit der restlichen Suite von Adobe. In diesem Bereich gibt es inzwischen jede Menge Tools, die bis auf wenige Sonderfunktionen alle recht ähnliche Arbeitsmöglichkeiten bieten. Mit welchem Programm man schließlich arbeitet, hängt inzwischen sehr weitgehend von der persönlichen Präferenz ab.

Von der Verwendung herkömmlicher Grafikprogramme (Photoshop, Illustrator o.ä.) würde ich jedoch abraten, da diesen essentielle Funktionen wie Prototyping oder eine Kommentarfunktion fehlen, andere Optionen jedoch unnötig überladen sind.

Abbildung 6: Tobias bei der Arbeit mit Adobe XD.

Wie sieht üblicherweise der Workflow für einen neues Element aus?

Unsere mBooks werden nicht wie ein herkömmliches Buch geschrieben und jede Seite einzeln gelayoutet, sondern wir arbeiten in unserem CMS mit dedizierten Bausteinen für die verschiedenen Inhaltstypen.

So wird z.B. jeder Quellentext immer in einem Element angelegt, das in unserem System als Quelle erkannt wird, genauso ist jeder Autorentext immer als Textelement angelegt. 

Dadurch verfügen wir über strukturierte Daten, und Änderungen an einzelnen Funktionen oder Designs können global angewendet werden.

Das bedeutet jedoch auch, dass wir vorab sehr gut darüber nachdenken müssen, welche Inhaltsbausteine wir für ein digitales Schulbuch brauchen und welche nicht.

Wenn AutorInnen eines Kapitels also eine Idee für ein neues Inhaltselement haben, werden die entsprechenden Anforderungen und Bedürfnisse im Team besprochen. Dieses Team besteht in der Regel aus dem Autor oder der Autorin, die ihre Idee vorstellen, einem Entwickler der abschätzt, ob die Idee technisch realisierbar ist und mir. Ich muss in den Teamsitzungen verstehen, welche Aufgabe das neue Element erfüllen soll, ob diese Funktion eventuell auch anders abbildbar ist und ob wir diese Funktion in Zukunft häufiger benötigen (oder ob sie nur einmal verwendet werden wird). Schließlich muss ich eine Vorlage für den Entwickler erstellen.

Sobald der Entwickler weiß, welche Inhalte für das neue Element benötigt werden, kann die Eingabemaske dafür im System angelegt werden. Die technische Umsetzung des Designs und der Funktionen im mBook dauert in der Regel noch etwas länger. Da die Maske im System jedoch schon funktioniert, kann die Autorin oder der Autor die entsprechenden Inhalte anlegen und wird nicht länger als nötig aufgehalten.

Stichwort Inklusion: Das mBook GL beinhaltet bereits eine Reihe von Funktionen, die zur Inklusion beitragen. Gibt es weitere Tools, die wir eventuell in zukünftigen Projekten sehen werden?

Wir haben durch das mBook GL viel über die Bereiche Inklusion und Zugänglichkeit von Inhalten gelernt. Diese Erfahrungen nehmen wir natürlich mit in alle zukünftigen Projekte. Besonders der Bereich Web Content Accessibility Guidelines (WCAG), also die Zugänglichkeit von Inhalten für Menschen mit Einschränkungen, wird für uns immer wichtiger. Entsprechend werden wir unsere Projekte in Zukunft noch stärker in diese Richtung optimieren.

Spezielle Tools, wie z.B. Screen Reader oder Braille-Schrift-Lesegeräte, werden wir aber nicht entwickeln. Hier gibt es etablierte Anbieter sowie Soft- und Hardware, mit der die NutzerInnen seit Jahren vertraut sind. Unsere Aufgabe ist es daher eher, Code zu schreiben, der es diesen Systemen nicht unnötig schwer macht, ihre Möglichkeiten zu entfalten.

Abbildung 7: Ein Beispiel für Inklusion im mBook GL: Die Texte wurden eingesprochen und können über die Magic Toolbar angehört werden.

Worauf muss man zusammenfassend besonders achten, wenn es um die (Weiter-)Entwicklung von UX und UI in einem Projekt geht?

Wie ein Produkt funktioniert, hängt immer davon ab, für wen es gemacht wird. Ein digitales Schulbuch unterscheidet sich natürlich von einem digitalen Kochbuch, aber auch ein Geschichtsbuch mit Zusatzinhalten für den inklusiven Unterricht wird sich in seinen Funktionsweisen von einem Mathematikbuch mit Zusatzinhalten für den inklusiven Unterricht unterscheiden. Im Blick zu behalten, wer das Produkt in welchem Kontext nutzt, ist dabei die wichtigste Aufgabe.

Überprüft werden können die eigenen Annahmen nur zuverlässig durch regelmäßiges Testen und Befragen der zukünftigen NutzerInnen.