Mobile project management

Een term die wij anno 2017 nog niet veel horen is mobile project management. Google er maar eens op, en je ziet met name zoekresultaten die dan betrekking hebben op een specifieke software applicatie waarmee je een mobiele applicatie tot stand kunnen brengen. Wat komt er eigenlijk allemaal bij het realiseren van een mobiele app kijken?

Enerzijds is het niet zo gek dat we nog weinig van specifieke ‘mobile project managers‘ horen, omdat de werkzaamheden die bij dergelijke rol horen (hierover later meer) op dit moment veelal worden uitgevoerd door online project managers binnen bijvoorbeeld een organisatie of webbureau. En, ik kan het niet vaak genoeg zeggen, maar hoewel bijna iedereen continu met zijn of haar mobile device (dus smartphone of tablet) in de weer is, lijken we in Nederland toch wat achter te blijven met de acceptatie van mobile apps en mobile marketing. Historisch gezien loopt Nederland vaak voorop in West Europa als het gaat om het adopteren van nieuwe techniek, maar ook van nieuwe muziek. Menig Amerikaanse of Britse band is éérst in Nederland bekend geworden, alvorens de rest van Europa in zag dat de band in kwestie érg goed was. Zo ook met techniek. De meest innovatieve startups en applicaties komen uit USA en Groot Britannië, en waaien via Nederland over door naar de rest van Europa.

Waar Amerikanen en Engelsen al ver gevorderd zijn met zaken als ‘mobiel betalen‘ en ‘mobile marketing‘, blijven we hier maar achter de feiten aanlopen, en zijn we vooral bezig met ‘online marketing’. Een discipline waarmee ik zelf al meer dan 10 jaar geleden in aanraking kwam: enkele bedrijven liepen al voor de muziek uit, en waren bezig met allerlei SEO en SEA campagnes. Het vreemde is, dat we allemaal kunnen zien dat internetconsumptie op mobiel elk jaar weer met sprongen omhoog schiet en dat de verkoop van desktopcomputers en diens internetgebruik stabiel blijft of zelfs afzakt in bepaalde branches, doelgroepen en toepassingen, maar dat we mobiel maar links laten liggen. Ik ben er achter gekomen dat dit geen bewuste keuze is, maar dat men doorgaans niet weet waar men moet beginnen.

In de praktijk heb ik vaak uitgelegd dat het ontwerpen, het ontwikkelen en de marketing voor een mobile device wezenlijk anders is dan voor een desktop-omgeving. Om het begrijpelijk te houden en niet te diep in de technische verschillen te duiken, hierbij een aantal punten die het onderlinge verschil tussen online en mobile duidelijk maken. Sommige punten zullen misschien voor een gebruiker als een open deur klinken, maar ga je een mobile app (laten) realiseren, dan zijn deze punten wel van cruciaal belang om rekening mee te houden:

1. Een ‘mobile’ gebruiker kan een gebruiker zijn op een smartphone maar ook op een tablet; het ontwerpen voor een smartphone is wezenlijk anders dan voor een tablet. Het scherm is op een smartphone is kleiner, dus moet je alleen de homepage bijvoorbeeld al een andere indeling geven;

2. Een smartphone of tabletgebruiker heeft geen muisbediening. Dat betekent dat je geen linker- of rechtermuisknop bediening hebt binnen een applicatie, of de mogelijkheid om een mouse-over te ontwerpen (een button die verkleurd als je er met de muis op gaat staan), maar dat je rekening moet houden met ‘vegen/swipen’ van een pagina, dat je met één vinger één of twee of zelfs drie keer kunt klikken, je kunt in- en uitzoomen met twee vingers, etcetera;

3. Het recenseren van een website kán wel, maar wordt maar weinig gedaan. Mobiele applicaties echter wel: veel apps die in de Google Playstore en in de Apple App Store staan, ‘dwingen’ je soms lichtelijk om een review te geven in de betreffende app store;

4. Bij het technisch realiseren van een mobiele applicatie, sta je voor de keuze of je een hybride of  een native app maakt. Kies je voor het laatste, dan zul je twee keer moeten investeren in de  technische ontwikkeling van de app in kwestie, omdat het ontwikkelen voor het Android-platform wezenlijk anders is dan voor het Apple iOS platform. Op internet zijn vele voor- en nadelen te vinden tussen hybride & native apps, zoals bijvoorbeeld dit artikel op Frankwatching of Emerce;

5. Indien de mobiele applicatie is ontwikkeld en hij is klaar om te presenteren aan de opdrachtgever, dan moet je compleet andere handelingen verrichten dan het tonen van een website. Bij een website richt de webdeveloper of het internetbureau een afgeschermd gedeelte in, waar alleen jij als klant terecht kunt. Bij een mobile app moet je de opdrachtgever de instructie geven om een applicatie als Testflight of Crashlytics te installeren, om vervolgens na enkele handelingen de demo-versie van de app op zijn of haar eigen toestel te installeren;

6. Indien de mobile app uitgecorrigeerd is door het mobile bureau in kwestie, dan moet deze naar de betreffende app store ‘gebracht’ worden. Gaat de app onder naam van het bureau in kwestie de app store in, of wil de opdrachtgever dit onder diens eigen bedrijfsnaam publiceren?
Dit laatste is gangbaar, maar dan moet je er wel voor zorgen dat de opdrachtgever in bezit is van een Apple en/of Google Android ‘developers’ account. In beide gevallen betreft dit een soms wat omslachtige registratie;

7. Voor de mobile app moet er vervolgens nog goed nagedacht worden over een titel, een omschrijving en screenshots van de mobiele app die de app ondersteunen in de app store. Is de app meertalig opgezet, dan moet deze omschrijving in meerdere talen worden aangeleverd en bij de app worden geplaatst;

8. Bij een update van een mobile app, moet de vernieuwde versie opnieuw naar de app store worden gezet, en krijgt de app gebruiker een update notificatie. Dit kan ook commercieel handig zijn, om zo te tonen dat er continu aan de app gewerkt wordt;

9. Is er sprake van een mobile waarbij de klant zélf de content kan beheren, dan moet er nog een online applicatie ontwikkeld en opgezet worden waarmee de opdrachtgever in een beheeromgeving de content in de app kan plaatsen;

10. Indien er een nieuw type iPhone bijvoorbeeld op de markt komt, dan moet een mobile bureau al haar apps nalopen om te kijken of alles nog werkt en het ontwerp bijvoorbeeld nog beeldvullend en correct is. Gelukkig krijgen mobile bureau’s de beta-versies van de besturingssystemen ver voordat een gebruiker deze update krijgt, en kunnen de uitgebrachte apps dus intensief getest worden op het nieuwste besturingssysteem.

Dit waren zo even 10 punten die mij zo te binnenschoten, maar er zijn nog wel andere punten die het realiseren van een mobile applicatie anders maken dan een online applicatie.

En, misschien wel één van de belangrijkste zaken waar je rekening mee moet houden:
een mobile gebruiker is kritisch; vaak worden grote bedragen geïnvesteerd in een smartphone of tablet, en is men zuinig op het toestel in kwestie, en worden ze intensief gebruikt. Dat betekent dat een mobiele applicatie ook op alle fronten goed doordacht moet zijn, en qua ontwerp en ontwikkeling geen steken moet laten vallen. Veel meer dan bij een website, moet je bij een mobiele applicatie het hebben van de eerste indruk. Lijkt de app niet gelijk te voldoen aan de kritische eisen van de mobile gebruiker, dan wordt de app verwijderd en misschien wel nooit meer geïnstalleerd. Ook al heb je na deze app verwijdering diverse updates doorgevoerd; menig gebruiker zal zich na een tijd nog herinneren: “Oh, díe app? Die is heel slecht. Die heb ik er gelijk weer afgegooid”, terwijl je misschien al je budget en effort hebt gestoken in nog 8 nieuwe versies. Het kán al te laat zijn.

Ben je voornemens een mobiele applicatie te laten ontwikkelen? Denk dan goed na over bovenstaande punten, en wat (ja ja, daar gaan we weer met het cliché) het doel van je applicatie is? Wat en wie wil je bereiken? Wat is de toegevoegde waarde van de mobiele appliatie ten opzichte van andere uitingen die je hebt?

Meer informatie over ‘alles op gebied van mobile‘ ? Neem gerust eens contact met mij op bij vragen over mobile design, mobile development of mobile project management.

Christian van Ekeris | eigenaar van 24 Brick Lane & Black Rooster
telefoonnummer 06-39511409 of cvanekeris@24bricklane.nl