App Ontwikkelen kun je leren!

De user experience van je app is heel belangrijk. Het uiterlijk van je app kan dan nog zo mooi zijn. Maar als de gebruiker twintig keer op back moet drukken om weer bij het begin te komen, dan moet je toch is nadenken over de flow van je app.

Daarom geven wij je een aantal tips om de user experience van je app te verbeteren

Tips
De grootste tip die wij je kunnen geven zijn:
- Ontwerp de flow van je app voordat je gaat beginnen met het uiterlijk of de code!
- Teken van te voren de flow van je app uit. Hoe ga je van punt A naar punt B.
- Zorg ervoor dat je niet halverwege tegen problemen aanloopt en dan nog van alles moet gaan wijzigen.

Logica
Verder heeft de user experience te maken met logica en verwachtingen. Denk na over hoe de logica van navigeren in elkaar zit. Het simpelste en de duidelijkste manier is om de gebruiker op rails te zetten, met de optie om verder en terug te gaan. Hierdoor krijg je een overzichtelijke en een lineaire manier van navigeren. Kijk verder naar hoe jij verwacht dat een app zal werken. Als het werkt net zoals andere app’s dan blijft de user experience goed, de gebruiker hoeft dan niet opnieuw te leren navigeren.

Geef elke pagina maar één doel!
Kijk naar de mail app van Apple zelf. De email lijst scherm heeft als hoofddoel het lezen van je email. Je email’s staan duidelijk in een lijst. Je kunt natuurlijk wel andere dingen doen zoals een email gaan schrijven, maar de button hiervoor staat rechts onderin en de nadruk ligt er niet op. Hierdoor voorkom je dat er te veel afleidende knoppen en dingen in het beeld staan.

Ga testen!
Als je uiteindelijk je app hebt gemaakt, is het ook belangrijk dat jij de flow van je app gaat testen. Geef de telefoon aan een aantal personen en observeer hoe hun jou app gebruiken. Het belangrijkste is dat je observeert en helemaal niks zegt. Als jij hele tijd verteld waarop ze moeten drukken leer je niks over de user experience.

Observeren
Waar drukken ze op? Zitten ze ergens vast maar komen er wel snel uit? Of geven ze op?
Als een aantal personen je app hebben gebruikt kun je zien wat je nog moet veranderen.

Conclusie
Begin vroeg met het maken van je flowchart, dit voorkomt problemen halverwege.
Verder denk logisch na over het navigeren door je app. Hoe doen andere app’s het?
Geef elke pagina één simpel doel, zorg voor zo weinig mogelijk afleiding.
Tot slot ga testen! Dan weet je zeker dat de flow van je app goed of slecht is.

Wanneer je als ontwikkelaar aan het werk gaat, komt het vaak voor dat je verder moet met een bestaande codebase. Het duurt dan niet lang voordat je erachter komt dat het schrijven van leesbare code belangrijker is dan je hiervoor dacht. Is het niet voor jezelf dan is het wel voor de ontwikkelaar die na jou wellicht met jouw code verder moet.

Het probleem.
Het is bijzonder frustrerend wanneer jij functionaliteit van een applicatie moet aanpassen in haastig en rommelig geschreven code. Je bent erg veel tijd kwijt aan het begrijpen van de code. Waar moet wat aangepast en waar kun je je stuk code plaatsen?
Methodes staan door elkaar heen en de enige manier om door de code heen te komen is door de Goto definition functionaliteit van je IDE. Na eindelijk de methode te hebben gevonden waar de aanpassing moet plaatsvinden, lijkt die ook nog eens onleesbaar. De meest uitgebreide genestte lussen, inconsistent gebruik van accolades, regels van 160 karakters, onbegrijpelijke variabele namen, en het chainen van methodes, inclusief haar parameters. Dezelfde code her en der, veel te lange methodes en de magic numbers vliegen je om de oren.
Het beroep dat er eens zo aantrekkelijk uitzag lijkt nu ineens een stuk minder aantrekkelijk. Jammer, want het kan wel leuk zijn.

Hoe kun je er iets aan doen?
Besteed wat meer tijd aan de opmaak van je code. Lees het blok code dat je net hebt geschreven eens terug, is het relatief eenvoudig te begrijpen voor iemand anders? Verbeter het door bijvoorbeeld grote blokken code op te splitsen in meerdere kleine stukjes en geef zinnige namen aan variabelen.
Houd regels kort, de meeste IDEs hebben de mogelijkheid om een liniaal te plaatsen in je editor. Zet deze eens op 80/100 karakters.
Denk na over de plaatsing van je methodes in je klassen, hoort deze methode wel waar zij staat? Of moet deze in een andere klasse.
Denk na over de structuur van je code en als je met een framework werkt, houd zoveel mogelijk haar structuur aan. Werk je al in andermans code? Probeer dan te begrijpen hoe deze is opgebouwd en zorg dat jouw aanpassingen daar zoveel mogelijk bij aansluiten. Hoe vervelend dat soms ook is, wijk zo min mogelijk af van de stijl van de codebase waar je in werkt.
Maar het belangrijkste blijft toch consistentie, heb je voor een bepaalde stijl gekozen, houd je daar dan ook aan.

Concluderend
Denk na over je code en hoe het eruitziet. Wees consistent. Meer lezen? Google de term Code Readability eens.
Succes!

Iedereen heeft wel eens het moment van, “daar zou een app voor moeten wezen”. De meeste mensen vergeten dit kort erna, maar wat als je het idee toch wilt uitwerken? Waar moet je dan rekening mee houden? Er komt vaak meer kijken bij het ontwikkelen van een applicatie dan op het eerste gezicht lijkt. Het is goed om voordat je aan de slag gaat, of een bedrijf opzoekt om zelf eens wat dingen op papier te zetten.

Wat is mijn idee?
Het is erg slim om van te voren zoveel mogelijk over je idee op papier te zetten. Je noteert alles wat in je opkomt. Het werkt goed om jezelf vragen te stellen. Voorbeelden van dit soort vragen zijn:

• Wat moeten mensen met mijn app kunnen?
• Welk ‘probleem’ lost mijn app op?
• Wie gaan mijn app gebruiken?
• Waarom zouden mensen kiezen voor mijn app?
• Moeten gebruikers inloggen?
• Hoe kunnen gebruikers inloggen?
• Wil ik er geld mee verdienen?
• Hoe wil ik er geld mee verdienen?
• Wie gaat hem ontwikkelen?

Zo zou je zelf een heleboel vragen kunnen bedenken en beantwoorden. Dit zorgt ervoor dat jijzelf een beter beeld krijgt van de applicatie. Blijf dit ook aanvullen wanneer je met nieuwe vragen komt.

Na aanleiding van je vragen en antwoorden zou je kunnen beginnen met een project-document waarin je zoveel mogelijk vastlegt over je applicatie. Soms helpt het om vrienden en/of familie te vragen wat ze vinden van je idee. Zo kom je er ook achter of er wel vraag naar is. Het zou ten slotte zonde zijn van de tijd en geld dat je zou investeren als alleen jij het idee goed vindt.

Beginnen met ontwerpen van je UI (User Interface)
Je kunt ook alvast beginnen met het ontwerpen van de schermen die de gebruikers gaan zien (vaak mockups genoemd). Deze laten precies zien waar op welk scherm bepaalde informatie wordt getoond. Je zou er ook in kunnen aangeven hoe de gebruiker van het ene scherm naar het andere gaat. Probeer bij het ontwerpen van de schermen terug te vallen op de vragen die je aan jezelf gesteld hebt. Zo zou je de belangrijkste en meest gebruikte informatie gemakkelijk toegankelijk moeten maken door te tonen of bereikbaar te maken vanaf het hoofdscherm.

Probeer te denken in ‘clicks’, hoe vaak moet een gebruiker klikken om bij bepaalde informatie te komen? Probeer ook rekening te houden met wat gebruikers gewend zijn aan hun systeem. Probeer daar eens naar te zoeken op internet.

En nu?
Als het goed is heb je nu een duidelijk beeld van je applicatie. Het is verstandig de ontwerpen toe te voegen aan je project-document. Probeer het te laten lijken op een handleiding, alsof de app al af is. Zo krijgen de mensen die het lezen een goed beeld van de applicatie.
Laat het document nog eens lezen door vrienden/familie/kennissen en luister goed naar hun feedback, zij zouden namelijk je toekomstige gebruikers kunnen zijn.

Ga je de app door een bedrijf laten maken kan kunnen zij je verder adviseren. Soms kan het zijn dat jij denkt dat iets erg goed is, maar wijkt het teveel af van wat gebruikers gewend zijn. Dit is gewoonweg erg riskant, niet alleen voor applicaties, maar ook voor bijvoorbeeld websites. Wat zou je ervan vinden als het menu van deze website rechtsonder in een hoekje staat? Luister naar het advies van Homer J. Simpson: “I can’t wear a pink shirt to work, everybody wears white shirts. I’m not popular enough to be different!”

De realisatie
Je ontwerp is nu af en kan worden uitgewerkt. Je kunt het nu gebruiken als referentie als je zelf gaat programmeren, of als medium om te laten zien aan degene die het voor je gaat maken wat je nou precies wilt.

Door Stephan E.G. Veenstra

Cross platform ontwikkelen met MonoDroid/-Touch van Xamarin

Om een App te ontwikkelen is er de optie om te kiezen om op elk platform native te werken. Dit zorgt vaak voor dubbel werk omdat veel “core” componenten dubbel geschreven moeten worden. Met de core componenten wordt bijvoorbeeld bedoeld met de connectie tussen server – App en de data modellen.

Gebruik maken van een cross platform tool.
Doormiddel van een Cross platform ontwikkeltool te gebruiken zoals MonoTouch kan het werk voor meerde platforms sterk verminderd worden. De kracht van MonoTouch is dat de App grotendeels wordt geschreven in C#. Hierdoor kan er gebruik worden gemaakt van LINQ, anonymous types en lambdas en kan er korter en efficiënter code geschreven worden.

Documentatie van Xamarin
Op de website van Xamarin hebben ze een uitgebreide documentatie opgesteld voor het ontwikkelen van een App. Op deze webpagina zijn veel voorbeelden gegeven hoe je verschillende standaard views kan opbouwen, zodat je een gevoel krijgt voor de taal. Voor de documentatie van Xamarin zie http://docs.xamarin.com. Hierop staan ook een aantal Guides en Tutorials voor het ontwikkelen op Android en iOS en vele andere handige voorbeelden.

MonoDevelop
Om een applicatie met MonoTouch te ontwikkelen heeft Xamarin een eigen IDE ontwikkeld, namelijk MonoDevelop. Deze IDE lijkt erg op Visual Studio maar is tevens ook cross platform beschikbaar, zowel op Windows als OSX en Linux. MonoDevelop is niet exclusief bedoeld om MonoTouch applicaties te ontwikkelen, maar er kunnen ook andere C# projecten mee worden gemaakt.

Snelheid
Omdat mono een cross platform taal is wordt er snel gedacht dat het trager is dan native bouwen, maar dit is niet helemaal waar. Hieronder staat voor Android en iOS een vergelijking tussen Mono en de native compilers.

Android
Op Android wordt er voor het native ontwikkelen gebruik gemaakt door de eigen geschreven compiler van Google, genaamd Dalvik. De ontwikkelaars van Dalvik geven aan dat het zeer snel werkt dat de libraries runtime worden gedeeld tussen alle applicaties. Het punt is dat linux (de OS van alle Android telefoons) dat zelf ook al regelt. Hierdoor is Mono JIT, de compiler van Mono al een stuk sneller. Voor meer informatie over dit onderwerp, al is het een redelijk oud en subjectief artikel, zie http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html

iOS
Op iOS moet MonoTouch pre-compilen naar native code door licentie beperkingen en die worden geforceerd door het besturingssysteem. Hierdoor gebruiken de Objective-C compiler (native iOS) en Mono’s “Ahead of Time Compilation” gebruiken dezelfde LLVM backend voor het genereren en optimaliseren van de binaire code. Dus de resultaten zullen ongeveer gelijk zijn, op wat memory overhead van Mono na.

Nadelen
Natuurlijk heeft ook Mono zijn nadelen. Hieronder volgen een aantal voorbeelden
• Het pakket is duur. Om een pakket voor alleen MonoTouch for Android te kopen is de Enterprise editie al $999,-. Hierdoor is het aanschaffen voor een particulier een grote drempel. Xamarin biedt wel een evaluatie versie aan dat niet compiled naar device, maar alleen naar de emulator.
• MonoDevelop is niet zo goed als Visual Studio. Een voorbeeld hiervan is de tool ReSharper, dat het leven van ontwikkelaar gemakkelijk maakt voor mensen die graag Visual Studio gebruiken, deze is er helaas niet voor MonoDevelop. Tevens wordt Visual Studio veel meer gebruikt en is er dus ook meer online hulp hiervoor.
• MonoDevelop maakt gebruik van Xcode van Apple om interfaces te ontwerpen voor iOS. De integratie tussen MonoDevelop en Xcode werkt wel, maar is niet heel snel. Waardoor het vervelend kan zijn bij het ontwikkelen als Xcode open staat, omdat MonoDevelop bij elke verandering gaat synchroniseren met Xcode.
• Documentatie is nog onder ontwikkeling. Xamarin heeft een uitgebreide documentatie, maar deze is nog wel in ontwikkeling. Een voorbeeld hiervan is dat iOS native voor een UIPickerView een DataSource gebruikt, maar Mono een Model voor de data. De reden hiervoor is niet beschreven in de documentatie van Xamarin.

Conclusie
Al met al is MonoTouch een mooie omgeving om in te werken voor cross platform Apps. Doordat Mono zijn eigen ontwikkel omgeving aanbiedt en native UI componenten gebruikt is het voor een ervaren ontwikkelaar op iOS/Android ook snel te leren. Let wel op dat de ontwikkel omgeven wat eigenaardigheden heeft, maar dat moet niet in de weg staan om een App te ontwikkelen.

Facebook integreren in je app
Anno 2012 doet bijna iedereen mee aan social media waaronder Facebook. Bij het maken van een app liggen daar vele kansen om je app “sociaal” te maken. Daarmee kun je het bereik van je app aanzienlijk vergroten.

Hoe werkt het:
Facebook biedt een krachtige API waardoor jouw gebruikers met slechts een paar klikken hun persoonlijke gegevens kunnen integreren in de app. Voor jouw gebruikers geen lange formulieren en gedoe om in te loggen, vrienden te kunnen vinden, etc. en jij kan vervolgens alle gegevens die je nodig hebt opvragen bij Facebook.

Facebook heeft voor iOS en Android SDK’s ontwikkelt die het mogelijk maken voor developers om gebruik te maken van Facebook. Daarnaast zijn er ook nog third party SDK’s van bijvoorbeeld Microsoft(Windows Phone) en RIM(Blackberry).

Mogelijkheden:
Een opsomming van een aantal mogelijkheden die je app “sociaal” maken:
- Authenticatie
Facebook biedt de mogelijkheid om gebruikers via hun Facebook-profiel snel in te laten loggen. Zo kun jij gebruik maken van hun gegevens zoals bijvoorbeeld e-mail adres en profielfoto. Allemaal zonder bevestigings e-mail etc. Zo is de drempel voor het gebruik van je app een stuk lager.

- Vrienden vinden
Wil je dat gebruikers in je app andere personen kunnen vinden? Dat is voor gebruikers veel makkelijker te regelen via Facebook dan met handmatige invoer.

-Content delen
Facebook gebruikers kunnen vanuit de app content delen die naar hun Open Graph gaat. Dat is een geweldig manier om de naamsbekendheid van je app te vergroten. Gebruikers kunnen het gebruik van jouw app aan elkaar tonen.

Nu het werk
Om gebruik te maken van de Facebook API moet je eerst op Facebook je app registreren. Log daarvoor in op Facebook. Registreer je als developer en genereer op je computer een key hash met Openssl. Met die key wordt je app gesigned zodat Facebook hem kan verificeren.

Registreer vervolgens een Facebook app op Facebook. Elke app krijgt een AppID die je moet gebruiken om vanuit je app de Facebook app te vinden.

Download de relevante SDK voor je app en include die in project. Nu kan je daarop de methodes voor login, loguit, vrienden ophalen, etc. aanroepen. Facebook regelt daarvoor alle UI en verificatie.
Geef bij een login met een parameter de persmissies aan die je nodig hebt voor de gegevens die je wil ontvangen van Facebook. Bij een succesvolle login stuurt Facebook deze gegevens naar jou. Geef als permissies bijvoorbeeld ‘email’ en ‘read_stream’ mee om ook het email adres en de stream van de gebruiker te ontvangen.
Nu kun je Facebook-profielgegevens in je app gebruiken.

Om rekening mee te houden:
Wanneer een gebruiker via Facebook inlogt zal die waarschijnlijk niet alle gegevens zomaar willen delen. Geef daarom duidelijk aan waarvoor je de gegevens zal gebruiken.

Denk eraan dat te veel afhankelijkheid van Facebook niet handig is omdat het zou kunnen dat ze hun service tijdelijk of helemaal niet meer kunnen leveren. Het is daarom aan te raden om naast Facebook andere systemen te hebben waarmee gebruikers je app kunnen gebruiken.