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.