MMXIV – 2014

Letztes Jahr habe ich ja schon einen Jahresrückblick gemacht. Es ist also Zeit das Jahr 2014 einmal runterzubrechen, was mir irgendwie sehr schwer fällt. Das liegt zum einen daran, dass dieses Jahr einfach so unglaublich voll war, dass ich überhaupt nicht weiss, was nun erwähnenswert war und was nicht. Zum anderen bin ich mit 2014 irgendwie nicht zufrieden gewesen, obwohl es eigentlich objektiv betrachtet gut lief. Ich habe viele Dinge nicht erledigen können und vieles nicht umzusetzen geschafft. Um ehrlich zu sein, frustriert mich das durchaus und gibt 2014 irgendwie einen bitteren Beigeschmack.

Dalton Caldwell über Broadcasts on App.net

Broadcast has been getting good uptake thus far, especially from folks that tell me they previously didn’t „get“ App.net. As of today more people use App.net for Broadcast than for microblogging. (on a daily basis, across all clients)

Na also, es wird doch :)

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-