Eingesperrte Mails
30. Januar 2007
Niemand nutzt sie, niemand braucht sie. Sie müllen die Oberflächen zu und verursachen unnötigen Programmieraufwand. Die Rede ist natürlich von internen Mailsystemen. Jede noch so kleine und unbedeutende Webservice-Klitsche scheint eine sehr seltsame Selbsteinschätzung zu hegen, denn wie sonst kann man sich erklären, dass jede sogenannte »Community« ihr eigenes Nachrichtensüppchen kocht?
Natürlich wollen die Leute sich austauschen und mit ihren ergruschelten Kontakten kommunizieren, doch dazu gibt es einen hervorragenden Kanal, der exakt dafür gemacht wurde: E-Mail. Gibt’s schon seit 30 Jahren oder so und fuktioniert immer noch hervorragend, weil meist plattformunabhängig, mobil, desktop- oder auch webbasiert. (Die Spamproblematik lasse ich hier mal außen vor.)
E-Mail ist toll, und warum zum Teufel sollte man nicht auf das Einbetten eines internen Mailsystems souverän verzichten? Selbst Simon Willison sagte in einem Vortrag einmal (Ich weiß nicht mehr, auf welcher Konferenz es war), dass Flickr eigentlich kein internes Mailsystem benötige. Genauso kenne ich viele Leute, die bei Xing möglichst schnell ihre Kommunikation auf bilateralen Boden verlagern wollen, statt über die Plattform zu gehen. Die Gründe sind simpel: Seine gesamten E-Mails hat man zentral an einem Ort und kann sie einheitlich lagern, durchsuchen und nutzen. Wenn dazu noch drei oder vier soziale Netzwerke kommen, bei denen ich vereinzelt möglicherweise wichtige Mails rumfliegen habe, wird es schnell sehr unübersichlich.
Natürlich ist mir klar, worum es den Anbietern geht: Man möchte die User auf der Plattform behalten und sie auch Teile ihres Mailverkehrs direkt auf den Seiten abwickeln lassen. Somit enstehen mehr PageViews, und möglicherweise wird auch die eine oder andere Google-Anzeige öfter geklickt.
Die Zukunft der modernen Webservices liegt jedoch ganz klar in der Vernetzung mit anderen Diensten über standardisierte Protokolle und APIs. Warum etwas aufwändig nachprogrammieren, wenn es bereits existierende Lösungen gibt, die ich Anzapfen und kombinieren kann? Wer also in seinem Webservice eine interne Kommunikationsmöglichkeit anbieten möchte, sollte das doch einfach per Webformular und simplem Plaintext-Mailversand an die entsprechende Adresse tun. Die dabei erzeugten Mails müssen ja nicht so krebsgeschwürartig vollgepropft sein wie die von eBay. Für die Livekommunikation kann man ICQ/AIM oder zur Not auch IRC nehmen, statt sich ein eigenes, proprietäres, webbasiertes System auszudenken. Warum immer das Rad neu erfinden und dadurch die User zwingen, neue Dinge zu lernen, wenn das Gute liegt so nah?
Also nochmal zum Mitschreiben: Die Zeit zum Implementieren eines internen Mailsystems lieber in die Usability- und Designverbesserung der Kernfunktionen stecken – da lohnt sich die Investition meistens mehr – Stickam, Du bist gemeint …