Conversatie beginnen

Het begon met een redesign


Zoals aangekondigd in de vorige blog post was het plan om te beginnen met het opfrissen van de look & feel van mySportsplanner.com. Hiermee zijn we voortvarend begonnen. Er zijn prachtige nieuwe ontwerpen gemaakt die de site echt weer 2018 maken.

Het kostte ons veel moeite niet even snel een paar verbeteringen door te voeren. De reden dat we dit niet gelijk wilden doen was omdat het redesign van de site al even wennen zal zijn voor de gebruikers, laat staan nieuwe functionaliteiten toevoegen of de user interface omgooien. De actuele stand van zaken heb kunnen je zien op test.mysportsplanner.com, waarop veel feedback gegeven is. Waarvoor nogmaals dank!

Ik loop al bijna 20 jaar mee in de internetwereld en heb regelmatig van dichtbij meegemaakt dat het opnieuw opbouwen van een site altijd pijnlijk is en langer duurt dan verwacht. Dit probeer je dus eigenlijk altijd te voorkomen. Maarja, in sommige gevallen moet je toch dingen van de grond af aan opnieuw opbouwen. Technologien verouderen en niet zijn meer onderhoudbaar en/of schaalbaar. Anderzijds kan het zijn dat je dubbel werk moet doen voor eenvoudige aanpassingen, terwijl een rebuild dit kan voorkomen.

Voorgaande is het geval bij mySportplanner. Ik zal een korte uitleg geven van ons development proces de keuzes daarachter. Zoals gemeld in de vorige blog post was de volgorde van actie’s eerst een redesign doen, gevolgd door een responsive webite (desktop, tablet en mobiel) te bouwen. Op het moment dat de designs geimplementeerd werden in bestaande codebase ontstond al snel het gevoel dat we dubbel werk aan het doen waren. Immers als je direct hierna een responsive site wilt ontwikkelen ontkom je er niet aan back-end onderdelen nieuw te schrijven.

Er is nog even gedacht om de huidige mobiele site, m.mysportsplanner.com, hiervoor in te zetten. Voor beide site’s gold dat de “technology stack” eigenlijk best verouderd was. 

Voor de techneuten onder ons, de site draaide op “Classic ASP” en een verouderde versie van het DotNet framework. De database draait op SQL server, deze is eigenlijk prima en verricht het zware werk. Met dit in het achterhoofd hebben we goed nagedacht wat wijsheid was. Gaan we voor snelheid of kiezen we voor een oplossing die “future proof” is, maar wel langer duurt. Gezien de plannen voor een app, white label versie en een api hebben we gekozen om toch de back-end te herschrijven en gelijk met een responsive website live te gaan en de stap van het redesign over te slaan. In eerste instantie vond ik dit jammer, maar nu dat we lekker bezig zijn zie je dat er mooie dingen gebouwd worden. 

Misschien is het leuk om een kleine indruk te geven van de technology stack waarmee we bezig zijn.

We hebben gekozen om een API te bouwen in Go. Deze API wordt het kloppende hart van alle mySportsplanner applicaties (website’s, apps, white label, externe developers, etc..). De API komt AWS te draaien en gaat gebruik maken van een Postgres database. Voor authenticatie gaan we gebruik maken van Google Firebase, dit geeft ons de mogelijkheid om snel te developen en ook eenvoudig “social login” aan te sluiten. De website’s zelf worden gebruikers van de API en wordt gebouwd Vue js en bulma.io als CSS framework. Kortom een gave selectie software. Je kunt de voorgang volgen op staging.mysportsplanner.com. We zijn van plan om over 2 maanden live te gaan.

Ik hoop dat je nu een beter beeld hebt wat er achter de schermen gebeurd. En ook nu geldt, laat wat van je horen als je vragen/opmerkingen hebt.

Bestanden kiezen of sleep bestanden hierheen
Was dit artikel nuttig?
Ja
Nee
  1. Aart

  2. Geplaatst
  3. Geüpdatet

Opmerkingen