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.


  1. http://support.app.net/customer/portal/articles/761034-what-is-alpha- 

App.net clients: Must have Features – Eine Idee – Teil 1

Aus aktuellem Anlass, habe ich beschlossen mir mal einige Gedanken darüber zu machen, ob es für einen App.net Client grundsätzlich sog. „must have“ Features gibt. Die Grundsätzliche Idee ist die folgende: Kann ich speziell auf das Beispiel von App.net zugeschnitten, eine Auswahl an verschiedenen Kriterien erstellen, welche ich einem Nutzer an die Hand geben kann, um eine Vorauswahl für einen App.net Client zu treffen. Da die Überlegungen nicht trivial und relativ lang sind, habe ich mich Entschlossen das Ganze in verschiedene Posts aufzuteilen. Viel Spaß also beim ersten Teil.

Eine Frage der Definition

Die grundsätzliche Frage ist hier natürlich: Was muss ein Client können, um sich als solcher bezeichnen zu dürfen. Muss der volle Funktionsumfang bspw. einer API abgedeckt werden, oder reicht es aus, sobald auch nur ein Teil genutzt wird.

A client is a piece of computer hardware or software that accesses a service made available by a server. Wikipedia

Auch wenn das obige Zitat für Viele nichts neues sein dürfte, so hilft es dennoch weiter. Grundsätzlich kann sich also erst einmal als App.net Client bezeichnen, was auf irgendeine Art und Weise mit dem App.net Server kommuniziert. Was hier jedoch erst einmal nicht abgedeckt wird, ist der Funktionsumfang. Die zentrale Frage bleibt erst einmal unbeantwortet.

Aktive Entwicklung: Ja oder nein?

Im Rahmen von ADNCC bzw. der Client Matrix wurde aktive Entwicklung so definiert, dass ein Update in den letzten zwei Monaten stattgefunden hat, bzw. Mitgliedern des Projektes bekannt ist, dass ein Update für Client eine aktuelle Beta-Phase durchläuft. In der Theorie ist diese Idee sicherlich nicht verkehrt. So gesehen ist es sicherlich nicht verkehrt, dass ein Client oft aktualisiert wird. Die Frage die sich hier unweigerlich stellt ist, ob ein Client überhaupt regelmäßige Updates erfahren muss. Sollen nur einige spezifische Features abgedeckt werden und die Software enthält keine Fehler bzw. läuft stabil, sind Updates nicht unbedingt notwendig. Als recht bekanntes Beispiel kann hier die Software „enlightenment“ genannt werden. Um den Sprung von 0.16 auf 0.17 zu schaffen, brauchte die Software knapp 13 Jahre. Dennoch war und ist sie für ihre Stabilität bekannt. Es ist also auch hier nicht wirklich einfach eine Aussage zu treffen. Es kommt einfach sehr stark auf den Umfang des Clients an. Werden nur einzelne, weniger Features unterstützt ist aktive Weiterentwicklung kein Indiz, ob ein Client gewählt werden sollte. Falls man jedoch eine eierlegende Wollmilchsau sucht, sollte ein Client gewählt werden, welcher regelmäßig Updates erfährt und somit ein Maximum an Unterstützung von App.net-Features mit sich bring. Gute Beispiele sind hier Felix und hAppy.

Einfluss der Anderen: Empfehlungen

Ich bin mir ziemlich sicher, dass ein Großteil der App.net Nutzer einen entsprechenden Client aufgrund von Empfehlungen gewählt haben. Die oftmals erste Frage, welche ein neuer App.net-Nutzer stellt, ist „Welchen Client soll ich nutzen?“. Tools wie etwa, ADNCC helfen hier nur bedingt weiter, da hier nur reine Features betrachtet werden. Ob der Client etwa benutzerfreundlich ist, kann vom Nutzer hier nur bedingt (etwa „Accessible“) überprüft werden. Natürlich ist es nicht wirklich möglich die Benutzerfreundlichkeit festzuhalten, ohne dabei den Charakter einer neutralen Matrix zu verlieren. Man muss die Clients testen und ein Urteil fällen. Selbst dann wäre es immer noch schwierig zu sagen, ob ein Command-line-client weniger benutzerfreundlich ist als ein Programm zum klicken.

Die zweite Möglichkeit wäre es die Nutzer der Clients bestimmen zu lassen, welche Clients tauglich sind oder nicht. Was hier jedoch gewährleistet werden muss ist, dass in regelmäßigen Abständen das etwa ein Voting zurückgesetzt wird, um den aktuellen Meinungsstand zu erfassen. Bspw. darf es nicht sein, dass ein Client mit X Stimmen zu den „besten“ Clients zählt, nur weil er vor bspw. einem Jahr für gut empfunden wurde. Es lässt sich also durch diese sehr kurze Ausführung erahnen, wie viele weitere Faktoren hier beachtet werden müssen.

Bisheriges Fazit:

Ich kann bisher nicht sagen, bezogen auf App.net Clients, ob es so etwas wie Must have Features überhaupt gibt. Zu groß sind die Unterschiedlichen Verwendungszwecke. Es ist zudem nicht einfach überhaupt einen Anhaltspunkt zu finden, anhand von welchen eine Empfehlung stattfinden könnte. Aktive Entwicklung bzw. die Empfehlungen helfen nur bedingt weiter.

Weiter geht es im zweiten Teil.

Aktuelles Gedankengut

Mein Blog lebt! In den letzten Tagen habe ich hier und da noch einige Kleinigkeiten hinzugefügt. Es gibt nun bspw. in der rechten Sidebar eine Übersicht über alle zur Verfügung stehenden Feeds. Insgesamt geht es gut voran: die Einträge häufen sich und alles wächst und gedeiht.


App.net ist für mich immer noch eines der besten Social Networks aller Zeiten. Es macht richtig Spaß dort mit Leuten zu kommunizieren. Ich kann jedem nur ans Herz legen reinzuschauen. Im Zuge dessen droht sich mein Twitter-account leider in Luft aufzulösen.


Und weil mir ADN so gut gefällt, habe ich auch versucht einen Teil zu diesem Netzwerk beizutragen. Wie man in den letzten Tagen gesehen hat, habe ich eine API programmiert, welche das ADNCC-Spreadsheet von @nhk im JSON-Format zugänglich macht. Für mich ist es das erste Projekt dieser Art und ich bin froh, dass bisher alles so gut geklappt hat. An dieser Stelle vielen Dank für die Unterstützung!

So richtig schön klassisch

Gestern war ich nach langer Zeit mal wieder im Zirkus Roncalli. Es ist schon ein Weilchen her, dass ich diesen Zirkus besucht habe, bzw. es ist schon lange her, dass ich überhaupt irgendeinen Zirkus besucht hatte. Ich bin mir eigentlich recht sicher, dass ich das letzte Mal im Zirkus Flic Flac war. Der Zirkus ist ja aus diversen Gründen durch die Medien recht bekannt. Man versucht dort, den klassischen Zirkus etwas zu modernisieren. Ich habe mir dort im Laufe der Jahre drei verschiedene Programme angesehen. Leider hatte ich den Eindruck, dass das Programm sich zwar verändert hatte, aber dennoch im Kern sehr ähnlich geblieben ist. Infolgedessen hat mir der Zirkus anfangs wesentlich besser gefallen. Ich will damit nicht sagen, dass der Zirkus oder sein Programm schlecht ist, vielmehr war das Programm, welches ich sehen durfte, so überwältigend, dass jene nachfolgende dem Ersten leider nicht das Wasser reichen konnte.

Gestern war es jedenfalls so weit. Ich mache es kurz: Es hat sich gelohnt. Eigentlich wurden auch gestern wieder viele Nummern gezeigt, welche vom Prinzip her bekannt sind. Der entscheidende Unterschied war jedoch, dass jene in sofern ergänzt oder verändert wurden, dass so etwas komplett Neues geschaffen wurde. Was mich insbesondere überzeugt hat, waren die richtig schön klassischen Clowns. Rote Nasen, weite Hosen, viel zu große Schuhe – nichts hat gefehlt. Ich war hell auf begeistert, denn für mich macht ein gutes Zirkusprogramm ein gut abgewogenes Verhältnis zwischen verschiedenen Genres der Nummern.

Falls also jemand mal wieder in den Zirkus gehen möchte. Meine Empfehlung sollte hiermit klar sein.

Alles auf Anfang

Hallo. Hier bin ich mal wieder. Alles auf Anfang. Diese Worte dürften zu den meistgenannten Worten hören, die man von mir in meinen Blogs bisher hören durfte. Die erste Frage, die sich eigentlich weniger meine Leser, sondern vielmehr ich mir stellen muss, ist: Wieso wurden diese Worte so oft genannt? Wieso werden sie wieder genannt? Wo sind denn die anderen Blogs?

Die Antwort auf die dritte Frage ist schon einmal recht einfach: Sie sind vermutlich nur noch in einem Backup existent. Was war passiert? Eigentlich recht einfach: Ich hatte einfach mal Lust zu bloggen. Kurzerhand entschloss ich mich mein erstes Blog aufzuziehen. Nicht erwähnenswert. Nach einigen Blogs und zahlreichen Posts, wurden meine Mühen von einigen Abonnenten belohnt. Eigentlich lief alles gut – sollte man meinen. Das Problem, welches sich zunehmend auftat war, dass es mir immer schwieriger viel, Themen zu finden, über welche ich bloggen konnte. Der Grund dafür dürfte wohl gewesen sein, dass ich mir damals vorgenommen hatte möglichst objektiv und meine Beiträge möglichst wenig „persönlich“ zu gestalten. Die Konsequenz, welche ich aus diesen Experimenten ziehen konnte: Für mich funktioniert nicht-persönliches bloggen nicht! Da ich das jedoch nicht frühzeitig erkannt habe, musste ich dies mit viel Zeit und vielen Worten (s.o.) bezahlen.

Was kann man also von diesem Blog erwarten? Es wird auf jedenfall persönlicher. Sicherlich werde ich auch über das eine oder andere Thema weniger persönlich sein, jedoch versuche ich es persönlich zu halten. Man sollte also zukünftig beim stöbern einen recht umfangreichen Eindruck über mich erhalten. Bei Zeiten plane ich zudem die sogenannte „Spielwiese“ zu eröffnen. Dies soll eine kleine Ansammlung von kleinen Vorlagen, Templates oder Code-Schnippsel werden, welche ich in meinen Alltag integriert habe. Wie ich das Ganze jedoch umsetze wird sich erst noch zeigen.

Bevor sich dieser erste Eintrag dem Ende neigt, möchte ich noch kurz auf das Thema „Kommentare & Diskussion“ eingehen. Wie man sehen kann, gibt es in diesem Blog keine Kommentare. Wieso? Wenn jemand etwas kommentieren möchte, soll er dies bitte über ein Social Network (vorzugsweise app.net) tun. Der Grund ist recht einfach: Ich erhoffe mir so mehr Interaktion mit den Kommentatoren. Ich möchte jedoch nicht vollständig ausschließen, dass bei dem ein oder anderen Beitrag doch einmal die Möglichkeit zum Kommentar gegeben wird.

So: Nun ist dieser erste Beitrag auch schon zu Ende. Auf die Zukunft. Waidmanns Heil!