Endbericht der Arbeitsgruppe. Usability RAD (Research Activities Documentation)

Transkript

1 der Arbeitsgruppe Usability RAD (Research Activities Documentation) Problemanalyse, Verbesserungsvorschläge, Visionen Wien, im Juli 2008 Seite 1 / 40

2 Versionshistorie Version Initiale Erstellung des Dokuments Version Einarbeitung der Vorschläge der einzelnen AG-Mitgliedern Version Hinzufügen der Problemliste vom März 2007 Version Aufarbeitung der neun Hauptvorschläge Version Ausgliederung der Problem- und Mängelberichte Version Rundlaufänderungen nach Sitzung vom Version Vor-Finale Fassung für den Umlaufbeschluss Version Änderungsversionen durch Mitglieder der Arbeitsgruppe Version Finale Fassung Die vorliegende finale Fassung (Version 2.0) dieses Berichts wurde von den Mitgliedern der Arbeitsgruppe in einem Umlaufbeschluss per genehmigt. Seite 2 / 40

3 Inhaltsverzeichnis Kurzfassung...7 Arbeitsbericht... 9 Allgemeine Empfehlung der Arbeitsgruppe Durchführung standardmäßiger Tests auf Usability Entwicklung und Einrichtung einheitlicher Standards für die Benutzerschnittstelle von Softwaresystemen Installation eines IT-Leitungsorgan , Betonung des Mehrwerts der neu eingerichteten Systeme durch den Auftraggeber Einrichtung eines RAD Advisory Boards Anmerkungen zu den Verbesserungsvorschlägen...12 Danksagung Arbeitsworkflow Beschreibung Ziel Referenz(en) auf Problemliste Betroffene Personengruppe Priorität Überprüfungskriterium Konkreter Umsetzungsvorschlag Speicherfunktion für Workflows (samt Wiederaufnahmemöglichkeit) Informationsfenster über offene Workflows Fortschrittsanzeige für Workflows AG Verantwortliche(r) Benutzerschnittstelle und Dokumentation Beschreibung Ziel Referenz(en) auf Problemliste Betroffene Personengruppe Priorität Überprüfungskriterium Konkreter Umsetzungsvorschlag Verwendung/Beachtung von existierenden User Interface Guidelines Zugang zum RAD verbessern (Wie komme ich zur RAD?) VPN Zugang vereinfachen An- und Abmeldung Dokumentation erweitern GUI User-Schnittstelle verbessern Benutzerprofile und persönliche Konfigurationsmöglichkeiten Festlegung bzw. Vorbelegung der Eingabefelder Angabe der Release-Information AG Verantwortliche(r) Datenfeedback Beschreibung Ziel Referenz(en) auf Problemliste Betroffene Personengruppe Priorität Überprüfungskriterium Seite 3 / 40

4 3.7 Konkreter Umsetzungsvorschlag Automatisiertes Feedback bei Datenmanipulation Festlegung der Feedbackrelevanz für Datenfelder und Status Berichterstellung für Eigengebrauch AG Verantwortliche(r) Editier- und Löschenfunktion Beschreibung Ziel Referenz(en) auf Problemliste Betroffene Personengruppe Priorität Überprüfungskriterium Konkreter Umsetzungsvorschlag Festlegung der Feedbackrelevanz für Datenfelder und Status Einführung des Workflowschritts verwerfen und wiederbeleben von verworfenen Datensätzen Kopieren von Datensätzen als Vorlagen für neu zu erstellende Datensätze Warnmeldungen/Alerting für identische Datensätze AG Verantwortliche(r) Datenstatus Beschreibung Ziel Referenz(en) auf Problemliste Betroffene Personengruppe Priorität Überprüfungskriterium Konkreter Umsetzungsvorschlag Festlegung der Datenzustände Benachrichtigung bei Daten(status)änderungen AG Verantwortliche(r) Import/Export/Report Beschreibung Ziel Referenz(en) auf Problemliste Betroffene Personengruppe Priorität Überprüfungskriterium Konkreter Umsetzungsvorschlag Importschnittstelle zur Batch Erhebung Exportschnittstelle für häufig verwendete Formate AG Verantwortliche(r) Integritätsbedingungen Beschreibung Ziel Referenz(en) auf Problemliste Betroffene Personengruppe Priorität Überprüfungskriterium Konkreter Umsetzungsvorschlag Einführung von et. al. bei Publikationen Seite 4 / 40

5 7.7.2 Auflösung der Verknüpfung Tagungs- bzw. Sammelband zu Beitrag in Tagungs- bzw. Sammelband Umordnung der Datenfelder bez. Pflicht- und Ergänzungsfelder Setzung von Defaultwerten bezüglich Benutzerprofil AG Verantwortliche(r) Orgware Beschreibung Ziel Referenz(en) auf Problemliste Betroffene Personengruppe Priorität Überprüfungskriterium Konkreter Umsetzungsvorschlag Installation eines RAD Advisory Boards Verwendung eines Trouble-Ticket-Systems Erweiterung des Schulungsangebots Umgang mit Hintergrunddaten AG Verantwortliche(r) Vision WorkSpace MyRAD / MyUniVie Beschreibung Ziel Referenz(en) auf Problemliste Betroffene Personengruppe Priorität Überprüfungskriterium Konkrete Umsetzungsvorschläge Überblick über Datenstatus Überblick über offene Workflows Universitäres Intranet Personalisierte Benutzerprofile zur Eingabeerleichterung Persönliche Konfigurationsmöglichkeit mittels RAD-Widgets AG Verantwortliche(r) Seite 5 / 40

6 Mitglieder der Arbeitsgruppe Ständige Mitglieder der AG Ao. Univ.-Prof. Mag. Dr. Gerhard Ecker Monika Fink Ao. Univ.-Prof. Dr. Wolfgang Lang ADir. Harald Riedel-Taschner Ao. Univ.-Prof. Dipl.-Ing. Dr. Erich Schikuta Department für Medizinische/ Pharmazeutische Chemie Verwaltungskoordination und Recht Fakultät für Physik / Elektronische Materialeigenschaften Zentraler Informatikdienst Institut für Knowledge and Business Engineering HR Dr. Wolfram Seidler Bibliotheks- und Archivwesen / Fachbereichsbibliothek Germanistik, Nederlandistik und Skandinavistik HR Mag. Maria Seissl Dr. Dorothea Sturn Mag. Dr. Lucas Zinner Bibliotheks- und Archivwesen Qualitätssicherung Forschungsservice und Internationale Beziehungen Ständige Auskunftspersonen der AG Ass.-Prof. Dr. Gert Bachmann Mag. Peter Paul Beran Ass.-Prof. Mag. Dr. Christian Cenker Ass.-Prof. Mag. Dr. Karl Reiter AR Markus Ristic Betriebsrat für das wissenschaftliche Universitätspersonal Institut für Knowledge and Business Engineering stv. Vorsitzender des Betriebsrats für das wissenschaftliche Universitätspersonal Betriebsrat für das wissenschaftliche Universitätspersonal Betriebsrat für das allgemeine Universitätspersonal Seite 6 / 40

7 Kurzfassung Das RAD (Research Activities Documentation) System der Universität Wien ist ein Softwaresystem der universitären Verwaltung mit der Aufgabe, den Mitarbeiterinnen und Mitarbeitern der Universität Wien die laufende zentrale Dokumentation ihrer Forschungsaktivitäten zu ermöglichen. Aufgrund dieser Zielsetzung ist es unbestritten, dass das RAD eine zentrale, wichtige, und auch universitätspolitisch sensible Aufgabenstellung zu erfüllen hat. Die ursprüngliche Einführung (Rollout) des RAD Systems fand unter erheblichem Zeitdruck statt und führte aufgrund unzulänglicher Tests auf Benutzerfreundlichkeit (Usability) zu äußerst geringer Akzeptanz bei den Anwendern. Unter Usability von Produkten versteht man üblicherweise 1 die Eignung eines Produktes bei der Nutzung durch bestimmte Benutzer in einem bestimmten Benutzungskontext, die vorgegebenen Ziele effektiv, effizient und zufriedenstellend zu erreichen. Es ist hierbei anzumerken, dass die fokussierten Anwendergruppen des wissenschaftlichen und nichtwissenschaftlichen Personals eine Größe von mehreren Tausend Personen umfassen, d.h. das RAD System eine Softwareanwendung mit einem bemerkenswert großen Benutzerkreis darstellt. Diese spannungsgeladene Situation war die Ausgangslage für die Arbeitsgruppe Usability RAD, die im Auftrag des Rektorats der Universität Wien mit der Aufgabe eingerichtet wurde, im Einklang mit den Benutzergruppen Verbesserungsvorschläge für zukünftige RAD Versionen zu erarbeiten. Diese Arbeitsgruppe unter der Leitung von Erich Schikuta bestand aus neun Mitgliedern und fünf ständigen Auskunftspersonen und umfasste Vertreter aller betroffenen Anwendergruppen und des Entwicklungsteams. Sie führte ihre Tätigkeit im Zeitraum Februar bis Juni 2008 (sieben Sitzungen) aus. Das Ziel der Arbeitsgruppe wurde am Beginn mit folgendem Satz prägnant formuliert: Diese Arbeitsgruppe, die sich rein mit der - wie der Name schon sagt - Benutzbarkeit des RAD- Interfaces beschäftigt, sowohl im WEB als auch im i3v, ist eine rein technisch orientierte Arbeitsgruppe, die die BenutzerInnen im Auge hat. Die Vorgangsweise der Arbeitsgruppe wurde in der ersten Sitzung auf der Basis eines problemzentrierten Ansatzes in drei Phasen gegliedert: Aufbauend auf einem ersten Mängelkatalog (Appendix II), den Peter Beran und Erich Schikuta im Auftrag des Rektorats schon im März 2007 erfasst hatten, wurde eine aktualisierte und konsolidierte Problemliste (Appendix I) erstellt, die alle aus den Fakultäten und Zentren der Universität Wien gemeldeten RAD Unzulänglichkeiten beinhaltet. Diese Problemliste stellte die Ausgangsbasis für die Erstellung eines Mängelkatalogs dar. Hierbei wurden alle Mängel nach einem einheitlichen Schema beschrieben und in Fehler-Gruppen kategorisiert (Arbeitsablauf, Datenmodell, Benutzerschnittstelle, Technik). Davon ausgehend wurde schließlich eine Liste von Verbesserungsvorschlägen entwickelt, die in neun unterschiedliche Themenbereiche gruppiert wurden: o Arbeitsworkflow, o Benutzerschnittstelle und Dokumentation, o Datenfeedback, o Editier- und Löschfunktion, o Datenstatus, 1 de.wikipedia.org Seite 7 / 40

8 o Import/Export/Report, o Integritätsbedingungen, o Orgware, o Workspace MyRAD. Diese Vorschläge reichen von sogenannten Easy Wins (d.h. schnell umzusetzenden Verbesserungen) bis zu visionären Vorstellungen eines MyRAD Scientific Workplace (d.h. der Beschreibung eines zukünftigen IT-basierten wissenschaftlichen Arbeitsplatzes). Es wurde darauf geachtet, dass alle(!) erfassten Mängel in der Arbeitsgruppe diskutiert und Lösungsvorschläge zu deren Behebung entwickelt wurden. Die Ergebnisse der Arbeitsgruppe Usability RAD sind im vorliegenden Dokument zusammengefasst. Dieses beinhaltet als zentralen Teil die Sammlung der identifizierten Lösungsvorschläge zur Verbesserung des RAD Systems. In der Anlage findet man auch die Liste aller gesammelten und behandelten Probleme und den Katalog der ursprünglichen Mängelerhebung. An den Beginn des Berichts wurden auch einige allgemeine Überlegungen der Arbeitsgruppe zur IT Infrastruktur der Universität Wien gestellt, die die folgenden Punkte betreffen: Durchführung standardmäßiger Tests auf Usability, Entwicklung und Einrichtung einheitlicher Standards für die Benutzerschnittstelle von Softwaresystemen, Installation eines IT-Leitungsorgan, Betonung des Mehrwerts der neu eingerichteten Systeme durch den Auftraggeber, Einrichtung eines RAD Advisory Boards. Seite 8 / 40

9 Arbeitsbericht Die Arbeitsgruppe traf sich zu sieben Sitzungen im Zeitraum Februar bis Juni Die finale Version des vorliegenden s wurde durch einen Umlaufbeschluss per erreicht. Termin Sitzungsnr. Inhalt Konstituierende Sitzung Überlegungen zur Vorgangsweise Problemsammlung und diskussion Problemsammlung und diskussion Diskussion Verbesserungsvorschläge Sammlung Verbesserungsvorschläge Diskussion Rohbericht 1. Juli Woche 2008 Umlaufbeschluss Seite 9 / 40

10 Allgemeine Empfehlung der Arbeitsgruppe 1. Durchführung standardmäßiger Tests auf Usability Bei Produkten bezeichnet Gebrauchs-/Benutzertauglichkeit oder englisch Usability die Eignung eines Produktes bei der Nutzung durch bestimmte Benutzer in einem bestimmten Benutzungskontext, die vorgegebenen Ziele effektiv, effizient und zufriedenstellend zu erreichen (de.wikipedia.org). Usability stellt einen zentralen Faktor für die Akzeptanz von Softwaresystemen durch den Benutzer dar und Usability-Engineering und der standardmäßige Test auf Usability sollte immer ein inhärenter Teil des Softwareentwicklungsprozesses sein. Professionell geschieht der Test auf Usability durch ein eigenes Testlabor, wobei Kognitions- und Grafik-Experten in einem strukturierten Testverfahren durch statistische Auswertung das Benutzerverhalten bei der Arbeit mit dem zu untersuchenden Softwareprodukt ermitteln und bewerten. Dieser Ansatz ist teuer und daher bei einfachen Softwareprojekten bzw. in einem Umfeld mit beschränkten Mitteln oft nicht praktikabel. Ein simpler Ansatz bietet sich durch den Einsatz von Fragebögen, die die Meinung der Benutzer über das Interface erfassen. Auch durch Beobachtung der Benutzer bei der Arbeit, durch Mitprotokollieren der Äußerungen der Benutzer (thinking aloud, entspricht einem Work Review und führt zu einem Mängelbericht) und durch den Einbau von Code können Informationen darüber gesammelt werden, welche Funktionen am meisten verwendet werden, welche am meisten Zeit beanspruchen und welche die meisten Fehler produzieren. Diese beschriebenen einfachen Möglichkeiten sollten für jedes Softwareprojekt an der Universität Wien vom Aufwand her vertretbar sein und bei Systemen mit starker Benutzerinteraktion und großen Benutzergruppen standardmäßig durchgeführt werden. Der Auftraggeber muss sich aber bewusst sein, dass jeder Test auf Usability mit Kosten verbunden ist, die bei der Schätzung der Gesamtkosten des Systems einzuplanen sind. 2. Entwicklung und Einrichtung einheitlicher Standards für die Benutzerschnittstelle von Softwaresystemen Es müssen einheitliche Standards für die Benutzerschnittstelle von Softwaresystemen an der Universität Wien entwickelt werden, die die Benutzerführung und den Look-and- Feel von Benutzerschnittstellen vereinheitlichen. Da hierzu spezifisches Usability- Expertenwissen notwendig ist, erscheint es empfehlenswert, diese Kompetenz über externe Experten einzukaufen. Dieses Bestreben muss auch im Zusammenhang mit der Entwicklung und Anwendung von Corporate Design Richtlinien für die Entwicklung von einheitlichen, intuitiven und komfortablen Benutzerschnittstellen für die Softwarepakete gesehen werden. Hierdurch wird einerseits eine deutliche Verbesserung der Akzeptanz der Systeme bei den Benutzern erreicht und andererseits aber auch Zeit und Geld durch Verringerung spezifischer Einschulungsmaßnahmen gespart. 3. Installation eines IT-Leitungsorgan Es muss über alle organisatorischen Ebenen der Universität Wien das Verständnis greifen, dass die IT Infrastruktur das Verbindungselement zwischen den organisatorischen und funktionalen Elementen der Universität darstellt. Daher hat das reibungsfreie, problemlose, intuitive (d.h. natürliche Prozesse unterstützende) und quasi unbemerkte Funktionieren dieses Klebstoffs zentrale Bedeutung. Seite 10 / 40

11 In den Gesprächen mit den verschiedenen Entwickler- und Anwendergruppen ist immer wieder das Problem angesprochen worden, dass zurzeit an der Universität Wien ein agierendes IT-Leitungsorgan mit Überblick und Entscheidungs-/Weisungsbefugnis (Kompetenz) über die gesamte IT Infrastruktur fehlt. Diese Person soll, ausgestattet mit fundiertem IT Sachwissen und projekterfahrener Führungskompetenz, ein abgestimmtes, erschöpfendes und durchdringendes Gesamtkonzept der IT Infrastruktur der Universität Wien verfolgen und entsprechend die Koordination der Vielzahl von Einzelprojekten durchführen. Dieses angestrebte umfassende Konzept muss alle Aspekte der IT Infrastruktur enthalten, wie die Softwareentwicklung, die Datenhaltung, den Einsatz der Systeme, Schulungsmaßnahmen, etc. 4, Betonung des Mehrwerts der neu eingerichteten Systeme durch den Auftraggeber Bei der Einführung von neuen Softwaresystemen an der Universität Wien tritt oft die Situation auf, dass die fokussierten Benutzer neue Systeme als Behinderung ihrer gewohnten Arbeitsabläufe sehen, dadurch nur bedingt bereit sind, Einschulungsaufwand zu betreiben und die Akzeptanz der Systeme dadurch schwer leidet. In manchen Fällen wird solch ein System gar als unerwünschtes Kontrollinstrument gesehen und dadurch generell abgelehnt. Es müssen daher von der Universitätsleitung bei der Einrichtung solcher Systeme Maßnahmen (ähnlich zu PR Aktivitäten) gesetzt werden, die den Benutzergruppen verdeutlichen, welcher Mehrwert für sie durch das neu eingerichtete System erreicht wird. Dies kann ein Weg sein, die aktuell wahrnehmbare Meinung vieler Benutzer, dass Systeme von Leitungsgremien verordnet werden, durch ein Anerkennen abzulösen, dass Systeme die Arbeitsabläufe der Benutzergruppen unterstützen und vereinfachen bzw. neue notwendige organisatorische Funktionalitäten zur Verfügung stellen. 5. Einrichtung eines RAD Advisory Boards Die Arbeitsgruppe ist überzeugt, dass das RAD System auch in der Zukunft eine zentrale Bedeutung für alle Benutzergruppen der Universität Wien besitzen wird. Um die Akzeptanz auch weiter zu gewährleisten und eine kontinuierliche Verbesserung und Erweiterung des RAD Systems zu erreichen, wird die Einrichtung eines RAD Advisory Boards empfohlen. Im ersten Schritt kann das erste Advisory Board aus den aktuellen Mitgliedern der Arbeitsgruppe bestehen (die Bereitschaft dazu wurde von den Mitgliedern erklärt). Es ist geplant, dass in einem wiederkehrenden (z.b. halbjährlichen oder jährlichen) Prozess dieses Advisory Board zusammentritt, die aktuellen Entwicklungen begutachtet, die von den Benutzergruppen und auch den Entwicklern gemeldeten Probleme analysiert und entsprechende Empfehlungen für die Verbesserung und Weiterentwicklung des Systems ausspricht. Seite 11 / 40

12 Anmerkungen zu den Verbesserungsvorschlägen Es wird von der Arbeitsgruppe betont, dass die präsentierten Vorschläge rein aus der Benutzersicht gemacht wurden. Die endgültige Umsetzbarkeit der Verbesserungsvorschläge muss daher von den Spezialisten der Entwicklungsfachabteilungen beurteilt werden. Es besteht dadurch auch die Möglichkeit, dass aufgrund nicht erkennbarer technischer Probleme und Abhängigkeiten einzelne Verbesserungsvorschläge nicht (sofort) oder nur eingeschränkt umgesetzt werden können. Solche problematischen Punkte sind daher durch das oben vorgeschlagene RAD Advisory Board zu analysieren und durch entsprechende Empfehlungen und überarbeitete Vorschläge zu behandeln. Die Verbesserungsvorschläge im folgenden Abschnitt wurden auf der Basis der erhobenen Problemlisten entwickelt, die auf den Meldungen der Fakultäten und Zentren beruhen. Durch die laufende Verbesserung des RAD Systems durch die Entwicklungsabteilung in Zusammenarbeit mit den administrativen Einrichtungen sind daher möglicherweise einige der im Folgenden angeführten Verbesserungsvorschläge schon (teilweise) umgesetzt worden und daher überholt. Auch hier sieht die ARGE die Notwendigkeit des RAD Advisory Boards, diese Entwicklungen zu begutachten und entsprechend mit der Verbesserungsvorschlagsliste abzugleichen. Die nachfolgenden Verbesserungsvorschläge erheben keinen Anspruch auf Vollständigkeit. Da das Dokument den Beitrag mehrere Mitglieder der ARGE zusammenfasst, ist die Formulierung an manchen Stellen elaborierter als an anderen. Dadurch dass gewisse Problembereiche mehrere der unten angeführten Themenbereiche betreffen, kann es zu Überlappungen bei manchen Verbesserungsvorschlägen kommen. Seite 12 / 40

13 Danksagung Als Leiter der ARGE Usability RAD möchte ich mich an dieser Stelle bei allen Mitgliedern und ständigen Auskunftspersonen der Arbeitsgruppe bedanken und besonders die konstruktive und kooperative Arbeitsweise in den Sitzungen hervorheben. Persönlich glaube ich, dass es durch die Tätigkeit dieser Arbeitsgruppe gelungen ist, ein gegenseitiges Verständnis der Positionen aller beteiligten Interessensvertreter zu erreichen, das es ermöglichte, in produktiver und positiver Atmosphäre die Ziele der Arbeitsgruppe zu erreichen. Abschließend bedanke ich mich auch bei den Vertretern der AUV des zentralen Informatikdienstes der Universität Wien, die immer geduldige Zuhörer und höchst kompetente Partner bei der Analyse der Probleme und der Diskussion um die Umsetzbarkeit der Vorschläge der ARGE waren. Erich Schikuta Seite 13 / 40

14 1 Arbeitsworkflow 1.1 Beschreibung Unter Arbeitsworkflow versteht die ARGE die Sequenz von Benutzeraktivitäten 2 zur Ausführung einer spezifischen Systemfunktion. Diese Definition ist möglicherweise unterschiedlich zur technischen Begrifflichkeit der Fachabteilung. Alle BenutzerInnen Aktivitäten (Dateneingabe, Änderungen, etc.) werden durch einen s. g. Workflow im RAD realisiert. Dies heißt, dass eine eindeutig vorgegebene Abarbeitungsfolge für jede Aktivität definiert ist, die durch eine Reihe von Benutzereingaben (Text, Steuerung, Quittierungen, etc.) realisiert wird. Bei allen Workflows sollten spezifisch (neben den üblichen Usability-Kriterien) einige grundsätzliche Regeln gelten: Klarer Fokus auf Benutzeraktionen (weniger Fenster bzw. konfigurierbar, ob sich für jede neue Benutzeraktion ein neues Browserfenster öffnen soll) Abgeschlossene Teil-Workflows mit entsprechender Quittierungsinformation Jederzeit Überblick über den Workflow ( Wissen wo man gerade ist ); Vermeidung der Verwirrung des Benutzers durch zusätzlich aufgehende Fenster die nach Beendigung nicht wieder zum Ursprungsfenster zurückkehren Intuitiver Arbeitsablauf (von oben nach unten, von links nach rechts); alle Pflichtfelder sollen nah beieinander liegen und noch vor den optionalen Eingabefeldern im Webformular aufscheinen Einheitliche (konsistente) Benutzerführung Jederzeit Unterbrechbarkeit des Workflows ohne Datenverlust (Speicherfunktion) etc. Der/Die BenutzerIn sollte immer wissen, im Kontext welcher Anwendung sie sich gerade befindet. 1.2 Ziel Die Arbeit mit dem System muss intuitiv und einfach vonstatten gehen. An jeder Stelle müssen die BenutzerInnen einen Überblick über die aktuelle Workflow-Situation haben und die Möglichkeit besitzen, Workflows für eine spätere Fortsetzung ohne Datenverlust unterbrechen zu können. 1.3 Referenz(en) auf Problemliste P4 Unklarer Arbeitsworkflow, zu viele Fenster, kein Feedback P19 Lange Antwortzeiten -> größtenteils schon durch neue Releases behoben P20 Vielschichtige Erfassungsebenen P13 Look & Feel schlecht P16 Verlust von eingegebenen Daten bei irrtümlichem Ausstieg P25 System überladen 2 Zum Zwecke der Lesbarkeit wird nicht zwischen Benutzerin und Benutzer unterschieden. Die Bezeichnung Benutzer in all seinen Abwandlungen und Zusammensetzungen ist deshalb immer geschlechtsneutral zu verstehen. Analog trifft dies für andere Personengruppen mit ihren unterschiedlichen Rollen wie Autor oder Sachbearbeiter zu. Seite 14 / 40

15 1.4 Betroffene Personengruppe 3 Reader 1.5 Priorität 4 Hoch 1.6 Überprüfungskriterium Akzeptanz durch den Benutzer Speicherfunktion Fensteranzahl nie größer als 2 Notwendiges scrollen in Fenstern minimieren Verringerung der Anfragen an die RAD Redaktion 1.7 Konkreter Umsetzungsvorschlag Speicherfunktion für Workflows (samt Wiederaufnahmemöglichkeit) Es muss möglich sein einmal angefangene und nicht vollständig beendete Workflows zwischen zu speichern, damit diese zu einem späteren Zeitpunkt (eventuell von einem/r anderen MitarbeiterIn) vervollständigt werden können. Priorität: hoch Informationsfenster über offene Workflows Nicht vollständig durchgeführte Workflows sollen in einem separaten Bereich/extra Fenster als eine Art ToDo Liste aufscheinen, damit BenutzerInnen Bescheid wissen, welche Workflows sie noch fertig stellen müssen. Priorität: hoch Fortschrittsanzeige für Workflows Diese kann entweder rein sprachlich realisiert werden, indem der momentane Abarbeitungsschritt und die Gesamtschritte angegeben werden ( Sie befinden sich momentan in Schritt 2 von 5 ) oder über einen grafischen Fortschrittsbalken (samt Prozentanzeige), welcher einen groben Überblick darüber liefert, wie weit man den momentanen Workflow schon durchgearbeitet hat. Priorität: mittel 1.8 AG Verantwortliche(r) G. Ecker, E. Schikuta 3 Reader sind jene MitarbeiterInnen der Universität Wien, welche i.d.r. nur lesend auf die Daten des RAD Systems zugreifen wollen bzw. müssen. Writer hingegen müssen auch die Möglichkeit haben, Attribute der Daten zu ändern oder im besten Fall auch löschen zu können. Sie sind vergleichbar mit den Redakteuren einer Online-Zeitschrift. 4 Als Niedrig sind jene Probleme einzustufen, welche zwar im täglichen Gebrauch stören, aber die Arbeitsleistung bzw. den Funktionalitätsumfang des RAD Systems nicht beeinträchtigen. Als Mittel gelten jene Probleme, welche die tägliche Arbeit mit RAD erschweren bzw. die Eingabe der Daten deutlich verlangsamen und so das System aus BenutzerInnen Sicht unattraktiv machen. Als Hoch eingestufte Probleme betreffen Kernfunktionen der RAD Applikation und sind umgehend zu lösen bzw. abzuschwächen, um ein sinnvolles Arbeiten erst zu ermöglichen. Seite 15 / 40

16 2 Benutzerschnittstelle und Dokumentation Die hier getätigten Aussagen basieren auf dem Interface, welches am 21. Mai 2008 (Vormittag) aktiv war. Alle Anwendungen sollen im selben Design gehalten werden. 2.1 Beschreibung Das RAD stellt die zentrale EDV-gestützte Schnittstelle der wissenschaftlichen MitarbeiterInnen für die Forschungsdokumentation der Universität Wien dar. Daher muss die Benutzerschnittstelle so einfach bzw. übersichtlich wie möglich und so komplex wie nötig sein. Weiters sollte ein technologischer Mindeststandard an der Universität Wien vorausgesetzt werden, d.h. die nach Internetstatistiken führenden Browser (Internet Explorer, Firefox, Opera, etc.) in der aktuellen, sowie der vorletzten Version müssen unterstützt werden, andere nicht. 2.2 Ziel Oberstes Ziel muss es sein, die Benutzbarkeit als zentralen Zeit- und Kostenfaktor zu optimieren und damit auch die BenutzerInnen- bzw. KundInnenzufriedenheit zu steigern. Ein klar strukturiertes Interface im gleichen Design mit Wiedererkennungswert soll geschaffen werden. Wenn also neue Daten durch die BenutzerInnen angelegt werden, sollten bereits Benutzerspezifische Defaulteingaben zu einer leichteren Bedienbarkeit verhelfen. Dadurch wird nicht zuletzt auch die Datenqualität gesteigert. 2.3 Referenz(en) auf Problemliste P5 Kein User Kontext zur Erleichterung von Eingaben P6 Navigationsproblem, wenn Menüs nicht verbessert werden -> Back Button, Standardfokus für Webformulare funktioniert nicht P8 keine griechischen/hebräischen/zyrillischen Zeichen -> i3v Problem P21 Bei irrtümlichem Klick wartet Programm auf Eingabe P23 Unlogisches Interface (Button Bearbeiten wenn es nicht möglich ist) P28 Fehlende Kurzdokumentation in den Webmasken 2.4 Betroffene Personengruppe Reader 2.5 Priorität Hoch/Höchste 2.6 Überprüfungskriterium Akzeptanz durch den Benutzer mind. 75%: Umfrage (auf UniVie Portal) Login Statistik samt Verweildauer und Zugriffsstatistik bezüglich der einzelnen RAD Bereiche Seite 16 / 40

17 2.7 Konkreter Umsetzungsvorschlag Verwendung/Beachtung von existierenden User Interface Guidelines Orientierung an einer der beiden folgenden User Interface Guidelines, um den BenutzerInnen bei der Bedienung der Arbeitsumgebung entgegenzukommen: Apple Human Interface Guidelines Windows Vista User Experience Guidelines Eine zentrale Notwendigkeit ist es, Vorgaben zur Erstellung von Uni Wien Webseiten vorzugeben, an denen sich dann die einzelnen Fakultäten, Zentren, Institute oder Arbeitsgruppen bei der Erstellung Ihrer Webpräsenz orientieren können. Priorität: mittel Zugang zum RAD verbessern (Wie komme ich zur RAD?) Die Information über den existierenden RAD Zugang muss besser an den Benutzer herangetragen werden. Suche auf UniVie liefert den Link Es ist jedoch nicht klar, wie der/die BenutzerIn nun von dort aus zur eigentlichen RAD Eingabe gelangt. Erst durch Anklicken des User Manuals gelangt man letztendlich auf die Seite, in der die Submenüs auf die RAD Applikation(en) verweisen. Dies sollte eigentlich in einem Punkt Eingabe subsumiert und nicht nur bei User Manual verlinkt sein. Diese Punkte verweisen aber wiederum auf und erst nach einem erfolgreichen Login findet der/die BenutzerIn einen Menüpunkt Research Activity Documentation, wo er/sie eigentlich den Menüpunkt RAD erwartet hätte. Eine Lösung wäre es einfach einen DNS-Eintrag (einen s. g. Alias unter anzulegen, der dann auf die RAD Eingabeseite (= UNIVIS) weiterleitet. Eine andere Möglichkeit ist einen Querlink auf der UniVie Startseite ( einzurichten, der direkt ins RAD führt. Ein weiteres Ziel sollte sein, in der Google-Suche mit den Suchbegriffen univie und rad auf der ersten Suchergebnisseite aufzuscheinen. Die Links zu Dokumentationen und Kurzdokumentationen des RAD fehlen völlig, wenn man sich im RAD System befindet. Die Dokumentation befindet sich lediglich im RAD- Portal, d.h. eigentlich ganz wo anders. Man sollte hier also die Dokumentation als Link im Menü im linken Bereich hinzufügen. Auch innerhalb der RAD Applikation kommt es manchmal zu Verwirrungen, weil BenutzerInnen nicht mehr wissen, in welcher Applikation sie sich momentan befinden. Das rührt hauptsächlich daher, dass alle geöffneten RAD Fenster den gleichen Namen tragen. Hier würde eine s. g. Breadcrump (Brotkrümelnavigation) helfen, um immer zu wissen in welcher Gliederungsebene man sich momentan befindet (vgl. CEWebS Breadcrumb Navigation). Abbildung 1: CEWebS Breadcrumb Navigation Seite 17 / 40

18 Ein zusätzlicher RAD/UNIVIS Home-Button würde es den BenutzerInnen erleichtern wieder auf die Startseite/Ursprungsseite zurückzukehren. Priorität: mittel VPN Zugang vereinfachen Momentan ist es noch schwierig bzw. unmöglich sich von einem Arbeitsplatzrechner, welcher nicht im Uni Wien Netz hängt ins RAD einzuloggen. Selbst unter Verwendung des UniVPN ist dies manchmal nicht möglich. Hier müssen die entsprechenden Firewall Regeln gesetzt werden bzw. Datenverkehrsfilter weniger rigoros ausgelegt werden, um allen Mitarbeitern auch von zu Hause aus mittels UniVPN den Zugriff auf RAD zu gewährleisten. Eine mögliche Lösung wäre es, den Login des RAD Systems mit jenem des web-basierten VPN Zugangs zu koppeln, um so das Arbeiten mit RAD besonders für technisch weniger versierte Anwender noch einfacher und bequemer zu gestalten. Priorität: niedrig An- und Abmeldung Eine Anmeldung zum RAD ist über das Login im UNIVIS durch Aufruf der Seite möglich. Die Links Angemeldet als und Abmelden sollten links im Menü oder aber links in der Kopfzeile stehen, wo jetzt unsinniger- bzw. überflüssigerweise English steht, das als eher unwichtig gesehen auch weiter rechts stehen könnte. Aufruf einer RAD Applikation und Betätigen des rechts oben versteckten Abmelde-Button wirft mich ganz aus dem univis hinaus. Ein erneutes Login führt mich aber nicht mehr ins univis, sondern wieder in die RAD äußerst verwirrend. UNIVIS PROBLEM: login im univis und Anklicken der Lehrabgeltung wirft mich aus der univis Seite hinaus (ohne Rückkehrmöglichkeit, Back-Button funktioniert nicht) ich muss mich dort bei nochmals anmelden, und weiß aber z.b. danach nicht, wie ich mich beim univis abmelden sollte, wo ich ja eigentlich eingestiegen bin. Außerdem ist bei der Prüfungsprämienabrechnung das Interface/Layout völlig anders. Wo bin ich? Darüber gibt das beschnittene, d.h. verkleinerte Menü links Auskunft. Ein Hinweis im Menü links, dass die Anwendung geschlossen werden muss (Abbrechen/Speichern), um einen Level höher zu kommen, wäre aber hilfreich. Oder eine Status- bzw. Meldungszeile am oberen Seitenrand, die darauf hinweist. Priorität: mittel Abbildung 2: RAD Benutzer- und Sprach-Menüleiste Dokumentation erweitern Dokumentation der Einstiegsseite rad.univie.ac.at ist äquivalent zu univis.univie.ac.at und deren Einbettung in UNIVIS. Erklärung des VPN Zuganges mit Mitteln des User-Systems. Seite 18 / 40

19 Kurzdokumentation: Ein vollständig ausgefülltes Formular der aktuellen RAD- Anwendung als Beispiel zur Hilfe anbieten. Projekte: Was sind Globalprojekte? Hardware/Software Anforderungen für Benutzer des RAD-Systems bezüglich des zu verwendeten Browsers bzw. der unterstützten Auflösungen. Manche der beschriebenen Vorschläge werden in der aktuellen Version des RAD Systems schon umgesetzt. Es wird dabei hingewiesen, dass die Verbesserung der Online- Dokumentation gemeinsam zwischen dem Entwicklungsteam und der RAD Redaktion durchgeführt wird. Es muss geklärt werden, ob die zur Verfügung stehenden Ressourcen ausreichen, um den angestrebten Dokumentationsumfang in der notwendigen Qualität erreichen zu können. Priorität: mittel GUI User-Schnittstelle verbessern Die nachfolgend angegebenen Vorschläge sind teilweise im aktuellen RAD System schon umgesetzt. Weiters müssen alle nachfolgenden Überlegungen unter dem Gesichtspunkt des Prinzips der Barrierefreiheit betrachtet werden. Es sollte ein technologischer Mindeststandard an der Universität Wien vorausgesetzt werden, d.h. die nach Internetstatistiken führenden Browser in der aktuellen, sowie der vorletzten Version müssen unterstützt werden, andere nicht. Fenstergröße für die Entwicklung sollte 1024 x 768 Pixel oder größer sein. Seitendarstellung kompakter, Boxen um Text Schwarz umranden und nicht im selben Grau wie die Überschrift verbessert Les- und Sichtbarkeit. Hilfe Button ist verwirrend und es ist oft nicht klar, wie dieser mit dem umgebenden Kontext zusammenhängt rechts in gleiche Zeile wie Input-Box platzieren, oder Hilfetext nur in Popup-Fenster ausgeben, wenn man mit der Maus darüberfährt. Dazu kann das alt-attribut des HTML Standards verwendet werden. Lösungsvorschlag: Prinzip der räumlichen Nähe anwenden, wobei zusammengehörige Web Elemente immer sehr nahe zusammen liegen (anwendbar auf die Hilfe-Links). Lösungsvorschlag: Hilfetext nicht in einem eigenen Fenster anzeigen, sondern diesen als alt -Text integrieren oder mittels mouseover -Ereignis beim Überfahren der entsprechenden Zeile mit der Maus anzeigen. Sortierung der Ausgabe von Listen über Anklicken der Spaltentitel. Alle wichtigen Kommandos sollten am Kopf und am Ende der Seite angegeben sein. Seite 19 / 40

20 Abbildung 3: RAD Statusanzeige und Hilfebutton Buttons allgemein: Forscherprofil: Der Bearbeiten-Button ist als solcher nicht erkennbar und es sollte wie bei Publikationen der Button NEU oben und unten auf der Seite erscheinen und immer als Button erkennbar sein. Forschungsprojekte: Button Abbrechen/Speichern sollte auch ganz oben aufscheinen. Abbildung 4: RAD Buttons Der Status der Eingaben (etwa Nicht zur Veröffentlichung freigegeben ) sollte mit dem Bearbeiten/Neu Button gekoppelt angezeigt und veränderbar sein Status DropDown Menü mit Set-Button in oberster Zeile Platz ist hierfür genügend vorhanden. Subanwendungen (z.b. Gast anlegen): Bei Klick auf Rolle (des Eingebenden) ändern, verschwindet das Gast-Fenster und es öffnet sich nur ein Rollen und Institutsfenster. Es sollte für beides, Gast und Rolle, nur eine Eingabemaske/ein Fenster existieren, etwa als DropDown im Sinne eines Folding-Editors. Seite 20 / 40