MSP: Vision Document HÜ "Counter, Highlighting"

Aus THM-Wiki
Wechseln zu: Navigation, Suche

Introduction

Eine Analyse mehrerer QA-Sitzungen sowie Gespräche mit Benutzern haben ergeben, dass der Fokus bei allen Formen von Web-Anwendungen, so auch bei einer Kollaborations-Plattform, auf Usability gelegt werden muss. Daher müssen einige Funktionalitäten des Moduls eModeration überarbeitet werden. Im Folgenden soll aufgezeigt werden, was wie verändert wird, um die Usability zu verbessern und damit das Modul aufzuwerten.

Business Needs / Requirements

Virtuelle Klebepunkte

Das Modul eModeration bietet Arbeitsgruppen die Möglichkeit, über bestimmte Sachverhalte abzustimmen, indem jedes Mitglied der Gruppe einen virtuellen Punkt an die virtuelle Pinwand „klebt“. Für den Moderator kann es bei größeren Arbeitsgruppen mühsam werden, die Punkte zu zählen.

Beispiel:

Eine Arbeitsgruppe von 20 Leuten stimmt über einen Sachverhalt ab. Jedes Mitglied bekommt hierfür vom Moderator 3 Punkte bereitgestellt. In der Summe hat der Moderator nun 60 virtuelle Punkte zu zählen.

Dass der Moderator an einem Bildschirm arbeitet kann das Zählen durchaus erschweren.


Bildgrößen der Galerie:

Um eine Moderation nicht abfotografieren zu müssen, stellt das Modul eModeration eine Galerie-Funktion zur Verfügung. Hiebei wird das gesamte virtuelle Flipchart als Bild abgespeichert. Derzeit unterscheiden sich die Bilder in ihrer Größe, um genauer zu sein in ihrer Höhe (meist zu lang). Gespräche mit Benutzer haben aufgezeigt, dass dies nicht dienlich ist, weshalb dieser Umstand geändert werden soll.


Farbhervorhebung beim Setzen von Klebepunkten:

Nach mehreren QA-Iterationen hat sich herausgestellt, dass die Farbhervorhebung eines Feldes, in dem ein Teilnehmer einen Punkt kleben darf, als hässlich empfunden wird. Die Hervorhebung sieht nur bei weißen Feldern gut aus.

Product / Solution Overview

Virtuelle Klebepunkte:

Um das oben beschriebene Problem zu lösen, soll ein ToolTipp implementiert werden, der dem Moderator die Anzahl der geklebten Punkte in einem Feld anzeigt. Somit kann er auf einen Blick erkennen, wieviele Punkte wo geklebt wurden und eine Abstimmung sehr schnell auswerten. Dies stellt im Sinne der Usability eine schlanke und sinnvolle Verbesserung dar.


Bildgrößen der Galerie:

Wenn der Platz nicht ausreicht, so wird derzeit die aktuelle Pinwandgröße verdoppelt. Dies führt oftmals zu überschüssigem Platz am unteren Ende der Pinwand. Hier soll die Vergrößerung der Pinwand minimal bleiben, also nur soviel Platz angehängt werden, wie notwendig.


Farbhervorhebung beim Setzen von Klebepunkten:

Da das „Blinken“ der Felder, in welche ein Punkt geklebt werden kann, als nicht ästhetisch empfunden wird, soll dies angepasst werden. Dazu wird die Grundfarbe der blinkenden Box an die Farbe des Untergrund-Elementes angepasst.

Scope & Limitations

Alle oben angesprochenen Features werden hauptsächlich mit Javascript realisiert. Entsprechend muss der Browser des Clients diese Skriptsprache natürlich erlauben.

Implementation

Klassendiagramm und Reverse Engineering

Das Klassendiagramm wurde erstellt, um einen ungefähren Überblick über den Code zu erhalten. Es wurde bewusst kein Wert auf vollständige Angaben gelegt (Methoden, Attribute und Assoziationen), da dies der Übersicht nicht sonderlich dienlich war. Das Klassendiagramm zeigt in der jetzigen Form die wichtigsten Klassen, die für diese Hausübung von Belang waren.

EMod Klassendiagramm.png

Als Tool wurde JS/UML ausprobiert. Leider konnte mit hiermit kein befriedigendes Ergebnis erzielt werden, da im vorhandenen Quellcode verschiedene Frameworks (Prototype und zwei weitere mit eigenen Ergänzungen) genutzt wurden. So konnte das Tool den Quellcode per Reverse Engineering nicht in brauchbare Diagramme umwandeln. Es blieb letztendlich nichts anderes übrig, als die Diagramme "von Hand" zu erstellen indem der Quellcode analysiert wurde.

Aufgetretene Probleme

Ein massives Problem bei der Implementierung der Hausübung war, sich in den vorhandenen Code einzuarbeiten. Dies fiel angesichts der vielen Klassen, schlechter Bennenung und auch der mangelnden Organisation extrem schwer. So ist sehr viel Zeit in die Einarbeitung geflossen, da auch keine passenden Unit-Tests zur Verfügung standen. Generell lässt sich sagen, dass zum einen keinerlei Dokumentation vorlag, zum anderen aber auch der Code nicht selbstdokumentierend geschrieben ist. Die Klassen-, Attribut- und Methodennamen sind nicht sprechend gewählt worden. Hier wäre ein Refactoring angebracht, was jedoch in der Kürze der Zeit nicht machbar war.

Die Umsetzung

Folgende Ziele wurden erreicht. Die Farbhervorhebung wurde angepasst, die Flächen blinken nun in der Hintergrundfarbe des "Droppbereichs". Außerdem wurde der Counter implementiert, der allen Teilnehmern anzeigt, wieviele "Klebepunkte" in einem "Droppbereich" platziert wurden. So bekommt man jetzt einen schnellen Überblick über den Zwischenstand einer Abstimmung.

Der Counter sollte ursprünglich mit Hilfe des vorgegebenen Codes realisiert werden, was jedoch nicht möglich war. Auch über das DOM konnten keine korrekten Informationen gefunden werden. So musste die "geographische Lage" des "Droppbereichs" und der Punkte bestimmt werden, um die korrekte Zahl für den Counter zu ermitteln. Für das Highlighting musste nur die Klasse PermanentHighlighter mit anderen Parametern ausgeprägt werden.

--Philippi-SPh 14:01, 13. Nov. 2008 (UTC)