Waarom is een koppeling met Google Calendar eenrichtingsverkeer?

Met jodiBooks bieden we een koppeling naar Google Calendar en Apple Calendar aan. We beschrijven in onze handleiding hoe die werkt.

Net als andere software pakketten beperken wij ons voorlopig tot een éénrichtingskoppeling: Google en Apple kunnen jouw jodiBooks agenda wel lezen, maar wijzigingen maken kan niet vanuit hun apps of website. Daarvoor moet je naar je jodiBooks dashboard.

De vraag of het niet twéé kanten op kan is er een die ik online wel zie, bij verzoekjes aan andere software makers. We hebben erover gedacht: Zullen wij een van de weinigen worden die dit wel aanbiedt? Het eerlijke antwoord is: Het staat op onze wensenlijst omdat het heel gaaf zou zijn als we dit (goed) konden, maar het krijgt geen voorrang. Een tweerichtingskoppeling met Google of Apple is erg lastig. Nou deinzen we niet meteen terug voor moeilijke dingen, maar het is zo'n uitdaging dat het waarschijnlijk heel wat extra knopjes in jodiBooks zou opleveren. We willen jodiBooks zo simpel mogelijk houden en zien nog geen manier om dit makkelijk te doen. We zullen er daarom eerder voor kiezen om onze agenda in onze eigen app te zetten.

Waarom is een tweerichtingskoppeling lastig?

Elk software programma heeft in de basis vier acties die het ondersteunt: Maken, Lezen, Wijzigen en Verwijderen. (Ook wel CRUD, naar het Engels Create, Read, Update, Delete).

Bij de eenrichtingskoppeling is het Google of Apple die met enige regelmaat (1 of 2x per dag) bij jodiBooks aanklopt en vraagt om jouw agenda te mogen Lezen. Onze software geeft Google dan de lijst van toekomstige afspraken. Die lijst moet er op een bepaalde manier uitzien, het zogenaamde 'iCal' format. Dit iCal format is een internationale standaard. We moeten het dan doen met veldjes die iCal ondersteunt. Dat betekent dat we jouw afspraken in je jodiBooks agenda een beetje moeten platslaan.

Laten we het aan de hand van een voorbeeld tonen. Stel, je hebt de volgende afspraak in je jodiBooks Agenda.

Hier halen we de klant, behandeling en de omschrijving uit. Het woordje 'Klant' of 'Customer' komt in het iCal format niet voor. Ook is er geen veldje 'Behandeling' of 'Behandelingen'. We voegen de behandeling en omschrijving samen tot een iCal "Description". De klantnaam geven we door als "Summary", de titel.

Dit geeft al een beetje een hint wat er moeilijk is aan een tweerichtingskoppeling. Als jij vanuit Google afspraken wilt Maken of Wijzigen, hoe krijgt jodiBooks dat dan weer gesplitst en in de juiste invoervelden gezet? Het is voor een mens heel makkelijk, maar voor een computer heel moeilijk om uit onderstaande tekst de klant naam, behandeling en opmerkingen van elkaar te scheiden. In onderstaand plaatje zie jij meteen wat de bedoeling is.

Hoe veel onderzoeksgeld er ook in gestopt wordt, het vraagstuk "Laat een computer net zo goed begrijpend lezen als een mens" is nog niet opgelost. Wij hebben er zeker niet de expertise voor.

Andere vragen bij een tweerichtingskoppeling

Als je in jodiBooks een afspraak Maakt, Wijzigt of Verwijdert, dan komt het met de eenrichtingskoppeling goed. De volgende keer dat Google bij ons aanklopt, krijgen ze de laatste versie van jouw jodiBooks agenda. De enige actie die bij eenrichtingskoppeling door Google wordt gedaan is Lezen. De andere drie acties, die mag Google niet doen. Willen we daar een tweerichtingskoppeling van maken, dan moet het andersom.

Laten we even een denkbeeldig salon software pakket in gedachten nemen wat een tweerichtingskoppeling heeft. We noemen dit pakket: ComplexSalon.

Bij een tweerichtingskoppeling geeft ComplexSalon per afspraak aan Google door wat er gewijzigd is. En omdat je in Google dan ook wijzigingen kunt maken in de agenda, geeft Google ook informatie door aan ComplexSalon. Dit is het verschil tussen wat we "pull" en "push" noemen. Bij de eenrichtingskoppeling is het Google die een "pull" doet en om de agenda vraagt (Lezen). Bij de tweerichtingskoppeling zijn het Google en ComplexSalon die over en weer informatie naar elkaar sturen, "pushen", elke keer als ze een afspraak Maken, Wijzigen of Verwijderen. Dat maakt het soms lastig.

• ComplexSalon moet bijhouden welke externe agenda's hij allemaal in moet lichten (Google, Apple, misschien wel de Google agenda van je stagiair). En ComplexSalon moet weten welke externe agenda informatie naar hém kan sturen. Dat betekent extra instellingen en vinkjes in ComplexSalon om het in te richten.
• Als je in Google Agenda een afspraak maakt, hoe weet ComplexSalon dan of het een afspraak met een klant is of een privé afspraak?
• Hoe weet ComplexSalon welk woordje in de titel of omschrijving de naam van de klant is? * Je kunt je klanten natuurlijk uitnodigen als deelnemer van de afspraak. Maar dan krijgen je klanten zowel van Google Calendar als van ComplexSalon een berichtje. Wil je dat?
• Moet ComplexSalon toegang krijgen tot jouw Google adresboek? En zo ja, wat moet er dan in ComplexSalon gebeuren als je die persoon aanpast of wijzigt in Google? Moet dat ook gesynchroniseerd worden?
• Als ComplexSalon iets overneemt uit Google Calendar wat niet had gemoeten, en jij verwijdert het weer uit ComplexSalon, hoe voorkom je dan dat ComplexSalon dit ook tegen Google zegt en het ook uit Google verdwijnt? Oh jee, dat wordt weer een extra vinkje ergens...
• En natuurlijk de behandelingen: Als ComplexSalon een afspraak heeft met behandelingen, moet hij die noodgedwongen in de omschrijving zetten als hij de afspraak naar Google "pusht". Wat nu als je in Google Calendar de afspraak verplaatst? Google Calendar stuurt dan de bijgewerkte afspraak weer naar ComplexSalon maar de behandelingen staan nu platgeslagen in de omschrijving. ComplexSalon moet dit dan weer uit elkaar peuteren...

Dit zijn maar een paar van de vragen die de software makers van ComplexSalon moeten beantwoorden. De kans dat het software pakket de verkeerde keuze maakt, wordt groter met het aantal opties dat je toevoegt. Dat maakt dat er niet alleen veel tijd gaat zitten in het maken van zo'n tweerichtingskoppeling, maar ook dat het nogal foutgevoelig wordt.

In feite is het een probleem wat onder software bouwers ook wel "ownership" genoemd wordt: Van wie is bepaalde informatie nou? Zolang het een eenrichtingskoppeling is, is het duidelijk welk software pakket wijzigingen mag maken in de afspraken. Maar zodra het tweerichtingsverkeer wordt, hebben Google Calendar en _ComplexSalon_ allebei een versie van de agenda. Allebei hebben ze instellingen en invoervelden die de ander niet heeft, ze moeten allebei een vertaalslag maken en ze moeten allebei bepalen wanneer ze elkaar moeten inlichten van wijzigingen.

Natuurlijk kun je daar eens goed voor gaan zitten en allerlei slimme software proberen te bouwen. Maar het blijft foutgevoelig. Daarom laten wij het in jodiBooks voorlopig even zoals het nu is, met onze bestaande eenrichtingskoppeling.

Wil je wel eens met eigen ogen zien hoe makkelijk jodiBooks is? Kijk dan eens in onze demo. Onze demo is openbaar. Je hoeft geen account te maken en ook geen gegevens achter te laten om onze demo te proberen.