Update 28 mei 2024: Er is inmiddels een nieuwe app. Als lid kun je nu al onze verhalen lezen, luisteren en kijken op één plek, waar en wanneer jij dat wil.

Het is alweer een hele tijd geleden sinds de vorige nieuwsbrief. Ik mocht nog niets verklappen over dat we een aan het maken waren. Tof!

Tenminste, ik vind het heel tof. Het was erg leuk om te maken. Zoals alle wat grotere verbeteringen aan het platform werken we intensief samen met ontwerpbureau Momkai, dat de app heeft ontworpen. En deze keer hebben we voor het eerst ook samengewerkt met internetbureau Q42 om extra kennis te krijgen over het maken van een app.

Die samenwerking met Q42 was extra bijzonder. Naast een aantal geplande sessies over grote vragen hadden we ook een chatkanaal met elkaar voor alle kleine vragen die tussendoor bij ons opkwamen. Zo konden we gemakkelijk nauw samenwerken, alsof het collega’s waren.

In-house vanuit huis

Toen we startten met het bouwen van de app, twintig weken geleden, werkten we net een maand vanuit huis. Dat maakte het wat lastiger om goede gesprekken te voeren over hoe het project technisch op te zetten.

App review van Ernst-Jan: "Zo mooi.... Ik wou dat ik 'm zelf gemaakt had!"
Ernst-Jan, onze CEO, had na de app te hebben aangekondigd ook een review geplaatst.

Vanaf het begin wisten we wel dat we de app in-house wilden maken. We hebben eerder wel projecten gehad waarbij code door externen gemaakt werd, of waar freelancers tijdelijk bijsprongen als wij ergens geen tijd voor hadden. Maar dat zorgde ervoor dat het lastig te onderhouden werd.

Het platform van De Correspondent (de website en nu de app) zien we als een product, niet als een project. Het is nooit af en naast verdere ontwikkelingen moet het ook Dat onderhoud moeten wij uiteindelijk doen, en dan is het heel fijn als je de code goed kent en begrijpt, oftewel zelf hebt gemaakt.

Het betekent ook dat we alle keuzes zelf moesten maken. Welke programmeertaal gaan we gebruiken? Schrijven we een en dezelfde code voor de website en de app of houden we dat gescheiden? (Ik leg graag meer uit in de bijdragesectie.)

Ook hebben we gekozen om Voor het hosten van onze podcasts gebruiken we SoundCloud en we gebruiken hun interface als speler op onze website. Dit betekent ook dat SoundCloud weet wanneer en waar je naar luistert.

Voor de app hebben we dat losgelaten, en hosten we de audio zelf. Binnenkort willen we dit ook op de website aanpassen, zodat je ook daar kunt luisteren zonder door anderen gevolgd te worden.

Onze website verbeteren we vijftien keer per dag, de app maar vijftien keer per... jaar

Het maken van een app dwingt ons tot een nieuwe manier van nadenken over verbeteringen. Op onze website zijn we sinds jaren gewend om door te voeren. Voor de app ligt het tempo van verbeteringen een stuk lager.

Deels komt dit door de techniek. De programmeertalen waarin we schrijven voor de website (php en javascript) kunnen direct door onze servers en jullie computers begrepen worden. Als we snel code moeten aanpassen hebben we dat snel gedaan: van idee tot werkend op de website kost als het nodig is maar enkele minuten.

Voor de app is dit anders en moet de code vertaald worden om bruikbaar te zijn op jullie telefoons. Dit gebeurt automatisch, maar duurt wel ongeveer een half uur. Dat klinkt misschien weinig, maar het maakt directe samenwerking erg lastig. Stel je voor dat je samen met iemand anders werkt in een document, en dat als jij iets tikt de ander het pas een half uur later ziet en feedback kan geven.

Verdere vertraging komt doordat we elke aanpassing die we aan de app willen maken door Apple en Google moeten laten goedkeuren. Dat proces duurt ongeveer een dag. En dat laten keuren mogen we ook nog eens niet te vaak doen, een keer in de een of twee weken is wel het maximum.

Hij rekende fijntjes voor me uit dat we voor de app zo’n vijftien keer per jaar een verbetering in jullie handen kunnen krijgen. Slik.

Ik legde aan onze nieuwe support engineer Teije uit dat we op de website op goeie dagen zo’n vijftien keer per dag een verbetering doorvoeren. Hij rekende fijntjes voor me uit dat we voor de app zo’n vijftien keer per jaar een verbetering in jullie handen kunnen krijgen. Slik.

Dus we zijn nu aan het bedenken hoe we ons maak-, test- en denkproces moeten aanpassen aan die nieuwe werkelijkheid. Blijven we elke verbetering nadat deze af is direct afronden en testen, wat veel tijd kost? Of doen we een keer per week een goeie testronde? En wanneer kan de redactie meekijken? En voor andere developers: blijven we onze favoriete GitHub flow gebruiken of gaan we naar git flow?

Volgende stappen: offline luisteren, bijdragen plaatsen in de app

Nu hebben jullie een eerste versie van onze app. Een dezer dagen komt er een update met wat kleine belangrijke verbeteringen (nadat Apple en Google die hebben goedgekeurd).

Daarna willen we de app verder ontwikkelen met onder andere offline luisteren, mooiere schermen voor collecties, en de bijdragesectie in de app. Maar ook verbeteringen aan het platform als geheel, de website én de app. Laat het weten als je nog ideeën hebt!

Tussendoortjes

Nog wat andere verbeteringen tussendoor:

  • Je kunt de website nu niet meer bezoeken met Internet Explorer, deze browser was zo oud dat het onze ontwikkelingen steeds meer tegenhield.
  • De ‘herinner me later’-functie kun je nu ook gebruiken voor aangekondigde chatgesprekken: we sturen je dan een reminder bij de start van het gesprek.
  • We hebben een foutje opgelost bij het lezen van bijdragen in nachtmodus.
  • En we hebben eindelijk een nieuwe DevOps engineer, welkom Peter-Jan!

Ontvang je deze nieuwsbrief liever in je inbox?