Instacast für den Mac – Erste Eindrücke

Ich bin ja einer dieser Syncronisations-Fetischisten. Ich bevorzuge es grundsätzlich, wenn ich auf allen Devices auf mindestens die wichtigsten Dinge zugreifen kann. Das mag zum Einen für simple Dinge wie Kontakte, oder Kalender gelten, zum Andern möchte ich unterwegs arbeiten können und ohne große Umwege diese Arbeit zu Hause fortsetzen können. Eigentlich hört sich das ganz stark nach Notebook an, allerdings muss man sich mein Nutzerverhalten so vorstellen: Sobald ich zu hause bin, liegt mein Telefon auf der Kommode im Flur. Auf der Couch wird nur ein Tablet verwendet und auch nur in Ausnahmefällen ein Notebook. Richtige Arbeiten werden grundsätzlich an einem Stand-PC erledigt. Auf die Gründe gehe ich nicht weiter ein. Ich mag es einfach so.

Jedenfalls gab es bisher immer eine Geschichte, welche mich immer geärgert hat: Podcasts. Ich konsumiere Podcasts mittlerweile überall. In der Bahn, vor meinem Rechner, in der Küche etc.. Bisher musste ich zu meinem Rechner immer irgendein anderes Device mitschleppen. Schließlich soll ja alles schön syncron sein und ich will nicht immer erst die Stelle suchen, bei welcher ich aufgehört habe. Wenn mal wirklich keine Lust hatte, habe ich immer Podgrasp verwendet. Aber wirklich zufrieden war ich damit auch nicht. Die einzige Lösung wäre iTunes mit der Podcast-App von Apple gewesen. Ich kommentiere das Ganze nur mit einem breiten Grinsen — die meisten Leser sollten wissen, was ich damit meine.

In den letzten Tagen ergab es sich, dass die öffentliche Betaphase von Instacast (Mac) gestartet wurde. Nach recht kurzer Zeit mit Instacast 2 , bin ich ja eigentlich auf Downcast gewechselt (ich berichtete davon). Eines vorweg: Ich bin jetzt wieder Instacast-Kunde.

Nachdem die Beta also zugänglich war, habe ich mir das Ganze natürlich angeschaut. Öffnet man das Programm findet man das fast klassische 3-spaltige Layout vor. Mit den Bedienelementen im Kopfbereich wirkt es in etwa wie eine Kreuzung aus Apple Mail und iTunes. Es wirkt alles sehr aufgeräumt und übersichtlich. Grundsätzlich sind alle wichtigen Bedienelemente vorhanden. Hervorzuheben ist hier, dass man den Soundausgang unabhängig vom System wählen kann. Ansonsten ist ein schneller Zugriff auf die Kapitel möglich. Zusätzlich lassen sich auch noch Playlists erstellen, welche ich allerdings nicht nutze. Ebenso lassen sich Inhalte an andere Programme weiterleiten (Safari-Leseliste etc.) und teilen (u.a. auch App.net, was in der iOS Variante leider noch nicht möglich ist). Was ich hier etwas eigenartig fand, war das die Optionen schon alle eingestellt waren, obwohl keine Accounts hinterlegt waren. Das macht nur mehr oder weniger Sinn. Die Syncronisierungs-Funktionen machen alle einen recht soliden Eindruck. Ich nutze die Software auf zwei Devices und meinem Rechner. Bisher ergaben sich keine Probleme.

Was mir noch fehlt, ist eine Funktion, welche noch X Minuten den Podcast abspielt und danach den Mac schlafen legt. Etwas vergleichbares ist in der iOS Variante bereits vorhanden. Ansonsten verhält sich die Software ähnlich zur iOS Variante. Daher verzichte ich darauf alles zu bebildern und ausführlich zu beschreiben.

Die Software ist aktuell (zeitlich limitiert) kostenlos, kann aber schon für knapp 15€ gekauft werden. Es ist also abzusehen, dass sie irgendwann kostenpflichtig werden wird. Zusammen mit den aktuell 4,50€ für iOS Varianten kann man mit knapp 20€ ein volles Podcast-Client-Paket erwerben. Da ich die Multiplatform-Verfügbarkeit von Software sehr bejahe, habe ich mir das Paket auch gekauft und gebe dem Ganzen eine weitere Chance. Ich hoffe, dass die Software regelmäßige Updates erfährt und nicht wie Instacast 2 irgendwann einfach gestrichen wird. Der aktuelle Update-Zyklus lässt allerdings gutes verhoffen. Wer also ein ähnliches Problem hat wie ich, bzw. einen guten Podcast-Client für den Mac braucht, kann hier getrost zugreifen. Obwohl die Software bisher nur in einer Beta-Version verfügbar ist, stellt Instacast für mich nicht nur den besten OS X Client dar, sondern zusammen mit den iOS Varianten, aktuell DAS Paket in Punkto Podcast-Clients dar.

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!

ADNCC API Version 0.7b

This post only describes changes compared to ADNCC API Version 0.6b. Further details can be found here. Additionally a first version of the promised search engine is out and can be found here.

Changes

There were several changes made for this version, so here is the most important one: no filters will be ignored randomly anymore. This means the API can now be used with so many filters as 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.

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.