Pflichtenheft - Home

Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek Pflichtenheft MULTImediathek Version 3.0 Version 1.0 2.0 3.0 Autor Dennis Weinmann Felix Fischer Marcus Gerlach Datum 28.04.2008 Status abgenommen Kommentar Ersterstellung Dennis Weinmann Felix Fischer Marcus Gerlach 14.05.2008 OOA‐Modelle hinzugefügt Funktionen aktualisiert Dennis Weinmann Felix Fischer Marcus Gerlach 17.06.2008 HCI Kriterien hinzugefügt FF’n’F TFH Berlin E‐Mail: dennis.weinmann@gmx.de fischer.felix@googlemail.com gerlach.marcus@googlemail.com 07.07.2008
1
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek Inhaltsverzeichnis 1. Grobe Projektbeschreibung 2. Zielbestimmung 2.1. Musskriterien 3 3 3 4 4 2.2. Wunschkriterien 2.3. Abgrenzungskriterien 3. Produkteinsatz 3.1. Anwendungsbereiche 4 4 4 4 3.2. Zielgruppen 3.3. Betriebsbedingungen 4. Produktübersicht 5 Produktfunktionen 5.1. Mussfunktionen 5.2. Wunschfunktionen 6 6 12 15 15 15 15 15 5. 6. Daten 6.1 Benutzerdaten 6.2 Projektdaten 6.3 Dateidaten 6.4 Verbindungsdaten 7. Produktleistungen 16 8. Qualitätsanforderungen 17 9. Benutzungsoberfläche 18 10. Nichtfunktionale Anforderungen 19 11. Technische Produktumgebung 11.1. Software: ggf. für Server und Client 19 19 19 11.2. Hardware: ggf. für Server und Client 12. Gliederung in Teilprodukt 19 13. Ergänzung 20 14. OOA—Modelle 21 21 22 23 26 27 32 36 14.1. Paketdiagramm 14.2. Klassendiagramm 14.3. Attributklassifizierung 14.4. Use‐Case Diagramm 14.5. Aktivitätsdiagramme 14.6. Sequenzdiagramme 14.7. Zustandsautomaten 15. Human Computer Interaction Kriterien 15.1 Auswahl der Bedienelemente 15.2 GUI‐Entwurfprinzipien 15.3 WIMP‐Kriterien 15.4 Barrierefreiheit 07.07.2008
37 42 43 47 2
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 1. Grobe Projektbeschreibung Für unser Projekt zur Lehrveranstaltung Multimedia Engineering II im Sommersemester 2008 planen wir die Entwicklung eines Webportals, das verschiedensten Menschen die Möglichkeit eröffnet, gemeinsame Projektarbeiten effizient und unkompliziert zu bewerkstelligen. Einer der Schwerpunkte unserer Anwendung ist eine möglichst intuitive und einfache Steuerung. Somit benötigt der Benutzer nur noch einen geringen Zeitanteil seiner Arbeitszeit, um sich mit seinen Teammit‐
gliedern zu koordinieren oder seine Arbeitsfortschritte zu präsentieren. Im Mittelpunkt des Programms steht eine Mediathek zur Präsentation von Projekten. Hier können sich Benutzer anmelden und Projekte erstellen. Zu diesen Projekten können Sie Teammitglieder einladen, Ent‐
wicklungsfortschritte veröffentlichen und über den Stand der Dinge informieren. Die Benutzer können Dateien und Bilder begleitend zu Ihrem Beitrag hochladen, sowie den Status über ihr Produkt mittels Pro‐
zentangaben übersichtlich darstellen. Genauere Beschreibungen der Funktionen folgen in den nächsten Abschnitten. Im Allgemeinen ist das Ziel der Anwendung, die Projektdarstellung nach außen, sowie umfangreiche Projektmanagement‐Funktionen zur strukturierten Dokumentation der Projektentwicklung. 2. Zielbestimmung 2.1. Musskriterien − Möglichkeit um sich als neuer Benutzer zu registrieren und ein Benutzerprofil anzulegen (/F010/) − Möglichkeit sich einzuloggen (/F20/) − Persönliche Daten ändern (/F40/) − Suche nach Projekten (Titel, Beschreibung) (/F50/) − Ansehen von Projekten (/F60/) − Anlegen neuer Projekte (/F70/) − Projektberechtigung als „privat“, „registrierter“ und „öffentlich“ kennzeichnen: (/F70) • privat: Mitglieder des Projektes können das Projekt sehen und downloaden. • registrierter: nur am Portal angemeldete Benutzer können das Projekt sehen und downloaden. • öffentlich: jeder kann das Projekt sowohl sehen als auch downloaden. − Zuordnen von Projektmitgliedern (/F80/, /F90/) − Projekte verwalten (/F100/, /F110/) − Devlog ‐ Zum Verfolgen der Projektfortschritte mit Hilfe von Entwicklertagebucheinträge und Datenan‐
hänge (/F131/ /F132/ /F133/) − Möglichkeit Statusanzeigen zu erstellen und Angabe wie viel Prozent des Projektes schon fertiggestellt wurden (/F121/, /F122/, /F123/) − Hochladen von Dateien (/F150/) 07.07.2008
3
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 2.2. Wunschkriterien −
Projektweite To‐Do's anlegen und verwalten (/F181/ /F182/ /F183/) −
Anlegen und verwalten von „Meilensteinen” (/F191/ /F192/ /F193/) −
RSS‐Feed neuester Projekte (/F200/) 2.3. Abgrenzungskriterien − Es soll kein reines Projektmanagement‐Tool sein, obwohl gewisse PM‐Teile schon enthalten sein wer‐
den. − Die Anwendung wird auch keine “social‐network” Web‐Anwendung über die man Leute kennenlernen kann um sich dann ein Team zusammenzustellen. Es wird davon ausgegangen, dass sich die Leute schon kennen und beim Erstellen des Projektes gleich involviert sind. 3. Produkteinsatz 3.1. Anwendungsbereiche − Projektpräsentation im Internet / in der Firma. − Dokumentation von Projekten in Form eines Devlogs 3.2. Zielgruppen − Studenten, die während des Semesters oder privat Projekte erstellen. − Community von Programmierern, Designern − Innerhalb von Firmen, wenn dort präsentationswürdige Projekte erstellt werden. 3.3. Betriebsbedingungen: physikalische Umgebung, Betriebszeit, Überwachung − Root‐Server im Internet oder lokaler Server im Firmennetz. − Java‐Server sollte ständig (24/7) erreichbar sein. − Überwachung erfolgt durch den Administrator des Servers. 07.07.2008
4
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 4. Produktübersicht 07.07.2008
5
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 5. Produktinformationen 5.1 Mussfunktionen /F10/ Anwendungsfall: Benutzer beim Portal registrieren Akteure: Besucher Kategorie: primär Vorbedingung: Benutzer ist nicht registriert Nachbedingung: Benutzer ist registriert und hat Profil angelegt. Nachbedingung Fehlschlag: Registrierung nicht erfolgreich. Beschreibung: 1 Registrierungsformular aufrufen, ausfüllen und absenden 2 Anweisungen in der erhaltenen Aktivierungsmail durchführen Erweiterung: 1a Profildaten eingeben 2a Aktivierungslink in der Aktivierungsmail aufrufen um Account zu aktivieren. Alternativen: ‐ 07.07.2008
6
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 5. Produktinformationen /F20/ Anwendungsfall: Benutzer am Portal anmelden Akteure: Projektleiter, Teammitglied, Besucher Kategorie: primär Vorbedingung: Benutzer ist nicht angemeldet, aber registriert Nachbedingung: Benutzer ist am Portal angemeldet. Nachbedingung Fehlschlag: Anmeldung nicht erfolgreich, erneut versuchen. Beschreibung: 1 Login‐Formular ausfüllen und absenden Erweiterung: ‐ Alternativen: ‐ /F30/ Anwendungsfall: Persönliche Daten ändern Akteure: Projektleiter, Teammitglied, Besucher Kategorie: primär Vorbedingung: Benutzer ist angemeldet Nachbedingung: Persönliche Daten geändert Nachbedingung Fehlschlag: ‐ Beschreibung: 1 eigenes Profil aufrufen 2 Daten ändern und bestätigen Erweiterung: ‐ Alternativen: ‐ /F40/ Anwendungsfall: Profilseite eines Benutzers anschauen Akteure: Projektleiter, Teammitglied, Besucher Kategorie: primär Vorbedingung: Benutzer ist angemeldet Nachbedingung: Profilseite wird angezeigt Nachbedingung Fehlschlag: Benutzer nicht gefunden Beschreibung: 1 Benutzer suchen 2 Benutzerprofil aufrufen Erweiterung: ‐ Alternativen: ‐ /F50/ Anwendungsfall: Projekt suchen Akteure: Besucher, Projektleiter, Teammitglied, Besucher Kategorie: primär Vorbedingung: ‐ Nachbedingung: Gewünschte Projekt wurde gefunden Nachbedingung Fehlschlag: Gewünschtes Projekt nicht gefunden Beschreibung: 1 Suchseite aufrufen 2 Suchanfrage durchführen Erweiterung: ‐ Alternativen: ‐ 07.07.2008
7
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek /F60/ Anwendungsfall: Projekt einsehen´ Akteure: Besucher, Projektleiter, Teammitglied, Besucher Kategorie: primär Vorbedingung: ‐ Nachbedingung: Projektseite wird angezeigt Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projekt suchen (/F50/) 2 Projektseite aufrufen Erweiterung: ‐ Alternativen: ‐ /F70/ Anwendungsfall: Projekt anlegen Akteure: Projektleiter, Teammitglied, Besucher Kategorie: primär Vorbedingung: Benutzer ist registriert und angemeldet Nachbedingung: Benutzer hat Projekt angelegt Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Profilseite aufrufen 2 Projekt erstellen Erweiterung: 2a Formular ausfüllen und Projektdaten angeben, u.U. Projekt hochladen Alternativen: ‐ /F80/ Anwendungsfall: Projektmitglied hinzufügen Akteure: Projektleiter Kategorie: primär Vorbedingung: Benutzer ist bereits registriert, Nachbedingung: Benutzer ist dem Projekt zugeordnet Nachbedingung Fehlschlag: Benutzer ist dem Projekt nicht zugeordnet Beschreibung: 1 Projektseite aufrufen 2 Benutzer dem Projekt zuordnen Erweiterung: 2a Benutzer muss zustimmen Alternativen: ‐ /F90/ Anwendungsfall: Mitglied entfernen Akteure: Projektleiter Kategorie: primär Vorbedingung: Benutzer ist angemeldet und Ersteller/Leiter des Projektes Nachbedingung: Mitglied wurde entfernt Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projektseite aufrufen 2 Mitglieder‐Seite aufrufen 3 Gewünschtes Mitglied entfernen Erweiterung: ‐ Alternativen: ‐ 07.07.2008
8
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek /F100/ Anwendungsfall: Projektdaten ändern Akteure: Projektleiter Kategorie: primär Vorbedingung: Benutzer ist angemeldet und Ersteller/Leiter des Projektes Nachbedingung: Projektdaten wurden aktualisiert Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Profilseite mit allen Projekten aufrufen 2 Projekt auswählen 3 Projektdaten ändern und speichern Erweiterung: ‐ Alternativen: ‐ /F110/ Anwendungsfall: Projekt löschen Akteure: Projektleiter Kategorie: primär Vorbedingung: Benutzer ist angemeldet und Ersteller des Projektes Nachbedingung: Projekt ist gelöscht Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Profilseite mit allen Projekten aufrufen 2 Projekt auswählen 3 Projekt löschen Erweiterung: ‐ Alternativen: ‐ /F131/ Anwendungsfall: Devlog Eintrag erstellen Akteure: Projektleiter, Teammitglied Kategorie: primär Vorbedingung: Benutzer ist angemeldet und Mitarbeiter an dem Projekt Nachbedingung: Devlog Eintrag erstellt Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projektseite aufrufen 2 Devlog aufrufen 3 Devlog Eintrag erstellen und speichern Erweiterung: ‐ Alternativen: ‐ 07.07.2008
9
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek /F132/ Anwendungsfall: Devlog Eintrag ändern Akteure: Projektleiter, Teammitglied Kategorie: primär Vorbedingung: Benutzer ist angemeldet, Mitglied an dem Projekt und Ersteller des Devlog‐Eintrags oder Projektleiter Nachbedingung: Devlog Eintrag geändert Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projektseite aufrufen 2 Devlog aufrufen 3 Devlog Eintrag öndern Erweiterung: 3a Eingabemaske ausfüllen und speichern Alternativen: ‐ /F133/ Anwendungsfall: Devlog Eintrag löschen Akteure: Projektleiter, Teammitglied Kategorie: primär Vorbedingung: Benutzer ist angemeldet, Mitglied an dem Projekt und Ersteller des Devlog Eintrags oder Projektleiter Nachbedingung: Devlog Eintrag gelöscht Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projektseite aufrufen 2 Devlog aufrufen 3 Devlog Eintrag löschen Erweiterung: 3a Eingabemaske ausfüllen und speichern Alternativen: ‐ /F140/ Anwendungsfall: Devlog einsehen Akteure: Besucher, Projektleiter, Teammitglied, Benutzer Kategorie: primär Vorbedingung: ‐ Nachbedingung: Devlog wird eingesehen Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projekt suchen 2 Projekteseite anzeigen 3 Devlog aufrufen Erweiterung: 3a wenn Devlog verfügbar ist und die Berechtigung dazu vorhanden ist. Alternativen: ‐ 07.07.2008
10
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek /F150/ Anwendungsfall: Dateien hochladen Akteure: Projektleiter, Teammitglied Kategorie: primär Vorbedingung: Benutzer ist angemeldet und Mitglied an dem Projekt Nachbedingung: Datei(en) hochgeladen Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projektseite aufrufen 2 Datei hochladen Erweiterung: 2a evtl. noch weitere Dateien hochladen 2b Datei(en) einem Devlog zuordnen Alternativen: ‐ /F160/ Anwendungsfall: Datei(en) Downloaden Akteure: Besucher, Projektleiter, Teammitglied, Benutzer Kategorie: primär Vorbedingung: Datei zum Download vorhanden Nachbedingung: ‐ Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Datei aus Devlog downloaden Erweiterung: ‐ Alternativen: ‐ 07.07.2008
11
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 5.2 Wunschfunktionen /F121/ Anwendungsfall: Status erstellen Akteure: Projektleiter Kategorie: primär Vorbedingung: Benutzer ist angemeldet und Mitglied an dem Projekt Nachbedingung: Status erstellt Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projektseite aufrufen 2 Status‐Seite aufrufen 3 Status hinzufügen Erweiterung: 3a Eingabemaske ausfüllen und speichern Alternativen: ‐ /F122/ Anwendungsfall: Status ändern Akteure: Projektleiter Kategorie: primär Vorbedingung: Benutzer ist angemeldet, Mitglied an dem Projekt oder Projektleiter Nachbedingung: Status geändert Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projektseite aufrufen 2 Status‐Seite aufrufen 3 Status ändern Erweiterung: 3a Eingabemaske ausfüllen und speichern Alternativen: ‐ /F123/ Anwendungsfall: Status löschen Akteure: Projektleiter Kategorie: primär Vorbedingung: Benutzer ist angemeldet, Mitglied an dem Projekt oder Projektleiter Nachbedingung: Meilensteingelöscht Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projektseite aufrufen 2 Status‐Seite aufrufen 3 Status löschen Erweiterung: ‐ Alternativen: ‐ 07.07.2008
12
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek /F181/ Anwendungsfall: ToDo erstellen Akteure: Projektleiter, Teammitglieder Kategorie: primär Vorbedingung: Benutzer ist angemeldet und Mitglied an dem Projekt Nachbedingung: ToDo erstellt Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projektseite aufrufen 2 ToDo‐Seite aufrufen 3 ToDo hinzufügen Erweiterung: 3a Eingabemaske ausfüllen und speichern Alternativen: ‐ /F182/ Anwendungsfall: ToDo ändern Akteure: Projektleiter, Teammitglieder Kategorie: primär Vorbedingung: Benutzer ist angemeldet, Mitglied an dem Projekt und Ersteller des ToDos oder Projektlei‐
ter Nachbedingung: ToDo geändert Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projektseite aufrufen 2 ToDo‐Seite aufrufen 3 ToDo auswählen und ändern Erweiterung: 3a Eingabemaske ausfüllen und speichern Alternativen: ‐ /F183/ Anwendungsfall: ToDo löschen Akteure: Projektleiter, Teammitglieder Kategorie: primär Vorbedingung: Benutzer ist angemeldet, Mitglied an dem Projekt und Ersteller des ToDos oder Projektlei‐
ter Nachbedingung: ToDo gelöscht Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projektseite aufrufen 2 ToDo‐Seite aufrufen 3 ToDo auswählen und löschen Erweiterung: ‐ Alternativen: ‐ 07.07.2008
13
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek /F191/ Anwendungsfall: Meilenstein erstellen Akteure: Projektleiter, Teammitglieder Kategorie: primär Vorbedingung: Benutzer ist angemeldet und Mitglied an dem Projekt Nachbedingung: Meilenstein erstellt Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projektseite aufrufen 2 Meilenstein‐Seite aufrufen 3 Meilenstein hinzufügen Erweiterung: 3a Eingabemaske ausfüllen und speichern Alternativen: ‐ /F192/ Anwendungsfall: Meilenstein ändern Akteure: Projektleiter, Teammitglieder Kategorie: primär Vorbedingung: Benutzer ist angemeldet, Mitglied an dem Projekt und Ersteller des Meilensteins oder Pro‐
jektleiter Nachbedingung: Meilenstein geändert Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projektseite aufrufen 2 Meilenstein‐Seite aufrufen 3 Meilenstein ändern Erweiterung: 3a Eingabemaske ausfüllen und speichern Alternativen: ‐ /F193/ Anwendungsfall: Meilenstein löschen Akteure: Projektleiter, Teammitglieder Kategorie: primär Vorbedingung: Benutzer ist angemeldet, Mitglied an dem Projekt und Ersteller des Meilensteins oder Pro‐
jektleiter Nachbedingung: Meilensteingelöscht Nachbedingung Fehlschlag: ‐ Beschreibung: 1 Projektseite aufrufen 2 Meilenstein‐Seite aufrufen 3 Meilensteine bearbeiten (hinzufügen, ändern, löschen) Erweiterung: ‐ Alternativen: ‐ 07.07.2008
14
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 6. Daten 6.1 Benutzerdaten /D10/ Benutzerdaten (max. 1.000) Benutzer_ID,Benutzername, Passwort, Name, E‐Mail‐Adresse, Geschlecht, URL Profilbild, ICQ, MSN, Ya‐
hoo, Homepage, Geburtsdatum, Erstelldatum 6.2 Projektdaten /D20/ Projekte (max. 2.000) Projekt_ID, Projektname, Beschreibung, Berechtigung, Erstelldatum, Fertigstellung, URL Projektlogo, Ver‐
sionsnummer, Projektleiter /D30/ Devlog_Einträge (max. 40.000) Devlog_Eintrag_ID, Projekt_ID, Erstelldatum, Titel, Inhalt, Verfasser(Benutzer_ID) /D40/ Meilensteine (max. 20.000) MeilensteinID, Projekt_ID, Titel, Beschreibung, ZielTermin, Verfasser(Benutzer_ID) /D50/ To‐DO (max. 40.000) ToDo_ID, Projekt_ID, Titel, Beschreibung, Verfasser(Benutzer_ID), ErledigtDatum /D60/ Status (max. 20.000) Status_ID, Projekt_ID, Name, Prozentwert 6.3 Dateidaten /D80/ Daten_Projekt (max. 20.000) Daten_ID, DatenURL, Datentyp, Uploaddatum, Verfasser(Benutzer_ID), Projekt_ID /D90/ Daten_Devlog (max. 250.000) Daten_ID, DatenURL, Datentyp, Uploaddatum, Verfasser(Benutzer_ID), Projekt_ID 6.4 Verbindungsdaten /D120/ Mitglieder (max. 1.000.000) Benutzer_ID, Projekt_ID 07.07.2008
15
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 7. Produktleistungen Da die Anwendung später via Internet erreichbar sein soll, wird da eine Standardantwortzeit von <5 Se‐
kunden angestrebt. Dies ist natürlich auch von der Internetgeschwindigkeit des Clients abhängig. Zu lange Wartezeiten könnten den Benutzer verärgern oder verunsichern. 07.07.2008
16
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 8. Qualitätsanforderungen Produktfunktionalität Funktionalität sehr gut gut normal nicht relevant X Angemessenheit X Richtigkeit X Interoperabilität X Ordnungsmäßigkeit X Sicherheit X Zuverlässigkeit Reife X Fehlertoleranz X Wiederherstellbarkeit X Benutzbarkeit Verständlichkeit X Erlernbarkeit X Bedienbarkeit X Effizienz X Zeitverhalten Verbrauchsverhalten X Änderbarkeit Analysierbarkeit X Modifizierbarkeit X Stabilität Prüfbarkeit Übertragbarkeit Anpassbarkeit* Installierbarkeit* X X X X * Entfällt, da es sich um eine Webanwendung handelt. Die entsprechende Bewertung trifft für die evtl. erstellte AIR‐Anwendung (Wunschkriterium) zu. 07.07.2008
17
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 9. Benutzeroberfläche 9.1 Standards und Rollen /B10/ Standardmäßig ist das Regelwerk von Web‐Anwendungen zu beachten. /B20/ Die Bedienungsoberflächen sind auf Mausbedienung ausgelegt. /BX0/ Folgende Rollen sind zu unterscheiden: Rolle unbekannter Benutzer registrierter Benutzer Projektmitarbeiter Projektersteller/‐leiter Rechte /F10/, /F40, /F60/, /F200/, /F210/ /F20/, /F30/, /F40, /F60/, /F70/, /F140/, /F160/, /F200/ *, /F121/, /F122/, /F123/, /F131/, /F132/, /F133/, /F150/, /F121/, /F122/, /F123/, /F191/, /F192/, /F193/ **, /F80/, /F90/, /F100/, /F110/ * Hat die gleichen Zugriffsrechte und Interaktionsmöglichkeiten wie ein registrierter Benutzer. ** Hat die gleichen Zugriffsrechte und Interaktionsmöglichkeiten wie ein Projektmitarbeiter. 9.2 Skizzen Profilseite der User Projektansicht Startseite 07.07.2008
18
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 10. Nichtfunktionale Anforderungen Beim Registriervorgang wird das Passwort doppelt abgefragt, um dessen Richtigkeit sicherzustellen. 11. Technische Produktumgebung Das Produkt ist Internetfähig, da es sich primär um eine Webanwendung handelt. Eine evtl. später erstell‐
te AIR‐Applikation ist Client/Server‐fähig. 11.1. Software: ggf. für Server und Client Server: − HTTP‐/FTP‐Server um die Anwendung hochzuladen und bereitzustellen − Java‐Server für die Kommunikation mit dem Datenbankserver (MySQL) Client: − Browser incl. aktuellem Flash‐Player (AS3‐fähig also mind. 9.x) 11.2. Hardware: ggf. für Server und Client Server: − Möglichkeit zum Hochladen der Flex‐Anwendung UND der Projekte (ausreichend Speicherplatz) − Server sollte ständig online sein um eine ausreichende Verfügbarkeit zu gewährleisten − Genügend Bandbreite für die Up‐/Downloads Client: − Browserfähiges Gerät mit Grafikbildschirm − Ausreichend RAM und CPU um die Web‐Anwendung ausführen zu können 12. Gliederung in Teilprodukte Es sind drei Teilprodukte geplant, wobei die erste Version die “vertikale Implementierung” eines Funkti‐
onsstrangs umfasst, wie sie bei dem Fach Softwareengineering II gefordert ist. Die zweite Version enthält dann alle Funktionen, die in den Musskriterien stehen. Die Dritte Version implementiert dann zusätzlich alle Funktionen, die in den Wunschkriterien aufgeführt sind. MULTImediathek V1.0 (Funktionsstrang „Benutzerprofil ändern“) /F10/Benutzer beim Portal registrieren /F20/ Benutzer beim Portal anmelden /F30/ Persönliche Daten ändern /F40/ Profilseite eines Benutzers anschauen 07.07.2008
19
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek MULTImediathek V2.0 (Musskriterien) /F50/ Projekt suchen /F60/ Projekt einsehen /F70/ Projekt anlegen /F80/ Projektmitglied hinzufügen /F90/ Mitglied entfernen /F100/Projektdaten ändern /F110/Projekt löschen /F121/Status erstellen /F122/Status ändern /F123/Status löschen /F131/Devlog Eintrag erstellen /F132/Devlog Eintrag ändern /F133/Devlog Eintrag löschen /F140/Devlog einsehen /F150/Dateien hochladen /F160/Dateien Downloaden MULTImediathek V3.0 (Muss‐ und Wunschkriterien) /F181/ToDo erstellen /F182/ToDo ändern /F183/ToDo löschen /F191/Meilenstein erstellen /F192/Meilenstein ändern /F193/Meilenstein löschen 13. Ergänzung 13.1 Verwendete Techniken Bei der Anwendung handelt es sich um eine Webanwendung, die mittels Flex/ActionScript entwickelt wird. Des weiteren wird ein Java‐Server mit Servlets eingesetzt um die Daten der User und Projekte in der Da‐
tenbank zu speichern und abrufen zu können. Als Datenbankserver wird das freie MySQL eingesetzt. 07.07.2008
20
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 14. OOA‐Modelle 14.1. Paketdiagramm Es handelt sich um ein kleines Projekt, wodurch die feinere Auflösung des Mediatheksystems in Unterpa‐
keten nicht notwendig ist. 07.07.2008
21
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 14.2. Klassendiagramm Autor: Marcus Gerlach, Felix Fischer, Dennis Weinmann Das Klassendiagramm wurde zusammen entwickelt und in mehreren Stufen verfeinert und überarbeitet. 07.07.2008
22
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 14.3. Attributklassifizierung Klasse: Projekt Berechtigung Typ: ProjektBerechtigung ‐‐> legt fest für welche Nutzer das Projekt sichtbar ist Beschreibung Typ: String ‐‐> Text der die Projektbeschreibung des Projekts Dateien Typ: Collection<Datei> ‐‐> Beinhaltet alle dem Projektrelease beigefügten Da‐
teien Devlogeintrage Typ: Collection<Devlogeintrag> ‐‐> Liste aller zum Projekt zugehörigen Devlogeinträge ‐‐> Datum, wann das Projekt im System erstellt worden erstellDatum Typ: Date ist fertigstellung Typ: Date ‐‐> Datum, an dem das Projekt fertiggestellt worden ist (nur wenn das Projekt final ist) Sonst könnte man angeben, wann das Projekt voraussichtlich fertig sein soll Id Typ: int ‐‐> Nummer, um das Projekt zu identifizieren Typ: Collection<Kommentar> ‐‐> Liste aller zum Projekt zugehörigen Kommentare Kommentare meilensteine Typ: Collection<Meilenstein> ‐‐> Liste aller zum Projekt zugehörigen Meilensteine mitglieder Typ: Collection<Benutzer> ‐‐> Liste aller Mitglieder für das jeweilige Projekt projektleiter Typ: Benutzer ‐‐> Referenz auf den Benutzer, der im Projekt, der Pro‐
jektleiter und Ersteller ist ‐‐> Referenz auf das Bild, welches als Projektlogo ge
projektlogo Typ: Bild nutzt werden soll projektname Typ: String ‐‐> Name des Projekts Status Typ: Collection<Status> ‐‐> Liste aller angelegten Status todo Typ: Collection<ToDo> ‐‐> Liste aller angelegten ToDo version Typ: float ‐‐> Die vom Projektleiter angeben Versionsnummer des Projekts (zb: Version 0.8) Klasse: Benutzer Typ: String ‐‐> Benutzername, der zum einloggen benötigt wird Benutzername email Typ: String ‐‐> hinterlegte emailadresse des Benutzers erstellDatum Typ: Date ‐‐> Datum der Erstellung des Benutzers geburtsDatum Typ: Date ‐‐> angegebenes Geburtstdatum des Benutzers geschlecht Typ: Boolean ‐‐> Geschlechtsangabe, true = männlich homepageURL Typ: String ‐‐> URL zur Homepage des Users, wenn vorhanden Typ: int ‐‐> icq‐nummer icq id Typ: int ‐‐> Nummer zur Identifizierung des Benutzers msn Typ: String ‐‐> mailadresse die für die Kommunikation bei msn hin‐
terlegt wurde name Typ: String ‐‐> Name des Benutzers passwort Typ: String ‐‐> passwort des Benutzers, das zum einloggen ge braucht wird profilbild Typ: Bild ‐‐> Referenz auf das Bild, welches als Profilbild verwen‐
det wird yahoo Typ: String ‐‐> yahoo messenger name des Benutzers 07.07.2008
23
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek Klasse: Devlogeintrag Anhang Typ: Datei ‐‐> Die Datei, die als Anhang dem Devlog beiliegt erstellDatum Typ: Date ‐‐> Datum, wann dieser Eintrag erstellt wurde id Typ: int ‐‐> Nummer zum Identifizieren der Devlogeinträge inhalt Typ: String ‐‐> Text des Eintrages titel Typ: String ‐‐> Titel des Eintrages verfasser Typ: Benutzer ‐‐> Referenz auf dem Benutzer, der den Eintrag verfasst hat Klasse: Meilenstein beschreibung Typ: String ‐‐> Beschreibung des jeweiligen Meilensteins. was muss ge‐
macht werden. erreichtStatus Typ: Boolean ‐‐> zeigt ob der Meilenstein bereits erreicht wurde oder nicht id Typ: int ‐‐> Nummer zum Identifizieren der Meilensteine titel Typ: String ‐‐> Titel des Meilensteins verfasser Typ: Benutzer ‐‐> Referenz auf den Benutzer, der den Meilenstein erstellt hat zielTermin Typ: Date ‐‐> Termin bis wann der Meilenstein erledigt sein muss. Klasse: ToDo beschreibung Typ: String ‐‐> Beschreibung des ToDo, Was muss gemacht werden... erledigtDatum Typ: Date ‐‐> Datum, wann ein ToDo als erledigt markiert worden ist Typ: boolean ‐‐> Markeirung ob der ToDO schon erledigt wurde oder nicht erreichtStatus id Typ: int ‐‐> Nummer zur Identifizierung des ToDo titel Typ: String ‐‐> Titel des ToDo Klasse: Status id Typ: int ‐‐> Nummer zur Identifizierung des Status name Typ: String ‐‐> Name vom Status prozentwert Typ: float ‐‐> Prozentwert der den Fortschritt repräsentiert Klasse: Kommentar erstellDatum Typ: Date ‐‐> Datum, wann der Kommentar geschrieben wurde id Typ: int ‐‐> Nummer zur Identifizierung des Kommentars inhalt Typ: String ‐‐> Text des Kommentars, also der Kommentar selbst verfasser Typ: Benutzer ‐‐> Referenz auf den Benutzer, der den Kommentar verfasst hat Klasse: MULTImediathek Benutzer Typ: Collection<Benutzer> ‐‐> beinhaltet alle angelegten Benutzer Projekte Typ: Collection<Projekt> ‐‐> beinhaltet alle angelegten Projekte Datatype: Bild id Typ: int ‐‐> Nummer zur eindeutigen Identifizierung es Bildes format Typ: String ‐‐> Gibt das Dateiformat an, wie z.b.: PNG, JPEG, BMP ‐‐> Größe des Bildes in kByte groesse Typ: float url Typ: String ‐‐> URL zum Bild 07.07.2008
24
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek Datatype: Datei datentyp Typ: String id : Typ int uploadDatum Typ: Date url Typ: String verfasser Typ: Benutzer zugehoerigkeit Typ: Projekt Enumeration: ProjektBerechtigung oeffentlich registrierte privat 07.07.2008
‐‐> Datentyp der Datei, wie z.b.: zip, exe, jar ‐‐> Nummer zum Identifizieren der Datei ‐‐> Datum, wann die Datei hochgeladen wurde ‐‐> URL zu der Datei ‐‐> Referenz zum Benutzer, der diese Datei hochgeladen hat ‐‐> Referenz auf das Projekt, zudem die Datei gehört ‐‐> jeder Besucher der Seite kann sich das Projekt ansehen ‐‐> nur registriere Benutzer können sich da Projekt ansehen ‐‐> nur Mitglieder des Projekts können dieses sehen und Be‐
nutzer, die in der Liste zusatzberechtige stehen 25
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 14.4. Use‐Case Diagramm 07.07.2008
26
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 14.5. Aktivitätsdiagramme 07.07.2008
27
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek Aktivitätsdiagramme 07.07.2008
28
Felix Fischer (s741064) 07.07.2008
Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 29
Felix Fischer (s741064) 07.07.2008
Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 30
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek Aktivitätsdiagramme 07.07.2008
31
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 14.6 Sequenzdiagramme 07.07.2008
32
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek Sequenzdiagramme 07.07.2008
33
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek Sequenzdiagramme 07.07.2008
34
Felix Fischer (s741064) 07.07.2008
Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 35
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 14.7 Zustandsautomaten 07.07.2008
36
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 15.1 Auswahl der Bedienelemente Texteingabefeld Dieses Element dient zur Eingabe von Texten durch den Benutzer. Jedem Element ist eine Beschriftung zugeordnet, so dass der Benutzer zu jedem Zeitpunkt weiß, was in das entsprechende Feld einzugeben ist. Das Element wurde je nach Umgebung in seiner Größe verändert, um zusätzlich die Erkennung des einzutragenden Textinhalts zu verdeutlichen. Deswegen ist das Element, das sich auf der Startseite befindet, indem der Benutzer seinen Benutzernamen eintragen soll deutlich kleiner, als das Element, indem der Benutzer eine Beschreibung oder ähnliches verfassen kann. Alternativen für diese Komponente würden die einfache und gewohnte Bedienbarkeit komplizie‐
ren und den Benutzer eventuell verunsichern, da es sich hier um eine oft benutzte und somit sehr bekannte Komponente handelt. Texteingabefeld für Benutzernamen und Passwort Texteingabefeld für einen Beschreibungstext
Die Unterschiedlichen Farben kommen durch die unterschiedlichen Verwendungen der einzelnen hier gezeigten Elemente zu Stande. Das Beschreibungsfeld Rechts ist in einem Popup und hat deswegen den für unsere Anwendung typischen Popup‐Farbstil. 07.07.2008
37
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek Button Die Buttons in unserer Anwendung haben alle das gleiche Farbschema. Somit stellen wir sicher, dass der Benutzer nicht verunsichert wird und auf Anhieb erkennt, was/wo ein Button ist. Jeder Button trägt eine Beschriftung, die den Benutzer eindeutig auf die Funktion des Buttons hinweist. Buttons sind in unserer Anwendung für die allgemeine Navigation verantwortlich und bieten so‐
mit dem Anwender einen Orientierungsstrang, mit dem er in der Lage ist, sich schnell und un‐
kompliziert im Programm fortzubewegen. Für dieses Element gibt es kaum sinnvolle Alternativen. Auch hier haben wir uns an üblichen Ges‐
taltungspraktiken orientiert und somit sichergestellt, dass sich auch ein Benutzer, der sich in der Anwendung nicht auskennt, sofort erkennt, wie welches Bedienelement benutzt werden kann. Button Button mit Maus darüber Gedrückter Button Linkbutton Linkbuttons haben wir an Stellen verwendet, wo wir eine Auflistung von Buttons haben. Die ist zum Beispiel der Fall bei der Projektansicht, wo man eine Liste aller Projektmitglieder hat. Diese Liste, bzw. die Namen sind direkt mit den persönlichen Benutzerprofilen dieser Menschen ver‐
linkt. Da eine Aneinanderreihung von normalen Buttons, wie sie im Abschnitt zuvor beschrieben wurden, das Gesamtdesign negativ beeinflusst hätte und außerdem diese Ansicht völlig überla‐
den würde, haben wir uns für die Verwendung von Linkbuttons entschieden. Dass sich die Linkbuttons vom normalen Text abheben haben wir die Beschriftung auf „Fett“ ge‐
setzt. Somit kann man auf Anhieb erkennen, wo sich auf der Seite Linkbuttons befinden, da wir es vermieden haben, an anderen Stellen das Schriftattribut „Fett“ zu verwenden. Das Farbschema soll sich an das der Buttons orientieren, um einen Bezug zu diesen herzustellen. Linkbutton 07.07.2008
Linkbutton mit Maus darüber Gedrückter Linkbutton 38
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek Checkbox An zwei Stellen in unserer Anwendung haben wir Checkboxen verwendet. Da diese Elemente weit verbreitet sind wir der Benutzer keine Probleme haben, diese richtig einzusetzen. Natürlich sind die Zustände, die durch die Checkbox geändert werden eindeutig benannt. Somit ist dem Anwender zu jedem Zeitpunkt klar, was die Checkbox ausdrücken/aktivieren oder deaktivieren wird. Alternativen wie zum Beispiel den Radiobutton zu nehmen haben wir abgelehnt, da die Checkbox als solches weit verbreitet und bekannt ist und somit auch Anwender, die die Applikati‐
on nicht kennen mühelos mit den Elementen arbeiten können. Deaktivierte Checkbox Aktivierte Checkbox Radiobutton Radiobuttons sind ein sehr gutes Mittel, den Benutzer zwischen mehr als zwei Auswahlmöglich‐
keiten (im Vergleich zu Checkboxen) wählen zu lassen, ohne, dass er diese explizit benennen muss. Somit verhindern wir einerseits Fehleingaben aber auch andererseits, dass der Anwender Zustände auswendig lernen muss. Somit wird die Gedächtnislast reduziert und der Benutzer kann sich mehr auf das Arbeiten konzentrieren. Auf Grund von diesen Vorteilen und da auch dieses Element sehr verbreitet und bekannt ist ha‐
ben wir uns für dessen Verwendung entschieden. Natürlich haben wir darauf geachtet, dass die einzelnen Zustände, die sich hinter den Radiobut‐
tons befinden eindeutig benannt sind und somit dem Benutzer keine Schwierigkeiten bereiten. Auswahlmöglichkeiten bei der Registrierung 07.07.2008
Auswahlmöglichkeiten bei einem ToDo 39
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek Schieberegler Ein weiteres Element zur Steuerung von Zuständen, das wir verwendet haben, sind Schiebereg‐
ler. Mit ihnen haben wir dem Benutzer die Möglichkeit gegeben, schnell und bequem Zustände zu wechseln. Ein Anwendungsfall hierfür ist bei uns die Lautstärkeregelung des Musikplayers. Alternativen für den Schieberegler wären Eingabefelder, in denen der Benutzer die Werte explizit eingeben müsste. Diese Arbeit würde aber langsamer von statten gehen und zusätzlich noch eine Tastatureingabe fordern. Diese Alternative wäre natürlich für Menschen gut, die eine sehr wackli‐
ge Hand haben oder die sehr grobmotorisch sind. Aber aus design technischen Gründen haben wir uns an dieser Stelle dagegen entschieden. Im Weiteren werden die Schieberegler mit einem Tooltip unterstützt, so dass der Anwender er‐
kennen kann, auf was der Schieberegler Einfluss hat und was er verändert. Lautstärkeregelung des Musikplayers Auswahlmenü Auswahlmenüs eignen sich hervorragend, um den Benutzer eine Auswahl anzubieten, die für Radiobuttons einfach zu groß ist und dies damit sehr unübersichtlich machen würde. Außerdem reduzieren wir mit der Verwendung ganz erheblich die Gedächtnislast des Anwenders. Dieses Element haben wir unter anderem beim Musikplayer verwendet. Der Benutzer kann so auf einfache Weise Musiktitel auswählen und muss diese nicht in Textfelder eintippen und dabei auf Richtigkeit der Schreibweise achten. Auch würde die Variante Texteingabefeld den Benutzer dazu zwingen jeden Titel auswendig lernen zu müssen. Da dies nahezu unzumutbar ist, haben wir uns für die Verwendung eines Auswahlmenüs an dieser Stelle entschieden. Zusätzlich bietet dieses Element eine gute Variabilität. Es können sehr leicht weitere Titel eingefügt werden, ohne das Seitendesign/‐layout zu ändern. Auswahlmenü für Musiktitel Aufgeklapptes Auswahlmenü für Musiktitel Das Element ist in der Anwendung so breit, da es auch möglich ist, Internetadressen für Li‐
vestreams auszuwählen. Beispielhaft wurden hier nur drei Titel eingestellt, dies ist aber variabel und in der Endversion werden diese Titel durch eine Vielzahl von weiteren Titeln ergänzt. 07.07.2008
40
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek Datumsauswahl Um den Benutzer eine möglichst einfache aber auch optisch schöne Lösung zu bieten, ein Datum zu selektieren, benutzen wir eine Datumsauswahl. Alternativen hierzu wären Eingabefelder, die aber weder optisch noch funktional mit der Datumsauswahl mithalten können. Ein Datum kann/muss man an 2 Stellen in der Applikation wählen, Dies ist einerseits das Geburts‐
datum, das man einstellen kann und andererseits einen Termin für einen Meilenstein, den man eintragen muss. Eingeklapptes Kalenderfeld Ausgeklapptes Kalenderfeld Das grau hinterlegte Feld zeigt den aktuellen Tag an und das blau hinterlegt Feld den gewählten Tag. Up‐Downs Auch dieses Bedienelement benutzen wir in unserer Anwendung. Es dient dazu, dass der Benut‐
zer bei der Statusverwaltung bequem und ohne Einsatz der Tastatur den Prozentwert eines Sta‐
tus ändern kann. Alternativen hierfür wäre ein reines Texteingabefeld, bei diesem müsste aber per Tastatureinga‐
be alles geändert werden. Somit haben wir die Kombination aus Texteingabefeld und Up‐Downs gewählt, so dass der Anwender die Vorzüge beider Elemente bei Bedarf nutzen kann. Ein links neben dem Bedienelement befindliches Textlabel zeigt dem Benutzer, um welchen Sta‐
tus es sich handelt. „Status 1“ mit 15% Fortschritt 07.07.2008
41
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 15.2 GUI‐Entwurfsprinzipien Unsere GUI setzt das minimalistische Design hervorragend um. Es werden rein funktionale Ele‐
mente verwendet und auf ablenkende Spielereien und Dekoration wurde verzichtet. Somit findet sich der Benutzer in einer sehr strukturierten und ordentlichen Umgebung wieder. Wichtige Elemente wie Buttons und Anzeigetexte heben sich gut vom Hintergrund ab. An dieser Stelle hätten wir einen noch stärkeren Kontrast zwischen Hintergrund und Schrift wählen kön‐
nen, dann wäre aber das Design der ganzen Anwendung doch sehr langweilig und öde. Da die Buttons bei uns die wichtigsten Bedienelemente sind haben sie den stärksten Kontrast zum Hintergrund und erlangen somit sofort die Aufmerksamkeit. Die klare und ähnliche Struktur auf allen Seiten der Anwendung hilft dem Benutzer sich überall zu Recht zu finden. Auf Icons haben wir verzichtet, da wir nur relativ wenige Buttons haben und die‐
se auch eindeutig und klar beschrieben sind. Auch beziehen sich die Buttons nicht auf die Bearbeitung der Daten selbst sondern nur auf einen jeweiligen Wechsel von Sichten und das Öffnen und Schließen von Popups. Für diese dann ein Icon zu entwerfen wäre ziemlich schwierig geworden, weil sie sich in der Funktion kaum unter‐
scheiden. Es werden halt nur andere Sichten gewechselt. Somit ist es besser, eindeutig benannte Buttons zu verwenden. Die ganze Applikation hat ein immer gleich bleibendes Farbschema. Daten werden vom Benutzer nur in den Popups eingegeben. Diese Unterscheiden sich deutlich vom normalen Hintergrund. Der Anwender hat somit eine klare optische Trennung von Dateneingabe und Datenbetrachtung. Somit weiß er zu jedem Zeitpunkt, ob er an dieser Stelle Daten manipulieren kann oder nicht. An dieser Stelle muss erwähnt werden, dass es hier zwei Ausnahmen gibt. Einerseits wird die AGB
‐Ansicht in einem Popup angezeigt, so dass sie auch bei der Registrierung, die bereits ein Popup ist, betrachtet/aufgerufen werden kann. Außerdem wurde dies auch bei Devlogs so umgesetzt. Das hat dort folgenden Sinn: da Devlogs in der Regel hoch frequentiert sind möchten wir den Be‐
nutzern das Scrollen in der Textarea ersparen. Somit wird ein Devlogeintrag in einem Popup mit einer im Vergleich zu den allgemein verwendeten Textareas wesentlich größeren Textarea ange‐
zeigt. Dies bietet dem Text wesentlich mehr Platz als es in der Haupanwendung ohne Popup der Fall wäre. Für den Text verwenden wir eine serifenlose Schrift, um auch bei niedrigen Auflösungen keine Leseprobleme zu verursachen. Überladungen von Text auf einer Seite verhindern wir insofern, dass zum Teil der ganze Text nur nach Aufforderung gezeigt wird und andererseits in einer Kom‐
ponente Textarea platziert wird. Sollte es sich hier um sehr viel Text handeln bietet die Textarea Scrollbalken, die man benutzen kann, um noch mehr zu lesen. 07.07.2008
42
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 15.3 WIMP‐Kriterien Obwohl wir eine Webanwendung haben treffen die klassischen Regeln für Webbrowser‐Fenster nicht zu, da wir unsere Applikation mit der neuen Technologie Flex entwickeln. Haupt‐ und Unterfenster ‐ Hauptfenster mit Panes, in einem Teilfenster TDI (Tabbed Document Interface) Dialogfenster ‐ Modale Popups für Eingabe und Anzeige von Daten ‐ Schließen explizit durch Interaktion (Bsp. Button „Übernehmen“, „Abbrechen“) Menüs ‐ Keine Drop‐Down und Kontextmenüs Widgest ‐ Anwendung enthält Knöpfe, Radiobuttons, Checkboxen, dynamische Auswahllisten ohne Eingabe, Schieberegler, Kalender, Up‐Downs, Texteingabe einzeilig und mehrzeilig ohne Formatierungsoptionen und Autocomplete Meldungen und Warnungen ‐ Modale kleine Dialogfenster sind vorhanden erscheinen in Bildschirmmitte und sind ver‐
schiebbar ‐ Texte sind kurz, verständlich und informativ ‐ Erfolgsmeldung nur bei Registrierung ‐ Bei Fehlern auf der Clientseite, die durch den Benutzer behoben werden können wird im Fehlertext ein Ausweg angeboten ‐ Bei Fehlern auf der Serverseite kann kein Ausweg gegeben werden, da eine Lösung dessen nicht durch den Benutzer realisiert werden kann ‐ Ausweg auf Clientseite ist insofern realisiert, dass Eingaben erst dann vom System bearbei‐
tet werden, wenn diese korrekt sind ‐ Abbruch der Eingabe ist immer möglich Dialogfenster ‐ Einheitliche Gestaltung in Form, Farbe und Struktur ‐ Kurze verständliche Beschreibungen ‐ Kaskadierung überwiegend vermieden, an manchen Stellen angewandt, um Zusatzfunktio‐
nen anzubieten, die im normalen Gebrauch nicht häufig benutzt werden Somit konnten die Dialogfenster klein und übersichtlich gehalten werden Bsp. Bei Registrierung neues Popup, wenn man Webcam‐Bild aufnehmen und benutzen möchte ‐ Erscheinen in Bildschirmmitte und sind verschiebbar und Applikationsmodal 07.07.2008
43
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek Splash Screen und About‐Box ‐ Werden nicht verwendet, da es sich um eine Webapplikation handelt ‐ Anstelle der About‐Box ist ein Impressum in der Anwendung zu finden ‐ Beim Applikationsstart wird ein von uns entworfener Ladebildschrim verwendet Hilfe‐System ‐ Jeder Zeit leicht über einen Knopfdruck zu erreichen ‐ Tutorials in Video‐ und in Textform vorhanden ‐ Direktwahl der verschiedenen Tutorials möglich 07.07.2008
44
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek a. Aufgabenangemessenheit b. Selbstbeschreibungsfähigkeit c. Steuerbarkeit d. Erwartungskonformität e. Fehlertoleranz f. Individualisierbarkeit g. Lernförderlichkeit a.) In unseren Eingabemasken haben wir eine Zweiteilung der Dateneingabe gemacht. Der eine Teil sind Daten, die das System unbedingt braucht und die der Benutzer eingeben muss. Der zweite Teil sind dann optionale Felder die nicht ausgefüllt werden müssen aber dazu dienen zum Beispiel den Kontakt zu anderen Menschen herzustellen oder um sich besser Präsentieren zu können. Dies ist nicht für den Ablauf der Anwendung relevant aber trotzdem ein Fakt, den unsere Applikation bereitstellen soll. Die Zweiteilung der Daten sieht man auf folgendem Bild. Die mit * gekennzeichneten Felder sind Daten, die angegeben werden müssen. Auch die Reihenfolge der Eingabefelder in unserer Anwendung und den Eingabemasken ist lo‐
gisch strukturiert und bei gleichen Datenfeldern auch gleich angeordnet. Popup zur Erstellung eines Meilensteins Popup zur Bearbeitung eines ToDos Popup zur Registrierung b.) In unserer Anwendung verwenden wir sehr aussagekräftige Steuerungselemente. Die Buttons sind klar und eindeutig benannt und geben sofort Aufschluss über ihre spezielle Funktion. Bei Steuerungselementen, deren Funktion nicht direkt ersichtlich ist steht immer ein kleines La‐
bel daneben, dass den Anwender aufklärt, was es mit dem Element auf sich hat. c.) Die Steuerbarkeit ist im Vergleich zu anderen webbasierenden Programmen sehr gut. Der Be‐
nutzer kann sich alternativ mit der Maus und/oder der Tastatur durch die Anwendung bewegen. Auch die Wahl des Arbeitsweges ist ihm völlig freigestellt, sowie seine Reaktionszeit auf Ereignis‐
se. Da unsere Applikation auf einer Kommunikation mit der Datenbank beruht ist ein komplettes Zu‐
rücksetzen aller Interaktionen nicht möglich, insofern diese den Datenbestand geändert haben. 07.07.2008
45
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek d.) Die komplette Anwendung ist sehr klar strukturiert und organisiert. Dazu gehört auch die Er‐
wartungskonformität. Soweit dies möglich war, haben wir alle gängigen Praktiken übernommen, die solch eine Anwendung bieten soll. Der Tastendruck <Enter> bedeutet wie gewohnt ok/
bestätigen und löst somit den Button Übernehmen/Erstellen aus. <Esc> schließt das aktuelle Fenster mit Ausnahme der Hauptanwendung, die man jederzeit mit <Alt + F4> beenden kann. Mit diesem Befehl wird der komplette Browser geschlossen. Auch gängiges Verhalten, wie zum Bei‐
spiel das Weiterspringen der Markierung von Elementen mit dem Tastendruck <Tab> wurde um‐
gesetzt. e.) Bei Eingabefehlern wird der Benutzer immer durch ein Informationsfenster darauf hingewie‐
sen und gebeten, die Eingabe zu korrigieren. Bei einem Schreibfehler oder ähnlichen Sachen hat der Anwender die Möglichkeit, seine Eingaben im entsprechenden Bearbeiten‐Menü zu korrigie‐
ren. Bei gravierenden Löschvorgängen, wie zum Beispiel das Löschen eines Projektes, wird zu‐
sätzlich mit einem Informationsfenster hinterfragt, ob das die Absicht des Anwenders ist. f.) Einstellungen wie Hintergrundfarbe, Layout und Schriftgröße sind nur mit viel Zusatzprogram‐
mieraufwand umsetzbar und dies haben wir in der Kürze der Zeit geschafft umzusetzen. Bei der Weiterentwicklung dieses Programms wird dieser Fakt aber eine ernst zunehmende Rolle spielen. g.) Zur Lernförderlichkeit haben wir Tutorials aufgenommen, die jede Komponente in der Anwen‐
dung erklären. Auch Vorgänge wie zum Beispiel „Neues Projekt anlegen“, „Registrieren“, „Login“ etc. werden exemplarisch durchgespielt. Wie haben die Tutorials einfach und kurz (<1 Minute) gehalten, um den Benutzer einen schnellen Einblick vermitteln zu können. Nachdem betrachten dieser Tutorials hat der Anwender eine genaue Übersicht über alle Funktio‐
nen, die ihm zur Verfügung stehen. Diese Tutorials sind jederzeit in der Applikation über den „Hilfe“‐Button erreichbar und es kann dort wieder reingeguckt werden, sollte man etwas verges‐
sen haben. 07.07.2008
46
Felix Fischer (s741064) Marcus Gerlach (s740974) Dennis Weinmann (s741074) Multimedia Engineering II ‐ MULTImediathek 15.4 Barrierefreiheit In der aktuellen Version unserer Applikation haben wir keine Unterstützung für blinde Benutzer. Auch gängige Programme, die den Inhalt blindengerecht darstellen, können wir hierfür nicht ver‐
wenden, da die Anwendung innerhalb des Browsers im Flashplayer läuft. Somit müsste solch eine Schnittstelle noch programmiert werden, um eine Barrierefreiheit für blinde Nutzer herzustellen. Zu Gute würde uns an dieser Stelle kommen, dass wir auf Grafiken verzichtet haben und alle Da‐
ten und Steuerungselemente in Textform vorliegen. Somit wäre das ein sehr guter Ansatzpunkt für einen Screenreader und/oder die Braillezeile, wenn die entsprechende Schnittstelle program‐
miert wäre. Da sich im Programm selbst nur die Daten aber nicht die Navigation ändert wäre das gut für blin‐
de Benutzer, da sie sich Pfade durch die Seiten merken. Diese Pfade sind immer gleich und bieten einen guten Anhaltspunkt. Eine Schwierigkeit wäre die eindeutige Beschriftung der Buttons, die dynamisch je nach Inhalt aufgebaut bzw. angezeigt werden. Da in der momentanen Version noch keine Individualisierbarkeit durch den Benutzer implemen‐
tiert ist, müssen sehbehinderte Anwender noch mit den von uns gestalteten Farben und Schrift‐
größen arbeiten. Der Kontrast ist aus Design technischen Gründen nicht maximal und könnte für stark sehbehin‐
derte Menschen ein Problem darstellen. Dem Einsatz der Bildschrimlupe spricht allerdings nichts entgegen, da zusammengehörige Daten zusammen stehen und nicht über die Seite verstreut sind. Somit entsteht kein Nachteil, wenn man zu einem Zeitpunkt nur einen Ausschnitt des Bildschirms betrachten kann. In wie fern das Ändern der Schriftgröße durch Grafikeinstellungen bewerkstelligt werden kann, weiß ich nicht, da es sich hier um eine im Browser laufende Flashapplikation handelt. Für gehörlose Benutzer sollte die Seite eigentlich keine Probleme darstellen. Die verwendeten Ausdrücke und Formulierungen sind nicht umständlich und kompliziert gewählt. Somit dürften sich kaum Verständnisbarrieren auftun. Eine Stelle an der wir nachbessern müssten wären Unter‐
titel in unseren Tutorialvideos, die als Zusatzoption angeboten werden müssten, so dass auch ge‐
hörlose Anwender die Kommentare verstehen. Alternativ könnte man die Videos auch mit Gebär‐
densprachenvideos ergänzen. Benutzer mit Lernschwierigkeiten unterstützt die einfache und gut strukturierte Anordnung der kurzen Texte und das minimalistische Design. Auf ablenkende Animationen haben wir vollkom‐
men verzichtet. Um zu vermeiden, dass die Seiten zu überladen sind arbeiten wir mit Popups. Dies könnte sich als ablenkend für diese Benutzergruppe darstellen. Die Sprache in der Applikati‐
on ist durchgängig deutsch und verwendet an einigen Stellen englische Begriffe, die sich aber im Laufe der Zeit eingedeutscht haben. Die zu jedem Zeitpunkt erreichbare Navigationsleiste am oberen Rand unterstützt den Anwender in so fern, dass er jederzeit wieder auf bekannte Seiten springen kann, sollte er sich nicht mehr zu Recht finden. Für internationale Anwender bietet die Anwendung im Moment noch keine Sprachunterstützung. Um ein Sprachgewirr zu verhindern übernimmt unsere Applikation nicht die Systemsprache. Um eine Mehrsprachigkeit anzubieten müssten wir noch Sprachpakete entwickeln und einbauen. So‐
mit kann man auch sicherstellen, dass kein Sprachgewirr entsteht. Sollten diese Ressourcen dann zur Verfügung stehen, wären sie einfach und mit einem Klick umstellbar 07.07.2008
47