Het Algoritme van de App Store

Een goed idee, een goede App. Weinig waard zonder de juiste posities in de App Store of heel simpel gezegt, zonder gevonden te worden. Ook hier ligt de macht de rankings uit te delen net als bij Google bij een algorithme.

developent appstore

Wat weten we wel over het algorithme van de App store? Het algorithme bestaat net als dat van Google uit veel onbekenden. Een paar onderdelen ervan kennen we echter wel ook zijn ze vrij voor de hand liggend. Ten eerste weten we dat er een gemiddelde van het dagelijks aantal downloads mee wordt gerekend, of bij de betaalde apps van de dagelijkse sale, wat ook weer vanuit het aantal downloads kan worden afgeleid. Bij de ranking zoals deze in de App store te zien is wordt er met de 4 voorafgaande dagen rekening gehouden, alle dagen daarvoor wegen bijna niets. Hier wordt een weighted average methode toegepast en de downloads worden gemeten aan de totale gemiddelde downloads en sales in de hele appstore. In het weekend is dat dus hoger dan op werkdagen. Een zondag met het dubbele aantal downloads betekend dus niets voor de rank van een app als dat ook voor de hele appstore geldt. We hebben het nog steeds over de rating, voor de adverteer inkomsten is dat natuurlijk juist heel goed.

Voor het gedeelte van “Meest opgebracht” in de app store weten we ook dat applicaties niet op basis van verkochte eenheden maar op basis van revenue gewaardeerd worden. Dat is te danken aan EA Sports die bij Apple zijn gaan klagen dat het oneerlijk is dat “indie-developers” ook 10$ vragen voor een minder goed spel en daar een veel hogere revenue uithalen vergeleken met EA die dus volgens zichzelf hogere kwaliteit leveren maar daardoor minder winst overhouden. Sinds EA één van de grotere partijen is die voor Apple winst genereerd door advertenties werd daar ook meteen gehoor aan gegeven.

In maart 2012 is de laatste en grote wijziging in het algorithme van Apple doorgevoerd. Dit was duidelijk te zien aan het voorbeeld van China, waar de meeste 5 sterren ratings van derde partijen worden ingekocht. De wijzigingen in het algorithme zijn altijd bedoeld om de “cheaters” er uit te halen. In het voorbeeld van de developer Koram Game uit China zijn ze met hun spel Feng Wan Three Kingdoms van de 4e naar de 335e plek gezakt. Ze hadden 302 5-sterren reviews en 51 reviews met 1 ster, tussenin bijna niets. Dat is dus als onnatuurlijk door het nieuwe algorithme herkend en eruit gegooid. Hele marketingkantoren hebben duizenden downloads en 5 sterren ratings voor klanten genereert zonder dat de apps ooit geopend zijn. Deze praktijken wordt sinds het nieuwe algorithme nu flink tegengewerkt.

Er zijn ook geruchten dat de “frequency of usage” bij zal gaan dragen aan de ranking in de App Store. Lokken met een gratis maar slechte app die snel niet meer gebruikt zal worden zou dus wel de downloads omhoog jagen maar weinig invloed op de rankings hebben. Dit zou voor Apple moeilijk doorvoerbaar zijn gezien de frequentie van gebruik veel met de inhoud en aard van een app te maken heeft. Hierdoor zouden vooral weer, nieuws en verkeers-apps dus een duidelijke voordeel hebben gezien ze het vaakst geopend/gebruikt worden. Maar ook dit is natuurlijk met een slim genoeg algorithme makkelijk recht te trekken. Denk hierbij aan het scannen van keywords en tags, de categorien, etc. Duidelijk is dit ook heel aantrekkelijk voor adverteerders gezien dan in een oogopslag duidelijk zou zijn welke apps vaak gebruikt worden.

Uiteraard zijn er inmiddels ook App Store Optimalisatie (ASO) bedrijven opgedoken die net als bij zoekmachine-optimalisatie proberen de klant hoger in de resultaten te pushen. Er worden belangrijke key points genoemd waar het op aankomt: KEYWORDS, NAMING, DESCRIPTION, SCREENSHOTS, VIDEO, PRICING, RATING AND REVIEWS.

Keywords is hier equivalent met zoekwoorden in de SEO, bij naming lijkt een recht toe recht aan naam zoals iFitness of Shooter meer kans op succes te hebben dan ver gezochte namen die niet in de titel al een indicatie geven wat van de app verwacht kan worden. In de Description die catchy en duidelijk moet zijn horen dan ook weer de relevante keywords terug te komen. De screenshots duidelijk, clean geen verwarrend menu met teveel keuzes tonen, probeer de app door maar 3 screenshots een uitstraling te geven. Laat door een Video aan de gebruiker zien dat de App zijn geld waard is en trigger daardoor oog een goede review. Pricing is een belangrijk punt gezien de 0.79€ apps voor velen “geen geld” is, dus de kans dat ze de app downloaden, amper tijd instoppen en dan een 1 sterren “waardeloos” review geven is hoger. Door de App iets boven de 1€ grens te plaatsen blijven deze gebruikers vaak weg oftewel ze nemen de tijd en denken iets langer over een review na. Rating en review legt zich zelf uit.

Vanuit privacy overwegingen zal er de komende maanden nog enorm veel aan het algorithme gewerkt worden. Er zijn op dit moment nog te veel apps die telefoonboek en creditcard gegevens uitlekken daar zal snel verandering in komen. Needless to mention dat Apple niet op al deze geruchten reageert dus zal men er alleen door meten en testen achter kunnen komen of het waar is.


User Experience

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.
user interface
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.


Het belang van leesbare code

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!


Het uitwerken van een idee

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:

App idee

• 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 MonoTouch

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.


Appontwikkelen.nl

  • Een app laten ontwikkelen?

  • App Ontwikkelen op Twitter

    View more tweets

  • Copyright © 1996-2010 App ontwikkelen kun je leren!. All rights reserved.
    Linklist | Contact                                         Jarrah theme by Templates Next | Powered by WordPress