Detailed Design

IDE

We hebben gekozen om Android studio als IDEA te gebruiken omdat we vinden dat je voor een android applicatie hierin je het beste de GUI kan designen.

Meertalige mogelijkheden

Omdat onze applicatie gemaakt wordt voor een bedrijf waarbij de twee voertalen Engels en Nederlands zijn, worden deze beide talen geïmplementeerd.

Richtlijnen prototype

Hoofdstuk 15:

Onze applicatie is een applicatie die eigenlijk in zijn geheel en grotendeels niet vergelijkbaar is met een object vanuit die realiteit. Als we dan kijken naar een gedeelte van de app, is er wel iets. Dit is de kalender die naast het hoofd overzicht van ruimtes staat. Deze heeft sterke eigenschappen van een “echte” kalender. Zo kun je naar links en rechts swipen dan het effect nabootst van door een kalender heen bladeren.

Hoofdstuk 16:

Onze applicatie maakt geen gebruik van gestures (op de kalender na). Er zijn eigenlijk alleen knoppen die je kan indrukken. Wanneer je een keuze moet maken, zoals wie je bent, en je selecteert een element uit een lijst, zie je meteen wat je hebt geselecteerd d.m.v. highlighting. Deze techniek wordt gebruikt op meerdere plaatsen in onze app, omdat dit direct feedback is naar de gebruiker.

Hoofdstuk 17:

De applicatie die wij maken is een tablet-applicatie, maar de tablet is vastgemaakt aan een muur waardoor de “easily reached areas” eigenlijk het hele scherm is. Daarom hoeven we hier minder rekening mee te houden. Verder hebben we gezorgt dat de knoppen op de applicatie groot zijn en er een duidelijke marge zit tussen 2 knoppen.

Hoofdstuk 18:

Onze app bevat een duidelijke animatie, dit is het draaiende Isaac logo wanneer er iets wordt geladen/handeling word verwerkt. Een voorbeeld wanneer je dit te zien krijgt is op het splashscreen, wanneer er verbinden gemaakt wordt met de server app. Dit is de enige animatie in de app, en dit is gedaan omdat er verder geen dingen zijn waarbij dit een duidelijke toegevoegde waarde zal hebben.

Hoofdstuk 19:

In onze applicatie zien alle schermen er ongeveer hetzelfde uit. Omdat een groot deel van onze applicatie schermen hergebruikt met een ander kleurtje en iets andere tekst, hebben wij ervoor gezorgd om deze allemaal consistent hetzelfde te maken. Zo zitten bijvoorbeeld de buttons op dezelfde plek en het is duidelijk wat een button is en wat niet. Hierdoor kan de gebruiker gemakkelijk navigeren tussen verschillende schermen.

Hoofdstuk 20:

Het doel van onze applicatie is het gemakkelijker en sneller maken van het vinden en reserveren van een vergaderruimte. Om dit te bereiken hebben we de belangrijke informatie in het midden van het scherm gezet met hier omheen wat minder belangrijke functionaliteit. In het midden staat de status van de ruimte en de knop om deze te reserveren. De informatie over de ruimte zelf is wat minder belangrijk en staat dus ook kleiner vermeld op het scherm. Mocht de ruimte bezet zijn dan is er een knop die direct zichtbaar is waarmee de gebruiker alle vrije ruimtes kan opvragen. Functionaliteit zoals het verlengen en beëindigen van vergaderingen is alleen zichtbaar en bereikbaar als de vergadering daadwerkelijk bezig is. Dit hebben wij zo gedaan omdat dit functionaliteit is die tevens ook via Exchange online bereikbaar is.

Hoofdstuk 21:

Onze applicatie is voor een groot deel zelf regulerend. Als er een vergadering begint dan springt de applicatie vanzelf op het gereserveerd scherm. Als deze niet op tijd gestart wordt dan springt hij ook vanzelf weer terug. De enige keer dat een gebruiker zelf input moet geven is als hij/zij een vergadering wil inplannen. Hierbij is er alleen keuze uit een aantal opties die vooraf bepaald zijn zodat er geen fouten kunnen ontstaan door verkeerde user input. Mocht er toch iets fout gaan dan wordt hier wel een melding weergegeven maar deze melding blokkeert de applicatie niet. Hierdoor wordt de gebruiker er wel op geattendeerd maar de verdere functionaliteit van de applicatie niet geblokkeerd.

Hoofdstuk 22:

In dit hoofdstuk wordt aangegeven dat gebruikers niet geïnteresseerd zijn in waarschuwings pop ups omdat ze daar simpelweg geen zin in hebben en denken dat ze alles goed doen.
In de applicatie hebben we de tips die gegeven worden in hoofdstuk 22 toegepast waar mogelijk.
In de vergader applicatie worden geen waarschuwings pop ups weergegeven. Bij het maken, starten, verlengen en beëindigen van vergaderingen kun je dit niet ongedaan maken in de vergader applicatie dit is een keuze die gemaakt is tijdens de ontwerpfase. We hebben hiervoor gekozen omdat de vergaderapplicatie ook altijd in verbinding staat met exchange/outlook waar je jouw gemaakte actie altijd kan annuleren of aanpassen.

Hoofdstuk 23:

In dit hoofdstuk wordt aangegeven dat modes verwarring veroorzaken bij gebruikers als ze niet goed gedesigned zijn. Bijvoorbeeld wanneer er meerdere modes langs en over elkaar worden weergegeven of wanneer het niet duidelijk is hoe je terug kunt gaan naar een ander mode.
In de vergader applicatie hebben we dit aangepakt door:
Je altijd een modes kan sluiten door op een duidelijk close button te drukken die altijd op dezelfde plek staat.
Er altijd maar een mode tegelijk te zien krijgt
Dat je altijd terug kunt gaan door op de terug button te drukken die altijd in android zichtbaar is

Hoofdstuk 24:

In dit hoofdstuk wordt aangegeven dat je de gebruiker zo min mogelijk opties moet geven om aanpassingen te maken aan je applicatie omdat ze minder verstand van de applicatie hebben dan de maker ervan.

In de vergader applicatie is dit hoofdstuk is dit niet van toepassing omdat de gebruiker geen instellingen heeft en ook niet kan aanpassen aan de werking en het uiterlijk of iets dergelijks.

Werkverdeling

Eric:

  • Richtlijnen protoype hoodstuk 15 t/m 18

Tim:

  • Meertalige mogelijkheden
  • Richtlijnen protoype hoodstuk 19 t/m 21

Bram:

  • IDEA
  • Richtlijnen protoype hoodstuk 22 t/m 24
  • Blog
Geplaatst in Weeks 1 - 4.