#development (9)

Seite 1 von 1

Aktuelle App-Entwicklungen

Ich hatte es in der letzten Woche schon kurz und kryptisch auf Mastodon und Bluesky1 angekündigt – nachdem ich mich beim Schreiben des Wortes „Links“ zugunsten von „Lonks“ verschrieben hatte und dachte, hey, wenn ich eine Link-Sammel-App rausbringen würde, sollte diese Lonks heißen; Lonks und Yonks, das würde sich hervorragend im Lebenslauf machen –, dass ich gerade an einer neuen iOS/iPadOS-App arbeite, die wir demnächst im kalifornischen Bergwerk einreichen werden.

Es handelt sich um ein kleines, wie wir finden feines Tool für Web-Designer und -Entwickler, von dem man sich fragt, warum es das nicht schon immer gab, nachdem man es einmal gesehen und genutzt hat. Spitze Zielgruppe mit spitzem Use Case, aber überaus interessant. Für die Moneta­risierung planen wir (derzeit) Freemium ein: Die App kann komplett kostenlos genutzt werden, es gibt eine inhaltliche Einschränkung, die mit einem Einmalkauf (≠ Abo) freigekauft werden kann. Genau das plane ich derzeit übrigens auch für Yonks 2.0 ein, siehe meine ersten Gedanken dazu hier. Bei einer bestehenden und dann auch noch auf Android verfügbaren App gestaltet sich das allerdings deutlich schwieriger, als bei einer frischen Apple-only-App.

Und speaking of Apple: Es gibt zwei, drei Voraus­setzungen und Funktionen, die das Unterfangen zum Scheitern bringen könnten. An einer Stelle umgehen wir App-Store-Beschränkungen, was andere aber auch machen. Nur sind das eben Namen wie Google. 🙈 Woanders gibt es eine CLI, die optional auf dem Mac installiert werden kann und die dann mit der App kommuniziert, was ehrlicher­weise Neuland in unserem ansonsten sehr erfahrenen App-Review-Game ist.

Also schauen wir mal. Die App ist bereits zu 95% fertig, ich arbeite aktuell nur noch am Polishing und Testing der CLI. Der Plan ist, die App schnellst­möglich einzureichen, um die Unklarheiten in Bezug auf’s Bergwerk alsbald zu klären, gleich­zeitig dem Bergwerk aber auch zu signalisieren, dass das hier kein Wochenend-AI-Slop ist, unter dem es gerade leidet. Daher das Anti-MVP-Polishing.


Weiter erweitern wir auf vielfachen Nutzer­*innen­wunsch und nach Rück­sprache mit den Kolleg­*innen von awork, unserer Projekt­management­software der Wahl, gerade die von uns entwickelte awork-Raycast-Extension, so dass diese fortan auch direkt aus Raycast heraus Tasks erzeugen und bearbeiten kann. Raycast-AI-Support inklusive. Sollte in den nächsten Tagen released werden, was ihr dann natürlich auch hier erfahrt.


Und weil Nischen unser Ding sind, haben wir uns eine weitere gesucht und nicht ein, nicht zwei, sondern gleich drei Stücke Software dafür ge­schrieben. Die Vor­gespräche sind alle erfolg­reich gelaufen, jetzt folgt das Store-Review in diesem Nicht-Apple-/Google-Kosmos.

Spoiler: Wir haben u.a. einen Feedreader gebaut, aber anders als man denkt. Normaler­weise eher etwas, das unter dem „eay“-Dach und nicht bei Hypercode zuhause wäre, aber einfach­heits­halber ver­öffentlichen wir es jetzt im Firmen­kontext. Ich hab’s aber alleine und nur für mich gebaut. 🤓 Sobald das so weit ist, steht es ebenfalls hier.


Und dann, last but not least, habe ich mir im Urlaub eine kleine Health-App gebaut, die ich so und/oder für bezahlbares Geld bisher nicht gefunden habe. Funktioniert wunderbar und ist im täglichen Einsatz bei mir. Aber ob ich die Zeit finde, das für eine Ver­öffentlichung fertig zu machen, bleibt abzuwarten.

Es gäbe schließlich noch genug zu tun, z.B. shortfil.ms zu aktualisieren. 😅


So oder so: Wenn was gezeigt werden kann, werde ich es zeigen. Die Micro-Apps-Blogserie von Matt Birchler, in der er kleine Anwendungen für über­schau­bare, meist private Zwecke gezeigt hat, hat mir nämlich gut gefallen.

  1. Weiterhin Indigo, siehe Fußnote 1 hier. []

It’s more than just the words

As we move our code to CodePen, our writing to Medium, our photographs to Instagram we don’t just run the risk of losing that content and the associated metadata if those services vanish. We also lose our own place to experiment and add personality to that content, in the context of our own home on the web.

Rachel Andrew möchte dieses Jahr nicht nur Inhalte zurück auf ihre Webseite holen, sondern auch den Kontext gestalten und neue Technologien auf ihrer Webseite ausprobieren. Guter, nachahmeswerter Vorsatz.

SWAPI, The Star Wars API

The Star Wars API will provide a RESTful API for Planets, People, Starships, Vehicles, Species and Films from the six major Star Wars films.

Paul Hallett, der im Oktober 2013 bereits die Pokéapi, eine RESTful API für Pokémon-Daten gebaut hat, veröffentlicht demnächst eine API mit Star Wars-Daten. Um Konflikte zu vermeiden werden sich die Datensätze zunächst ausschließlich auf den neuen Disney-Kanon beziehen und natürlich irgendwann »The Force Awakens« beinhalten, schreibt Hallet im Blogeintrag zur SWAPI.

Ich kann’s kaum erwarten, damit rumzuspielen und begrüße einen weiteren Schritt in Richtung „APIs für alles und jeden“. (via Kottke, der derweil zusammen mit Matt Webb überlegt, wie gut Open Source Franchises wären)

Update, 23.12.2014: Die API ist nun online, hier die Dokumentation.

shortfil.ms – meine neue Kurzfilmplattform

In der vergangenen Woche habe ich den ein oder anderen auf Twitter mit meinem täglichen Countdown zum #SecretNewProject in den Wahnsinn getrieben. Gestern Nachmittag Abend hatte das Rätseln und Warten dann ein Ende und wir konnten endlich das Projekt, an dem wir die letzten Wochen gearbeitet haben, uraufführen: shortfil.ms, eine neue Plattform zum Entdecken und Schauen von Kurzfilmen!

Die Idee dahinter ist einfach, wie es so schön in unserer Pressemitteilung heißt1:

Die Idee dahinter ist einfach: Es gibt eine Unmenge guter Kurzfilme, von denen niemand weiß. Hier kommt shortfil.ms ins Spiel. Das Team dahinter trägt die ungesehenen, kleinen (Meister-)Werke zusammen und vereinfacht den Zugriff für Film-Fans. Neben der Möglichkeit die Kurzfilme nach Genre, Regisseur, Sprache oder Herkunftsland zu durchstöbern, kann sich der Nutzer zudem auch vom Discovery-Tool auf der Startseite überraschen lassen. Dazu gibt er einfach ein, wie viel Zeit er hat, welches Genre er gerne sehen möchte und shortfil.ms liefert ihm einen zufälligen, sehenswerten Kurzfilm, der zu seinen Eingaben passt. Mit einem Klick lässt sich der Film gleich auf shortfil.ms abspielen.

Das ganze funktioniert natürlich auch auf mobilen Endgeräten, um auch in der Bahn oder im Wartezimmer genutzt werden zu können. Denn eigentlich sind Kurzfilme ja das ideale Medium um trotz verkürzter Aufmerksamkeitsspanne (I’ve been there!) artgerecht unterhalten zu werden. Bisher ist es halt nur nicht so einfach, gerade dann gute Kurzfilme eines bestimmten Genres zu finden, wenn man sie braucht.

YouTube und Vimeo lassen sich nur mehr schlecht als recht durchstöbern. Hervorragende Kurzfilm-Blogs (Short of the Week, das Netzfilmblog) und -Blogger (allen voran Sascha, Ron und Marco) posten zwar immer wieder ausgewählte Perlen, aber ich wollte mehr. Ein irgendwann gigantisches Archiv an Kurzfilmen, durchsuchbar nach Metadaten aller Art. Eine Art IMDb oder „Netflix für Kurzfilme“, um es mit den Worten meiner Frau zu sagen:

Und diese Idee haben wir in den letzten Wochen umgesetzt.2

Wir, das sind übrigens Peer Bresser, der für unsere Videoproduktion zuständig ist, Sebastian Winand, der als Redakteur fungiert, und ich, Stefan Grund, der für Idee, Konzept und Entwicklung verantwortlich war. Zusammen erweitern wir den Kurzfilmkatalog jeden Tag, so dass ihr auf shortfil.ms immerzu neue, gute Filme zu sehen bekommt.

Es würde uns und mich sehr freuen, wenn ihr euch shortfil.ms anseht und uns mitteilt, was ihr davon haltet. Weitere Follower und Freunde auf Twitter und Facebook 3, wo die zuletzt hinzugefügten Kurzfilme hinsyndiziert werden, sind natürlich auch gerne gesehen. 😀

  1. Für „Die Welt braucht gute Kurzfil.me“, den wortwitzigen Titel der Pressemitteilung, habe ich dann auch gleich noch die Domain kurzfil.me erstanden. Die hat wiederum zuvor mal meinen Bloggerkollegen Gilly und Maik gehört, ohne das ich davon etwas wusste. Zufälle gibt’s! []
  2. Weshalb es hier zwischenzeitlich auch so ruhig war. []
  3. Erfreulicherweise war der meiner Meinung nach ebenfalls recht lustige Username „shortfil“ noch überall zu haben. []

Twitter beschneidet API

Das Twitter-Debakel geht weiter: Twitters Produktmanager Michael Sippey hat einen neuen Blogeintrag verfasst, in dem er auf die bevorstehenden Änderungen der API-Version 1.1 eingeht. Außerdem unterstreicht er nochmal den Ratschlag von letztem Jahr, keine traditionellen Twitter-Clients mehr zu entwickeln. Marco Arment hat das kalifornische Schönsprech „übersetzt“ und unter dem Strich steht da, dass all das, was Twitter vorher großartig gemacht hat, so nicht mehr erlaubt ist. Oder wie Ben Brooks es treffend als Analogie zu Apple formuliert:

…this is the moment in Twitter´s life where they kicked Steve Jobs out of the company and told Sculley to run it.

Der Gedanke in Zukunft ausschließlich bei App.net zu posten und die Inhalte nur noch zu Twitter zu iftttten, verliert jedenfalls zunehmend an Schrecken. In diesem Sinne: Ich bin – Überraschung, Überraschung! – @eay auf App.net.

Profitgier essen Apps auf

Wie wohl fast jeder ernsthafte Twitter-User nutze ich den Service hauptsächlich durch Apps von Drittanbietern (mein Favorit ist seit jeher Echofon). Die vielen guten Clients sind das, was Twitter groß gemacht hat und der (einzige?) große Vorteil gegenüber allen anderen Social Networks. Twitter scheint das aber zunehmend zu vergessen: Im März 2011 legte man externen Entwicklern bereits nahe, keine kompletten Clients mehr zu programmieren (hier der Originalpost von Twitter-Developer Ryan Sarver), gestern wurde Product Manager Michael Sippey dann nochmal konkreter und kündigte an, dass die API-Guidelines in den kommender Wochen verschärft werden. In Twitter-Neusprech liest sich das dann so:

We´re building tools for publishers and investing more and more in our own apps to ensure that you have a great experience everywhere you experience Twitter, no matter what device you´re using. You need to be able to see expanded Tweets and other features that make Twitter more engaging and easier to use. These are the features that bring people closer to the things they care about. These are the features that make Twitter Twitter. We’re looking forward to working with you to make Twitter even better.

Und „bring people closer to the things they care about“ ist dabei nicht viel mehr als eine Beleidigung an jeden nicht vollkommen verblödeten Leser des Twitters Dev-Blogs (also wahrscheinlich alle), denn eigentlich steht da: Die Nutzer näher an die Inhalte bringen, die Twitter interessieren. Und das sind bekanntlich Werbung und der Content von Premium-Partnern, wie bspw. der New York Times, deren Artikel fortan direkt unter einem Tweet angeteasert werden.

Die Beweggründe dafür sind natürlich offensichtlich: Twitter muss Geld verdienen und hat sich irgendwann mal dazu entschieden, das mit Werbung zu versuchen. Und diese spült umso mehr Dollars in die Tasche umso mehr Nutzer sie sehen. Also werden Twitter.com und die offiziellen Apps mit Discover-Tabs und Inline-Werbung zugepflastert. Im Gegensatz zu den Twitter-Clients der Drittanbieter: Klar, hier können Werbe-Tweets reingeschleust werden, aber kann man die Entwickler auch dazu zwingen, so schwachsinnige Funktionen wie eben das Discover-Tab so prominent zu platzieren, wie das in Twitters eigener iPhone-App der Fall ist? Wohl eher nicht. Und wenn ihr nicht für uns seid, seid ihr gegen uns.

Marcel schlägt also zu Recht kostenpflichtige Pro-Accounts vor, deren Nutzer dann nicht mit dem ganzen Werbeblödsinn behelligt werden. Ich würde sogar soweit gehen: Twitter sollte die Nutzung von Drittanbieter-Clients ausschließlich zahlenden Pro-Usern zugänglich machen. So wären (bis auf die Werbeindustrie) alle glücklich: Die Intensivnutzer, Twitters Finanzabteilung und die App-Entwickler. Andernfalls bzw. wenn alles so kommt wie jetzt angekündigt, ist das den Entwicklern gegenüber ziemlich genau das, was Gruber als „dick move“ bezeichnen würde.

Wenn iOS- und Mac-Entwickler Brent Simmons, der Mann hinter Glassboard und zuvor NetNewsWire, nun also eine Twitter-Alternative fordert, ist das überaus verständlich. Wer Dave Winers Blog liest, wird sowieso jeden zweiten Tag mit dem Gedanken konfrontiert. Nach Simmons würde sich eine Art Parallelsystem anbieten, die von den Drittanbietern zusätzlich zum Twitter-Support integriert wird und die auf Basis von RSS und OPML Tweets und Follow-Informationen bereitstellt, ohne dabei eine zentrale Plattform zu benötigen. Sobald das System dann etabliert ist, sollte man den Twitter-Support rauswerfen und Dick Costolo & Co. mit ihren Werbefuzzis allein lassen. Prinzipiell eine gute Idee, auch wenn die meines Erachtens technisch schwierig zu bewerkstelligen ist.1 Hoffen wir also, dass es gar nicht erst soweit kommen muss.

Andererseits: Microblogging wird ja auch total überschätzt. Oder um es nochmal mit Grubers Worten zu sagen: „Twitter = Jackass of the Week“

  1. Der RSS-Feed müsste irgendwo gehostet werden (von einer dahinter liegenden Datenbank, die als Archiv für die eigenen Statusmeldungen – formerly known as Tweets – fungiert, mal abgesehen). Und das könnte dann wiederum der eigene Webspace sein (und würde unsere Eltern somit ausschließen), der einer zentralen Plattform (herzlichen Glückwunsch, you created the next Twitter!) oder direkt auf Servern der App-Entwickler passieren (eigentlich gut, nur was ist, wenn der App-Entwickler pleite geht?) []