Werken in de cloud, met name documenten, formulieren en spreadsheets, is voor veel bedrijven al de standaard. Binnen Nederland is Google Apps for Work daarin een van de grootste spelers. Zo gebruiken we bij Incentro vaak formulieren om collega’s uit te nodigen voor een meeting of evenement en kunnen we daarmee direct inventariseren wat men wil eten.
We merkten echter dat vaak mensen wel ja zeiden maar geen afspraak in hun agenda zette en daardoor last minute toch niet kwamen. Erg vervelend voor de organisatie. Maar constant iedereen die ‘ja’ antwoord nog eens los een uitnodiging sturen voor het event is ook weer extra werk voor de organisator. Wij vonden dat dit toch makkelijker moest kunnen. Het mooie aan Google Apps for Work is dat indien je opties mist je deze zelf kan programmeren. Daarom hebben we een Event Planner gemaakt voor Google Forms. Onze eerste gedachte was, dit bestaat vast al, maar na enige tijd zoeken kwamen we tot de conclusie dat dit niet het geval was.
Wat hebben we nodig om het zelf te maken?
De eerste vraag die we onszelf stelden was “Wat hebben we nodig?”. Een persoon die het formulier invult (de gebruiker) moet slechts ‘ja’ of ‘nee’ invullen. Echter de maker van het formulier (de auteur) moet het tijdstip en de locatie ingeven.
Het toevoegen van elementen aan een formulier in Google Forms gebeurd allemaal inline. Helaas bleek het niet toegestaan om dit uit te breiden met je eigen form element. Qua gedrag was dat voor ons ideaal geweest want dan kan de auteur gelijk een ‘event planner’ form item toevoegen. Bij plugins die interactie nodig hebben kan je kiezen uit een sidebar of een popup. Omdat we niet per-se de flow van de gebruiker hoeven te onderbreken hebben we gekozen voor de sidebar.
Realisatie
Het maken van een Google Forms add-on is redelijk eenvoudig. Als je een formulier aanmaakt kan je via Tools -> Script Editor snel beginnen met het maken van een add-on. Door op “Google Forms Add-on” te klikken in de script editor popup begin je met een voorbeeld project met onder andere een sidebar. Het voorbeeld project is handig om te zien hoe Google zelf de opzet voor een addon maakt. Als het project is geladen in de Google Scripts Editor zie je twee soorten bestanden geladen: HTML- en GoogleScript bestanden. De CSS en JavaScript worden niet als losse bestanden ingeladen maar blijken in een HTML bestand te staan.
Problemen onderweg
Tijdens het ontwikkelen liepen we tegen een aantal problemen aan. Ten eerste is de taal waar je in schrijft geen JavaScript al lijkt het er wel veel op. Ook debuggen is niet echt heel erg makkelijk.
Google Script !== JavaScript
Wie snel naar een GoogleScript kijkt zal snel denken dat het JavaScript is met een extra Google smaak. Maar niets is minder waar. De code stijl lijkt heel sterk op JavaScript en het is wel eens waar gebaseerd op JavaScript maar ondersteunt niet alle functionaliteiten die JavaScript wel heeft.
Een van de grootste problemen waar we tegenaan liepen was datum en tijd. In JavaScript zijn we gewend aan de new Date() functie. Deze kan verschillende parameters ondersteunen zoals een timestamp, losse parameters voor jaar, maand en dag of een datum string. In GoogleScript is er slechts 1 manier om een nieuwe datum te maken:
new Date('fullMonth dd, yyyy hh:mm:ss') |
Elk ander format dat erin wordt gestopt geeft een epoch van 0, oftewel 1 januari 1970. Nadat we hier allemaal een keer tegenaan waren gelopen, kwamen we erachter dat er een Utilities.formatDate() bestond om een juist datum formaat te genereren. Heel handig, al hadden we het nog makkelijker gevonden als de standaard ‘new Date()’ zou hebben gewerkt.
Debuggen
Nadat de plugin is geschreven is het noodzakelijk deze te testen. Dit kan je doen door in het menu van de script editor Publish -> Test as addon te kiezen. Hiermee kan je een formulier openen waarbinnen je add-on testbaar is. Voor ons was dit in het begin genoeg en dat is het waarschijnlijk voor de meeste plugins. Echter de gebruiker zal, indien deze ‘ja, ik ben er bij’ kiest, ook de afspraak in zijn of haar agenda moeten zien verschijnen. Zodra je dit soort functionaliteit wilt gaan testen zal je je plugin moeten publiceren.
Het publiceren gaat op ongeveer dezelfde manier als het testen van de add-on. Je kiest in het menu Publish -> Deploy as add-on en vult het formulier in. Als je dit hebt gedaan wordt je doorverwezen naar het Google Developer Dashboard en zie je daar je add-on staan. Deze is niet gepubliceerd nog en staat als ‘draft’ genoemd. Om de add-on te kunnen testen moet je hem publiceren. Tijdens de publicatie kan je hem beschikbaar maken voor wie je wilt, onder andere voor een groep testers. Zo kan je de gebruikerskant testen. De addon wordt dan geïnstalleerd voor de editor en zo kan je een formulier maken waar ook op gereageerd kan worden.
Om dit vervolgens te debuggen kan je in de script editor de logs bekijken. Hierbij wordt alleen de laatste actie onthouden en weergegeven. Let er dus op dat je niet gelijk met 100 mensen tegelijk gaat testen want dan heb je geen duidelijke logging.
Conclusie
We hebben ondervonden dat het maken van een add-on relatief eenvoudig is. Er zijn echter wel een aantal haken en ogen aan. Alle punten die in deze blog zijn genoemd zijn overkomelijk en goed op te lossen. De grootste uitdaging is up to date blijven aangezien Google ook door ontwikkeld aan Forms. Zo kan het zijn dat je tool werkt maar een half jaar later niet meer werkt door een update in Google Forms.
Dit bericht is eerder verschenen op Now Digital (http://nowdigital.nl/hands-on-google-apps-for-work-customisation/)