Herontwikkeling Vital
applicatie
Bart Buijse
Vital BV
Herontwikkeling Vital applicatie
Afstudeerrapport
Auteur: Bart Buijse Studentnummer: 500663268 Telefoonnummer: +31 642 847 126 Plaats: Hazerswoude-Rijndijk Opleiding: (Technische) Informatica Onderwijsinstelling:Hogeschool van Amsterdam
Begeleidende docent:
J.G.M. Derriks
Bedrijfsbegeleider:
Twan van der Schoot
Bedrijf:
Vital BV
Frederik van Eedenplein 4 2394 EB, Hazerswoude Rijndijk Tel. +31 654 663 215
Website: www.vital4me.nl
Stageperiode:
Inhoud
Samenvatting ... 6 Begrippenlijst ... 7 Inleiding ... 8 1 Context ... 9 1.1 Vital BV ... 9 1.1.1 Algemeen ... 9 1.1.2 Producten en diensten ... 9 1.2 Opdracht ... 10 1.2.1 Aanleiding ... 10 1.2.2 Opdrachtomschrijving ... 10 1.2.3 Doelstelling ... 10 1.2.4 Technologieën ... 11 1.2.5 Middelen ... 11 2 Methodes ... 12 2.1 Software ontwikkelmethode ... 12 2.1.1 Wat is Scrum ... 12 2.1.2 Rollen ... 12 2.1.3 Theorie ... 12 2.1.4 Eigen toepassing ... 13 2.2 Onderzoeksmethodes ... 14 2.2.1 Observatie ... 14 2.2.2 Interview ... 14 2.2.3 Desk research ... 15 2.2.4 Conclusie ... 15 3 Ontwerp aanpak ... 163.1 Inventarisatie eisen van de opdrachtgever ... 16
3.2 Inventarisatie feedback van de gebruikers ... 16
3.3 Inventarisatie ontwerprichtlijnen ... 16
3.4 Nieuw ontwerp ... 17
3.5 Nieuw ontwerp valideren ... 17
4.1.1 Inloggen ... 18
4.1.2 Het aanpassen van memberprofielen ... 18
4.1.3 Het aanmaken van een nieuwe trainingsgroep ... 18
4.1.4 Toevoegen van members aan een trainingsgroep ... 18
4.1.5 Verwijderen van members uit een trainingsgroep ... 19
4.1.6 Starten van een ATDS test ... 19
4.1.7 Afsluiten van de test ... 19
4.1.8 Overige taken ... 19
4.2 Resultaten interview methode ... 19
4.2.1 Het hoofdmenu in de ATDS applicatie ... 19
4.2.2 Memberlijst ... 19
4.2.3 Het verbinden van een apparaat met de ATDS applicatie ... 19
4.2.4 ATDS test – ECG grafiek ... 20
4.2.5 ATDS test – tijdlijn ... 20
4.2.6 ATDS test – overbodige informatie ... 20
4.2.7 Members toevoegen aan trainingsgroepen ... 20
4.2.8 Trainingsgroepen beheer ... 20
4.2.9 Teruggaan naar het vorige venster ... 20
4.3 Resultaten desk research ... 20
4.3.1 Tussenruimte en positionering ... 21 4.3.2 Consistentie ... 21 4.3.3 Grootte ... 21 4.3.4 Feedback ... 21 4.3.5 Relatie ... 21 4.3.6 Duidelijkheid ... 22 4.3.7 Tolerantie ... 22 4.4 Conclusie ... 22 5 Technologieën ... 23 5.1 Windows 10 ... 23 5.2 Visual Studio 2015 ... 23
5.3 Team Foundation Server ... 23
5.4 .NET Framework ... 23
5.5 Windows Presentation Foundation ... 23
5.6 C# ... 23
5.8 XML ... 24
5.9 Bluetooth ... 24
6 Keuzes ... 25
6.1 Keuzes vanuit Vital ... 25
6.1.1 Programmeertaal ... 25
6.1.2 Versiebeheer ... 25
6.2 Ontwikkelmethode ... 25
6.3 Project template ... 26
6.3.1 Windows Presentation Foundation Application ... 26
6.3.2 Windows Forms Application ... 26
6.3.3 Windows Universal App ... 27
6.3.4 Overige mogelijkheden ... 27 6.3.5 Keuze ... 28 6.4 Lokalisatie ... 28 6.5 XML ... 28 7 Techniek ... 29 7.1 Design patterns ... 29 7.1.1 Factory method ... 29 7.1.2 Singleton ... 29 7.1.3 Bridge... 29 7.1.4 Command ... 29 7.1.5 Observer ... 29 7.1.6 MVVM ... 30 7.2 UML ... 30 7.3 Unit testen ... 31 8 De applicatie ... 32 8.1 Eisen ... 32 8.2 MVVM ... 32 8.2.1 Data binding ... 33 8.3 Deelvensters ... 33 8.4 Lokalisatie ... 33 8.5 Server communicatie ... 34 8.6 Bluetooth ... 34 8.7 Applicatie stijl ... 34
9 Conclusie ... 36
10 Aanbevelingen ... 37
10.1 Het ontwerpen van een gebruikersinterface ... 37
10.2 Het opnieuw valideren van het ontwerp ... 37
11 Bronnenlijst ... 38
Bijlagen ... 39
Bijlage A – Observatie taken voor de oude Team en ATDS applicatie ... 39
Bijlage B – Interviewvragen voor de oude Team en ATDS applicatie ... 40
Bijlage C – Vital applicatie eisen ... 41
Bijlage D – Verwerking gebruikerservaringen ... 43
Samenvatting
De afstudeerstage heeft plaatsgevonden binnen het bedrijf Vital BV. Vital BV is een bedrijf dat zich bezig houdt met het ontwikkelen van wiskunde algoritmes met betrekking tot o.a. de vitaliteit van een persoon. Deze algoritmes gebruiken zij in hun software om trainingsadviezen te genereren. Vital BV beschikt over twee applicaties voor het Windows platform. Uit commentaar van de gebruikers is gebleken dat beide applicaties niet gebruiksvriendelijk zijn. Vital wil daarom de applicaties verbeteren.
De opdracht was het opnieuw ontwikkelen van de bestaande twee applicaties tot één nieuwe applicatie, waarbij de negatieve gebruikerservaringen van de bestaande twee applicaties zijn vermeden. Om dit te realiseren is er een onderzoek uitgevoerd om de punten die zorgen voor een negatieve gebruikerservaring te identificeren.
Dit onderzoek bestond uit het observeren van gebruikers tijdens het uitvoeren van voorgelegde taken, het interviewen van gebruikers en het zoeken naar ontwerprichtlijnen.
De resultaten van het observeren gaven een goed beeld over de gebruikerservaringen van de
bestaande twee applicaties. De resultaten van de interviews met de gebruikers gaven een goed beeld van de mening en verwachtingen van de gebruiker. Met desk research zijn meerdere nuttige
ontwerprichtlijnen gevonden. Door de gevonden ontwerprichtlijnen is geleerd wat aandachtspunten zijn en wat goede keuzes zijn bij het maken van een gebruikersinterface.
Met de resultaten van het onderzoek, is er een goed beeld ontstaan van de verbeteringen die nodig zijn voor de nieuwe applicatie. Deze verbeteringen zijn uitgewerkt tot een nieuw ontwerp in
mockups. Dit ontwerp is gevalideerd door het te presenteren aan de opdrachtgever en de
gebruikers. Na enkele aanpassingen waren beide partijen tevreden en betekende dit dat het nieuwe ontwerp gevalideerd was.
Aan de hand van dit nieuwe ontwerp is een applicatie ontwikkeld. Tijdens de ontwikkeling van deze applicatie is erg gelet op de onderhoudbaarheid en de leesbaarheid van de code. Dit was belangrijk omdat Vital deze applicatie in de toekomst wil blijven gebruiken en uitbreiden. Hier zijn meerdere technieken voor gebruikt.
De ontwikkelde applicatie maakt het mogelijk verschillende vitaliteitstesten uit te voeren. De applicatie kan verbinden met een hartslagband en verschillende soorten fitness apparatuur door middel van Bluetooth. De ontvangen data wordt naar de server verstuurd waar de berekeningen plaatsvinden. De resultaten van deze berekeningen worden in de applicatie weergegeven in een grafiek. Aan het einde een test wordt dan het adviesrapport geopend op de website van Vital.
Begrippenlijst
API Een application programming interface (API) is een verzameling definities waarmee een computerprogramma kan communiceren met een ander programma of onderdeel.
AppsoluteTraining Dit is het merk van Vital.
ATDS test Anaerobic Threshold Detection System. Eén van Vital’s test programma’s. Deze test bepaald bij welke hartslag jouw lichaam over gaat op significante zuurstofverbranding en wanneer het over gaat op zuurstofloze verbranding (verzuring van de spieren).
Framework Een framework is een geheel van softwarecomponenten dat gebruikt kan worden bij het programmeren van applicaties.
HttpPost Een HttpPost is één van de vele vormen van aanvraagmethodes ondersteund door het http protocol. HttpPost vraagt aan een webserver om de
meegestuurde data te accepteren en een antwoord terug te sturen.
Team test Eén van Vital’s test programma’s. Dit is een groepstest. Dit kan bijvoorbeeld zijn met een zaal vol spinners. Elke spinner krijgt een hartslagbandje om die verbonden is met de smartphone van de spinner. De gegevens worden verstuurd naar de server. Team zal op een groot scherm dan per persoon weergeven wat zijn momentele inspanning is. De trainer kan hier dan op inspelen.
Unicode Unicode is een internationale standaard voor de codering van tekens en symbolen in binaire codes. De standaard voorziet alle tekens en symbolen van alle geschreven talen van een nummer.
Vitality test Eén van Vital’s test programma’s. Deze test bepaald hoe vitaal jij bent. Het bestaat uit vijf minuten stilzitten. Hier wordt o.a. gekeken naar de
ademhaling en de hartslag maar ook worden er een aantal belangrijke gegevens berekend. Deze test wordt vaak van tevoren gedaan om te bepalen of de testpersoon een bepaalde training zou aankunnen.
Inleiding
Dit document is het verslag van mijn afstudeerstage. Deze stage heeft plaatsgevonden binnen het bedrijf Vital BV en heeft 20 weken geduurd.
Vital BV is een bedrijf dat zich bezig houdt met het ontwikkelen van wiskunde algoritmes gebaseerd op het R-R interval1. Deze algoritmes gebruiken zij in hun software om trainingsadviezen te
genereren.
Vital BV beschikt over twee applicaties voor het Windows platform. Uit commentaar van de gebruikers blijkt dat beide applicaties niet gebruiksvriendelijk zijn. Vital wil daarom de applicaties verbeteren.
Mijn opdracht is het opnieuw ontwikkelen van de bestaande twee applicaties tot één nieuwe applicatie, waarbij de negatieve gebruikerservaringen van de bestaande twee applicaties worden vermeden. Om dit te realiseren heb ik een onderzoek uitgevoerd om de punten die zorgen voor een negatieve gebruikerservaring te identificeren. Door deze punten te identificeren is voorkomen dat deze punten terugkomen in het ontwerp van de nieuwe applicatie. Na het identificeren van deze punten, is er een nieuw ontwerp gemaakt. Dit ontwerp is gevisualiseerd in mockups.
In dit document zal er eerst worden ingegaan op het bedrijf Vital BV en wat de context van de afstudeerstage was. Dan zal het onderzoek worden beschreven. Na het onderzoek zullen de technologieën worden beschreven die gebruikt zijn. Ook zullen de keuzes voor deze technologieën worden uitgelegd waar dit van toepassing was. Met deze technologieën is de nieuwe applicatie ontwikkeld. Hoe deze applicatie is opgebouwd zal hier ook worden beschreven. Tot slot zullen de resultaten van het onderzoek worden beschreven in de conclusie.
1
Context
1.1 Vital BV
1.1.1 Algemeen
Vital BV is een relatief klein maar groeiend bedrijf dat nu enkele jaren bestaat. Het bedrijf richt zich vooral op sporters, trainers en fysiotherapeuten. Vital onderscheidt zich door zijn wiskundige
algoritmes gebaseerd op het R-R interval. Deze algoritmes berekenen data als ademhaling, aerobe en anaerobe omslagpunten, rust metabolisme, trainingsintensiteit en meer. Aan de hand van deze data kan de vitaliteit van een test persoon worden bepaald en kan er een adviesrapport gegenereerd worden. Uit dit adviesrapport wordt bijvoorbeeld duidelijk of de test persoon fysiek in staat is een bepaald trainingsschema te volgen of hoe de conditie van de test persoon is veranderd sinds de laatste test.
Vital BV is pas verhuisd naar een nieuwe locatie in Hazerswoude-Rijndijk en deelt deze locatie met sportschool Sport2BFit en fysiotherapie Fysioklein. Vital werkt nauw samen met Sport2BFit om de producten in de praktijk te testen en feedback te verzamelen.
Het kantoor is gevestigd op: Vital BV
Frederik van Eedenplein 4 2394 EB, Hazerswoude Rijndijk Tel. +31 654 663 215
Website: www.vital4me.nl
1.1.2 Producten en diensten
Het bedrijf biedt de volgende producten voor de professionele markt (fysiotherapeuten, fitnesscentra, arbodiensten en trainers) aan:
- Appsolute Training ATDS voor het afnemen van inspanningstesten en rustmetingen - Appsolute Training Team voor teamtrainingen
- Appsolute Training app voor individueel trainen of in een groep trainen (Android en iOS) En daarnaast biedt het bedrijf ook de volgende diensten:
- Opleidingen en trainingen van inspanningsfysiologie - Afnemen, testen en metingen op gebied van vitaliteit - Geven van groepstrainingen
1.2 Opdracht
1.2.1 Aanleiding
Momenteel beschikt Vital over een ATDS en een Team applicatie voor het Windows platform. De twee applicaties zijn ontwikkeld als bèta applicaties. Uit commentaar van klanten blijkt dat beide applicaties niet gebruiksvriendelijk zijn. Vital wil daarom de applicaties verbeteren.
Bepaalde functionaliteiten zoals gebruikersbeheer komen in beide applicaties voor. Dat betekend dat deze functionaliteiten dubbel onderhouden moeten worden. Om dit te voorkomen vindt Vital het wenselijk om beide applicaties te combineren tot één applicatie.
1.2.2 Opdrachtomschrijving
De opdracht is het herschrijven van de bestaande ATDS en Team applicatie naar een nieuwe enkele applicatie met een verbeterede gebruikersinterface. Met één applicatie krijgt de gebruiker een beter overzicht van alle functionaliteiten omdat hij dan niet meer tussen twee applicaties hoeft te
wisselen. De verbeterde gebruikersinterface moet ervoor zorgen dat de klanten beter met deze functionaliteiten overweg kunnen. De hoofdfunctionaliteit van de applicatie is het uitvoeren van een test. Daarom is zo min mogelijk gebruikersinteractie gewenst om een test te starten.
Naast dat de nieuwe applicatie gebruiksvriendelijker moet zijn, zijn er ook technische redenen voor deze opdracht. Door de twee oude applicaties te combineren in een enkele applicatie vereenvoudig je het toekomstige ontwikkelproces. Zaken als gebruikersbeheer hoeven niet meer in twee
verschillende applicaties ontwikkeld en onderhouden te worden. 1.2.3 Doelstelling
Het doel is om een nieuwe applicatie te ontwikkelen waarin de functionaliteit van de bestaande ATDS en Team applicatie behouden blijft maar de aspecten die voor een negatieve
gebruikerservaring zorgden worden vermeden. Om dit te realiseren, worden de problemen van de gebruikersinterface van de bestaande applicaties geïdentificeerd. Door de problemen expliciet te identificeren vermijden we dat deze problemen zich opnieuw voordoen in de nieuwe applicatie. De onderzoeksvraag wordt dan:
- Hoe kan ik uitgaande van de gebruikerservaringen met een bestaande twee applicaties vermijden dat dezelfde negatieve gebruikerservaringen worden herhaald in de nieuwe applicatie?
Deelvragen hierbij zijn:
- Hoe kan ik gebruikerservaringen met de bestaande applicaties inventariseren? - Hoe kan ik een beeld krijgen (van de aard) van de verbeteringen die nodig zijn? - Kan ik van de uitwerking van deze verbeteringen al een indruk krijgen van de
gebruikerservaringen zonder over te moeten gaan tot een release van een complete applicatie?
1.2.4 Technologieën
De technologieën die gebruikt zijn bij het realiseren van deze opdracht zijn: - Windows 10
- Visual Studio 2015 - Team Foundation Server - .NET Framework
- Windows Presentation Foundation - C#
- XAML - XML - Bluetooth
Deze technologieën zullen worden beschreven in hoofdstuk 5. 1.2.5 Middelen
Bij het realiseren van de opdracht zijn de volgende middelen gebruikt: - Een ontwikkelcomputer met Bluetooth ondersteuning
- Visual Studio 2015 - Microsoft Word - Visual Paradigm - Balsamiq Mockups
- Zephyr BioHarness 3 hartslagband - Zephyr HXM hartslagband
2
Methodes
2.1 Software ontwikkelmethode
Als software ontwikkelmethode is een afgeleide van Scrum gebruikt. Wat Scrum is en hoe het in de afstudeeropdracht wordt toegepast is hieronder beschreven.
2.1.1 Wat is Scrum
Scrum is een software ontwikkelmethode die ontworpen is om veel flexibiliteit te ondersteunen. Het wordt daarom ook vaak gebruikt als klanten nog niet goed weten hoe het eindproduct eruit moet komen te zien. Door tijdens de ontwikkeling regelmatig het product te bespreken en deelproducten op te leveren, kan de klant langzamerhand een betere indruk krijgen over het product en het ontwikkelteam de juiste richting op sturen. Scrum staat de klant dus in staat om tijdens de ontwikkeling de producteisen te veranderen.
2.1.2 Rollen
Scrum definieert verschillende rollen voor de belanghebbende (Engels: stakeholder) in een project die elk hun eigen specifieke taak hebben. Hoewel meerdere rollen door één persoon vervuld kan worden, is dat niet altijd wenselijk.
Producteigenaar:
De producteigenaar (Engels: product owner) zorgt ervoor dat de waarde van het product wordt gemaximaliseerd. Hoe dit gedaan wordt varieert heel erg. Ook beheert hij de product backlog. Zo bepaald hij wat er gedaan wordt en in welke volgorde.
Het ontwikkelteam:
Dit is een multidisciplinair ontwikkelteam dat verantwoordelijk is voor het afleveren van het product. Het team organiseert zichzelf.
Scrummaster:
De scrummaster begeleidt het team door ervoor te zorgen dat het scrumproces goed gevolgd wordt. Ook zorgt de scrummaster voor de communicatie met derden. Zo wordt het ontwikkelteam niet constant lastig gevallen met derden die iets over het product te vertellen hebben.
2.1.3 Theorie
Om scrum goed toe te passen zijn drie pijlers van belang. Transparantie:
Significante aspecten voor het ontwikkelproces dienen bekend te zijn bij de personen die verantwoordelijk zijn voor eindproduct. Deze aspecten moeten gedefinieerd zijn in een gemeenschappelijke standaard met de waarnemers. Een voorbeeld is dat beide partijen een gemeenschappelijk begrip hebben over een compleet product.
Inspectie:
Waarnemers dienen regelmatig het product, voor zo ver het al af is, te inspecteren op ongewenste punten. Door dit regelmatig te doen zal er tijdig kennis gedaan worden van eventuele nodige aanpassingen.
Aanpassing:
2.1.4 Eigen toepassing
Omdat ik alleen werkte als het ontwikkelteam, heb ik gebruik gemaakt van een aangepaste versie van scrum. Hieronder zal ik per scrum evenement uitleggen waar het voor is en hoe ik het heb toegepast.
De backlog
De backlog is een log waarop te vinden is wat er nog gedaan moet worden, wat er momenteel gedaan wordt en wat er al af is om een potentieel bruikbaar (deel)product te creëren.
De backlog gebruik ik om voor mezelf te noteren wat er nog gedaan moet worden en wat er al af is. Ook gebruik ik dit om voor mezelf te kijken hoeveel tijd ik ervoor dacht nodig te hebben en hoeveel tijd ik uiteindelijk eraan heb besteed.
De sprint
De sprint is een tijdsperiode waarin een potentieel bruikbaar product wordt gecreëerd. Het beste is het om de tijdsperiode van een sprint consistent te houden. Als een sprint is beëindigd volgt
onmiddellijk de volgende sprint. Alle activiteiten die niet zijn gerealiseerd in de vorige spring worden meegenomen naar de volgende spring via de backlog.
Tijdens de sprint
- Zullen er geen veranderingen worden gemaakt in de eisen, specificaties of wensen van de klant die ervoor zorgen dat het doel van de sprint niet meer wordt behaald.
- Kwaliteitsdoelen worden niet gewijzigd.
- De scope kan verhelderd of onderhandeld worden tussen de producteigenaar en het ontwikkelteam naarmate er meer wordt geleerd.
Sprints pas ik toe in tijdsperiodes van twee weken. Tijdens een sprint zal ik regelmatig met de producteigenaar de voortgang bespreken en eventueel de scope verhelderen.
De story
De story is een korte omschrijving van wat een gebruiker wil. In de beschrijving zegt men ‘wie’, ‘wat’, ‘waarom’ wil.
In mijn eigen toepassing zijn de stories vervangen voor de mockups en de reacties van de gebruikers tijdens het interview en het observeren.
Dagelijkse stand-up meeting
Een dagelijkse stand-up meeting is een korte vergadering van ongeveer 15 minuten waarin het ontwikkelteam de voortgang bespreekt. Het doel hiervan is o.a. om de kans te vergroten dat het ontwikkelteam het doel van de sprint behaald.
Omdat ik alleen het ontwikkelteam vormde, heb ik dit concept moeten aanpassen. Dit heb ik gedaan door mezelf dagelijks de volgende vragen te stellen:
- Wat heb ik vandaag gedaan? - Hoe ga ik verder?
- Zie ik hindernissen die ervoor kunnen zorgen dat ik het doel van de sprint niet haal? - Wat heb ik nodig van mijn klant om door te kunnen gaan?
De sprint review
De sprint review is een meeting met de scrummaster, de belanghebbende en de producteigenaar. Deze vindt plaats aan het einde van een sprint. Hier wordt een nieuw potentieel bruikbaar product gepresenteerd en is vooral bedoeld om feedback te krijgen. Ook wordt hier gepresenteerd wat er is gedaan, waar tegenaan is gelopen, wat er in de volgende sprint zal worden gedaan en worden onderwerpen als budget en de plek op de markt besproken.
Aan de sprint review heb ik weinig aangepast. Ik bespreek alle review punten op het budget en de plek op de markt na. Deze twee zijn voor mij niet noodzakelijk te bespreken omdat deze niet onder mijn verantwoordelijkheden vallen. Een sprint review duurt in mijn geval meestal een kwartier tot een uur. Indien een deelproduct nog niet helemaal af is zal de reden hiervoor worden besproken. Daarna zal besproken worden wanneer het wel af zal zijn en indien nodig zal de planning hierop worden aangepast.
2.2 Onderzoeksmethodes
Tijdens het onderzoek zijn verschillende onderzoeksmethodes gebruikt voor het vergaren van relevante data. Welke er gebruikt zijn en waarom wordt hieronder beschreven.
In dit paragraaf wordt de volgende deelvraag behandelt:
- Hoe kan ik gebruikerservaringen met de bestaande applicaties inventariseren? 2.2.1 Observatie
Om erachter te komen welke punten van de gebruikersinterface van de oude applicaties voor de gebruiker onduidelijk zijn, heb ik de observatie methode gebruikt. Hiervoor heb ik één-op-één sessies met gebruikers gehouden. Tijdens een sessie heb ik een aantal taken gegeven die de gebruiker dan moest uitvoeren. Tijdens de uitvoering keek ik hoe moeilijk het voor de gebruiker was om tot het gewenste resultaat te komen. Zo kon het bijvoorbeeld zijn dat de gebruiker iets niet meteen begreep. Dit viel op als de gebruiker zat te zoeken naar de juiste knoppen of onverwachte acties uitvoerde.
De observatie methode is gekozen omdat dit laat zien hoe de gebruiker zelfstandig probeert taken in de applicatie uit te voeren en hoe duidelijk deze taken voor de gebruiker zijn.
2.2.2 Interview
Om positieve punten en verbeterpunten te detecteren in de gebruikersinterface, heb ik gebruikers geïnterviewd. Hier heb ik één-op-één sessies met de gebruikers voor gehouden. In deze sessies heb ik een aantal vragen gesteld waaruit duidelijk is geworden wat de mening van de gebruikers is over de oude applicaties. Tijdens een interviewsessie ben ik samen met de gebruiker door de applicaties gelopen en vroeg ik per venster of er verbeterpunten en/of onduidelijkheden waren. Ook vroeg ik of er punten waren die de gebruiker juist wel erg fijn vond. Deze punten zijn meegenomen in de ontwikkeling van de nieuwe applicatie.
De aanpak met een interview is gekozen om naast een indruk van de begrijpelijkheid van de
gebruikersinterface van de oude applicaties ook de mening van de gebruikers hierover te krijgen. Het kan namelijk zijn dat gebruikers bepaalde onderdelen wel begrijpen maar niet handig vinden. Met deze aanpak kun je daar achter komen.
2.2.3 Desk research
Voor het vinden van behulpzame informatie over het ontwikkelen van een gebruiksvriendelijke gebruikersinterface heb ik desk research gebruikt. Ik heb daarbij gezocht naar ontwerprichtlijnen. Deze richtlijnen leiden tot een overzichtelijker, beter te begrijpen en professioneler ontwerp voor de gebruikersinterface.
Desk research is gekozen omdat ontwerprichtlijnen al vaker zijn onderzocht. Het was daarom een goed idee om zelfstandig de bestaande resultaten te bestuderen in plaats van deze zelf proberen te ontwikkelen.
2.2.4 Conclusie
De gebruikerservaringen heb ik kunnen inventariseren met behulp van de drie gekozen methodes. Elk van deze methodes gaf unieke informatie over de gebruikerservaringen.
De observatie methode heb ik gebruikt om te inventariseren hoe duidelijk de gebruikersinterface is. Omdat gebruikers zelfstandig een aantal taken hebben uitgevoerd, gaf dit een goed beeld van hoe goed de gebruikers de gebruikersinterface kunnen begrijpen en gebruiken.
De interview methode heb ik gebruikt om een mening van de gebruikers te krijgen over de gebruikersinterface. Dit konden positieve of negatieve punten zijn. In het nieuwe ontwerp zijn de positieve punten meegenomen en de negatieve punten verholpen.
Desk research heb ik gebruikt om ontwerprichtlijnen te inventariseren. Door deze ontwerprichtlijnen heb ik geleerd wat aandachtspunten zijn en wat goede keuzes zijn bij het maken van een
gebruikersinterface. Deze punten heb ik gebruikt om verbeterpunten te identificeren aan het oude ontwerp.
3
Ontwerp aanpak
Om tot het uiteindelijke ontwerp voor de nieuwe applicatie te komen, heb ik een aantal stappen gebruikt. Deze stappen zijn hieronder beschreven.
In dit hoofdstuk wordt de volgende deelvraag behandeld:
- Hoe kan ik een beeld krijgen (van de aard) van de verbeteringen die nodig zijn?
3.1 Inventarisatie eisen van de opdrachtgever
Om de eisen van de opdrachtgever te inventariseren, heb ik een gesprek voorbereid. Eerst ben ik zelfstandig door de oude applicaties gelopen. Hier heb ik notities gemaakt van de functionaliteiten die zich in de oude applicaties bevinden. Eigen voorstellen tot verbeterpunten heb ik ook genoteerd. Na deze voorbereiding ben ik een gesprek aangegaan met de opdrachtgever. Tijdens dit gesprek ben ik met de opdrachtgever stap voor stap door de oude applicaties gelopen. Per venster heb ik de functionaliteiten behandeld en heb ik geïnventariseerd wat behouden moet blijven, wat aangepast moet worden en wat er weg moet. Dit leverde een goed overzicht van de eisen voor de nieuwe applicatie.
Zie Bijlage C voor een lijst van de eisen voor de nieuwe applicatie.
3.2 Inventarisatie feedback van de gebruikers
De feedback van de gebruikers was belangrijk omdat zij uiteindelijk de nieuwe applicatie gaan gebruiken. Omdat zij al met de oude applicaties hadden gewerkt, konden zij goede feedback geven over wat er beter moest of wat er juist heel goed was.
Om onduidelijkheden in de oude applicaties te inventariseren heb ik de observatie methode gebruikt. Hierin hield ik één-op-één sessies met de gebruikers waarin ik taken gaf die de gebruikers hebben moeten uitvoeren. Hier heb ik geobserveerd of de gebruiker meteen wist wat hij moest doen, of de gebruiker voor een taak langer nodig had dan normaal of dat de gebruiker helemaal niet wist wat hij moest doen om de taak correct uit te voeren. Zie Bijlage A voor een lijst van de
gevraagde taken.
De positieve punten en verbeterpunten van de oude applicaties heb ik geïnventariseerd met behulp van de interview methode. De interviews heb ik in één-op-één sessies met de gebruikers gehouden. Hier ben ik met de gebruiker door de oude applicaties gelopen. Per venster vroeg ik dan of zij positieve punten of verbeterpunten konden geven. Nadat we door de oude applicaties waren gelopen stelde ik nog een paar algemenere vragen over de oude applicaties. Zie Bijlage B voor een lijst met de interviewvragen.
3.3 Inventarisatie ontwerprichtlijnen
Ontwerprichtlijnen leiden tot een overzichtelijker, beter te begrijpen en professioneler ontwerp voor de gebruikersinterface. Om deze ontwerprichtlijnen te inventariseren heb ik desk research gebruikt. Hier ben ik zelfstandig op internet gaan zoeken naar resultaten van eerdere onderzoeken met betrekking tot dit onderwerp. Omdat de nieuwe applicatie voor Windows wordt ontwikkeld, ben ik ook gaan zoeken naar de ontwerprichtlijnen die Microsoft hanteert.
3.4 Nieuw ontwerp
Het nieuwe ontwerp is gemaakt met mockups. Voorafgaand het maken van deze mockups is gezocht naar ontwerprichtlijnen. Deze richtlijnen leiden tot een overzichtelijker, beter te begrijpen en professioneler ontwerp.
De combinatie van de ontwerprichtlijnen, de eisen van de opdrachtgever en de feedback van de gebruikers, heb ik gebruikt om de verbeterpunten in de bestaande applicaties te identificeren én hoe deze veranderd zouden moeten worden. Dit heb ik gedaan door elk venster van de oude applicaties te analyseren en te noteren wat er verandert moet worden.
Aan de hand van de genoteerde veranderingen die gemaakt moesten worden, heb ik de mockups ontwikkeld. Zie Bijlage D voor de ontwikkelde mockups en een volledige verwerking van de gebruikerservaringen.
3.5 Nieuw ontwerp valideren
De ontwikkelde mockups moeten worden gevalideerd. Dit heb ik gedaan door met de opdrachtgever en enkele gebruikers de mockups helemaal door te nemen. De opdrachtgever en de klanten konden per venster aangeven wat ze wel en niet goed vonden. Aan de hand van deze feedback zijn de mockups nog aangepast. Dit proces is herhaald totdat de mockups voldeden aan de wensen van beide partijen. Indien er een conflict ontstond tussen de wensen van de opdrachtgever en de wensen van de klant, zou er tussen de partijen een vergadering worden georganiseerd waarin zij hun conflict in wensen met elkaar tegemoetkomen. Dit heeft niet plaats hoeven vinden.
Het nieuwe ontwerp is, ten opzichte van het ontwerp van de oude applicaties, verbeterd als beide partijen tevreden zijn over de mockups. Dit betekent tevens dat de ontwikkelde mockups klaar zijn.
3.6 Conclusie
Om een beeld te krijgen van de verbeteringen die nodig zijn ben ik eerst zelfstandig door de
applicatie gelopen om eventuele verbeterpunten te noteren. Daarna ben ik een gesprek aangegaan met de opdrachtgever om deze verbeterpunten te bespreken en de uiteindelijke eisen van de nieuwe applicatie te inventariseren.
De feedback van de gebruikers heb ik geïnventariseerd met de observatie methode en de interview methode. Dit zorgde voor een goed beeld van de gebruikerservaring van de oude applicaties, de mening en de verwachtingen van de gebruiker.
De ontwerprichtlijnen heb ik geïnventariseerd met behulp van desk research. De resultaten hiervan geven een goed beeld van eerder onderzochte ontwerprichtlijnen en standaarden gehanteerd door Microsoft.
Met de eisen van de opdrachtgever, de feedback van de gebruikers en de ontwerprichtlijnen, heb ik een goed beeld kunnen krijgen van de verbeteringen die nodig zijn voor de nieuwe applicatie. Om dit beeld uit te werken heb ik mockups gemaakt. Deze mockups geven weer hoe de nieuwe applicatie eruit komt te zien.
De gemaakte mockups heb ik gevalideerd door het te presenteren aan de opdrachtgever en enkele gebruikers. Ten gevolge hiervan zijn de mockups nog aangepast. Na de gewenste aanpassingen waren beide partijen tevreden over de mockups. Dit betekende dat het ontwerp verbeterd was en de mockups klaar waren.
4
Onderzoeksresultaten
Tijdens het onderzoek heb ik twee één-op-één sessies gehouden met de gebruikers. In de eerste sessies gaf ik de gebruikers een lijst met taken. Ik observeerde dan hoe goed de gebruiker deze taken kon uitvoeren om onduidelijkheden in de applicatie te identificeren.
In de tweede sessie hield ik een interview met de gebruikers. Hiermee identificeerde ik positieve punten en verbeterpunten.
Als laatste stap heb ik desk research gebruikt om ontwerprichtlijnen te verzamelen. De resultaten van dit onderzoek zijn hieronder beschreven.
In dit hoofdstuk wordt de volgende deelvraag behandelt:
- Kan ik van de uitwerking van deze verbeteringen al een indruk krijgen van de
gebruikerservaringen zonder over te moeten gaan tot een release van een complete applicatie?
4.1 Resultaten observatie methode
Tijdens het observeren van de gebruikers tijdens het uitvoeren van de gegeven taken zijn een aantal punten opgevallen. Per taak zal worden beschreven wat deze punten zijn.
4.1.1 Inloggen
De gebruikers hadden geen problemen met de correcte handelingen uitvoeren tijdens het inloggen. Echter als er op de knop was gedrukt om in te loggen, was het veel gebruikers niet duidelijk of de applicatie daadwerkelijk bezig was met inloggen of dat ze per ongeluk mis hadden gedrukt. Dit kwam omdat er geen feedback was vanuit de applicatie. De knop werd niet grijs en er was geen status tekst. Dit resulteerde in dat veel gebruikers opnieuw probeerde de knop in te drukken.
4.1.2 Het aanpassen van memberprofielen
De gebruikers weten waar ze moeten zijn om de gebruikersprofielen aan te passen. De profielen worden ook correct aangepast. Echter worden ze niet altijd correct opgeslagen. De oude applicatie biedt per profiel een opslaan knop die per profiel moet worden ingedrukt om de veranderingen door te sturen naar de server. Vaak veranderde gebruikers een profiel en gingen ze zonder de wijzigingen op te slaan, verder naar het volgende profiel. De applicatie gaf hier ook geen waarschuwing voor. 4.1.3 Het aanmaken van een nieuwe trainingsgroep
De gebruikers wisten waar ze heen moesten. Als zij op de knop drukken om een nieuwe
trainingsgroep aan te maken, is hun niet duidelijk dat zij eerst een trainer moeten selecteren om aan de nieuwe trainingsgroep te linken. Ook was het niet duidelijk dat de naam vooraf ingevuld moest worden.
4.1.4 Toevoegen van members aan een trainingsgroep
Het toevoegen van members gaat goed maar gebruikers ergeren zich merkbaar bij het toevoegen van meerdere gebruikers aan de trainingsgroep. Dit komt omdat er maar één member tegelijk aan een trainingsgroep toegevoegd kan worden. Gebruikers moeten per member die zij willen toevoegen opnieuw klikken op de toevoegen knop, de member uit de lijst selecteren en op opslaan drukken.
4.1.5 Verwijderen van members uit een trainingsgroep
De gebruikers drukken op de juiste knop maar het is hun niet direct duidelijk dat zij eerst een member uit de weergegeven lijst moeten selecteren voordat zij op de verwijder knop drukken. Dat komt omdat de knop om een member toe te voegen een nieuw venster opent en de knop om een member te verwijderen niet.
4.1.6 Starten van een ATDS test
Tijdens deze taak hadden gebruikers die een apparaat probeerde te verbinden (bijvoorbeeld een fiets), hier erg veel moeite mee. Zij wisten niet welke COM poort bij het apparaat hoorde om mee te verbinden. Verder ging het starten van een ATDS test goed.
4.1.7 Afsluiten van de test
In beide applicaties werd door de gebruikers wel eens verkeerd afgesloten. Dat komt omdat de sessie pas wordt afgesloten als in de applicatie op de stop knop wordt gedrukt. De gebruikers weten dat niet en drukken vaak gewoon op het kruisje om de hele applicatie direct af te sluiten. Hierdoor wordt de sessie niet correct beëindigd.
4.1.8 Overige taken
De overige taken verliepen goed en waren geen directe problemen in op te merken.
4.2 Resultaten interview methode
Tijdens het interview hebben de gebruikers een aantal verbeterpunten aangegeven. Deze verbeterpunten worden hieronder beschreven.
4.2.1 Het hoofdmenu in de ATDS applicatie
In de ATDS applicatie zitten drie knoppen in het hoofdmenu. Deze knoppen hebben geen tekst en worden weergegeven aan de hand van een plaatje. De gebruikers gaven aan de betekenis van de knoppen onduidelijk te vinden. Dat kwam omdat er geen titel tekst boven het plaatje staat dat aangeeft wat de knop inhoudt. Ook als je de muis op het plaatje zet zal er geen tekst weergegeven worden dat dit duidelijk moet maken.
4.2.2 Memberlijst
In beide applicaties zit een lijst waaruit de gebruiker één of meerdere members dient te selecteren. De members worden hierin met hun voor- en achternaam weergegeven. De gebruikers gaven aan dat zij members moeilijk konden vinden en vrijwel altijd de zoek functie moesten gebruiken. De reden hiervoor was dat de memberlijst niet op alfabetische volgorde was gesorteerd.
4.2.3 Het verbinden van een apparaat met de ATDS applicatie
In de ATDS applicatie is het mogelijk een fiets of loopband te verbinden die dan wordt aangestuurd of uitgelezen door de software. Het koppelen van een apparaat met de software vinden gebruikers erg lastig. Het is onduidelijk welke poort er geselecteerd moet worden omdat de poorten niet vermelden om welk apparaat het gaat. De gebruiker ziet alleen een poort met een Bluetooth adres. Verder vonden niet alle gebruikers het duidelijk hoe zij de software zo konden instellen dat het alleen het apparaat zal uitlezen in plaats van ook aansturen.
4.2.4 ATDS test – ECG grafiek
Tijdens een test met de ATDS software wordt er een ECG grafiekje weergegeven. Deze grafiek wordt vaak niet goed ingezoomd waardoor de data niet af te lezen is. Dit wordt dan bijna een rechte lijn. Deze grafiek moet dus beter omgaan met nieuwe minimum en maximum waardes van de assen. 4.2.5 ATDS test – tijdlijn
Tijdens een ATDS test worden de berekende resultaten van de server weergeven in een grafiek. Dit zijn waardes als ademhaling, hartslag, amplitude en meer. Op de x-as van deze grafiek wordt de tijd weergegeven. Deze tijd is gelijk aan de systeemtijd van de computer. Gebruikers vinden het moeilijk om hierop af te lezen hoe lang de test persoon al bezig is. Zij willen dat de trainingstijd begint bij 0:00:00.
4.2.6 ATDS test – overbodige informatie
Tijdens een ATDS test wordt de laatst berekende data aan de zijkant weergegeven. Deze data bevat ook komma getallen. Dit vinden gebruikers overbodig. Zij geven aan het fijner te vinden als de waardes op gehele getallen worden afgerond.
4.2.7 Members toevoegen aan trainingsgroepen
Members kunnen alleen één voor één worden toegevoegd aan een trainingsgroep. Dit vinden gebruikers zeer irritant want zij moeten vaak veel members tegelijk toevoegen. Gebruikers willen dat dit makkelijker kan door meerdere members in één keer te kunnen toevoegen aan de trainingsgroep. 4.2.8 Trainingsgroepen beheer
Bij het aanmaken van een Team sessie wordt een trainingsgroep geselecteerd. De members in de trainingsgroep worden dan in die sessie gezet. Gebruikers wisten niet dat het mogelijk was om in de applicatie aan te geven dat één of meerdere members die specifieke sessie niet meedoen. Dit moet namelijk door een gebruiker in een leeg veld te slepen waar geen tekstje bij staat waar het voor bedoelt is.
4.2.9 Teruggaan naar het vorige venster
In de ATDS applicatie is het niet mogelijk om terug te gaan naar het vorige venster. Gebruikers gaven aan wel eens terug te willen gaan om de gegevens die zij hebben ingevuld te dubbelchecken of om iets aan te passen. Zij moesten hiervoor eerst helemaal doorgaan met wat zij hadden aangeklikt of zij moesten de applicatie herstarten om opnieuw te beginnen.
4.3 Resultaten desk research
Met desk research is er gezocht naar ontwerprichtlijnen. Deze ontwerprichtlijnen worden gebruikt bij de ontwikkeling van de mockups. De gebruikte ontwerprichtlijnen worden hieronder beschreven.
4.3.1 Tussenruimte en positionering
De tussenruimte tussen elementen in het ontwerp mag niet te groot of te klein zijn.2 Als er te grote, te kleine of onregelmatige tussenruimtes in het ontwerp zitten, kan dit als zeer onprofessioneel overkomen. De eerste indruk van de applicatie zal dan meteen negatief zijn. Om dit te voorkomen dienen de gebruikersinterface elementen consistent te worden gepositioneerd. Er zijn geen regels voor de tussenruimtes maar de Visual Studio designer heeft hier wel handige richtlijnen voor. 4.3.2 Consistentie
De gebruikers hebben consistentie nodig. Als ze eenmaal gewend zijn iets via een bepaalde handeling te kunnen doen, moet dit ook zo blijven. Als diezelfde handeling opeens een ander gevolg geeft zal dit frustratie creëren. Een voorbeeld is dat de terug-knop en de volgende-knop altijd op dezelfde plek moeten staan. Gebruikers kunnen bijvoorbeeld uit opgebouwde gewoonte automatisch op volgende drukken als ze naar het volgende venster willen. Als deze knop opeens de terug-knop wordt, is er een grote kans dat zij dit te laat zien en er ongewenst op drukken. Daarom is consistentie in de applicatie erg belangrijk.
4.3.3 Grootte
Elementen moeten niet te groot of te klein zijn.3 Als de tekst in een knop stukken kleiner is dan de knop zelf, valt dit erg op. Ook zorgt dit ervoor dat de andere elementen niet goed meer samengaan met de grote knop. Dat komt omdat er inconsistenties ontstaan tussen de formaten van elementen. Om dit te voorkomen dienen elementen een correct formaat te hebben passend bij de interface. 4.3.4 Feedback
De applicatie dient de gebruiker te allen tijde te informeren of de input correct of incorrect was, waar het momenteel mee bezig is of wat de status van de applicatie is. Als er geen feedback wordt geleverd, kan het voorkomen dat de gebruiker een taak meerdere keren uitvoert omdat het niet duidelijk is of de taak gestart is. Het is dus belangrijk dat de gebruiker altijd geïnformeerd blijft. 4.3.5 Relatie
De gebruikersinterface is snel overzichtelijker te maken door gerelateerde elementen te
onderscheiden van andere elementen. Dit creëert een logische groepering van informatie in het venster. De gebruiker kan dan beter focussen op de informatie waar hij momenteel in is
geïnteresseerd omdat het netjes bij elkaar staat.
2 Microsoft, User Interface Principles,
https://msdn.microsoft.com/en-us/library/windows/desktop/ff728831%28v=vs.85%29.aspx#spacing_and_positioning, (2016) 3 Microsoft, User Interface Principles,
4.3.6 Duidelijkheid
De gebruiker moet kunnen begrijpen wat een bepaalde actie voor gevolgen zal hebben. Om dit te bereiken is het belangrijk dat bij het selecteren van opties, er duidelijkheid is over wat elke optie doet. Bij het indrukken van knoppen moet het gevolg te voorspellen zijn. Als de gebruiker iets moet invullen moet duidelijk zijn wat er wordt verwacht.
Om verwarring te voorkomen moet alleen de belangrijke informatie worden weergegeven. Als informatie niet relevant is op het gegeven moment kan dit voor verwarring zorgen.
Het moet de gebruiker altijd duidelijk zijn in welke context hij zich momenteel bevindt. Dit kan bijvoorbeeld bereikt worden met een titel bovenaan de pagina. Als de gebruiker weg is geweest en net terugkomt, zal hij misschien niet meer weten welke actie hij vooraf heeft uitgevoerd. Als de momentele context dan niet duidelijk is weet de gebruiker niet meer waar hij mee bezig was. 4.3.7 Tolerantie
Gebruikers kunnen wel eens fouten maken. Zo kunnen ze bijvoorbeeld verkeerd klikken waardoor ze naar het verkeerde venster gaan. De applicatie dient hierop tolerant te zijn door de gebruiker in staat te stellen zijn actie ongedaan te maken.
4.4 Conclusie
De onderzoeksresultaten geven een goed beeld van de verbeteringen die nodig zijn voor de gebruikersinterface van de nieuwe applicatie. Deze verbeteringen zorgen er o.a. voor dat de gebruikersinterface simpeler te begrijpen is en dat gebruikers sneller een gewenste actie kunnen bereiken.
Om een indruk te krijgen van de gebruikerservaring van de nieuwe applicatie is het handig om de gebruikersinterface gevisualiseerd te hebben. Om dit te bereiken zijn er mockups gemaakt. Zie Bijlage D voor deze gemaakte mockups. Deze mockups zijn gepresenteerd aan de opdrachtgever en enkele gebruikers. Zij konden met de mockups al een goede indruk krijgen van de gebruikerservaring. Na een paar aanpassingen waren beide partijen tevreden. Een release van een complete applicatie was dus niet nodig om alvast een indruk te krijgen van de gebruikerservaringen van de nieuwe gebruikersinterface.
5
Technologieën
Voor het realiseren van het eindproduct zijn de volgende technologieën gebruikt.
5.1 Windows 10
Windows 10 is een besturingssysteem ontwikkeld door Microsoft dat fungeert als een medium tussen de hardware en de computergebruiker. Windows 10 maakt het mogelijk om programma’s op een makkelijke manier te bedienen.
Windows 10 is gebruikt als besturingssysteem voor de ontwikkelcomputer en is nodig als besturingssysteem om het eindproduct mee uit te voeren.
5.2 Visual Studio 2015
Visual Studio 2015 is een programmeerontwikkelomgeving van Microsoft. Het biedt een complete set ontwikkeltools om software mee te ontwikkelen. Deze ontwikkeltools houden onder andere in: een code editor voor de verschillende talen, een debugger om fouten in je code op te sporen, een visueel ontwerpen voor het maken van (dialoog)vensters en een profiler voor het analyseren van onder andere de uitvoersnelheid en het geheugengebruik van andere applicaties. De standaard editie komt met de talen Visual Basic.Net, C#, F# en C++.
Visual Studio 2015 is gebruikt voor de ontwikkeling van het eindproduct.
5.3 Team Foundation Server
De Team Foundation Server is een Microsoft product dat zorgt voor versiebeheer, rapportage, requirements management, project management, testen van software, release management en meer. Het wordt volledig ondersteund in Visual Studio.
De Team Foundation Server is gebruikt voor het versiebeheer.
5.4 .NET Framework
Het .NET Framework is een applicatie framework ontwikkeld door Microsoft. Het zorgt voor een samenwerking tussen applicaties en bibliotheken. Het .NET Framework maakt het mogelijk dat elk ondersteunde programmeertaal code kan gebruiken van andere programmeertalen.
Het .NET Framework is gebruikt voor de ontwikkeling van het eindproduct.
5.5 Windows Presentation Foundation
De Windows Presentation Foundation is een grafisch subsysteem van het .NET Framework. Het maakt het mogelijk om geavanceerde grafische interfaces te ontwikkelen. Zo’n interface wordt ontwikkeld met het programmeermodel XAML. De Windows Presentation Foundation onderscheidt zich doordat het met de resolutie mee schaalt.
De Windows Presentation Foundation is gebruikt tijdens de ontwikkeling van de gebruikersinterface van het eindproduct.
5.6 C#
C# is een programmeertaal ontwikkeld door Microsoft als deel van het .NET-initiatief. C# is een objectgeoriënteerde taal dat wordt gezien als de belangrijkste taal voor het .NET Framework. C# is gebruikt als programmeertaal voor de ontwikkeling van het eindproduct.
5.7 XAML
Extensible Application Markup Language (XAML) is een opmaaktaal gebaseerd op XML. Het wordt vooral gebruikt om de grafische interface te ontwikkelen in een Windows Presentation Foundation applicatie.
XAML is gebruikt tijdens de ontwikkeling van de gebruikersinterface van het eindproduct.
5.8 XML
Extensible Markup Language (XML) is een standaard formaat voor het opslaan van gestructureerde data. XML is tekst gebaseerd en leesbaar voor zowel de machine als de mens.
XML is gebruikt om gebruikersinstellingen van het eindproduct op te slaan en uit te lezen op de lokale computer.
5.9 Bluetooth
Bluetooth is een open standaard voor draadloze verbindingen tussen apparaten op korte afstand. Een voorbeeld van een Bluetooth toepassing is het handsfree bellen waar de telefoon een draadloze verbinding heeft met de headset.
Bluetooth is gebruikt om een verbinding tot stand te brengen tussen het eindproduct en een hartslagband en tussen het eindproduct en fitness apparatuur.
6
Keuzes
6.1 Keuzes vanuit Vital
Enkele keuzes zijn door Vital gemaakt. Deze worden hieronder beschreven. 6.1.1 Programmeertaal
Als programmeertaal is C# gekozen. Hier waren meerdere redenen voor.
Vital is bekend met de programmeertaal C#. Daarom Is het voor Vital handig om de nieuwe applicatie ook in C# te laten ontwikkelen. Zo kan Vital de applicatie ook na mijn stage nog goed blijven
onderhouden.
Ook lag C# als programmeertaal voor de hand omdat we te maken hadden met legacy software. De oude applicaties zijn in C# geschreven. Door voor de nieuwe applicatie dezelfde programmeertaal te gebruiken konden sommige stukken code (met de nodige aanpassingen) worden hergebruikt. Dit zou de ontwikkeling versnellen. Ook is de server geschreven in C#. Daarom bevorderd het voor Vital ook de consistentie om voor de server en de client dezelfde programmeertaal te gebruiken.
Op de server van Vital worden rapporten gegenereerd met de resultaten van een uitgevoerde test. In deze rapporten worden grafieken gemaakt met o.a. de hartslag data en de berekende waardes. Om deze grafieken te maken wordt een framework van Telerik gebruikt. Telerik biedt naast een
framework voor websites, ook de mogelijkheid grafieken te maken voor client applicaties. Echter ondersteunt Telerik voor Windows alleen de taal C#. Vital wil in de client applicatie dezelfde grafieken maken als op de website worden gemaakt. Mede daarom is C# gekozen als programmeertaal.
6.1.2 Versiebeheer
Voor het versiebeheer is gekozen voor de Team Foundation Server. Deze keuze is gemaakt omdat de andere projecten van Vital hier ook mee werken. Om consistentie te behouden is hier opnieuw voor gekozen.
6.2 Ontwikkelmethode
Als ontwikkelmethode is er gekozen voor Scrum. Hier is voor gekozen omdat er een volledige applicatie naar de wens van de opdrachtgever wordt gemaakt. Wensen van opdrachtgevers kunnen wel eens veranderen over tijd of omdat het resultaat toch niet helemaal is zoals het was voorgesteld. Om dit te voorkomen zijn deel opleveringen ideaal. Zo kan de opdrachtgever het resultaat tot zo ver toe zien en direct beoordelen. Als zijn wensen dan veranderen kan dit meteen meegenomen worden in de vervolgontwikkeling. Scrum zorgt ervoor dat de ontwikkelde applicatie inderdaad aan de wensen van de opdrachtgever voldoet en er geen onverwachte ontevredenheden plaatsvinden bij de uiteindelijke oplevering.
6.3 Project template
Voor het ontwikkelen van een applicatie biedt Microsoft verschillende project templates aan. Hieronder worden deze project templates benoemt met wat het inhoudt en waarom ik deze wel of niet heb gekozen.
6.3.1 Windows Presentation Foundation Application
Een Windows Presentation Foundation (oftewel: WPF) Application is een vrij nieuw presentatie systeem voor het ontwikkelen van applicaties. Het is ontworpen om resolutie onafhankelijk te zijn. Dit wil zeggen dat het niet uitmaakt of de applicatie op een klein of een groot scherm wordt uitgevoerd. Ook kan de applicatie zonder problemen kleiner of groter worden gemaakt door de gebruiker.
In een WPF applicatie wordt de gebruikersinterface gemaakt via XAML (Extensible Application Markup Language). Via XAML is de hele gebruikersinterface in tekst op te schrijven. Dit is dan ook goed gescheiden van de achterliggende code. Hierdoor zijn aanpassingen zoals een tekstlabel omzetten naar een tekstveld gemakkelijk te realiseren. De applicatie blijft dan makkelijker te onderhouden als de gebruikersinterface veranderd moet worden.
Verder ondersteunt een WPF applicatie meerdere technieken om een zo goed mogelijke gebruikerservaring te creëren. Zo ondersteunt het bijvoorbeeld animaties, 2-D en 3-D beelden, media, documenten en stijlen.4
Een WPF applicatie heeft vele mogelijkheden en is gemakkelijk te onderhouden. Echter is het wel iets meer werk te programmeren. Dit is mede doordat je een geavanceerdere gebruikersinterface
ontwikkeld. Hoewel het bij het begin meer werk is te ontwikkelen, is het achteraf minder werk te onderhouden. Omdat Vital van plan is deze applicatie nog lang te gaan onderhouden en samen met de geavanceerdere technieken die WPF biedt, is dit een goede keus om de opdracht mee te
realiseren. Daarom heb ik dit template gekozen om mijn opdracht mee uit te voeren. 6.3.2 Windows Forms Application
Windows Forms Applications zijn programma’s die bestaan uit een of meerdere visuele
oppervlakken. De visuele weergave is meestal simpel en eenvoudig te ontwikkelen. Bediening als knoppen en tekstvelden zijn eenvoudig in het oppervlak te slepen. Zodra de gebruiker dan iets met deze bediening doet, zal de bijbehorende code worden uitgevoerd.
Windows Forms Applications waren vroeger altijd zeer populair bij .NET ontwikkelaars. Hedendaags worden ze meestal alleen nog gebruikt voor de simpelere applicaties. Dit omdat er momenteel een beter alternatief is voor grotere projecten, namelijk WPF. Bij een Windows Forms Application wordt de achterliggende code direct aan de bediening gekoppeld. Dit creëert een zogenaamde tight coupling5. Dat wil in dit geval zeggen dat als je de bediening aan wilt passen, je ook direct de achterliggende code moet aanpassen.
Het te ontwikkelen programma dient onderhoudbaar te zijn en de grafische gebruikersinterface zal zeer waarschijnlijk meerdere keren moeten worden aangepast tijdens de ontwikkeling. Omdat Windows Forms Applications last hebben van tight coupling en daardoor moeilijker te onderhouden zijn, is dit niet de ideale keuze voor het te ontwikkelen programma.
6.3.3 Windows Universal App
Dit is een applicatie gemaakt voor de Windows Store. Deze applicatie kan dan eventueel worden uitgebreid om ook op een Windows Phone te draaien. Dit is mogelijk door de gebruikersinterface te onderscheiden van de achterliggende code. Zo kun je een interface voor beide platforms maken die dezelfde achterliggende code gebruiken. Windows Store en Windows Phone gebruiken beide .NET Core6. Dit is waar je de applicatie op bouwt en waar de applicatie op uitgevoerd wordt. Het is een compacte versie van .NET Framework dat voor desktop applicaties wordt gebruikt.
Een van de eisen van de opdracht was dat de applicatie moest kunnen communiceren met een hartslagband via een seriële Bluetooth verbinding. Dit is helaas niet mogelijk in een Windows Store app.7 Dit speelde een grote rol in de beslissing om geen Windows Store App te ontwikkelen. Verder is uit onderzoek gebleken dat mensen de Windows Store apps niet veel gebruiken.8 De meeste mensen gebruiken alleen enkele simpele apps voor e-mails, foto’s of bijvoorbeeld
takenlijstjes. Er bestaat dus een risico dat mensen de applicatie niet of weinig gaan gebruiken als er voor een Windows Store App wordt gekozen.
6.3.4 Overige mogelijkheden
De overige applicatie templates zijn vooral Mobile Applications, Web Applications en een Console Application. Aangezien de opdracht was om een Windows applicatie te ontwikkelen met een gebruikersinterface, voldoen deze project templates niet aan de eisen van de opdracht.
6.3.4.1 Mobile Applications
Mobile Applications worden ontwikkeld voor de Windows Phone. Dit is dus een telefoon applicatie die niet op een Windows computer zal werken. Ook omdat Vital al een telefoon applicatie in ontwikkeling heeft en een tweede telefoon applicatie niet gewenst was, is dit template snel afgevallen.
6.3.4.2 Web Applications
Web Applications zijn applicaties die draaien op een website. Simpel gezegd dus een website. Een website voldoet niet aan de eisen van de opdracht. Dit niet per se omdat de eis een Windows applicatie was, maar meer omdat het programma moet kunnen communiceren met hartslagbanden en fitness apparatuur. Via een website is dit niet mogelijk en dus viel deze keuze ook af.
6.3.4.3 Console Application
Een console Application is een programma dat uitgevoerd wordt in een command prompt. Hier is alleen een op tekst gebaseerde interface op mogelijk. Je kunt hier dus geen knoppen of andere elementen in laten zien. Ook kun je hier niet de grafiekjes in tekenen die wel weergegeven moesten worden. Deze keuze viel af omdat er geen grafische interface mogelijk was.
6 Auteur onbekend, .NET Core, https://en.wikipedia.org/wiki/.NET_Framework#.NET_Core, (2016)
7 Eric Hanson-MSFT, Forum post,
https://social.msdn.microsoft.com/Forums/en-US/6bdaa46f-fa49-4854-a97b-81b003ef3495/serial-port-access-for-metro-app?forum=tailoringappsfordevices, (2012)
8 Soluto, Windows 8 Metro apps usage,
6.3.5 Keuze
Een WPF applicatie is iets meer programmeerwerk maar maakt het mogelijk om geavanceerdere gebruikersinterfaces te ontwikkelen ten opzichte van de andere mogelijkheden. Ook is het met een WPF applicatie mogelijk om goed de gebruikersinterface te onderscheiden van de achterliggende code. Dit maakt de applicatie gemakkelijker te onderhouden. Vital is van plan de ontwikkelde applicatie nog lang te gaan onderhouden. Om die reden, samen met de mogelijkheid tot het
ontwikkelen van een geavanceerdere gebruikersinterface, heb ik gekozen om een WPF applicatie te ontwikkelen.
6.4 Lokalisatie
Eén van de eisen van de applicatie is dat hij in het Nederlands moet zijn. Echter is er tijdens een tussenoplevering duidelijk geworden dat de applicatie later eventueel naar het Engels vertaald dient te worden. Het is dus van belang dat dit mogelijk is. Daarom is ervoor gekozen om alle teksten in een resource bestand te zetten. De applicatie zal dan in het resource bestand zoeken naar welke tekst hij op in het venster moet plaatsen. Op deze manier is het eenvoudig om een nieuw resource bestand toe te voegen in een andere taal.
Deze benadering is mogelijk met de standaard ontwikkeltools van Visual Studio maar ook met 3rd party tools. Het belangrijkste verschil tussen de twee is dat de 3rd party tools het mogelijk maakte de taal tijdens het uitvoeren van de applicatie te veranderen. Dit is niet mogelijk met de standaard ontwikkeltools van Visual Studio tenzij je alle vensters opnieuw opbouwt.
Het veranderen van de taal in de applicatie is geen eis en hoeft geen rekening mee gehouden te worden. Door 3rd party tools te gebruiken creëer je een afhankelijkheid op die tool. Omdat er geen reden is om deze 3rd party tools te gebruiken, is er gekozen om de standaard ontwikkeltools van Visual Studio te gebruiken.
6.5 XML
In de nieuwe applicatie is het nodig om apparaat namen op te slaan. Deze apparaat namen kunnen door de gebruiker worden aangepast. Hier zouden dan Unicode karakters tussen kunnen zitten. Hierdoor vielen een aantal manieren van data opslag weg zoals: ini-bestanden9. XML kan Unicode karakters echter wel correct opslaan. Omdat de taal C# een hoop functies heeft om XML op te slaan en uit te lezen10 en XML het toestaat om Unicode karakters op te slaan en uit te lezen, is er gekozen om data op te slaan in XML.
7
Techniek
Tijdens de ontwikkeling van het eindproduct zijn een aantal technieken gebruikt. Deze technieken zijn hieronder beschreven.
7.1 Design patterns
Design patterns zijn oplossingen voor herhalende problemen die ontstaan tijdens het ontwerpen van object georiënteerde code. Over het algemeen zorgen design patterns voor code dat beter te
onderhouden is door een goede structuur aan te brengen en zorgt het voor code waar minder snel fouten in worden gemaakt doordat het goede scheidingen maakt tussen verantwoordelijkheden van stukken code.
Hieronder zijn een aantal design patterns beschreven die voor de ontwikkeling van het eindproduct zijn gebruikt. In Figuur 1 is een UML class diagram weergegeven met enkele van deze design patterns erin verwerkt.
7.1.1 Factory method
De factory method is een manier om objecten te initialiseren zonder exact te hoeven vaststellen van welke klasse dit object is. Dit was vooral handig voor het initialiseren van een object dat zorgt voor een verbinding met een LifeFitness of DAUM fitness apparaat. De factory method bepaald a.d.h.v. de gegeven argumenten welk object hij teruggeeft.
7.1.2 Singleton
Singleton is een design pattern dat ervoor zorgt dat een klasse maar één keer geïnstantieerd wordt. Dit betekent dus dat er maar één object beschikbaar zal zijn van die klasse. Dit is gebruikt voor de klasse die de opgeslagen data beheerd zoals inloggegevens en opgeslagen apparaten omdat er nooit meer dan één instantie van nodig is. Als er meerdere instanties zouden worden gemaakt kan dit problemen veroorzaken waarbij de data verouderd is of wordt overschreven met oude data. 7.1.3 Bridge
Het doel van het bridge design pattern is om de abstractie en de implementatie van een bepaalde klasse los te koppelen van elkaar zodat de twee onafhankelijk van elkaar kunnen variëren. Dit is gebruikt voor de klasse die zorgt voor een verbinding met een fitness apparaat. Via bridge wordt de type verbinding meegegeven. Zo wordt bijvoorbeeld een Bluetooth verbinding gebruikt maar kan dit in de toekomst ook heel gemakkelijk worden uitgebreid om ook een andere type verbinding te ondersteunen.
7.1.4 Command
Een command is een object dat alle informatie bevat om een actie uit te kunnen voeren. Dit is gebruikt om het MVVM pattern te implementeren. Onderdelen van de gebruikersinterface die acties moeten uitvoeren worden gelinkt aan een command. Dit command voert dan zijn implementatie uit. 7.1.5 Observer
Een observer is een object dat via een ontkoppelde manier kennis kan nemen van
toestandsveranderingen van een ander object. De taal C# heeft hier een eigen implementatie voor, namelijk een event. Een object kan zich inschrijven bij een event om geïnformeerd te worden bij een toestandsverandering. Een voorbeeld van hoe dit is gebruikt is de member lijst. Er zijn meerdere vensters die de memberlijst nodig hebben en via events is ervoor gezorgd dat elk venster met dezelfde lijst kan werken en niet eerst onnodig hoeft te verversen.
7.1.6 MVVM
Model–View–ViewModel (MVVM) is een design pattern dat ontworpen is om de gebruikersinterface los te koppelen van de achterliggende code. Dit maakt het mogelijk om een designer de
gebruikersinterface te laten ontwikkelen terwijl de programmeurs de achterliggende code ontwikkelen. Ook zorgt dit voor een flexibele gebruikersinterface doordat je deze kan aanpassen zonder de achterliggende code te hoeven benaderen. Dit design pattern is gebaseerd op Model-Controller-View (MVC) dat vaak bij websites wordt toegepast.
7.2 UML
Voor belangrijke software ontwerpen is een UML class diagram gemaakt om vooraf het
programmeren vast te leggen hoe de code structuur eruit komt te zien. Denk hierbij aan de code die zorgt voor de verbinding tussen verschillende soorten fitness apparaten of de code die zorgt voor de verbinding met de hartslag banden.
Om tot een goedgekeurd ontwerp te komen maakte ik eerst zelf een ontwerp waarvan ik op dat moment tevreden was. Dit ontwerp besprak ik dan uitgebreid met mijn begeleider die hier meestal veel leerzaam commentaar op kon geven. Na dit gesprek paste ik het ontwerp aan op het gegeven commentaar. Als het dan werd goedgekeurd begon ik aan het programmeren. Zie Figuur 1 voor een voorbeeld van een goedgekeurd ontwerp.
Figuur 1 - Een UML class diagram van de code die verantwoordelijk is voor de verbinding tussen een fitness apparaat van het merk LifeFitness en DAUM. Design patterns die hierin verwerkt zitten zijn: factory method, bridge en observer.
7.3 Unit testen
Unit testen is een methode om stukjes code afzonderlijk te testen. Hierbij worden alle functionaliteiten van een stukje code dat je wilt testen op één plek gezet. Unit testen kunnen gebruikt worden om te testen of de gemaakte code correct is. Omdat de unit testen bij elkaar staan zijn deze gemakkelijk uit te voeren om te controleren of alles correct werkt voordat de applicatie uitgeleverd wordt. Ook kunnen unit testen van pas komen bij het herstructureren van stukken code. Als de code is aangepast kunnen de unit testen gemakkelijk worden uitgevoerd om te controleren of dezelfde output gegenereerd wordt.
In de ontwikkeling van het eindproduct zijn op zo veel mogelijk plekken unit testen gemaakt om de kans op bugs te minimaliseren.
8
De applicatie
In dit hoofdstuk is te vinden wat de eisen van de applicatie zijn en hoe de applicatie is opgebouwd.
8.1 Eisen
De nieuwe applicatie moet een client-server applicatie zijn. Dat wil zeggen dat de applicatie moet communiceren met een server om data te versturen en ontvangen. In dit geval moet de applicatie communiceren met de bestaande Vital server. Deze server beheert alle account gegevens en opgeslagen test data. Ook zorgt deze server voor het berekenen van data als ademhaling, aerobe en anaerobe omslagpunten, rust metabolisme, trainingsintensiteit en meer.
De functionaliteiten van de oude applicaties moeten verwerkt zitten in de nieuwe applicatie. De nieuwe applicatie moet daarom in staat zijn om een ATDS test, een Vitality test en een Team test uit te voeren. Ook moet het gegevens kunnen beheren zoals: member gegevens en trainingsgroep gegevens.
De nieuwe applicatie moet gebruiksvriendelijker zijn. Hiervoor is het gebruikersonderzoek uitgevoerd. De resultaten van het gebruikersonderzoek dienen verwerkt te zitten in de
gebruikersinterface. Daardoor zullen de negatieve gebruikerservaringen van de oude applicaties worden vermeden en ontstaat er een gebruiksvriendelijkere applicatie.
Een lijst met de exacte eisen voor de nieuwe applicatie is te vinden in Bijlage C – Vital applicatie eisen.
8.2 MVVM
Voor de ontwikkeling van de gebruikersinterface en de bijbehorende logica, is het MVVM design pattern gebruikt. De gebruikersinterface en de bijbehorende logica staan daarom los van elkaar. Dit zorgde ervoor dat eventuele veranderingen in de gebruikersinterface makkelijker te realiseren waren.
De applicatie heeft één
hoofdvenster dat altijd open staat. Dit hoofdvenster bevat de basis opmaak van de applicatie. Zo is hier het logo in opgenomen en bevat het een simpele opmaak voor de achtergrond om de applicatie wat aantrekkelijker te maken. In dit hoofdvenster wordt de juiste View gekozen en weergegeven. De gekozen View wordt dan in het
hoofdvenster geplaatst. Figuur 2 - Het hoofdvenster van de applicatie. Hier wordt de juiste View in gekozen en weergegeven.
8.2.1 Data binding
Het koppelen van de logica aan de gebruikersinterface gaat met data binding. In een View heb ik aangegeven met welk ViewModel hij moet gaan werken. De elementen van de View heb ik aan het gekozen ViewModel gekoppeld. Op deze manier kan de View data weergeven uit en data sturen naar het ViewModel. Denk hierbij aan de tekst van een tekstveld of het uitvoeren van een actie na het indrukken van een knop. Zie Figuur 3 voor een voorbeeld van hoe data binding is gebruikt voor het koppelen van een knop aan een ViewModel.
8.3 Deelvensters
Omdat de functionaliteiten van de twee oude applicaties van Vital zijn samengevoegd tot een nieuwe applicatie, heb ik gekeken naar wat deze functionaliteiten gemeenschappelijk hadden. Voor de gemeenschappelijke functionaliteiten heb ik deelvensters gemaakt. Deze deelvensters kunnen dan op meerdere plekken geplaatst worden om dubbele
ontwikkelingen te voorkomen. Ook kan het ervoor zorgen dat de code complexiteit van een venster verkleind wordt doordat een deel van de code zal worden verplaatst naar het
deelvenster.
Een voorbeeld van een gemeenschappelijke functionaliteit is de memberlijst. Deze memberlijst, te zien in Figuur 4, is op meerdere plekken in de applicatie noodzakelijk. Omdat hier een deelvenster van is gemaakt, is voorkomen dat deze
functionaliteiten dubbel ontwikkeld zijn. Ook heeft het de code complexiteit verkleind in de vensters waar de memberlijst in geplaatst is.
8.4 Lokalisatie
Om lokalisatie te ondersteunen zijn de standaard Visual Studio ontwikkeltools gebruikt. Hier wordt gebruik gemaakt van één of meerdere resource bestanden. In een resource bestand staan alle teksten opgeslagen die naar de gebruiker gepresenteerd zullen worden. Zo heeft de ontwikkelde applicatie momenteel één resource bestand voor alle Nederlandstalige teksten. Doordat de applicatie is ontwikkeld om dit te ondersteunen, is in de toekomst gemakkelijk een Engelstalig resource bestand toe te voegen. Zodra de applicatie wordt geopend, zal het detecteren in welke taal Windows staat geconfigureerd op de betreffende computer. Als dit bijvoorbeeld Engels is, zal de applicatie het Engelstalige resource bestand proberen te gebruiken. Indien de gedetecteerde taal niet beschikbaar is, zal de applicatie terugvallen op zijn standaard taal. De standaard taal is Nederlands.
Figuur 4- Een voorbeeld van een deelvenster. Dit deelvenster laat de memberlijst zien met relevante functionaliteiten.
Figuur 3 - Een stuk XAML code dat weergeeft hoe de actie van een knop met data binding wordt gekoppeld aan een actie van een ViewModel.
8.5 Server communicatie
Het opslaan of ophalen van account gegevens en test data, moet via de server. Ook is de server verantwoordelijk voor het berekenen van de test data. De applicatie moet dus kunnen
communiceren met de server.
De server had al een bestaande API die voor deze functionaliteiten zorgde. Deze API wordt gebruikt door de oude applicaties. Het gebruikt HttpPost om data te ontvangen en te versturen. Deze API is overgenomen in de nieuwe applicatie. Omdat het bij veel delen van de API nodig was de code te herstructureren en omdat het soms nodig was de respons van een functie van de API aan te passen, heb ik de bestaande API gekopieerd en in een nieuwe locatie gezet. Op deze manier kon ik de nodige aanpassingen maken zonder de functionaliteit van de oude applicaties aan te passen.
8.6 Bluetooth
Eén van de eisen voor de applicatie was dat het moest kunnen verbinden met fitness apparatuur van LifeFitness en DAUM. Ook moest de applicatie kunnen verbinden met een Zephyr BioHarness3 hartslagband. Om te kunnen communiceren met deze apparaten was Bluetooth over een seriële poort nodig. De applicatie scant naar apparaten en zal dan proberen het apparaat te identificeren. Als de applicatie het apparaat herkent, zal het proberen ermee te verbinden. Als dat lukt, zal de applicatie het apparaat configureren om de juiste data door te sturen. De applicatie zal dan de data dat het apparaat opstuurt ontvangen en op de juiste wijze behandelen.
8.7 Applicatie stijl
Om de applicatie wat aantrekkelijker te maken heb ik in XAML een stijl ontwikkeld dat toegepast wordt op meerdere elementen van de gebruikersinterface. Deze stijl wordt in de gehele applicatie toegepast. Een voorbeeld is dat de tekst donkerrood wordt weergegeven. Een ander voorbeeld is dat de buitenrand van een tekstveld zwart is maar lichtrood wordt als de muis erop staat en uiteindelijk fel rood wordt als het gefocust is.
8.8 Grafieken
Na het opsturen van de ruwe data naar de server, stuurt de server de berekende waardes terug. Deze berekende waardes moeten worden gepresenteerd aan de gebruiker in een grafiek. Het ademhaling signaal en de ECG data van de hartslagband moet ook met behulp van een grafiek worden gepresenteerd. Om grafieken te kunnen maken gebruikt Vital uitbreidingspakketten van Telerik11. Deze zijn ook in de ontwikkelde applicatie gebruikt.
De grafiek die de berekende resultaten moet weergeven, moet meerdere lijnen data bevatten. Om deze lijnen van elkaar te onderscheiden zijn dezelfde kleuren gebruikt als Vital momenteel op de website gebruikt.
