Waarom een robot die op het verkeerde moment groet de illusie van echtheid doorbreekt

Een begroeting als “Goedemorgen” is een sociaal signaal, maar geeft ook informatie. Een gebruiker kan die vergelijken met de klok op hetzelfde scherm of met de lokale tijd die diegene kent. Als de twee niet overeenkomen, is de mismatch meteen zichtbaar en kan de begroeting automatisch aanvoelen. Dat is een ontwerpconclusie op basis van de waarneembare inconsistentie; het bewijst niet dat elke gebruiker hetzelfde zal reageren.

Onderzoek naar gesprekssystemen laat zien dat fouten invloed kunnen hebben op hoe mensen een agent waarnemen, al verschilt het effect per type fout. In een onderzoek naar een belichaamde gespreksagent verminderden fouten in de beurtwisseling de sympathie, terwijl sommige coherentieproblemen een ander effect hadden. De nuttige les is niet dat een begroeting op het verkeerde moment altijd een bepaalde reactie oproept, maar dat interactiefouten indrukken kunnen beïnvloeden die verder reiken dan de directe inhoud. Adobe Research, “Analyse van gespreksfouten in mens-agentinteractie”

Een tijdgebonden begroeting kan ook bewustzijn suggereren dat het systeem misschien niet heeft. De actuele kloktijd kennen is niet hetzelfde als weten wanneer iemand wakker is geworden, wat diegene aan het doen is of welk deel van de dag diegene als “ochtend” beschouwt. Een betrouwbare tijdsaanduiding maakt een juiste formulering mogelijk, maar bewijst geen persoonlijk inzicht.

Behandel de actuele tijd en de lokale tijdzone van de gebruiker als afzonderlijke invoerwaarden. Een tijdstempel geeft een punt op de tijdlijn aan; een tijdzone bevat de regels die nodig zijn om dat moment als lokale kloktijd weer te geven. De richtlijnen van het W3C maken onderscheid tussen deze tijdsweergaven en leggen uit dat tijdzones regels voor afwijkingen en wijzigingen naar zomertijd omvatten. Voor het berekenen van de lokale tijd raadt het W3C aan een tijdzone-identificatie te gebruiken. W3C, “Werken met tijd en tijdzones”

Een robuuste werkwijze voor een begroeting die door software wordt gegenereerd is:

Verkrijg het actuele moment via een systeemklok of een andere betrouwbare tijdsbron.

Verkrijg een tijdzone-instelling waarvan bekend is dat die overeenkomt met de beoogde gebruiker of de context van het gesprek.

Zet het moment om naar die tijdzone met een formatter die rekening houdt met tijdzones.

Kies de begroeting op basis van de omgerekende lokale tijd of laat de tijdsaanduiding weg als de context ontbreekt of verouderd is.

In JavaScript accepteert Intl.DateTimeFormat een optie timeZone voor het formatteren van een datum. Als een toepassing die optie weglaat, wordt de actuele tijdzone van de hostomgeving gebruikt. Dat kan de tijdzone van de server of het apparaat zijn in plaats van die van de gebruiker. De formatter kan ook de tijd en datum weergeven die de interface voor hetzelfde moment toont. MDN, “Intl.DateTimeFormat”

Alleen een numerieke afwijking is mogelijk niet voldoende voor toekomstig of terugkerend tijdgedrag. Een benoemde zone zoals Europe/London staat voor een verzameling regionale regels; de afwijking kan per datum verschillen. IANA legt uit dat de tijdzonedatabase wordt bijgewerkt om veranderingen in grenzen, UTC-afwijkingen en regels voor zomertijd weer te geven. Software is dus afhankelijk van zowel een geschikte zone als redelijk actuele tijdzonedata. IANA, “Tijdzones”

De begroeting en de klok op het scherm moeten worden afgeleid van dezelfde tijdstempel en dezelfde tijdzonecontext. Als het ene onderdeel de lokale tijdzone van de browser gebruikt en het andere een standaardtijdzone van de server, kunnen ze rond middernacht of wanneer iemand reist van elkaar verschillen. Als de interface een datum toont, controleer die dan samen met de begroeting: de lokale datum kan afwijken van de datum op de locatie van de server.

Een nuttige implementatieregel is om de lokale tijd één keer te berekenen voor de gespreksgebeurtenis en dat resultaat zowel aan de begroetingslogica als aan de weergave door te geven. Vraag een taalmodel niet afzonderlijk om de tijd af te leiden uit gesprekstekst, apparaatcontext of een onthouden schema. Het model kan op basis van een geverifieerde waarde de formulering kiezen, maar de klokberekening moet op tijdgegevens berusten.

Als een gebruiker geen tijdzone heeft opgegeven en het product geen betrouwbare lokale instelling heeft, vermijd dan een uitspraak over een specifiek deel van de dag. “Hallo” blijft accuraat in alle tijdzones en op alle tijdstippen. Als voor een taak een expliciete zone nodig is, vraag daar dan duidelijk en laagdrempelig naar in plaats van stilzwijgend de tijdzone van de server als die van de gebruiker te behandelen.

Er bestaat geen universele, feitelijke grens tussen ochtend, middag en avond. Teams moeten bereiken in lokale tijd vastleggen als een keuze voor de productformulering en vervolgens nagaan of de gekozen bewoording past bij de beoogde toon. Houd deze bereiken expliciet in de configuratie of code, zodat reviewers kunnen zien wat er bij elke grens gebeurt. Vermijd bewoordingen die kennis van iemands routine suggereren, zoals “Je bent vroeg op”, tenzij de gebruiker die informatie daadwerkelijk heeft gegeven en die relevant is.

Een veilige terugvaloptie hoort bij het ontwerp. Als de tijdstempel ongeldig is, de tijdzone-identificatie ontbreekt of niet wordt herkend, of de omzetting mislukt, gebruik dan een neutrale begroeting. Vervang die niet door de klok van de server zonder die keuze expliciet te maken. Als de klokweergave vertraagd kan zijn, kan een algemeen “Hallo” ook beter standhouden dan een begroeting die onjuist wordt terwijl een bericht wacht om te verschijnen.

Een test van het normale verloop op een gebruikelijk lokaal tijdstip brengt veel tijdsproblemen niet aan het licht. Gebruik vaste tijdstempels en expliciete tijdzones voor reproduceerbare resultaten, en controleer gevallen zoals:

Een tijdstip vlak voor en na elke grens tussen begroetingen.

Lokale middernacht, inclusief een datumwisseling tussen de lokale weergave en de server.

Twee zones met op hetzelfde moment verschillende lokale datums.

Een overgang naar of uit zomertijd in een zone waar dat wordt toegepast.

Een zone met een afwijking van een halfuur of een kwartier.

Een ontbrekende of ongeldige zone, waarbij het verwachte resultaat een neutrale begroeting is.

Een vertraagd bericht, waarbij wordt gecontroleerd of de formulering is gebaseerd op het generatiemoment of het weergavemoment, en of die keuze overeenkomt met het gedrag van het product.

Deze gevallen volgen uit de manier waarop tijdzones momenten omzetten naar lokale kloktijd en uit het feit dat regionale klokregels kunnen veranderen. Een testsuite moet het gekozen gedrag zichtbaar maken in plaats van te vertrouwen op een impliciete standaardinstelling van de machine. De releasegeschiedenis van IANA documenteert daadwerkelijke regelwijzigingen en herinnert eraan dat testomgevingen en ingezette tijdzonedata verouderd kunnen raken. IANA, “Releases van de tijdzonedatabase”

Gebruik een tijdgebonden begroeting alleen als drie dingen beschikbaar zijn: een betrouwbaar actueel moment, een tijdzone die aan de gesprekscontext is gekoppeld en consistente opmaak voor de begroeting en elke zichtbare klok. Als een van deze elementen onzeker is, kies dan een neutrale formulering. Als het systeem alleen de tijd kent, kan het nauwkeurig naar het tijdstip van de dag verwijzen; het moet niet suggereren dat het iemands schema, stemming of activiteit kent.

Een begroeting kan een assistent op zichzelf niet attent doen overkomen. De waarde ervan hangt af van de vraag of de kleine bewering die erin besloten ligt overeenkomt met de rest van de interface. Nauwkeurige, terughoudende formuleringen geven de interactie een samenhangend begin en laten de persoonlijke context over aan degene die die daadwerkelijk kan geven.