MMXIII – 2013

Morgen ist es wieder so weit: Aus der Dreizehn wird eine Vierzehn. Eine neues Jahr beginnt. Zeit mal einen Rückblick auf das (noch) aktuelle Jahr 2013 zu werfen.

Januar

Obwohl in diesem Jahr eigentlich sehr viel passiert ist, verlief der Januar relativ ereignislos. Ich bin ein Jahr älter geworden, es war kalt – das war es eigentlich.

Februar

Im Februar war auch schon wesentlich mehr los – zumindest aus meiner Sicht heraus. Nachdem ich mich quasi mehrere Jahre von sozialen Netzwerken ferngehalten habe, entschloss ich mich es noch ein zu versuchen. Und zwar mit App.net. Wieso eigentlich? Ich muss vielleicht dazu erwähnen was damals, als ich mich entschloss es mit Social Media mal sein zu lassen, mein eigentliches Problem war: Mein Freundeskreis hält sich nicht in sozialen Netzwerken auf. Ein paar sind vllt. noch bei Facebook, allerdings setzte ich bei sozialen Netzwerken einen Austausch vorraus – der findet bei mir auf Facebook nicht statt, also fällt dieses Netzwerk schonmal weg. Jedenfalls war das eigentliche Problem, das ich es irgendwie nie, weder auf Twitter noch sonstwo, geschafft habe dazwischen zu kommen. Ich weiss nicht wo der Fehler lag – jedenfalls war es sehr frustrierend. Nichtsdestotrotz entschloss ich mich es noch einmal zu versuchen – und zwar mit App.net. Ich sollte Recht behalten. Da dieses Netzwerk noch relativ jung war, wurden die Karten quasi neu gemischt. Bis jetzt habe dort viele interessante Menschen kennen gelernt. Mit einigen Arbeite ich mittlerweile sogar an verschiedenen Projekten. Genau so habe ich mir das vorgestellt.

Projekte: Was ist denn nun schon wieder los?

Für alle, die sich gefragt haben: Was ist denn nun schon wieder los? Wieso gibt es keine neuen Beiträge? Die Antwort ist relativ einfach: Ich habe in der letzten Zeit einige Projekte aufgezogen bzw. arbeite an einigen Projekten mit.

Um den Besuchern dieser Website einen etwas besseren Überblick zu verschaffen über die Dinge, welche in meiner Freizeit u.a Treibe, habe ich eine kleine Übersicht erstellt.

Natürlich werde ich weiterhin versuchen hier regelmäßig über verschiedene Dinge zu berichten. Ich kann jedenfalls empfehlen mal in das ABSradio reinzuhören. Dort spreche ich zusammen mit Basti und Sascha über verschiedene Dinge. Wer sich für die Projekte interessiert, an denen ich mitarbeite, kann sich dort auf dem Laufenden halten.


Projekte: ADNCC 1.1 Screenshot

Abschließend noch ein paar Anmerkungen zu den Änderungen von ADNCC. ADNCC befindet sich mitlerweile in der Version 1.1 (die Dokumentation der neuen API erfolgt bald). Neben einem komplett neuen Design, lassen sich Clients nun vergleichen und etwaige Vergleiche als URL verschicken. Im Rahmen der Datenpflege könnten wir jedoch noch etwas Hilfe gebrauchen. Weitere Informationen lassen sich auf der ADNCC Website finden.

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.

ADNCC API Version 0.6b

A new Version of the API (0.7b) is available here.

Description

The ADN-client-comparison (ADNCC) API enhances the „ADN-Client Feature Matrix“ by @nhk in order to offer an API, which makes information about the clients accessible, in a different way then the original Spreadsheet. In detail, The data is pulled from the original spreadsheet and released as an JSON object. This data then can be used in any way.

Features

Beside pulling the whole data, the pull request can be modified. For instance if you would like to pull information about a certain client only, you can limit the number of results by adding the clients name to the URL:

http://adn-client-comparison.nigma.de/pull.php?name=Felix

Another example would be that you only want to fetch all android clients. This could be realized by calling:

http://adn-client-comparison.nigma.de/pull.php?platform=Android

Indeed, this concept assigned to every key available in the data (e.g. stream_marker_support, interactions_view etc.).

Known Issues

As the API is in beta phase there are several things that need to be fixed, or are not as solid as they should be. It is known that if applying more than two filters, in some cases filters will be ignored randomly. However, the data obtained if using two or no filters worked fine for all performed tests.

Future development

In the near future it is planned use this API in order to build a website, which suggests suitable clients for the user, based on several choosable filters and criteria. It is not known yet if the API filter-options are further developed, because this strongly depends on if it is necessary to build the mentioned website.

Implementation

PHP is known to decode and encode JSON to and from arrays. An example would be:

The database contains <?php echo count(json_decode(file_get_contents("http://adn-client-comparison.nigma.de/pull.php"))); ?> entries.

Which would result in: The database contains 58 entries.

As the results of the request are in JSON-Format no further explanation for JavaScript-implementation should be needed ;-)

Disclaimer

The provided data is neither collated by myself, nor by the developer of the clients. Therefore I’m not responsible for the accurateness of the provided information.

Feature requests, bug reporting etc.

Please report any feature requests and bugs, which were not mentioned in the known issues paragraph, to my ADN account.