Advertisement
Guest User

Untitled

a guest
May 26th, 2017
93
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 5.37 KB | None | 0 0
  1. Prototyping und Konzeptentwicklung
  2. „Seminararbeit gemeinsam verfassen“
  3.  
  4. Auswahl der Problemstellung
  5. Das schreiben einer Seminararbeit in einem Team, womöglich über den Globus verstreut, stellt das größte Problem im Bereich der Kommunikation dar.
  6. Wenn die Teammitglieder sich untereinander nicht absprechen, kann es sehr leicht zu groben Problemen bei der Arbeit kommen. Das ganze kann sogar bis zu einem verspäteten Abgabetermin, oder dem Scheitern des Projektes führen.
  7. Die bisherigen Lösungen reichen nicht aus, um die Hindernisse auf einmal zu lösen, geschweige denn überhaupt einen Großteil davon zu beseitigen. Der Verkehr über einen E-Mail Client zum Beispiel bietet Asynchronität, ist allerdings bei einem größeren Projekt sehr schnell unübersichtlich.
  8. Ein IRC-Chat wie zum Beispiel Skype hat den Vorteil, dass direkt kiommuniziert werden kann, wenn denn die Parteien alle gleichzeitig online sind, und der Datenaustausch relativ schnell vonstatten geht, allerdings ist dies nicht immer der Fall und übersichtlich ist es auch nicht.
  9. Internetplattformen wie google Wave bieten da bereits eine bessere, kollaborative Lösung, die jedoch auch nicht frei von Fehlern ist. Die Übersicht ist selbst bei einer Wave nicht gegeben, wenn dabei auch nahezu gleichzeitige Kommunikation möglich ist, so ist es immer noch sehr überladen in seinen Funktionen.
  10. Prototyping sozialer Interaktionsmöglichkeiten
  11. Benötigt wird also ein Programm, dass den Datenaustausch übersichtlich gewährleistet und nebenbei auch laufend Backups erstellt, dass sowohl synchrone, als auch asynchrone Kommunikation ermöglicht und im besten Fall auch so etwas wie eine Tafel gewährleistet, an der gemeinsam gearbeitet werden kann. Unserer Meinung nach ist hier „weniger mehr“, denn je mehr unnütze Funktionen das Produkt im Endeffekt hat, desto unübersichtlicher wird es und desto weniger wird es benutzt werden.
  12. Diese ganzen Möglichkeiten muss das Programm in einem Fenster und einen Blick liefern. Das Aussehen der Buttons und Artefakte muss exakt ihrer jeweiligen Funktion entsprechen und auch einem DAU (dümmster anzunehmender User) sofort federleicht von der Hand gehen. Das bedeutet, die Umgebung muss so gestaltet sein, dass sie im besten Falle wiedererkannt wird, weil sie ähnlich funktioniert, wie bereits existierende Systeme. Wir dachten in diesem Fall an ein Browserfenster, welches seitlich und oben alle Informationen und Möglichkeiten auf einen Blick darstellt.
  13. Die jeweilige Funktion hat einen eigenen Raster und wird in der Mitte des Bildschirmes ausgeführt, die Umgebung ändert sich dabei kaum (bis auf die Buttons). Nebenbei hat der User die Möglichkeit am linken Rand in einem IRC Channel in Echtzeit mit möglichen anderen Benutzern in Kontakt zu treten um Fragen zu stellen, auf die eine umgehende Antwort erwartet wird.
  14. Im rechten Bereich des Fensters soll der Dateiupload stattfinden, welcher die letzten aktualiserten Dateien auf einen Blick darstellt (vergleich google Wave) und auf einen Klick auf den Server zugreift, wo alle anderen und die Backups der letzten Zeit aufscheinen. Um dem Benutzer die Möglichkeit zu nehmen, die Arbeit zu vernichten, können die Backups ausnahmslos wiederhegestellt und nicht gelöscht werden, außerdem haben sie nicht die Mächtigkeit neuere Versionen zu überschreiben. Anstatt Daten zu löschen, müssen sie, wenn sie unerwünscht sind, verschoben werden. Erst nach Ablauf des Projektes gibt es die Möglichkeit das Projekt vollständig zu löschen.
  15. Standardfunktionen, wie eine Benachrichtigung per E-Mail oider SMS, müssen genauso gegeben sein, wie erweiterte Funktionen, zum Beispiel Textverarbeitung, grafische Darstellung und so weiter.
  16. Dokumentation mittels Storyboard
  17. Da wir beide keine begnadetetn Zeichner sind, wird das Storyboard erst in der Übung erstellt werden.
  18.  
  19.  
  20.  
  21. Beschreibung des Projekts
  22. Name
  23. Alinon (Abgkz. für: All in one)
  24. Ziel/Lösung
  25. Das Ziel dieses eigenständigen Online Programmes ist es, die Möglichkeit zu bieten, auf einen Blick alle notwendigen Funktionen, bei einfachster Bedienbarkeit zu erreichen.
  26. Die Lösung ist wie in Kapitel 2 beschrieben, das einem Browserfenster ähnliche Design und die damit verbunde Usability.
  27. Zielgruppe und Anwendungskontext
  28. Die Zielgruppe soll in diesem Fall idealerweise irrelevant sein, da die Benutzung so einfach gestaltet sein soll, dass sowohl jung, als auch alt sich gleichermaßen einfach mit der Handhabung tun. Der Anwedungskontext sollte prinzipiell auf das Schreiben einer Seminararbeit reduziert sein, kann aber durchaus auch bei kleineren Arbeiten von großem Nutzen sein.
  29. Begründung zentraler Designentscheidungen
  30. Einfachheit besticht und funktioniert einfach besser. Je komplizierter das Design, desto schwerer ist es zu erlernen/benutzen (siehe zB 3D-Studio Max). Alles in einem Fenster zu haben hilft einem den Überblick zu behalten. Chat und Dateiupload ebenfalls am Rande zu halten verhindert ebenfalls, dass man sich in seiner Arbeit verliert, man muss nicht dauernd zwischen Fenstern hin und her wechseln.
  31. Festlegung der Evaluationskriterien
  32. Das wichtigste Kriterium einer Software ist, dass diese auch benutzt wird, vor allem wenn sie online zur Verfügung gestellt wird. Des weiteren wäre es notwendig ein zuständiges Forum für Lob, Kritk, Anregungen und Wünsche einzurichten, in welchem die Testbenutzer ihre Meinungen der Öffentlichkeit und vor allem den Entwicklern Preis geben können.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement