Om iedereen weer up to speed te krijgen, in de vorige 2 afleveringen van m’n blog heb ik verteld waarom ik een app ben gaan bouwen, namelijk om speler statistieken bij te kunnen houden van de pitchers in een honkbalteam. In deel 2 heb ik verteld hoe ik dat gedaan heb. De blogs zijn geschreven over de techniek. Zodat je de sport Honkbal letterlijk naar nulletjes en eentjes kan vertalen.
Door mijn ervaringen op te schrijven en met jullie te delen merk ik dat het project veel meer is gaan leven voor mijzelf. Niet dat ik al bij een tegenslag de handdoek in de ring gooi, maar op zoek ga naar oplossingen en verder wil met het realiseren van de app. Het werken aan dit project heeft me naast kennis van java en appontwikkeling, ook geleerd hoe belangrijk informatie analyse en testen is om tot een succes te komen. En ’t aller belangrijkst is toch wel dat het leuk is om te doen, zo naast je reguliere werk.
Waarde voor spelers en coaches?
Een belangrijke vraag gedurende het ontwikkelen van de app was wat voor waarde heeft de app nu eigenlijk voor spelers en coaches? Toen ik begon was de app bedacht om data op te slaan voor analyses van de coaches. Echter kwamen er aanvullende feature wensen zodat de data ook voor de spelers zelf te raadplegen zou moeten zijn. En verder nog, dat de spelers zelf de data ook moeten kunnen invoeren, bekijken en analyseren. Hierdoor moet je dus de data in een cloud beschikbaar hebben waardoor er een extra proces van gebruikersbeheer noodzakelijk werd. Maar hiernaast ook het proces van synchroniseren van de data en spelers naar alle spelers. Dus dan blijkt dat je er nog niet bent…. Ik had oorspronkelijk een basis opgezet die fors uitgebreid moest worden waardoor ik zijstappen moest zetten om naar ’t hoofddoel te komen en aanvullende kwaliteitsattributen te bepalen in de analyse, bouw en test.
Tijdens het ontwikkelen hield ik rekening met verschillende kwaliteitsattributen zoals “gebruiksvriendelijkheid”, “juistheid” en “veiligheid” . De app moest makkelijk te gebruiken zijn. Zeker ook voor iemand die voor ’t eerst de app gebruikt. De flow door de app moet logisch zijn, vanaf het inloggen, vastleggen van gegevens bij je eigen profiel, data invoeren bij een training of wedstrijd, bekijken en analyseren van de eigen data en het weer uitloggen. Daarbij moet het ophalen en synchroniseren van data over verschillende clients zonder fouten gebeuren. Je wilt tenslotte geen vervuiling of nog erger data kwijtraken. Wat ik ook in ’t achterhoofd had was de “veiligheid” . Welke minimale set aan gegevens heb ik nodig om de app veilig te laten functioneren? En kan ik gebruikmakend van een cloudoplossing een deel van ’t gebruikersbeheer en veiligheid aan de cloudoplossing overlaten? En tenslotte, misschien wel ’t aller belangrijkste, de app moet voor de gebruikers nuttig zijn om de data te kunnen bekijken en hun sessies te analyseren vertaald in het kwaliteitsattribuut “gebruiksvriendelijkheid”. Met deze uitgangspunten ben ik aan de slag gegaan.
Hoe creëer je bruikbaarheid en dus ook waarde voor de gebruikers?
Als voorbeeld toon ik hieronder het opvoeren van trainingsdata.
Bij het opvoeren van data krijg je een scherm te zien waar je verschillende parameters kan vastleggen tijdens een sessie.
- Je moet eerst een speler selecteren voor wie jij de sessie gaat bijhouden,
- Je kiest of het een training of een wedstrijd betreft,
- Je kiest welke pitch gegooid is,
- Wat is het resultaat.
Dat doe je door middel door het schuiven van een ‘bal’ welke je naar de plek waar deze bij de catcher is aangekomen. Het groen omrande vakje is om de slagzone aan te geven, de plek waar een scheidsrechter een geworpen bal slag geeft. Daarbuiten heet het wijd. Tenslotte als je dat tijdens de sessie meet, voer je de snelheid van de pitch in. Het plaatje hieronder zie je als je voor ’t eerst het scherm opent.
Je kan daarna kiezen of de sessie verder gaat (OK + NEXT),dit de laatste worp in de sessie was (OK + FINISH) dan wel alles wat ik opvoerde was niet goed, reset ’t scherm maar door een druk op CANCEL. Na kiezen van OK + FINISH wordt alle data naar de cloud gestuurd.
Kwaliteitsattribuut 'Juistheid'
Bij het opslaan komt het kwaliteitsattribuut “juistheid” om de hoek kijken. De data die opgevoerd wordt moet op de juiste manier opgeslagen worden en later over de verschillende clients weer gesynchroniseerd zijn omdat je anders hele verkeerde analyses aan het doen bent. Om analyse te bevorderen voegde ik een scherm toe waar grafisch de locaties en resultaat van een sessie worden getoond.
Hieronder een voorbeeld van een pitch:
Wat het scherm je laat zien is dat de eerste pitch (Pitchnr: 1) van het type Cutter (type fastball) was. En dat het resultaat van de worp een strike (slagbal) was. Tevens kan je aan de rode stip zien waar de persoon die de sessie vastlegde beoordeelde waar de bal terecht kwam. Was bij deze sessie ook snelheid gemeten, dan was onder pitch nummer een extra blok tevoorschijn gekomen met snelheid van de worp.
Dit bevordert het gebruikersgemak om sessies te kunnen analyseren. Het is wel veel werk om de data goed gesynchroniseerd te krijgen en op de juiste manier te tonen, op basis van attribuut “juistheid”. Dit onderdeel goed werkend krijgen is wel het meeste werk geweest bij het bouwen van de app. Je bent continue aan het testen met de emulator in de IDE, maar ook met fysieke telefoons. Het liefst doe je dit automatisch. Op het onderwerp testen van de app kom ik in een volgende blog op terug.
Een ander voorbeeld van gebruiksgemak, bruikbaarheid en “gebruiksvriendelijkheid”, is dat je maar een keer je e-mail en wachtwoord hoeft in te voeren waarna je kunt aangeven dat de app deze mag onthouden. Niemand heeft er volgens mij zin in om telkens weer gebruikersnaam en wachtwoord in te moeten voeren.
Nieuwe functionaliteiten
Zoals bij alle projecten gebruikelijk is, komen er continu nieuwe verzoeken voor extra functionaliteit vanuit de PO/ business. Een van die verzoeken was om wedstrijd data vast te leggen in de app. In het eerste plaatje zie je een switch voor training of wedstrijd (match). Deze heb ik ingebouwd als startpunt van de nieuwe requirement. Naast een kleine aanpassing van het scherm zit ik nu in de fase dat ik het datamodel moet veranderen, belangrijke classes aangepast moeten worden en dat de wijze van het versturen en ophalen van data anders moet.
Er is dus weer genoeg werk aan de winkel 😊….En vanzelfsprekend kom ik daar ook in een volgende blog op terug.
