App.net clients: Must have Features – Eine Idee – Teil 2
Im ersten Teil dieser Serie wurden bereits einige Punkte angesprochen, welche mir helfen sollten festzustellen, ob es so etwas wie “Must have features” für einen App.net-Client gibt. Wirklich weiter gekommen bin ich dabei nicht: Weder die Definition des Wortes “Client”, noch Empfehlungen von App.net-Nutzern oder aktive Entwicklung haben mir bei meiner Suche weiter geholfen.
Natürlich habe ich mir wieder Gedanken gemacht und ich habe mich entschlossen das Ganze mal von einem ganz anderen Standpunkt aus zu sehen. Die Idee ist etwas fundamentaler anzusetzen: Es hilft sicherlich weiter, wenn man erst einmal überlegt, was App.net überhaupt ist. Als guter Ansatz, kann der oftmals falsche Vergleich zwischen Twitter und App.net herhalten. Fangen wir mal ganz von vorne an: Warum ist dieser Vergleich eigentlich falsch?
Man kann es relativ einfach zusammenfassen: Viele Leute verwechseln α mit App.net. Das Problem dabei ist, dass App.net somit auf die Rolle eines Twitter-clones reduziert wird. Das ist allerdings völlig falsch. Es handelt sich bei α lediglich um den ersten Dienst1 für App.net. Somit ist der Vergleich zwischen Twitter und App.net hinfällig. App.net ist vielmehr die Plattform, auf welcher u.a. α aufbaut. Ich denke, dass man App.net viel mehr als eine Plattform verstehen sollte, welche eine Infrastruktur bietet um weitere Dienste aufzubauen. Dies stimmt recht gut mit der Beschreibung von App.net überein:
App.net is an ad-free, subscription-based social feed and API. App.net aims to be the backbone of the social web through infrastructure that developers can use to build applications and that members can use for meaningful interactions.
Wenn man also an dem Punkt ist, dass App.net lediglich die Plattform ist, müsste man theoretisch zwischen α und App.net unterscheiden. Alle bisherigen Ansätze wären folglich nicht mehr angemessen. Die eigentliche Bezeichnung App.net-client muss zudem neu definiert werden. Vom jetzigen Standpunkt aus, bleiben eigentlich nicht sonderlich viel Features übrig, die ein reiner App.net-client haben kann. Die Frage, welche “Must have Features” ein App.net client also haben muss, ist damit trivial. Vielmehr müsste man unterscheiden zwischen einem Client für Microblogging, Datenverwaltung oder etwa Messaging. Da hier die Ansprüche sehr unterschiedlich sind, macht es keinen Sinn gemeinschaftliche “must have features” zu definieren.
Was ich jedoch tun kann, um dieser Idee final etwas Leben einzuhauchen, ist trotzdem ein Resultat zu präsentieren. Zwar können beide Artikel keine “must have features” nennen, was sie aber können ist eines verdeutlichen: Ob ein Feature wirklich “must have” ist, oder nicht, entscheidet einzig und allein der Nutzer bzw. der vom Nutzer vorgegebene Verwendungszweck. Möchte der Nutzer Feature X nutzen, ist es “must have”. Alles andere ist optional. Tools wie ADNCC, helfen also, entgegen meiner anfänglichen Behauptung doch weiter. Sie helfen dem Nutzer den wesentlichen Anforderungspunkt an seine Software zu formulieren. Dem Nutzer hierbei jedoch irgendeine Art von Vorgabe zu geben (wie etwa “empfohlene Features” oder ähnliches) ist in diesem Fall jedoch nicht empfehlenswert.
Fazit: Es gibt keine wirklichen “must have” Features für App.net clients. Ein Feature wird “must have”, sobald ein Nutzer es haben möchte, oder es essenziell für einen App.net Dienst ist. Die Frage wird insbesondere dadurch trivial, da App.net ein Plattform ist und nicht α ist. Die Antwort auf die Frage ist somit unbefriedigend, zeigt aber dennoch wieder auf, wie schwierig die Beantwortung einer solchen einfachen Frage ist, wenn man nicht direkt an der Wurzel anfängt. Die Quintessenz für den Fall ADNCC ist jedoch klar: Vorgaben oder empfohlene Einstellungen helfen dem Nutzer nicht weiter, sie verhindern vielleicht sogar die genaue Anpassung an die Bedürfnisse des Nutzers.