Effecten van het digitaal verzamelen van feedback
Robin Masters 2-8-2012
Woord vooraf
Dit onderzoek en het document dat voor u ligt is de uitkomst van vijf maanden intensief onderzoeken, ontwerpen en ontwikkelen bij Ranshuijsen van Loon.
Feedback, de kern van dit document, is iets waar ik erg in geïnteresseerd ben. De resultaten van dit onderzoek zal ik in de loop van mijn carrière blijven gebruiken .
Met dit onderzoek is er een einde gekomen aan een mooi studentenleven en ben ik klaar om de wereld in te gaan, maar voordat ik vertrek wil ik deze mogelijkheid gebruiken om een aantal mensen te bedanken.
Allereerst wil ik alle docenten bedanken die mij les hebben gegeven. Van deze docenten wil ik Joop Blankert, Arend Keemink, Wendy van IJperen en A.S.M.Chin See Chong-Bérénos extra bedanken voor het begeleiden tijdens mijn afstudeertraject.
Voor het mogelijk maken van deze fantastische opdracht wil ik Rim Ranshuijsen en Mathieu van Loon bedanken. Dankzij hen kon ik één van mijn interesses en mijn ideeën onderzoeken en uitwerken. Voor deze kans zal ik hun altijd dankbaar zijn.
Als laatste wil ik mijn moeder Annemarie en mijn buren Patrick en Corina Schilperoord bedanken voor de ondersteuning die zij mij hebben gegeven in heel mijn studentenleven.
Ik wens u veel leesplezier toe en hoop dat u net zoveel opsteekt van dit onderzoek als ik.
Robin Masters Rotterdam, augustus 2012
Executive summary
Ranshuijsen van Loon (RVL) creates software for various branches and companies. RVL aims to create their software as user friendly as possible, because most of the users use the software on a day-to-day basis. It is not good when users are unable to report a problem. These problems can build up and cause irritations.
Reports - amongst others - consist of user experiences and wishes in usability and functionality for an application. They are a source of feedback for the developers. At this time feedback is reported via telephone or e-mail. The result is a cluttered and incomplete dataset. Information can be lost or the report itself can be incomplete. A lot of users do not have the possibility to directly contact the support desk. In this paper the effects of digitally collecting these reports is researched.
Before the effects can be measured a market research will look for the tools and possibilities available today. The research concludes that there is no tool available that satisfies the requirements of RVL. A decision was made to create a new prototype.
This prototype allows users to report problems and ask questions which a support desk can then try to resolve. Two-way communication between the support desk and the application users is possible when needed. Both parties have the possibility to lookup reports and their communication history. This makes sure that both parties have complete knowledge of the status and progress of a report.
By using a digital feedbacktool the amount of time needed for a report is reduced. The quality of the reports is improved because the tool automatically collects required data. No information is forgotten by users because they can create a report immediately. Every user now has the possibility to provide feedback which increases the volume and scope. The status and progress for a report can be monitored in the overview. The amount of interruptions via telephone and e-mail has dropped. The developers can now spend more time on developer tasks.
Costs are reduced due to the fact that reports need less time creating by users and handling by the support desk.
The usage of telephone and e-mail is reduced drastically but will not disappear because people like personal contact. Combining the methods allows for a streamlined process.
Samenvatting
Ranshuijsen van Loon (RVL) maakt software voor veel verschillende branches en bedrijven. RVL streeft er naar om de gebruikservaring van deze software zo prettig mogelijk te maken. Want de gebruikers gebruiken de software meestal dagelijks. Wanneer gebruikers met een probleem zitten, is het niet goed als zij dit nergens kunnen melden. De problemen kunnen zich gaan opstapelen en zorgen voor irritaties.
De meldingen bestaan onder andere uit ervaringen en wensen in gebruiksgemak en functionaliteit van de applicatie en zijn dus feedback voor de ontwikkelaars. Momenteel wordt feedback telefonisch of via e-mail gemeld. Dit zorgt voor een onoverzichtelijk en incompleet beeld.
Informatie kan verloren raken of incompleet worden aangeleverd. Ook is het voor veel gebruikers niet mogelijk om direct contact op te nemen met RVL of een partij die support moet leveren. In dit onderzoek wordt er gekeken wat het effect is van het digitaal verzamelen van deze meldingen.
Door middel van een marktonderzoek wordt er gekeken naar de huidige mogelijkheden. Uit dit marktonderzoek blijkt dat er geen tool bestaat wat aan de eisen van RVL voldoet. Dit heeft er voor gezorgd dat er aan de hand van de eisen een eigen prototype is gemaakt.
Het prototype geeft de gebruiker van een applicatie de mogelijkheid om een melding te doen die door de support kan worden afgehandeld. Daarna kan de support communiceren met de gebruiker wanneer dat gewenst is. De support en de gebruiker hebben beide een overzicht van alle meldingen en de communicatie historie. Dit zorgt ervoor dat beide partijen een duidelijk beeld hebben van de vooruitgang en status van een melding.
Het gebruik van de digitale feedbacktool zorgt ervoor dat minder tijd nodig is om een melding af te handelen. De kwaliteit wordt verhoogd doordat de tool automatisch benodigde gegevens verzamelt en de gebruiker niet wacht met melden waardoor er weinig tot geen details worden vergeten. Elke gebruiker heeft nu de mogelijkheid om feedback te geven, wat zorgt voor een groter volume en bereik. Het overzicht zorgt er voor dat de meldingen of details daarvan niet verloren kunnen gaan. Ontwikkelaars worden minder via de e-mail of telefonisch gestoord door gebruikers.
Hierdoor kunnen de ontwikkelaars zich meer focussen op de ontwikkeltaken.
Deze tijdswinst zorgt ook voor minder kosten aan beide kanten omdat de onderbreking van de gebruiker minder lang is en ontwikkelaars minder tijd nodig hebben om een melding af te handelen.
Het gebruik van e-mail of de telefoon wordt sterk verminderd maar zal niet helemaal verdwijnen, omdat mensen graag persoonlijk contact hebben. Door combineren van de methodes kan er wel worden gezorgd dat het melden kan worden gestroomlijnd.
Verklarende woordenlijst
Wo o rden
Metrieken
De gemeten tijd of ruimte tussen minimaal twee metingen.
Smiley (of emoticon)
Grafische weergave van een gezichtje met een bepaalde uitdrukking. Deze worden door een klein icoontje weergegeven.
Screenshot
Een fotokopie van wat er op het beeldscherm wordt getoond. Hiermee kan er een weergave worden gemaakt van wat er op dit moment op het scherm wordt getoond.
Lean productieomgeving (Bicheno & Holweg, 2008)
Een managementfilosofie waarmee het productieproces wordt gestroomlijnd. De door Toyota bedachte gedachte zorgt ervoor dat productietijden worden verkort en versneld zodat de kosten laag blijven.
Aggregeren
Het samenvoegen van gegevens uit meerdere bronnen.
Metadata
Extra gegevens die eigenschappen geven aan de data.
Supportcall
Telefonisch gesprek met een klant. De klant belt op met een probleem in de applicatie.
JavaScript
Programmeertaal die vooral veel in webapplicaties voorkomt.
Plugin
Een stuk code die de werking van een bestaande applicatie aanvult.
Cross-browser
Wanneer een website of web applicatie correct werkt op meerdere browsers is deze applicatie cross-browser.
Cross-platform
Wanneer een applicatie op meerdere besturingssystemen werkt is deze cross-platform.
Community based
Forum waar gebruikers vragen stellen en beantwoorden.
Blog (afkorting van webblog)
Is een persoonlijke site waar een persoon een bericht op plaatst. Het wordt veelal gebruikt als het equivalent van een dagboek.
Afko rt ingen
FAQ : Frequently Asked Questions
Lijst van veelgestelde vragen met daarbij een antwoord.
HTML : HyperText Markup Language
Taal waarmee websites worden opgemaakt.
DOM : Document Object Model
Een model waardoor software de actuele HTML code kan inzien. Naast de code kunnen ook alle waardes worden gelezen.
URL : Uniform Resource Locator
Is informatie die verwijst naar een stuk data. Op een gestructureerde manier wordt onder andere de locatie, het bestandsnaam, authenticatie en protocol gedefinieerd.
API : Application Programming Interface
Een verzameling van functies en variabelen waarmee een programma met een ander programma kan communiceren.
AJAX : Asynchronous JavaScript and XML
JavaScript techniek waarmee asynchroon acties kunnen worden gestart op een back-end server.
Hierdoor kan een webapplicatie nieuwe inhoud krijgen of verwerken zonder dat de pagina moet worden ververst.
Leeswijzer
De eerste vijf hoofdstukken van dit document hebben een informerende inhoud. Dit wil zeggen dat hier informatie in staat die komt uit de literatuur, van het internet of uit ervaringen van de medewerkers van Ranshuijsen van Loon.
Daarna wordt er een hypothese opgesteld waarin de stellingen staan die door middel van het prototype worden bewezen. De uitkomsten hiervan zijn te vinden in de conclusie.
In de bijlagen wordt er dieper op een onderwerp ingezoomd. Wanneer u meer wilt weten moet u deze raadplegen.
Moeilijke woorden of afkortingen worden in het vorige hoofdstuk “Verklarende woordenlijst” kort toegelicht. Waar het kan worden Engelse woorden gemeden maar dit is niet altijd mogelijk.
Inhoudsopgave
1 INLEIDING ... 9
1.1 “UITLAATKLEP” ... 9
1.2 ORGANISATIE ... 9
1.3 ACHTERGROND ... 9
2 FEEDBACK ... 10
2.1 WAT IS FEEDBACK ... 10
2.2 FEEDBACKPROCESSEN ... 10
2.3 FEEDBACK BINNEN SOFTWARE DEVELOPMENT ... 11
2.4 VERZAMELEN VAN FEEDBACK MET EEN TOOL ... 11
3 ONDERZOEKSVRAAG ... 12
3.1 HOOFDVRAAG ... 12
3.2 RANDVOORWAARDEN ... 12
3.3 EINDPRODUCTEN ... 12
Literatuur ... 12
Prototype ... 12
4 MARKTONDERZOEK VAN BESTAANDE OPTIES ... 13
4.1 TELEFOON ... 13
4.2 E-MAIL ... 13
4.3 HELPDESK SOFTWARE ... 14
5 MEERDERE BRONNEN ... 15
5.1 “KNOWLEDGE IS POWER” ... 15
5.2 DATA AGGREGEREN NAAR CENTRALE LOCATIE ... 15
Aggregeren ... 15
Beleid ... 15
Methodes ... 15
Voordelen ... 15
Nadelen ... 16
6 HYPOTHESE ... 16
6.1 AANLEIDING ... 16
6.2 STELLING ... 16
7 PROTOTYPE ... 17
7.1 EISEN ... 17
7.2 FEEDBACKTOOL ... 17
7.3 DOEL ... 17
7.4 RESULTAAT ... 17
Client ... 17
Management ... 17
Geheel ... 17
8 CONCLUSIE EN AANBEVELINGEN ... 18
8.1 CONCLUSIE ... 18
Tijdswinst ... 18
Vergroten van volume en bereik ... 18
Verlagen van de drempel ... 18
Hogere kwaliteit ... 18
Minder verstoringen van het werk ... 18
Overzicht van meldingen ... 19
Minder supporttijd ... 19
Opsommend ... 19
8.2 AANBEVELINGEN... 20
9 REFERENTIES EN BRONNEN ... 21
10 BIJLAGEN ... 22
10.1 BIJLAGE A(BESTAANDE FEEDBACK APPLICATIES EN TOOLS) ... 22
Feedback ... 22
Screenshot mogelijkheden binnen webapplicaties ... 26
Mogelijkheden ... 28
10.2 BIJLAGE BREQUIREMENTS FEEDBACKTOOL ... 29
10.3 BIJLAGE CKWANTITATIEF ONDERZOEK ... 30
Onderzoeksmethode ... 30
Metadata ... 31
Resultaten ... 32
10.4 BIJLAGE DINTERVIEW ... 33
Inleiding... 33
Vraag en antwoord ... 33
10.5 BIJLAGE EPROTOTYPE... 34
Inleiding... 34
Client ... 34
Management ... 39
10.6 BIJLAGE FREQUIREMENTS ANALYSE VAN BESTAANDE TOOLS ... 44
Inleiding... 44
Resultaten ... 44
Conclusie ... 44
1 Inleiding
1.1 “U itlaatklep”
Veel gebruikers hebben bij het gebruik van een softwarepakket vragen over de werking. Daarnaast komt het ook voor dat er fouten optreden in de software.
Wanneer gebruikers met een vraag of fout (beide in het vervolg aangeduid als probleem) zitten, is het niet goed als zij dit nergens kunnen melden. De problemen kunnen zich gaan opstapelen en zorgen voor irritaties. Het kan dan zelfs zover komen dat de gebruiker het niet meer fijn vindt om met de software te werken en dus een andere oplossing gaat zoeken.
Een uitlaatklep zorgt ervoor dat de gebruiker problemen kwijt kan. Ze stapelen zich dan niet bij de gebruiker op maar aan de ‘andere kant’, de kant die de meldingen ontvangt.
De ‘andere kant’ zijn de ontwikkelaars van het softwarepakket of een tussenliggende helpdesk. Zij beschikken wel over de middelen en de kennis om dit probleem op te lossen. Wanneer die gevonden is kan de gebruiker worden ingelicht en is het probleem opgelost.
1.2 Organisatie
Ranshuijsen van Loon (RVL) ontwikkelt software voor bedrijven. RVL streeft ernaar om de software zo gebruiksvriendelijk mogelijk te maken. Deze software wordt als standaardpakket geleverd (en doorverkocht door derden) of wordt op maat gemaakt naar de wensen van de klant.
Rim Ranshuijsen en Mathieu van Loon hebben beide meer dan 10 jaar ervaring in het ontwerpen en ontwikkelen van maatwerksoftware voor bedrijven. In 2009 hebben zij de handen ineen geslagen en was Ranshuijsen van Loon geboren.
(Ranshuijsen van Loon, 2012)
Ranshuijsen van Loon bestaat uit vier vaste mensen.
1. Rim Ranshuijsen 2. Mathieu van Loon 3. Tim Groote 4. Robbert Groen
1.3 Achtergrond
Ranshuijsen van Loon (RVL) heeft veel ervaring met het ontwikkelen van gebruiksvriendelijke software. Feedback is een van de aspecten die hiervoor hebben gezorgd.
RVL maakt software voor veel verschillende branches en bedrijven. Momenteel wordt feedback telefonisch of via e-mail gemeld. Dit zorgt voor een onoverzichtelijk en incompleet beeld.
Informatie kan verloren raken of incompleet worden aangeleverd. Ook is het voor veel gebruikers niet mogelijk om direct contact op te nemen met RVL of een partij die support moet leveren.
Daarom zoekt RVL al een tijd naar een oplossing waarmee deze informatie door gebruikers gemakkelijk kan worden aangeleverd en op een centraal punt kan worden verwerkt. Ook het vergroten van de feedbackkanalen (andere vormen van feedback) is een wens.
Dit probleem is de basis van dit onderzoek.
2 Feedback
Voordat er onderzocht kan worden wat de beste manier is om feedback te verzamelen moet er eerst in de literatuur worden gekeken wat feedback nu daadwerkelijk is.
2.1 Wat is feedback
Bij feedback wordt meestal gedacht aan het opnoemen van mogelijke verbeteringen of het geven van kritiek. Dit is niet helemaal juist.
Er moet niet uit een individueel oogpunt worden gekeken maar vanuit het oogpunt van een systeem. Het individu is alleen een acteur in het gehele systeem en heeft maar gedeeltelijk verantwoordelijkheid binnen het systeem (Senge, 1990).
Feedback is het constateren van feiten die relevant zijn ten aanzien van een gesteld doel waarna er moet worden gekeken of er moet worden gehandeld om het doel te bereiken. Het feedback proces is een “cause and effect” cirkel en de benodigde feedback input is geheel afhankelijk van het doel van het systeem. De feiten kunnen onder andere door uitvoering van een meting of het vragen van een opinie worden ingewonnen.
Het idee dat feedback alleen informatie over een individu verzamelt, moet worden losgelaten. Het individu is een acteur binnen een bepaald systeem of proces. De feedback moet daarom worden verzameld over het proces (Senge, 1990).
Een voorbeeld is het ontwikkelen en testen van een informatiesysteem. Hierin zijn ontwikkelaars betrokken bij het creëren van het systeem. Het systeem wordt vervolgens getest door een tweede groep mensen. Deze tweede groep mensen wil door het geven van feedback vanuit het perspectief van de gebruiker invloed uitoefenen op de (correcte) werking.
1. Ontwikkelaars maken een nieuwe versie van de applicatie
2. Testers controleren de werking van de applicatie op correctheid en informeren de ontwikkelaars met de resultaten
3. Ontwikkelaars interpreteren de resultaten
4. Ontwikkelaars kijken wat en hoe er veranderd moet worden in de applicatie 5. Terug naar stap 1
2.2 Feedback processen
Er zijn twee soorten feedbackprocessen (Senge, 1990):
1 Versterkende feedbackprocessen: Deze processen hebben als eigenschap dat zij groeien of krimpen. Visueel gezien is dit op langere termijn geen cirkel maar een spiraal.
2 Stabiliserende processen: Een vast doel is het kenmerk van deze processen. Er wordt een doel gedefinieerd voordat het proces start en het proces stopt als het doel gehaald is.
Beide soorten processen hebben te maken met een vertraging. De vertraging is de tijd die nodig is om de informatie te verzamelen en te verwerken. Hoe langer het duurt voordat een volgende iteratie begint, des te meer is er kans op fouten in het proces.
2.3 Feedback binnen software development
Software ontwikkelaars maken normaal gesproken geen gebruik van het uiteindelijke software pakket en zijn dus geen onderdeel van het proces. Daartegenover staat dat de gebruikers van dit pakket niet in staat zijn om veranderingen door te voeren omdat zij hierover geen kennis beschikken.
Het doel van sofware is het verbeteren of vergemakkelijken van één of meerdere processen en om dit doel te bereiken moet er door middel van verschillende methodes informatie worden vergaard bij verschillende bronnen:
Melden: Gebruikers moeten de mogelijkheid hebben om problemen te kunnen melden wanneer een onderdeel van de software niet doet wat het moet doen. Of de mogelijkheid om een vraag te kunnen stellen waarmee zij verduidelijking kunnen krijgen over de werking van de applicatie. Er zijn hier twee aspecten die belangrijk zijn:
1. Het probleem of de vraag van de gebruiker moet worden opgelost zodat er verder kan worden gewerkt.
2. Er moet worden gekeken of er iets mis is met de applicatie of het ontwikkeltraject.
Wanneer er bijvoorbeeld een vraag wordt gesteld kan het zijn dat er iets mis is met de gebruiksvriendelijkheid.
Metrieken: “Meten is weten (als je weet wat je meet)” is een bekende uitspraak. Met het verzamelen van feiten en gemiddelden kunnen processen in kaart worden gebracht. Er kan een geschiedenis worden opgebouwd en wijzigingen kunnen worden bestudeerd.
Informeren: Door de actoren binnen een proces vragen te stellen kunnen zij meningen geven over een proces. Zij kunnen informatie leveren over een proces waarmee dit verbeterd kan worden. Zij zijn degenen die er dagelijks mee werken en de knelpunten dagelijks ervaren.
Het is belangrijk om de vertragingen te beperken tussen het verkrijgen van de informatie en het doorvoeren van eventuele veranderingen (Nielsen, 1999) (Bicheno & Holweg, 2008). Dit zorgt ervoor dat positieve en/of negatieve effecten snel zichtbaar worden en deze in de volgende iteratie kunnen worden aangepast. Daarnaast zorgt het ervoor dat gebruikers merken dat hun meningen tellen en de bedrijven die de applicaties in gebruik hebben zien dat er daadwerkelijk wat gebeurd.
2.4 Verzamelen van feedback met een tool
In de literatuur is weinig tot niets bekend over het verzamelen van feedback binnen (web)applicaties. Er wordt beschreven hoe mensen het beste ondervraagd kunnen worden (Taylor- Powell, 1998) (Wrigth, 2006), wat feedback daadwerkelijk is (Senge, 1990). En er worden door wat commentaar en blogs wel bevindingen gepubliceerd (Nielsen, 1999).
Maar de resultaten van het gebruik van een digitale feedbacktool worden niet gepubliceerd.
3 Onderzoeksvraag
3.1 Hoofdvraag
“
Wat is het effect van een digitale feedbacktool binnen een webapplicatie ?
”3.2 Randvoorwaarden
De digitale feedbacktool die gebruikt gaat worden voor het onderzoek moet aan de volgende voorwaarden voldoen:
Inzetbaar op locaties waar geen verbinding buiten het bedrijfsnetwerk mogelijk is.
Mogelijkheid om data van de verschillende webapplicaties en/of organisaties te aggregeren.
Communicatie (tussen de gebruiker en degene die de support afhandelt) moet mogelijk zijn.
Het genereren van de data moet laagdrempelig zijn, dit wil zeggen dat wanneer er feedback door de gebruiker wordt gegenereerd hij of zij hier zo min mogelijk moeite voor moet doen.
3.3 Eindproducten
Dit onderzoek zal twee eindproducten opleveren: de literatuur en een prototype.
Li terat uur
Dit document bevat het onderzoek naar het verzamelen van feedback voor webapplicaties. Dit onderzoek bestaat uit meerdere delen:
Feedback: Er is gekeken naar wat feedback daadwerkelijk is en hoe dit binnen software development wordt toegepast.
Marktonderzoek: Hier wordt gekeken welke tools er op het moment van het onderzoek beschikbaar zijn. Deze tools worden naast de eisen van Ranshuijsen van Loon gelegd om te kijken of deze bruikbaar zijn.
Meerdere bronnen: De door de feedbacktool gegenereerde gegevens worden decentraal verzameld. Er wordt gekeken of het mogelijk is om deze decentrale gegevens te centraliseren en of dit voordelen heeft.
Met de informatie van deze onderzoeken wordt een hypothese opgesteld. Daarna zal het prototype worden gebruikt om de conclusie te onderbouwen. In de conclusie zal de hoofdvraag worden beantwoord.
Protot ype
Er is een prototype gebouwd om te kunnen meten wat voor effect het digitaal verzamelen van feedback direct binnen een applicatie heeft. Het prototype zal bij een positief effect op de feedback worden door ontwikkeld en worden ingezet in de productieomgevingen.
4 Marktonderzoek van bestaande opties
4.1 Telefoon
(Ranshuijsen van Loon, 2012)
Het melden van problemen via de telefoon komt veel voor. Vooral wanneer er veel haast is bij het oplossen van een fout in de software, zal de gebruiker snel contact opnemen. Bij de aanwezigheid van een helpdesk is deze zo goed als altijd telefonisch bereikbaar. De gebruiker kan direct zijn probleem kwijt en eventueel direct een oplossing krijgen. Voor de gebruikers is dit de fijnste oplossing omdat zij zeker weten dat het probleem is aangekomen.
Wanneer er geen helpdesk aanwezig is wordt er direct contact opgenomen met de ontwikkelaars.
Deze zijn bezig met andere taken en zijn er niet op voorbereid om een supportcall af te handelen.
Het opnemen van de telefoon zorgt ervoor dat zij hun huidige taak moeten stoppen om de klant te helpen. De klant verwacht meestal dat dit direct kan gebeuren wat ervoor zorgt dat tijdens het telefoongesprek het probleem wordt aangenomen, onderzocht en het liefst direct wordt verholpen.
Bij een technisch probleem is dit niet mogelijk omdat er moet worden gezocht, gecorrigeerd en getest voordat het probleem daadwerkelijk is verholpen. De melding wordt dan dus genoteerd.
De telefoon zorgt dus voor irritaties bij ontwikkelaars omdat zij moeten stoppen waar ze mee bezig zijn en later deze taak moeten oppikken. Daarnaast zorgt dit ook nog voor een probleem met het werkschema.
Naast de irritaties is de notering vaak ook niet compleet. Het probleem wordt snel opgeschreven met eventueel wat contactinformatie. Dit gebeurt meestal op een kladblok wat totaal niet overzichtelijk is.
4.2 E-mail
(Ranshuijsen van Loon, 2012)
Problemen die een wat minder hoge prioriteit hebben worden vrijwel altijd via de e-mail gemeld.
Hiermee kan de gebruiker meer details toevoegen zoals een screenshot.
De gebruiker kan zijn tijd nemen om de e-mail op te stellen en dus goed het probleem omschrijven. Daarnaast kan de geschiedenis in het e-mailprogramma worden gelezen.
Één van de problemen is dat er wel een mogelijkheid om te e-mailen aanwezig moet zijn op de computer; dit is namelijk niet altijd het geval. Ook weet de gebruiker misschien niet wat het e- mailadres is waarmee contact moet worden opgenomen (wat weer resulteert in een telefoontje).
Voor ontwikkelaars is deze methode een stuk prettiger. Wanneer het e-mailprogramma niet open staat, krijgen zij geen meldingen en kunnen gerust doorwerken. Het probleem wordt met redelijk wat details gemeld. En de ontwikkelaar kan het probleem oppakken wanneer het schikt, bijvoorbeeld in een bugfix ronde.
Het nadeel is dat de meldingen niet georganiseerd binnenkomen, dit moet de ontwikkelaar zelf doen. Wanneer de gebruiker mailt naar iemand die niet op kantoor is bijvoorbeeld door vakantie dan kan het lang duren voordat er antwoord wordt gegeven.
4.3 Helpdesk Software
Het belangrijkste voordeel van het gebruik van een softwarematige feedbacktool is dat het in de applicatie prominent aanwezig is. De gebruiker kan te alle tijden de tool openen en feedback versturen.
Deze feedback komt dan in een overzichtelijk beheersysteem waar de helpdesk of de softwareontwikkelaars de meldingen kunnen beheren, verhelpen en beantwoorden. Hiermee wordt er automatisch voor gezorgd dat de gebruiker een grote garantie heeft dat een melding goed terechtkomt en wordt afgehandeld.
Het nadeel van het gebruik van een softwarematige feedbacktool is dat deze moet worden geïmplementeerd in de applicatie. De applicatie moet dan worden getest zodat eventuele fouten worden gevonden die door het implementeren zijn ontstaan.
Er zijn diverse softwarematige oplossingen waarmee er helpdeskfunctionaliteit aan een applicatie kan worden toegevoegd. In bijlage A is een overzicht te vinden van een aantal pakketten en hun mogelijkheden.
5 Meerdere bronnen
5.1 “K nowledge is power”
Vertaald uit het Latijns: “Scientia potentia est” (Bacon, 1597) betekent: Kennis is macht.
Wanneer een organisatie of persoon meer kennis over een onderwerp krijgt is dit een goed wapen om de concurrentie voor te blijven.
Door het verzamelen van feedback binnen een applicatie die bij een organisatie draait, wordt er kennis verkregen over meerdere aspecten. Welke aspecten dit zijn is nu niet relevant. De afbakening van deze kennis binnen deze organisatie is wel relevant. Dit betekent dat de kennis die wordt vergaard alleen representatief is voor deze organisatie.
5.2 Data aggregeren naar centrale locatie Aggre gere n
Om de feedbackgegevens beheersbaar te maken moet er de mogelijkheid zijn om deze bij elkaar op te slaan. Dit zorgt ervoor dat de support vanuit een centraal punt de feedback kan behandelen en verwerken.
Met aggregeren wordt tijdens dit onderzoek bedoeld dat gegevens van meerdere locaties naar één centrale plek worden gebracht.
Beleid
Het is mogelijk dat de organisatie niet wil dat de gegevens de locatie verlaten. In dit geval is aggregeren niet mogelijk.
Methode s
Er zijn twee mogelijke methodes voor het aggregeren van de data.
1. Internet: Via internet haalt de centrale locatie de gegevens weg bij de organisatie. Dit is de snelste en de makkelijkste optie. Het ophalen van de gegevens kan dan bijna realtime gebeuren.
2. Data drager: Met het gebruik van een data drager kunnen de gegevens worden geëxporteerd naar bijvoorbeeld een USB Stick of Schijf. Het nadeel hiervan is dat de gegevens moeten worden opgehaald van de locatie, wat weer tijd kost. Deze optie heeft alleen de voorkeur wanneer er geen internet op de locatie aanwezig is of wanneer het door een netwerkbeleid niet mogelijk is.
Wanneer de data aanwezig is op de centrale locatie kan deze worden geaggregeerd met de bestaande data. Er kunnen nu vergelijkingen worden gemaakt tussen de verschillende organisaties en applicaties.
Voorde le n
Wanneer de feedback op één centrale locatie te vinden is, kunnen de ontwikkelaars makkelijk bij alle meldingen. Er hoeft dan ook maar één locatie worden beheerd.
Het aggregeren van de data zorgt ervoor dat er een overzicht van een applicatie kan worden gemaakt. Wanneer er bijvoorbeeld een probleem wordt gemeld bij verschillende klanten, is het nu mogelijk om snel te kunnen zien of er meer klanten last hebben van dit probleem. Er kan dan meer prioriteit worden gegeven aan een bepaald probleem.
Nadelen
Het enige nadeel van het aggregeren van de gegevens (wanneer dit is toegestaan door de organisatie) is het maken van de technische oplossing. De oplossing moet ervoor zorgen dat de aggregatie verloopt zonder problemen en dat nieuwe meldingen binnen een bepaalde tijd geaggregeerd zijn.
Er moet dus ontwikkeltijd worden gestoken in het ontwikkelen van deze oplossing.
6 Hypothese
6.1 Aanleiding
Het gebruik van de telefoon zorgt voor snelle en directe communicatie maar niet iedere gebruiker heeft hiervoor de mogelijkheid (bijvoorbeeld bij afwezigheid van een telefoon op de werkplek).
Wanneer een gebruiker een e-mail opstelt kan er worden nagedacht over wat er wordt opgeschreven. Daarnaast kan er meer informatie in de e-mail worden gezet. Voor het gebruik van e-mail moet de werkplek hier ook voor worden ingericht (er moet een e-mail applicatie beschikbaar zijn, inclusief een e-mail adres voor de gebruiker).
Met het gebruik van een feedbacktool kan elke gebruiker die met de applicatie werkt een feedback kanaal starten. De gebruiker hoeft hiervoor maar weinig handelingen verrichten.
Wanneer er een feedbacktool beschikbaar is geeft dit de mogelijkheid voor de gebruiker – om zonder iemand te storen – snel een melding te doen met veel informatie. Hierdoor zal de gebruiker minder geneigd zijn om telefonisch contact op te nemen.
De meldingen komen georganiseerd binnen en kunnen worden gesorteerd op onder andere prioriteit en tijd van melding.
Het gebruik van de e-mail wordt dan helemaal vervangen, de feedbacktool heeft alle voordelen van e-mail maar geen van de nadelen.
Naast het feit dat iedere gebruiker nu feedback kan geven zal een melding maar gaan over één specifiek item. De handelingen (het melden van feedback) kunnen snel worden uitgevoerd en de mogelijkheid is op elke pagina aanwezig. Dit zorgt ervoor dat de gebruiker de meldingen niet verzamelt maar direct meldt wanneer zij ter sprake komen.
6.2 Stelling
Door het gebruik van een (digitale in de applicatie aanwezige) feedbacktool wordt het volume en bereik van de feedback vergroot, zal tijd worden gewonnen en hogere kwaliteit feedback worden geleverd.
7 Prototype
7.1 Eisen
Na het onderzoek naar de bestaande applicaties en literatuur is er besproken aan welke functionele eisen een feedbacktool moet voldoen. Deze eisen zijn te vinden in bijlage B.
7.2 Feedbacktool
Na het vaststellen van de eisen waaraan de feedbacktool moet voldoen is er gekeken welke bestaande tools hieraan voldoen. In bijlage F is te zien aan welke eisen de tools wel of niet voldoen. Er is een score berekend en de feedbacktool Uservoice heeft uiteindelijk de hoogste score.
Uservoice voldoet echter niet aan twee cruciale eisen. Dit zijn de mogelijkheid tot aggregatie en offline inzetbaarheid.
Dit betekent dat er geen pakket is dat aan de minimale eisen voldoet. Er is daarom gekozen om een eigen tool te bouwen. Met deze tool moet het uiteindelijk mogelijk zijn om verschillende soorten feedback te verzamelen. Voor dit onderzoek zal het prototype van deze tool zich alleen richten op het mogelijk maken van meldingen door de gebruiker.
7.3 Doel
Voor dit onderzoek is het doel van het prototype om gegevens te verzamelen. Met deze gegevens moet kunnen worden bewezen of het gebruik van een feedbacktool effect heeft op de support aan een gebruiker. Naast het verkrijgen van de gegevens wordt er ook gekeken of het technisch mogelijk is om de wensen uit de eisen te kunnen realiseren.
7.4 Resultaat Clie nt
Het deel dat voor de gebruiker zichtbaar is en waar de feedback kan worden gemeld. Door het volgen van een kort traject kan een gebruiker een nieuwe melding plaatsen of communiceren met degene die de support afhandelt.
De client is gemakkelijk te installeren in nieuwe omgevingen. De applicatie waar de tool in moet draaien heeft maar een kleine aanpassing nodig om te geïnstalleerd te kunnen worden.
Manageme nt
Dit deel is zichtbaar voor degene die de support moeten afhandelen. Alle meldingen komen hier georganiseerd binnen. Het geeft “de support” de mogelijkheid om te communiceren met de gebruiker en meldingen van de gebruiker te verwerken en af te handelen.
Geheel
De gehele omgeving kan moeiteloos los draaien van het internet. Dit zorgt ervoor dat er in bedrijfsnetwerken geen problemen zijn met betrekking tot de beveiliging.
In bijlage E is de werking van de feedbacktool te vinden. In deze bijlage is te zien hoe een gebruiker een nieuwe melding aanmaakt, hoe de support hierop reageert en de melding verwerkt, hoe de support en de gebruiker met elkaar kunnen communiceren, en hoe de support een overzicht heeft over alle verschillende soorten meldingen en feedback clients.
8 Conclusie en aanbevelingen
8.1 C onclusie
Het verkrijgen en analyseren van feedback zal altijd tijd kosten. Het zijn immers mensen die het grootste deel van de feedback moeten genereren. Het analyseren of interpreteren van deze data is ook mensenwerk.
Wat wel mogelijk is, is het verbeteren van het feedback traject. Met verbeteren wordt het verkorten van de benodigde tijd, het verhogen van het volume en het verhogen van de kwaliteit bedoeld. Het digitaal verzamelen van feedback binnen een applicatie verbetert het feedback traject op al alle drie deze punten.
Ti jdsw ins t
De gemeten tijden uit bijlage C laten een duidelijk verschil zien tussen het wel of niet gebruiken van de feedbacktool. De tijdwinst met het gebruik van de tool bedraagt bijna 50%. Dit wil zeggen dat er voor beide partijen minder tijd nodig is en zij (de ontwikkelaars en de gebruikers) zich meer kunnen focussen op de taken waar zij eigenlijk mee bezig moeten zijn.
Vergro te n van vo lum e en bere ik
Sommige gebruikers hebben geen mogelijkheid om via de e-mail of telefonisch contact op te nemen met een helpdesk of de ontwikkelaars. Zij krijgen nu de mogelijkheid om dit wel te doen.
Hiermee wordt de bron van feedback dus vergroot.
Gebruikers die hiervoor wel de mogelijkheid hadden kunnen nu sneller een melding doen. In bijlage D is te lezen dat de gebruiker nu sneller een melding zal doen in plaats van deze op te sparen of helemaal niet te doen.
Het vergroten van de bron en het versnellen van het feedback proces zorgt er dus voor dat er meer feedback binnenkomt.
Verla gen va n de drempe l
Veel gebruikers konden eerst geen feedback geven of het geven van feedback koste teveel tijd.
Het verlagen van de drempel, door het verkorten van de benodigde tijd en het toegankelijk maken van het feedback traject, zorgt ervoor dat gebruikers ook meldingen doen over problemen die ze hiervoor nooit zouden melden. Gebruiksvriendelijkheid van de applicatie staat in deze meldingen vaak centraal. Deze extra (nieuwe) feedback zorgt er voor dat het doel van gebruiksvriendelijke software maken beter kan worden behaald.
Hogere kwa li te it
Wanneer gebruikers problemen gaan onthouden om deze later met meerdere tegelijk in één keer te melden, komt de kwaliteit in gevaar. De gebruiker vergeet cruciale gegevens zoals welke handelingen zijn verricht om het probleem te produceren en welke gegevens er werden ingevoerd.
Wanneer er direct een melding wordt gedaan zijn deze gegevens nog vers aanwezig bij de gebruiker. De feedbacktool zorgt er ook voor dat de gebruiker veel informatie niet hoeft op te geven.
Minder v erst ori nge n va n het wer k
Omdat er minder telefonisch contact nodig is kan de ontwikkelaar vaker ongestoord aan het werk zijn. Meldingen kunnen op geplande tijden worden bekeken en worden afgehandeld. Dit zorgt voor lagere werkdruk en minder frustraties wat er voor zorgt dat de werksfeer en het werkplezier worden verbeterd.
Overz icht va n meld i nge n
Alle meldingen komen digitaal binnen en zijn dus geregistreerd. Handmatig registreren van meldingen is niet meer nodig en er is een goed overzicht waarmee openstaande issues kunnen worden bijgehouden.
Minder s upport ti jd
Doordat het afhandelen van een probleem korter duurt worden de kosten verlaagd die aan support moeten worden besteed. Dit is voor alle partijen een pluspunt. Naast het verlagen van de kosten zorgt dit er ook voor dat er meer meldingen kunnen worden verwerkt in dezelfde tijd. Ook kan de tijd die eerst nodig was om problemen af te handelen nu aan ontwikkeltijd worden toegewezen.
Opsommend
Het inzetten van een feedbacktool zorgt voor de volgende verbeteringen:
Tijdswinst
Vergroten van het volume van feedback
Vergroten van het gebruikersbereik
Hogere kwaliteit feedback
Verlagen van de drempel
Minder verstoringen van het werk van de gebruiker en/of de ontwikkelaars
Overzichtelijk centraal punt van meldingen
Verminderen van supporttijd (winst in geld)
Het gebruik van een digitale feedbacktool zorgt ervoor dat er georganiseerd een groter volume aan kwalitatief hogere feedback wordt gegenereerd. De tijd die hiervoor nodig is wordt verlaagd voor de gebruikers en de ontwikkelaars. Het vergemakkelijkt en versnelt de manier van communiceren tussen ontwikkelaar en gebruiker.
Daarom is een feedbacktool de ideale oplossing voor het verzamelen van feedback binnen webapplicaties.
8.2 Aanbevelingen
Het gebruik van de telefoon zal niet kunnen worden gestopt simpelweg omdat de meeste mensen houden van persoonlijk contact.
Door combineren van de feedbacktool en de telefoon kan er wel voor worden gezorgd dat het melden kan worden gestroomlijnd.
Deze vorm van de feedbacktool heeft al veel voordelen maar zorgt nog steeds voor een incompleet beeld van het gebruik van de applicatie. Om de tool compleet te maken moeten er twee segmenten toe worden gevoegd: metrieken en vragenlijsten.
Hiermee kan dan het volgende ontwikkelingstraject worden gebruikt:
1. De metrieken worden verzameld en geanalyseerd. Er wordt gekeken waar er knelpunten zijn en hoe deze opgelost moeten worden.
2. Vragen moeten worden gesteld aan de gebruikers. Wanneer er niet genoeg informatie vrijkomt uit de metrieken om een probleem op te lossen moeten er aan de gebruikers vragen worden gesteld.
3. Wanneer er extremen zijn gevonden in de metrieken of de vragen, moet er worden gekeken wat deze zijn. De gebruiker(s) moet(en) dan worden geïnterviewd om nog meer informatie te verkrijgen.
4. De software wordt aangepast.
5. Eventueel eerst stap 2 nog een keer uitvoeren maar anders de iteratie opnieuw starten bij stap 1.
9 Referenties en bronnen
Bacon, F. (1597). Meditationes Sacrae.
Bicheno, J., & Holweg, M. (2008). The Lean Toolbox.
Nielsen, J. (1999, 01 10). Collecting Feedback From Users of an Archive. Retrieved from UseIT:
http://www.useit.com/alertbox/990110.html
Philips Lighting in Terneuzen. (2012). Retrieved from De Kanaalzone:
http://www.dekanaalzone.nl/pages/bedrijven/popups/index.php?id=14
Ranshuijsen van Loon. (2012). Ranshuijsen van Loon. Retrieved from Ranshuijsen van Loon:
http://www.renvl.nl/
Schaap Holland BV. (2012). Retrieved from Schaap Holland BV:
http://www.schaapholland.nl/zakelijkeklant
Senge, P. (1990). The Fifth Discipline. Doubleday.
Taylor-Powell, E. (1998). Questionnaire Design: Asking questions with a purpose. University of Wisconsin-Extension.
Wrigth, K. B. (2006, 06 23). Researching Internet-Based Populations: Advantages and Disadvantages of Online Survey Research, Online Questionnaire Authoring Software Packages,
and Web Survey Services. Retrieved from Wiley Online Library:
http://onlinelibrary.wiley.com/doi/10.1111/j.1083-6101.2005.tb00259.x/full
10 Bijlagen
10.1 Bijlage A (Bestaande feedback applicaties en tools) Feedback
Voor het vragen van feedback aan gebruikers zijn al diverse tools ontwikkeld. Er zal worden gekeken naar de mogelijkheden van de tools en of ze van toepassing zijn op dit project. Aan het eind word er een conclusie getrokken
B e st aan d e T o o l s
BugMuncher
BugMuncher is een simpele feedbacktool waarmee snapshots van het scherm kunnen worden gemaakt. De gebruiker kan dan één gebied markeren en diverse gebieden zwart maken om informatie te verbergen. De gebruiker kan dan deze snapshot opsturen met één vraag erbij.
Het is een pure JavaScript oplossing wat gelijk al voor wat problemen zorgt : de tool maakt geen echte screenshot maar een snapshot van de DOM en duwt deze dan naar een server waarna er een image gecreëerd wordt. Hiermee wordt dus niet een 100% kopie gemaakt van wat de gebruiker ziet omdat browser gerelateerde fouten dan niet kunnen worden weergegeven.
De markeer en verberg tool zijn simpele HTML elementen die in de website worden geïnjecteerd.
De tool brengt verschillende privacyproblemen met zich mee omdat de gehele DOM naar de server van de maker wordt gestuurd en daar wordt verwerkt. De verberg tool werkt dan alleen als de image gegenereerd is, maar de data kan daarvoor al wel worden gelezen. Ook is het een probleem dat het een externe service is.
Pluspunten:
Markeer tool
Verberg tool
Bron: http://bugmuncher.com/
Prijs: $10/maand (1 week trial) Branding: Yes
Feedbackify
Feedbackify is een feedbacktool waarmee gebruikers input kunnen geven. De gebruiker kan kiezen voor vier opties:
Probleem
Suggestie
Compliment
Anders
De eerste drie opties geven nog een mogelijkheid om de feedback wat te specificeren.
Na het selecteren kan de gebruiker zijn zegje doen en de data versturen.
Als er de wens voor is kan er één rating (0-10) vraag worden gesteld maar deze verandert niet wanneer er voor een feedback optie word gekozen. Het is dus één generale vraag.
De tool heeft wat aanpassingsopties zoals het aanpassen van de koptekst, introtekst en de rating vraag. Ook is het mogelijk om het logo van het bedrijf te uploaden zodat dat kan worden weergegeven in het formulier.
Voor het verwerken van de feedback is een ‘Feedback Dashboard’ ontwikkeld. Hiermee kan op categorie worden gezocht naar gebruiker input. Het dashboard staat op de server van Feedbackify.
Pluspunten:
Simpele en strakke lay-out
Rating vraag
Bron: http://www.feedbackify.com Prijs: $19/maand (15 dagen trial) Branding: Yes
Get Satisfaction
Get Satisfaction (GS) is een geavanceerde feedbacktool.
De gebruiker kan kiezen voor vier opties:
Probleem
Suggestie
Compliment
Vraag
De gebruiker kan naast de standaardtekst input ook nog extra details geven en zijn emotie over de kwestie tonen.
Naast de input is er ook een mogelijkheid om populaire onderwerpen van de geselecteerde optie te zien. Hier kunnen eventueel al problemen mee worden opgelost of aan bestaande meningen gegevens worden toegevoegd.
Bij het geven van input moet de gebruiker altijd ingelogd zijn om eventueel directe terugkoppeling te doen. Hiervoor kunnen bestaande systemen zoals Facebook, Google of Live worden gebruikt of via het eigen user systeem van GS.
Er is ook een mobiele variant van de tool die dezelfde mogelijkheid biedt.
Het verwerken van feedback is community-based, wat wil zeggen dat gebruikers de mogelijkheid hebben om elkaars problemen op te lossen. Een beheerder kan dan natuurlijk altijd nog extra input geven of het probleem oplossen wanneer het niet door een gebruiker kan worden opgelost.
In het dashboard van GS kan de beheerder wat standaard gebruiksstatistieken zien van de website. Daarnaast geeft het ook de mogelijkheid om statistieken over de feedback te zien.
GS geeft ook de mogelijkheid om bepaalde onderdelen te integreren in mobiele applicaties door middel van het beschikbaar stellen van bepaalde API aanroepen.
Pluspunten:
Community-based
Populaire onderwerpen
Emotie bij input d.m.v. een smiley
Mogelijkheid integratie in mobiele applicaties d.m.v. API
Bron: http://getsatisfaction.com/
Prijzen: $19/maand, $49/maand, $99/maand en ‘enterprise plan’ (allemaal 15 dagen trial) Branding: Yes
Uservoice
Uservoice is qua gebruiker input functionaliteit grotendeels hetzelfde als Get Satisfaction. Het enige waarmee het zich onderscheidt is de keuze om de input als feedback te geven of als een support aanvraag. Ook heeft het wat minder login koppelingen ( Facebook / Google) maar je kan wel de melding versturen met alleen een e-mailadres.
Ook is er een helpdesk optie om de F.A.Q. op te roepen en worden de populaire onderwerpen direct in het dialoog getoond.
Naast een iOS plugin is er ook een Facebook Page plugin waarmee feedback kan worden weergegeven en eventueel commentaar door gebruikers kan worden geleverd.
Het dashboard heeft geen statistieken of metrieken.
Community-based
Populaire onderwerpen
Populaire F.A.Q. items
Mogelijkheid integratie in iOS en Facebook
Bron: http://www.uservoice.com/
Prijzen: gratis, $25/maand, $65/maand, $125/maand (allemaal 30 dagen trial) Branding: Ja en nee
C o n c l u si e
Er zijn verschillende tools beschikbaar die een deel van de gewenste features hebben.
Abonnementtechnisch mogen de tools allemaal op één omgeving worden geïnstalleerd. Dit wil zeggen dat wanneer het bij meerdere klanten wordt geïmplementeerd er losse abonnementen moeten worden afgesloten. Daarnaast kunnen de gegevens niet in een centraal beheerpaneel worden weergegeven en verwerkt.
Een ander probleem is dat alle tools niet lokaal inzetbaar zijn. Dit wil zeggen dat zij allemaal als service worden aangeroepen via het internet. Een bijkomend probleem is dat de data bij een derde beland wat privacy- en veiligheidsproblemen kan opleveren.
Veel van de features waren tijdens het brainstormen al naar boven gekomen maar bijvoorbeeld een tool voor een mobiel platform is een goede toevoeging in een latere versie van het project.
Zeker omdat hiervoor steeds meer applicaties gaan worden gemaakt.
Screensho t moge l ij khed en bi n nen weba pplicat ies
Om zo veel mogelijk informatie te krijgen bij een bug report of andere user input is de informatie die een gebruiker ziet van veel belang. Daarom is één van de onderzoekspunten van dit project het verkrijgen van de huidige informatie op het scherm van de gebruiker.
Id e e ë n
Op dit moment zijn er twee ideeën over hoe dit te realiseren moet zijn.
Het eerste idee is het ouderwetse maar nog steeds veel gebruikte screenshottoets op het toetsenbord. Hiermee is alle data in één keer vastgelegd en te zien zoals de gebruiker het ook voor ogen krijgt
Het tweede idee is het inlezen van de gehele DOM inclusief de door AJAX gewijzigde content en deze naar een server te posten om daar dan een plaatje te genereren.
De tools die op dit moment beschikbaar zijn maken gebruik van een van deze twee technieken.
B e st aan d e T o o l s – D O M S n ap sh o t
Deze technieken werken in alle browsers en hebben geen applet of Active X object nodig.
BugMuncher
De tool is in het hoofdstuk Feedback al aan bod gekomen. Hij gebruikt de DOM snapshot methode om een screenshot te maken.
Bron: http://bugmuncher.com/
Prijs: $10/maand (1 week trial) Branding: Yes
html2canvas
Deze tool maakt een DOM snapshot en genereert een plaatje in een HTML v5 canvas object. Dit object kan dan met een formulier worden verstuurd.
Bron: http://html2canvas.hertzen.com/
Prijs: gratis
B e st aan d e T o o l s – S c re e n sh o t
Clipboard ActiveX
Dit is een opensource project op CodeProject , hiermee kan een image in het clipboard worden ingevoegd in een formulier door het gebruik van een Active-X-object.
Bron: http://www.codeproject.com/Articles/25967/Clipboard-ActiveX-for-Image-Copy-Paste-into- Web-Fo
Prijs: gratis
Clipboard JavaScript
Dit is een mogelijkheid die aanwezig is in nieuwe versies van browsers. Hierin verkrijgt de JavaScript code toegang tot het clipboard inclusief eventuele images. Omdat de browsers verschillende implementaties hebben moet hiermee rekening worden gehouden.
Bron: http://joelb.me/blog/2011/code-snippet-accessing-clipboard-images-with-javascript/
Prijs: gratis
ScreenShootMe
Deze tool laadt via een Java applet de screenshot in het clipboard naar de server. Nadat de screenshot op de server is ingeladen is er nog de mogelijkheid om de screenshot te bewerken en te verkleinen.
Deze tool word aangeboden als een service en is dus niet in-app te gebruiken.
Bron: http://screenshoot.me/
Prijs: gratis
SUPA
Dit is een opensource project op SourceForge , hiermee kan een image in de clipboard worden ingevoegd in een formulier door het gebruik van een Java Applet.
Bron: http://supa.sourceforge.net/
Prijs: gratis
SnapEngage
SnapEngage is een betaalde service die gebruikt maakt van een Java Applet om een screenshot te uploaden. De tool heeft een mogelijkheid om direct met een support medewerker te praten en kan worden geïntegreerd in ERP pakketten.
Bron: http://www.snapengage.com/
Prijs: $19/maand, $49/maand, $129/maand en $289/maand (15 dagen trial)
C o n c l u si e
Er zijn veel mogelijkheden die dezelfde opties bieden. Oorspronkelijk was de DOM snapshot een optie voor het project maar omdat er zoveel screenshot mogelijkheden zijn is dit geen optie meer.
Het Active-X-object is ook geen goede optie, omdat dit niet in alle browsers en besturingen kan draaien.
SnapEngage en ScreenShootMe zijn beide diensten die niet kunnen worden geïntegreerd binnen het project en vallen ook af.
Er moet daarom een keuze worden gemaakt tussen twee opties Clipboard JavaScript (CJ) en SUPA. Het probleem met CJ is dat dit niet cross-browser hetzelfde werkt of überhaupt geïmplementeerd is. In oudere browser versies zit de mogelijkheid sowieso niet. Daarom is SUPA de beste optie, dit werkt cross-browser en cross-platform. Het enige nadeel hiervan is dat het door sommige browsers niet als vertrouwd wordt gemarkeerd. Dit is op te lossen door de web applicatie in de vertrouwde zone te zetten.
Mogel i jk heden
Een overzicht van alle relevante mogelijkheden (de mogelijkheden van alle pakketten bij elkaar):
Mogelijkheid om via een knop die altijd zichtbaar is de tool te openen. Hierin kunnen de gebruikers een aantal acties uitvoeren.
Feedback bericht versturen:
o Verschillende soorten feedback
Probleem
Suggestie
Compliment
Vraag
o Screenshot toevoegen
Een deel van de screenshot markeren
Een deel van de screenshot zwart maken
o Schaal van 0-10 toevoegen (Stellen van een vraag aan de gebruiker waarna er een mening van 0-10 kan worden gegeven).
o Emotie toevoegen
Informatie in een forum of FAQ
o Meest populaire items worden in het dialoog weergegeven o Link naar de locatie om verder te zoeken
o Gebruikers kunnen elkaar informatie geven (onder andere antwoorden op elkaars vragen)
Inloggegevens gebruiken van een Facebook of Google account of van het pakket zelf
Overzichtelijk beheer
o Items kunnen worden gerangschikt en hun status kan worden bijgehouden.
o Statistieken bijhouden
10.2 Bijlage B Requirements feedbacktool
Na het analyseren van de bestaande pakketten en de randvoorwaarden van de opdracht moet de uiteindelijke feedbacktool de volgende mogelijkheden hebben:
1. Mogelijkheid om een melding te doen.
a. Drie type meldingen moeten beschikbaar zijn:
I. Stellen van een vraag: Hiermee kan de gebruiker een vraag stellen. Deze optie kan worden gebruikt wanneer een bepaalde handeling niet wordt begrepen.
II. Melden van een probleem: Hiermee kan de gebruiker een probleem melden. Wanneer de applicatie niet doet wat hij moet doen of wanneer er fouten worden geconstateerd door de gebruiker kan dat op deze manier worden gemeld.
III. Geven van een compliment: Hiermee kan de gebruiker een compliment geven aan de ontwikkelaars. Deze optie geeft de gebruiker de mogelijkheid om bijvoorbeeld bij een verandering van de applicatie een compliment te geven.
b. Toevoegen van een screenshot door de gebruiker. Hiermee kan de gebruiker visueel maken wat het probleem is.
c. Meenemen van de gegevens van de applicatie en de huidige pagina. De applicatie moet automatisch gegevens verzamelen van de huidige pagina. Deze gegevens kunnen dan worden gebruikt om de gebruiker sneller te helpen. De gegevens bestaan onder andere uit:
I. De volledige locatie gegevens van de huidige pagina (URL) II. Naam van de applicatie en de organisatie
III. Optioneel: De huidige HTML DOM
2. Mogelijkheid tot communicatie. De gebruiker moet kunnen communiceren met de backend (de ontwikkelaars of de helpdesk). Dit wil zeggen dat de gebruiker tot de volgende mogelijkheden moet kunnen beschikken:
a. Communicatiehistorie:
I. Lijst met de laatste gesprekken II. Weergeven van deze gespreken
b. Antwoord kunnen geven op de berichten van de backend.
3. Inzetbaar op offline locaties. De tool moet kunnen worden geïmplementeerd in bedrijfsnetwerken waar geen internet aanwezig is (door beleid of ontbreken van een fysieke aansluiting).
4. Mogelijkheid tot aggregatie. Het beheer over de feedback moet op één centrale plek gedaan kunnen worden. De feedbacktool moet de mogelijkheid hebben om meerdere applicaties of klanten in één centrale plek te houden.
5. Minimalistisch en overzichtelijk design. Wanneer de tool niet gebruikt wordt moet dit zo min mogelijk storen voor de gebruiker. Bij het gebruik van de tool moet de applicatie nog zoveel mogelijk zichtbaar zijn. De opties en mogelijkheden van de tool moeten duidelijk zijn voor gebruikers, zodat deze niet worden afgeschrikt wanneer ze de tool moeten gebruiken.
De volgende mogelijkheden zijn wensen voor de toekomst:
6. Mogelijkheid tot het verzamelen van metrieken.
a. Metingen moeten kunnen worden gestart of gestopt door de gebruiker of de applicatie.
b. De applicatie moet een tussenmeting kunnen doen.
7. Mogelijkheid tot het tonen van een vragenformulier. Er moet een vragenformulier getoond kunnen worden dat de gebruiker moet kunnen invullen en opsturen. Ook moet de gebruiker het vragenformulier kunnen negeren.
10.3 Bijlage C K wantitatief onderzoek Onderzo eks met hode
De applicatie ‘Quality Cockpit’ (zie: Applicatie) is gelijktijdig bij twee bedrijven ingezet. Beide bedrijven hebben meerdere testers die als taak hebben de applicatie klaar te stomen voor de productieomgeving.
De testers bij bedrijf A hebben direct toegang gehad tot de feedbacktool en de testers bij bedrijf B pas halverwege. Er kan zo goed worden gezien wat de impact van de feedbacktool is.
Metingen worden als volgt gedaan:
Aantal meldingen
o Meldingen via de tool kunnen per soort opgeteld worden o Telefonische meldingen worden afgeturfd
o E-mails worden in een map gesleept en opgeteld
Tijd aanmaken meldingen door de gebruiker in de tool
o De tool slaat de tijd op wanneer de meldingsknop wordt aangeklikt o De tool slaat de tijd op wanneer de melding wordt verstuurd o Totaaltijd voor de melding is dan eindtijd - starttijd
o De gemiddelde tijd wordt berekend door de totale tijd van alle meldingen te meten en te delen door het aantal meldingen
Tijd aanmaken melding e-mail door de gebruiker
o Starttijd wordt in de e-mail genoteerd in formaat HH:mm o Eindtijd wordt door de e-mail tool meegestuurd
o Totaaltijd voor de melding is dan eindtijd - starttijd
o De gemiddelde tijd wordt berekend door de totale tijd van alle meldingen te meten en te delen door het aantal meldingen
Tijdsduur telefoon gesprek
o Starttijd wordt genoteerd door de persoon die het gesprek behandelt in formaat HH:mm
o Eindtijd wordt genoteerd door de persoon die het gesprek behandelt in formaat HH:mm
o Totaaltijd voor de melding is dan eindtijd - starttijd
o De gemiddelde tijd wordt berekend door de totale tijd van alle meldingen te meten en te delen door het aantal meldingen
Tijdsduur interview
o Een stopwatch wordt gebruikt om de lengte van het interview vast te stellen o De gemiddelde tijd wordt berekend door de totale tijd van alle meldingen te
meten en te delen door het aantal meldingen
Bij het berekenen van de tijd wordt er afgerond in halve minuten waar de melding minimaal één minuut kost.
De aantallen worden dan vermenigvuldigd met het gemiddelde van de tijd. Deze worden dan opgeteld om de totale tijd te berekenen.
Metadata
A p pl i c at i e
De ‘Quality Cockpit’ is een softwarepakket ontwikkeld door Ranshuijsen van Loon. Met de applicaties kunnen de medewerkers van een bedrijf rapportages invullen over de gedraaide productie. Met deze rapportages kunnen de bedrijven zien wat de kwaliteit is van hun producten.
B e d ri jv e n
Bedrijf A: Philips (Terneuzen) (Philips Lighting in Terneuzen, 2012)
In deze vestiging van Philips worden starters en glimlichten voor fluorescentielampen geproduceerd. Deze productie wordt hier al 30 jaar gedaan en is met de export naar 100 verschillende landen de marktleider op alle continenten.
Bedrijf B: Schaap Holland (Schaap Holland BV, 2012)
Schaap Holland is een leverancier van aardappelen. Zij leveren aan heel Europa. Daarnaast kweken ze ook nieuwe rassen. De klanten van Schaap Holland zijn zowel zakelijk als particulier.
Resul tate n
Me t i n g e n
Uit de metingen blijkt dat de tool voor meer meldingen zorgt maar 46,6% minder tijd kost.
T y p e me l di n g e n
Probleem
Het overgrote deel van de meldingen die waren aangemerkt als probleem, waren meldingen van fouten in de software. Dus echte bugs of het ontbreken van een bepaalde mogelijkheid.
Vraag
Vragen gingen bijna altijd over de werking van de software. Gebruikers vroegen zich af waar bepaalde mogelijkheden zaten of hoe ze een bepaalde handeling moesten verrichten.
Compliment
Er is maar één compliment gestuurd. Dit compliment werd gestuurd omdat de gebruiker tevreden was met de werking van de feedbacktool.
10.4 Bijlage D Int erview In le idi ng
Om te zien of gebruikers daadwerkelijk tevreden zijn met de feedbacktool en wat voor gevolgen dit voor hen heeft, is er een interview gedaan met Willem. Willem is een van de testers die de tool heeft gebruikt tijdens het testtraject.
Vraag en an twoord
Tijdens het testen ben je veel tijd kwijt om problemen te melden en vragen te stellen aan de ontwikkelaars. Hoeveel tijd (in procenten) denk je dat je hieraan kwijt bent tijdens het testen?
- Testen neemt gemiddeld 4-8 uur per week in beslag op het moment dat we met nieuwe ontwikkelingen bezig zijn.
- Van deze tijd ben je 30-40% van de tijd bezig met het stellen van vragen aan ontwikkelaars.
Je hebt nu al een tijdje met de feedbacktool gewerkt, wat vind je het grootste voordeel van de tool?
- De directe manier van vragen stellen in de software zelf. Ik hoef geen mailprogramma te openen.
- Ik kan kiezen wat voor soort vraag ik wil stellen.
- De ontwikkelaar krijgt meteen de ingelogde gebruiker te zien (=persoonlijker) en vanaf welke website het misgaat.
En het grootste nadeel?
- Ik zie voor mij als gebruiker van de tool geen nadeel. Wanneer het via de tool niet mogelijk is om mijn melding te doen kan ik alsnog via de ouderwetse manier contact opnemen.
Zorgt de tool ervoor dat je meer kan focussen op het testen en niet op het melden?
- Nee, uiteindelijk moeten bugs, verbeteringen en complimenten toch altijd gemeld worden.
Het kost nu alleen minder tijd en je hebt de gestelde vragen over een specifieke Cockpit bij de hand.
Zorgt de tool ervoor dat je nu sneller een melding doet (i.p.v. het op te sparen voor een mailtje of een telefoontje) ?
- Ja, het is makkelijker om een melding te maken omdat de tool in de software hangt.
Zou je de feedbacktool ook terug willen zien in andere applicaties ? - Ja
Waarom ?
- Hij biedt de mogelijkheid om snel en op de juiste plaats support te leveren
10.5 Bijlage E Prototype In le idi ng
Om het prototype te demonstreren wordt er een traject gevolgd van het melden van een probleem.
Zo kan er worden weergegeven hoe het prototype werkt.
Clie nt
De client is het onderdeel van de feedbacktool die voor de gebruiker zichtbaar is in de applicatie.
Hiermee kan de gebruiker meldingen doen en zijn communicatiehistorie inzien.
De startknop
De knop die altijd zichtbaar is. Met deze knop kunnen gebruikers het startscherm openen of sluiten
Het startscherm: zonder eerdere communicatie.
Na het drukken op de “Help & Feedback” knop (Afbeelding 14-1) wordt dit scherm geopend. Hier kan de gebruiker een keuze maken uit drie verschillende soorten meldingen. Door op één van de drie knoppen te drukken zal de gebruiker naar het volgende scherm gaan.
Melding scherm (voor een probleem).
Na het drukken op de knop “een probleem” wordt het dialoog weergegeven. De gebruiker kan schakelen tussen de drie opties, wanneer de gebruiker zich bedenkt kan er voor worden gekozen om er een vraag van te maken.
De gebruiker kan hier een probleem melden. Wanneer er de wens is om een screenshot toe te voegen kan de gebruiker dit doen door op de knop “Screenshot Tool” te drukken. Als de melding klaar is kan er op “Versturen” worden gedrukt om de melding te verzenden.
Screenshot scherm.
Dit is het dialoog dat wordt opgeroepen wanneer gebruiker op de “Screenshot Tool” knop drukt. Er worden instructies weergegeven over hoe er een screenshot moet worden genomen.
De gebruiker heeft dan twee opties: De screenshot toevoegen of terug te keren zonder het toevoegen van een screenshot.
Confirmatiedialoog: nieuwe melding.
Wanneer de gebruiker een melding heeft verstuurd wordt dit confirmatiedialoog getoond. Dit scherm sluit automatisch na 5 seconden (in de knop telt de tijd af).
De gebruiker kan de wens hebben om direct nog een melding te doen. Daarom blijven de drie meldingmogelijkheden staan. Zo kan er direct gestart worden.
Notificatie tooltip: Antwoord van support.
(We gaan er nu vanuit dat er aan de support kant is gereageerd. Hoe dit precies gaat wordt in het volgende deel weergegeven).
Wanneer de support een bericht heeft verzonden naar de gebruiker wordt er een notificatie weergegeven. Zo weet de gebruiker of er nieuwe berichten zijn. De feedbacktool kan dan worden geopend om het bericht te lezen.
Het start scherm: zonder eerdere communicatie.
Dit is hetzelfde startscherm dat eerder is getoond, maar dan met de communicatielijst.
Te zien zijn twee meldingen die door de gebruiker zijn aangemaakt. De status en de datum van de melding worden samen met de omschrijving weergegeven.
De gebruiker kan dan een bericht aanklikken waarmee de historie van het bericht wordt weergegeven.
Communicatie historie
In het bovenste deel wordt de communicatiehistorie van de melding getoond. De berichten zijn gesorteerd van nieuw naar oud. De gebruiker kan zo dus terugkijken op de melding. Wanneer het gewenst is kan er een reactie worden geplaatst.
Communicatie historie met reactie dialoog.
In het onderste deel kan de gebruiker een reactie typen. Net zoals in een nieuwe melding kan er weer een screenshot worden toegevoegd.
Confirmatiedialoog: reactie
Na het versturen van de reactie wordt er een confirmatiedialoog weergegeven. Dit scherm sluit automatisch na 5 seconden (in de knop telt de tijd af).
Dit is het gehele traject dat een gebruiker van een applicatie kan verwachten wanneer er gebruik wordt gemaakt van de feedbacktool.
Manageme nt
De managementomgeving is zichtbaar voor de supportafdeling of de ontwikkelaars. Hier kan een overzicht worden weergegeven van alle meldingen, applicaties en bedrijven.
De meldingen van alle aangesloten feedback clients komen hier binnen. Er kunnen dus meerdere applicaties en/of bedrijven worden onderhouden in een managementomgeving.
Gebruikers van de managementomgeving worden hierna als ‘de support’ aangeduid.
Feedback overzicht
Wanneer er op het kopje “Feedback” wordt geklikt (of wanneer er al in het feedback gedeelte wordt gewerkt op het kopje “Overzicht”) wordt het hier bovenstaande overzicht weergegeven.
Dit is het overzicht van alle meldingen. Het aantal onbeantwoorde en beantwoorde meldingen wordt weergegeven zodat er gelijk gezien kan worden of er nog meldingen open staan.
De support kan dan in het menu of op de blokken klikken om naar de lijst te gaan van het gewenste type melding.
Meldingenoverzicht: Problemen
Het overzicht van een bepaalde type melding, in dit geval problemen. Hier worden alle meldingen getoond in de volgorde van nieuwste wijziging naar de oudste wijziging. Er kan op status van de melding worden gefilterd. Dit wil zeggen dat er alleen meldingen worden weergegeven die niet zijn gemarkeerd (standaard worden gesloten meldingen niet getoond).
De kleur links in de rij van een melding geeft de status van de melding weer.
Groen: Gesloten
Geel: Fixed
Oranje: Pending
Rood: Open
Door op een rij te klikken kan een melding worden geopend. Een beheerder kan eventueel ook meldingen verwijderen.
