Terminfindungswebdienst
Geschrieben von Gregor Nathanael Meyer um 10:4028 11 2010
Seit ein paar Jahren veranstalte ich mit ein paar Kollegen in unregelmäßigem Abstand einen kleinen Jour-Fixe, die Terminabsprache findet in einer Mailingliste statt. Die Erfahrung damit zeigt, dass das schon bei 6 Leuten unübersichtlich wird und eine klare Diskussion für Alternativtermine nicht ganz leicht ist. Nun kommt noch ein mehr oder weniger regelmäßiger Spieleabend dazu, an dem auch noch Leute teilnehmen werden, denen ich die korrekte Bedienung einer Mailingliste gar nicht erst zutraue. Es muss also eine alternative technische Unterstützung hinzukommen. Spontan fällt mir da nur Doodle ein, aber deren tabellenartiges System geht mir nicht weit genug, weil es die komplexen Zusammenhänge von Zusagen nicht abbilden kann. Dass man mehrere Daten zur Wahl hat und nur entweder sagen kann, ob man kann oder nicht, reicht eben nicht. Also überlege ich, sowas schnell mal selbst zu schreiben. Aber was braucht es für ein Featureset? Nach ein wenig Nachdenken bin ich auf folgende Funktionen gestoßen:
- Es muss geschlossene Gruppen geben, die per E-Mail abonnierbar sind. Neue Terminvorschläge (mit oder ohne Alternativen) und Änderungen gehen als Benachrichtigung raus, ein Klick auf einen Link in der Mail sollte dabei direkt einen Status setzen können, ohne, dass man sich extra einloggen muss. Es sollte zudem auch offene Gruppen/Events mit und ohne Einladung geben.
- Bei mehreren Terminvorschlägen für ein Event muss es eine intuitive Priorisierung geben, vielleicht per Drag and Drop, vielleicht anders. Man muss ausdrücken können, dass einem Termin A lieber als Termin B ist, man aber bei Termin C gar nicht kann. Zudem muss unterschieden werden zwischen benachrichtigt, aber nicht reagiert und einer expliziten Ablehnung.
- Es muss eine Möglichkeit geben, vielleicht bzw. unter Vorbehalt zuzusagen. Daraus ergibt sich auch die Anforderung, dass es einen leicht zugänglichen Kommentar zu jedem eigenen Voting geben muss. So ein Kommentar sollte nicht chronologisch aufgeführt werden, sondern als Metainformation zum Voting.
- Man muss seine Votings ändern können, ein Zeitstempel für die letzte Änderung muss dabei veröffentlicht werden. Außerdem sollten Events auch vor ihrem eigentlichen Datum als abgeschlossen markiert werden können.
- Es sollte die Möglichkeit geben, dass der Eventbesitzer bestimmte oder alle Personen als "Muss dabei sein" oder "Wäre schon wichtig" markieren kann. Zudem sollte er den Usern der Gruppe freistellen können, solche Bedingungen für sich (und ggf. auch andere) zu definieren.
- Es sollte einen Kommentarbereich geben, wo kurze Diskussionen ausgetragen werden können (etwa "Was essen wir?).
- Die Votingtabelle sollte via iFrame anderswo einbindbar sein.
- Die Softwarebasis sollte unter einer Open-Source-Lizenz veröffentlicht werden, so dass jedermann so ein System für sich aufsetzen kann. Möglicherweise kann man sowas auch als Cloud-Dienst für andere anbieten.
- Es muss eine API (mindestens JSON) geben, über die der Dienst (wahlweise) auch von Außen bedienbar wird. Authentifizierung könnte per oAuth gemacht werden, standardmäßig aber per Cookie und bei Mails via Token. Sicherheit bei der Authentifizierung sollte im Zweifel gegenüber Komfort bei der Nutzung nachrangig behandelt werden.
- Die Oberfläche sollte optisch angenehm sein und sich mit ausgeprägter AJAX-Unterstützung flüssig bedienen lassen. Ein Fallback mit Mindeststandard für Nutzer ohne JavaScript könnte implementiert werden, aber es dürfen dadurch keinerlei Komforteinbußen bei Nutzern mit JavaScript entstehen. Der Internet Explorer 6 (und ggf. auch 7) wird als Browser nicht berücksichtigt, solche Nutzer werden entweder gewarnt (und können es dann wenigstens mal versuchen) oder sofort abgewiesen. Ausnahme: Der Request wird trotzdem ausgeführt, klicks auf Links in Benachrichtigungsmails müssen immer funktionieren. Technisch wird auf CSS3 und HTML5 gesetzt, als JavaScript-Framework kommt jQuery zum Einsatz, serverseitig basiert das System auf PHP 5.3 (und MySQL oder SQLite via PDO) und ggf. auf einem Framework (Symfony, Zend, Flow3). Gegen ein Framework spricht, dass man das System ggf. kapseln könnte, um es als PlugIn für verschiedene CMSe zu portieren. So komplex sollte das nicht sein und das MVC-Paradigma und andere Design-Patterns kann man auch so nutzen. Der Login-Mechanismus (samt Gruppen- und Userverwaltung), der Dispatcher (für das Routing der Requests und vor allem der API) und das Model müssten dann modular aufgebaut und austauschbar sein, die Output-Templates sind es ja sowieso schon.
- Ggf. könnte das System nicht nur für Events genutzt werden, sondern auch für die allgemeine Entscheidungsfindung. Man stellt also etwa Pizza, Asia, Pommesbude, Döner und Nudeln zur Wahl und bekommt am Ende eine Entscheidung mit dem besten Kompromiss. Da wird besonders deutlich, wie wichtig eine Einstufung jenseits von ja und nein ist.
Habe ich eine wichtige Funktion vergessen? Gibt es Input? Meldet Euch einfach bei mir, aber denkt daran, dass ich kein ICQ mehr benutze.
Kategorien : Web-hinteres-Ende
Trackbacks : Keine Trackbacks »
Short-URL: http://spackblog.de/729
