g1t13

Mehrbenutzereditoren (up)

Projekt-Team 13 
 

Motivation (up)

In Seminaren und Praktika muss man immer wieder mit Kollegen zusammen an einer Dokumentation arbeiten.  
Diese Gruppenarbeiten können mitunter viel F2F-Zeit in Anspruch nehmen, langwierig und frustrierend sein. 
Ich versuche immer wieder Mehrbenutzereditoren bei Gruppenarbeiten einzusetzen, und es ist für mich sehr interessant wie wenige Kollegen damit umgehen können und sich dieser Möglichkeit überhaupt bewusst sind.  
 
Auch viele Lehrende nutzen Wikis für Gruppenarbeiten, ohne sich den Stärken und Schwächen der benutzten Software im Klaren zu sein. Die Alternativen sind kaum bekannt. 
 
Um das richtige Tool für die Aufgabe zu finden, und herauszufinden welche Software ich für die nächsten Gruppenarbeiten nutzen und meinen Kollegen empfehlen werde, befasse ich mich in dieser Ausarbeitung mit dem Thema "Mehrbenutzereditoren". 

Ziel des Projektes (up)

Ziel der Arbeit ist es die Forschungsfragen zu klären und ein Handout zu erstellen, das die Erkenntnisse kurz und bündig für meine Kollegen aufbereitet. 
Zielgruppe sind Studenten aller Studienrichtungen. 
 

Kurzpräsentation (up)

Projektablauf (up)

Projektplan (up)

 

Projekt (up)

Idee (up)

Evaluation von Mehrbenutzereditoren, Vor- und Nachteile von synchroner Technologie mit Schwerpunkt auf Mediawiki, Google Docs und Titanpad 

Struktur (up)

 

Abstract (up)

In der folgenden Ausarbeitung sollen verschiedene technische Ansätze im Kontext von Mehrbenutzereditoren getestet, verglichen und evaluiert werden.  
Im Speziellen wird ein Augenmerk auf die Vor- und Nachteile synchroner gegenüber asynchronen Editoren gelegt und die jeweiligen User-Interfaces auf Tauglichkeit und Intuitivität überprüft. 
Um die Tauglichkeit für studentische Gruppenarbeit zu prüfen werden bestimmte Kriterien ausgearbeitet, mit Kollegen und einem einfachen Fragebogen getestet, und in weiterer Folge bewertet. 

Forschungsfragen (up)

Vorstellen der Möglichkeiten (up)

Mediawiki (up)

Mediawiki Logo
Abbildung 1: Mediawiki Logo
 

Eigendefinition (up)

MediaWiki is free server-based software which is licensed under the GNU General Public License (GPL). It's designed to be run on a large server farm for a website that gets millions of hits per day. MediaWiki is an extremely powerful, scalable software and a feature-rich wiki implementation, that uses PHP to process and display data stored in a database, such as MySQL. 
Pages use MediaWiki's wikitext format, so that users without knowledge of XHTML or CSS can edit them easily. 
When a user submits an edit to a page, MediaWiki writes it to the database, but without deleting the previous versions of the page, thus allowing easy reverts in case of vandalism or spamming. MediaWiki can manage image and multimedia files, too, which are stored in the filesystem. For large wikis with lots of users, MediaWiki supports caching and can be easily coupled with Squid proxy server software. 
«http://www.mediawiki.org/wiki/Manual:What_is_MediaWiki%3F» 
 
Ansicht Mediawiki
Abbildung 2: Ansicht Mediawiki
 
 
Der bekannteste Vertreter der Gruppe der Wiki-Software ist wohl das Projekt "Mediawiki". Sie wird vom Projekt Wikipedia genutzt. Diese Enzyklopädie beruht ja bekanntlich auf der Idee, dass viele Nutzer gemeinsam an einem Artikel arbeiten können, und so Stück für Stück ein möglichst optimales Ergebnis erreicht wird. 
Technisch basiert Mediawiki auf einer großen Datenbank, welche die Inhalte zur Verfügung stellt, einem recht einfachen Frontend das Input und Output erlaubt und einer Benutzerverwaltung. Versionierung ist in Mediawiki einfach gelöst indem alle Entwicklungsstufen gespeichert werden, Veränderungen angezeigt werden können und wenn nötig wieder rückgängig zu machen sind.  
Mediawiki kann als eigenständiges Softwarepaket heruntergeladen und auf eigenen Servern installiert werden.  
Bei der Bedienung, vor allem beim Editing, verfolgen Wikis ein ganz anderes Konzept als herkömmliche WYSIWYG Desktop-Wordprozessoren. Hier wird, ähnlich wie bei html oder latex ein "what you mean is what you get" Ansatz verfolgt, der eine spezielle Auszeichnungssprache nutzt um Textteilen eine gewisse Funktion - und damit eine spezielle Formatierung zuzuweisen. 
Diese Differenz ist historisch bedingt, da die Grundidee des Read-Write Web schon von Tim Berners Lee definiert wurde, und in weiterer Folge von Technikern, um nicht Geeks zu sagen, wie Ward Cunningham technisch umgesetzt wurde.  
Wie man so oft sehen kann ist Usability nicht die Hauptsorge dieser Gruppe, was das einarbeiten in ein Wiki, wie auch die folgende Umfrage zeigen wird, eher zeitaufwändig macht. 
Interessant ist auch, dass Mediawiki schon vom Konzept her ein gleichzeitiges Bearbeiten unterbindet. Es ist somit also ein rein asynchroner Mehrbenutzereditor. In meinen Augen bietet das zwar in der Konzeption und technischen Umsetzung von Großprojekten - wie eben der Wikipedia - Vorteile, allerdings liegen darin auch einige Probleme begründet, die wir aktuell in der studentischen Nutzung von Mehrbenutzereditoren sehen. Ein "Wiki" wird vielfach als Allheilmittel gegen Probleme bei Gruppenarbeiten gesehen, stellt aber an und für sich für den Umfang zB. einer Seminararbeit nicht unbedingt geeignete Tools zur Verfügung. 
 

Google Docs (up)

Google Docs Logo
Abbildung 3: Google Docs Logo
 

Eigendefinition (up)

Google Docs is a suite of products that lets you create different kinds of online documents, work on them in real time with other people, and store your documents and your other files – all online, and all for free. With an Internet connection, you can access your documents and files from any computer, anywhere in the world. (There's even some work you can do without an Internet connection!)  
 
Google documents is an online word processor that lets you create and format text documents, and collaborate with other people in real time. Here's what you can do with Google documents: 
 
Convert most file types to Google Docs format. 
Add flair and format your documents, with options such as paint format, margins, spacing, and fonts. 
Invite other people to collaborate on a doc with you, giving them edit, comment or view access. 
Collaborate online in real time and chat with other collaborators. 
View your documents' revision history and roll back to any version. 
Download Google Docs to your desktop as Word, OpenOffice, RTF, PDF, HTML or zip files. 
Translate a document to a different language. 
Email your documents to other people as attachments. 
 
«http://support.google.com/docs/bin/answer.py?hl=en&answer=49008» 
 
Ansicht Google Docs
Abbildung 4: Ansicht Google Docs
 
 
Der Suchmaschienenbetreiber Google hat sich mit den Google Labs schon länger darauf spezialisiert auch in andere Bereiche zu expandieren und hier Möglichkeiten anzutesten. Aus dieser Arbeit ist neben Google Mail auch die Dokumentenverwaltung Google Docs entstanden. 
Auf die datenschutzrechtlichen Bedenken möchte ich erst später eingehen, im Zentrum soll in dieser Ausarbeitung die Funktion der Software stehen. 
Google bietet einen Mehrbenutzereditor für Dokumente, aber auch für Präsentationen oder Tabellenkalkulation an, der in seiner Entwicklung stark an den Funktionsumfang herkömmlicher Desktop-Publishing-Software erinnert. Das ist auch der Ansatz, der hier verfolgt wird, möglichst herkömmliche Desktop-Tools in die Cloud zu verlagern - und bekannte Nutzermuster zu erhalten. 
Somit zeigt sich auch klar, wer die Zielgruppe dieses Produktes ist. Nutzern, die herkömmliche Desktop-Tools, wie Open Office oder MS Office gewohnt sind, soll der Umstieg möglichst einfach gemacht werden. So erhofft man sich eine große Nutzerbasis in kurzer Zeit zu gewinnen. Die Zahlen, die ich dazu gefunden habe, geben dem Konzern mit dieser Taktik durchaus Recht. 

Google und der Datenschutz (up)

Wenn man über Google spricht muss man auch ein paar Worte über Datenschutz verlieren. Diese Arbeit soll zwar generell mehr Usability-lastig sein, doch darf man nicht aus den Augen verlieren, dass man Google Docs nur fremdgehostet nutzen kann. Somit bietet man Google, wenn auch anonymisiert und den Datenschutzrichtlinien entsprechend «http://www.google.com/intl/de/policies/privacy/», Zugriff auf die privaten Daten. Abwägen muss jeder Nutzer dieses Risiko für sich selbst, und in letzter Instanz hängt es auch vom Ver- oder Misstrauen gegenüber dem Konzern ab. Allerdings muss man sich - um eine fundierte Entscheidung treffen zu können - mit dem Thema befassen und die Risiken kennen. 
 
 

Etherpad (up)

Etherpad Logo
Abbildung 5: Etherpad Logo

Eigendefinition (up)

EtherPad is the first web-based word processor that allows people to work together in really real-time. 
 
All editing of the document is instantly visible on the screens of all participating users, enabling new and productive ways to collaborate on text documents. Etherpad is useful for meeting notes, drafting sessions, education, team programming, and more 
 
«http://etherpad.org/» 
 
Ansicht Etherpad
Abbildung 6: Ansicht Etherpad
 
 
Als dritte Option möchte ich Etherpad vorstellen. Ein Vertreter der eher minimalistischen, auf Usability spezialisierten Mehrbenutzereditoren. Titanpad basiert auf dem Open Source Projekt Etherpad. 
Dadurch, dass Etherpad Open-Source Software ist, kann man mit der Software sowohl fremdgehostet sehr einfach und schnell ein Dokument mit mehreren Nutzern anlegen und nutzen, hat aber auch die Möglichkeit den Quellcode auf eigenen Servern laufen zu lassen, um mögliche Datenschutzprobleme von vorn herein auszuschließen. 
Wenn man Etherpad in einem Spektrum an Mehrbenutzereditoren sehen möchte, setzt das Projekt Etherpad verstärkt auf den kollaborativen Aspekt. Mediawiki ist spezialisiert auf große Projekte, erfahrene und eingearbeitete Nutzer und viele kleine Änderungen. Google Docs sieht sich selbst als Word-Processor, der nebenbei Mehrbenutzerbetrieb bietet.  
Etherpad hingegen ist ein reiner Mehrbenutzereditor, der auch etwas Formatierung erlaubt. 
 
 
Spektrum der Mehrbenutzereditoren
Abbildung 7: Spektrum der Mehrbenutzereditoren

Theorie (up)

Multibenutzer-Editoren sind - von der Idee her - sehr eng mit der Entwicklung des Internets verbunden. Bereits Tim Berners Lee hatte in seiner ersten Konzeption des Internets eine Plattform erdacht, an der jeder mitarbeiten konnte. Der Term "Read/Write Web" wurde von ihm geprägt. 
 
"The idea was that anybody who used the web would have a space where they could write and so the first browser was an editor, it was a writer as well as a reader. Every person who used the web had the ability to write something. It was very easy to make a new web page and comment on what somebody else had written, which is very much what blogging is about." («http://codinginparadise.org/weblog/2005/08/tim-berners-lee-on-readwrite-web.html») 
 
 
Dass sich das Internet an und für sich nicht in diese Richtung entwickelt hat, wissen wir heute. Klarerweise ist es einfacher Inhalte zu konsumieren, als sie zu schaffen. 
Die Grundidee existiert allerdings immer noch, und aus ihr wurden die ersten Wikis entwickelt. Auf die Namensgebung und Geschichte möchte ich hier nicht weiter eingehen, das würde den Rahmen sprengen, aber interessant ist, dass die Möglichkeiten von Wikis erst durch das Auftauchen der Wikipedia einem breiteren Publikum bekannt gemacht wurde. 
 
Im Gegensatz zu Wikis - welche asynchrone Editoren sind - bauen sowohl Google Docs als auch Etherpad auf einem synchronen Ansatz auf. 
Mehrere Benutzer können gleichzeitig an einem Dokument arbeiten, Änderungen werden quasi zeitgleich zu den Mitarbeitern übertragen. Diese Transparenz ist natürlich sehr anspruchsvoll was Rechenleistung und Netzwerkverbindung betrifft. 
Die hohen Anforderungen und großen Nutzerzahlen von Google Docs werden durch eine Zwischenlösung abgefedert. Google Docs ist nur "pseudo-synchron", technisch ist ein kleiner, durchschnittlich mit fünf bis fünfzehn Sekunden angegebener, Lag eingebaut, der die Server-Last verringert. Beim Arbeiten fällt das kaum auf, erst wenn man einen Absatz gemeinsam überarbeitet kann es zu Problemen kommen. Mehr dazu in der Gegenüberstellung. 
 
Etherpad, die Software auf der z.B. die frei Nutzbare Installation Titanpad basiert, bietet im Gegensatz dazu synchrone Bearbeitung. Diese Synchronisierung geht in dem Fall aber auf Kosten des Funktionsumfangs. Auch hierauf gehe ich in der Gegenüberstellung im Detail ein. 
 
 

Szenario beschreiben (up)

Diese Ausarbeitung geht von einem relativ einfachen Szenario, basierend auf einer studentischen Gruppenarbeit im Zuge eines Seminares, aus. Im Ausmaß von ca. zehn Seiten soll eine Seminararbeit kollaborativ über ein gewähltes Thema geschrieben werden.  
Die Gruppe besteht aus drei Teilnehmern, die Voraussetzungen wie generelles Verständnis von Büro-Software sind gegeben, allerdings sind ansonsten die Hintergründe sehr unterschiedlich - wie es eben bei einer Seminararbeit durchaus vorkommt. Hier arbeiten interdisziplinär verschiedene Studienrichtungen zusammen - z.B. ein Informatiker mit einer Architektin und einem Bauingenieur. 
Unsere fiktive Gruppenarbeit ist auf einen mittelfristigen Zeitraum ausgelegt, der gemeinsame Arbeitsbereich wird am Anfang des Semesters eingerichtet, und soll vier Monate lang genutzt werden. 
 
Wie auch im Fragebogen ersichtlich, besteht eine Seminararbeit vereinfacht gesagt aus folgenden Schritten: 
Aus diesen Voraussetzungen und Arbeitsschritten heraus, habe ich meinen Fragebogen erstellt (siehe Anhang). Diese vereinfachte Arbeitsanweisung habe ich mit Kollegen und Freunden durchgespielt und sowohl ihre Bewertungen als auch meine Notizen gesammelt. So habe ich 39 Datensätze gebildet, und im Laufe der Arbeit interessante Erkenntnisse über die Vor- und Nachteile der jeweiligen Ansätze gefunden. 
 
 

Kriterien definieren (up)

Um eine Software für den studentischen Alltagsgebrauch tauglich zu machen, muss sie diverse Kriterien erfüllen. Im Laufe der Recherchen und durch Gesprächen mit Kollegen ist die Liste durchaus anschaulich geworden, um die Arbeit trotzdem übersichtlich zu halten habe ich mich auf die zehn für mich aussagekräftigsten Kriterien beschränkt. 
 

Kosten (up)

Studenten haben kaum genug Geld um sich teure Mehrbenutzereditoren, die für Firmen entwickelt wurden, zu leisten. 

Einarbeitungszeit (up)

Um bei einer Seminararbeit den Overhead möglichst gering zu halten und sich auf den Inhalt konzentrieren zu können muss das User-Interface dementsprechend intuitiv angelegt sein. 

Export (up)

Die Abgabe ist im Normalfall der Abschluss jeder guten Arbeit, der erstellte Inhalt muss möglichst problemlos und ohne Umwege zu einem korrekt formatierten und ansehnlichen PDF exportiert werden können. 

Systemvoraussetzungen (up)

Systemvoraussetzungen und Installation sind ein kritischer Faktor. Wenn eine Software ausschließlich für Informatiker gemacht ist, und sich auch nur von Informatikern administrieren lässt, können andere Zielgruppen wie es z.B. bei der interdisziplinären Arbeit notwendig ist, nicht damit arbeiten. 

Funktionsumfang (up)

Hier möchte ich ein Zitat von Yvon Chouinard einbinden: "It's so easy to complicate your life, it's so hard to simplify it." 
Das richtige Maß and Komplexität und Funktionsumfang ist u.U. schwer zu finden, und je nach Zielgruppe unterschiedlich. Ich werde in diesem Punkt auch auf die Vor- und Nachteile von Modularität eingehen. 

Internationalisierung (up)

Studentische Gruppenarbeiten sind im besten Fall mit sehr unterschiedlichen Personen besetzt und heterogen. Ein mehrsprachiges Interface bietet auch Studenten die nicht Deutsch als Muttersprache sprechen die Möglichkeit sich vollständig in die Arbeit zu integrieren. 

Versionierung (up)

Bei Gruppenarbeiten hat man ab und zu das Problem, dass unabsichtlich Inhalte entfernt, überschrieben oder verändert werden. Ein sinnvoll angelegter Mehrbenutzer-Editor sollte die Möglichkeit bieten Änderungen einzelner Benutzer anzuzeigen und wenn nötig rückgängig zu machen. 

Mobil (up)

Egal ob Mobiltelefon, Tablet, Netbook oder Laptop. Arbeit passiert schon lange nicht mehr ausschließlich im Büro, funktionieren die Tools auch auf einem Handy-Bildschirm noch brauchbar? 

Sicherheit (up)

Da in Seminar-, Bacc.-, und Masterarbeiten durchaus sicherheitsrelevantes Know-How bearbeitet werden kann, müssen auch die Sicherheitsfeatures der jeweiligen Softwareprojekte beleuchtet werden. Auch Datenschutz- und Datensicherheit spielen hier eine Rolle, sowie mögliche Backupstrategien. 

Zukunft (up)

Ein Rollout im größeren Stil, egal ob jetzt in einer Uni-LVA oder in einer Firma ist auch immer eine Support-Frage. Auch in Zukunft muss sicher gestellt sein dass Bugfixes und Patches zeitnahe angeboten werden und das Projekt auch weiter entwickelt wird. 
 
 

Evaluation der Möglichkeiten (up)

Die Evaluation im Bereich Usability und User Interface Design habe ich mithilfe eines Fragebogens gelöst. Weiter oben in meiner Ausarbeitung - im Absatz "Szenario beschreiben" - habe ich bereits über die wichtigsten Schritte bei der Erstellung einer Seminararbeit geschrieben. Dieses Szenario habe ich als Basis für die Erstellung meines Fragebogens genutzt.  
Fragebogen
Abbildung 8: Fragebogen
Oben ist der Fragebogen konvertiert ins PNG-Format, sollte das nicht korrekt angezeigt werden habe ich hier das Original PDF hinterlegt: Fragebogen PDF 
 
Diesen Fragebogen habe ich gemeinsam mit Kollegen und Freunden ausgefüllt, um mir ein Bild zu machen welche Software wie bekannt ist und welche Probleme entstehen. Dazu ist zu sagen dass dieser Fragebogen nicht eigenständig verwendet wurde, ich habe zuerst den Kontext erklärt, und dann gemeinsam mit meinen Freunden die Schritte ausgeführt. Deswegen gibt es neben den "Benotungen" im entstandenen Datenblatt auch Notizen über auffällige oder interessante Methoden und Beobachtungen.  
 
Aus dieser Arbeit sind 39 Datensätze entstanden, die ich mit Diagrammen auswerten möchte, und in die Bewertung der jeweiligen Softwareprojekte mit einfließen lasse.  
 
Basisdaten aus denen die Auswertung entstand.
Abbildung 9: Basisdaten aus denen die Auswertung entstand.
 
Als Quelle für die Ausarbeitung benutze ich dieses Spreadsheet, in dem zum einen die von mir erhobenen Basisdaten, aber auch die Diagramme der Auswertung enthalten sind. Der Vollständigkeit halber wird dieses Spreadsheet im ODS-Format auch hier noch einmal verlinkt: daten.ods 
 

Bewertung (up)

Da dieser Part besonders umfangreich ist, habe ich ihn in einer eigenen Seite ausgelagert. 

Fazit (up)

Bewertungen zusammengefasst
Abbildung 10: Bewertungen zusammengefasst
 
{handout} 
 

Extern (up)

 

Literaturangaben (up)

Letzte Änderung: 17.06.2012, 22:25 | 2885 Worte