Dlaczego powitanie robota o niewłaściwej porze burzy iluzję naturalności
Powitanie dopasowane do pory dnia brzmi jak drobna uprzejmość, ale zawiera też twierdzenie o faktach: system wie, która jest godzina tam, gdzie toczy się rozmowa. Jeśli mówi „Dzień dobry” w nocy, ta rozbieżność może sprawić, że cała interakcja wyda się sztampowa lub niewiarygodna. Praktyczne rozwiązanie polega na tym, by wszelkie odniesienia do pory opierać na aktualnym znaczniku czasu i określonej strefie czasowej, zadbać o zgodność powitania z godziną widoczną w innych miejscach oraz przetestować sytuacje graniczne. Gdy brakuje takiego kontekstu, proste „Cześć” jest bardziej niezawodne niż zgadywanie, że ktoś ma poranek.
Dlaczego niewłaściwa pora wydaje się czymś więcej niż błędem w sformułowaniu
Powitanie takie jak „Dzień dobry” jest sygnałem społecznym, ale niesie też informację. Użytkownik może porównać je z zegarem na tym samym ekranie albo z lokalną godziną, którą zna. Gdy te informacje są sprzeczne, rozbieżność od razu rzuca się w oczy i może sprawić, że powitanie wyda się automatyczne. To wniosek projektowy wynikający z widocznej niespójności; nie dowodzi, że każdy użytkownik zareaguje tak samo.
Badania nad agentami konwersacyjnymi pokazują, że błędy mogą wpływać na to, jak ludzie postrzegają agenta, choć skutki zależą od rodzaju błędu. W badaniu ucieleśnionego agenta konwersacyjnego błędy w naprzemienności wypowiedzi obniżały sympatię, podczas gdy niektóre błędy spójności działały inaczej. Praktyczny wniosek nie jest taki, że powitanie o niewłaściwej porze zawsze wywoła określoną reakcję, lecz że błędy w interakcji mogą kształtować wrażenia wykraczające poza bezpośrednią treść. Adobe Research, „Conversational Error Analysis in Human-Agent Interaction”
Powitanie nawiązujące do pory dnia może też sugerować świadomość, której system może nie mieć. Znajomość aktualnej godziny nie oznacza, że system wie, kiedy dana osoba wstała, co robi ani którą część dnia uważa za „poranek”. Dokładne odmierzanie czasu pomaga dobrać właściwe sformułowanie, ale nie świadczy o osobistym zrozumieniu.
Zacznij od znacznika czasu i znanej strefy czasowej
Traktuj aktualny czas i lokalną strefę czasową użytkownika jako osobne dane wejściowe. Znacznik czasu wskazuje punkt na osi czasu; strefa czasowa określa reguły potrzebne do wyrażenia tej chwili jako lokalnego czasu zegarowego. Wytyczne W3C rozróżniają te sposoby przedstawiania czasu i wyjaśniają, że strefy czasowe obejmują reguły dotyczące przesunięć i zmian czasu letniego. W3C zaleca użycie identyfikatora strefy czasowej, jeśli jest on potrzebny do obliczenia czasu lokalnego. W3C, „Working with Time and Timezones”
W przypadku powitania generowanego przez oprogramowanie niezawodna kolejność działań wygląda następująco:
Pobierz bieżącą chwilę z zegara systemowego lub innego zaufanego źródła czasu.
Pobierz ustawienie strefy czasowej, o którym wiadomo, że odpowiada zamierzonemu użytkownikowi lub kontekstowi rozmowy.
Przelicz tę chwilę na czas w danej strefie za pomocą formatowania uwzględniającego strefę czasową.
Wybierz powitanie na podstawie przeliczonego czasu lokalnego albo pomiń odniesienie do pory, jeśli kontekst jest niedostępny lub nieaktualny.
W JavaScript funkcja Intl.DateTimeFormat przyjmuje opcję timeZone do formatowania daty. Jeśli aplikacja pominie tę opcję, zostanie użyta aktualna strefa czasowa środowiska, w którym działa kod. Może to być strefa serwera lub urządzenia, a nie użytkownika. Ten sam formatter może też zwracać godzinę i datę wyświetlane w interfejsie na podstawie tej samej chwili. MDN, „Intl.DateTimeFormat”
Samo przesunięcie numeryczne może nie wystarczyć do obsługi przyszłych lub powtarzających się zdarzeń. Nazwana strefa, taka jak Europe/London, odzwierciedla zbiór regionalnych reguł; przesunięcie może się zmieniać w zależności od daty. IANA wyjaśnia, że jej baza danych stref czasowych jest aktualizowana, by uwzględniać zmiany granic, przesunięć względem UTC i reguł czasu letniego. Oprogramowanie zależy więc zarówno od odpowiedniej strefy, jak i od dostatecznie aktualnych danych o strefach czasowych. IANA, „Time Zones”
Oprzyj powitanie i widoczny zegar na tym samym źródle
Powitanie i zegar na ekranie powinny być wyliczane na podstawie tego samego znacznika czasu i tego samego kontekstu strefy czasowej. Jeśli jeden element korzysta z lokalnej strefy przeglądarki, a drugi z domyślnej strefy serwera, mogą się różnić około północy lub podczas podróży użytkownika. Jeśli interfejs wyświetla datę, sprawdź ją razem z powitaniem: lokalna data może różnić się od daty w miejscu, w którym znajduje się serwer.
Przydatna zasada wdrożeniowa: oblicz czas lokalny raz dla danego zdarzenia w rozmowie i przekaż wynik zarówno logice powitania, jak i elementowi wyświetlającemu godzinę. Nie proś osobno modelu językowego o odgadnięcie pory na podstawie tekstu rozmowy, kontekstu urządzenia lub zapamiętanego harmonogramu. Model może wybrać sformułowanie na podstawie zweryfikowanej wartości, ale obliczenie czasu powinno opierać się na danych o czasie.
Jeśli użytkownik nie podał strefy czasowej, a produkt nie ma wiarygodnego ustawienia lokalnego, unikaj wskazywania konkretnej pory dnia. „Cześć” pozostaje trafne niezależnie od strefy i godziny. Jeśli do wykonania zadania konieczne jest określenie strefy, poproś o nią w jasny i niewymagający wysiłku sposób, zamiast po cichu uznawać strefę serwera za strefę użytkownika.
Przemyśl granice pór powitania
Nie ma uniwersalnej, obiektywnej granicy między porankiem, popołudniem i wieczorem. Zespoły powinny określić przedziały czasu lokalnego jako decyzję dotyczącą języka produktu, a następnie sprawdzić, czy wybrane sformułowania pasują do zamierzonego tonu. Zapisz te przedziały jawnie w konfiguracji lub kodzie, aby osoby sprawdzające mogły zobaczyć, co dzieje się na każdej granicy. Unikaj sformułowań sugerujących znajomość czyjejś rutyny, takich jak „Wcześnie dziś wstałeś”, chyba że użytkownik rzeczywiście podał taką informację i jest ona istotna.
Bezpieczny wariant awaryjny powinien być częścią projektu. Jeśli znacznik czasu jest nieprawidłowy, brakuje identyfikatora strefy czasowej lub jest on nierozpoznany albo przeliczenie się nie powiedzie, użyj neutralnego powitania. Nie zastępuj tych danych zegarem serwera bez jawnego podjęcia takiej decyzji. Jeśli odczyt zegara może być opóźniony, ogólne „Cześć” może też dłużej zachować aktualność niż powitanie, które stanie się nietrafne, zanim wiadomość zostanie wyświetlona.
Testuj przejścia i kontekst, a nie tylko typowe popołudnie
Test typowej sytuacji w zwykłej porze lokalnej nie ujawni wielu błędów związanych z czasem. Używaj stałych znaczników czasu i jawnie określonych stref, aby wyniki były powtarzalne, i sprawdzaj takie przypadki jak:
Czas tuż przed każdą granicą pory powitania i tuż po niej.
Lokalna północ, w tym zmiana daty między lokalnym wyświetlaczem a serwerem.
Dwie strefy, w których w tej samej chwili obowiązują różne daty lokalne.
Zmiana czasu letniego w strefie, która ją stosuje.
Strefa z przesunięciem o pół godziny lub kwadrans.
Brakująca lub nieprawidłowa strefa, gdy oczekiwanym wynikiem jest neutralne powitanie.
Opóźniona wiadomość: sprawdź, czy jej sformułowanie opiera się na czasie wygenerowania czy wyświetlenia oraz czy ten wybór jest zgodny ze sposobem działania produktu.
Te przypadki wynikają ze sposobu, w jaki strefy czasowe przeliczają chwile na lokalny czas zegarowy, oraz z tego, że regionalne reguły dotyczące zegarów mogą się zmieniać. Zestaw testów powinien jasno pokazywać przyjęte zachowanie, zamiast polegać na niejawnym ustawieniu domyślnym komputera. Historia wydań IANA dokumentuje rzeczywiste zmiany reguł, przypominając, że środowiska testowe i wdrożone dane o strefach czasowych mogą się zdezaktualizować. IANA, „Time Zone Database Releases”
Praktyczna zasada decyzyjna dla zespołów produktowych
Używaj powitania dopasowanego do pory dnia tylko wtedy, gdy dostępne są trzy elementy: wiarygodna bieżąca chwila, strefa czasowa powiązana z kontekstem rozmowy oraz spójne formatowanie powitania i każdego widocznego zegara. Jeśli którykolwiek z tych elementów jest niepewny, wybierz neutralne sformułowanie. Jeśli system zna tylko godzinę, może poprawnie odnieść się do pory dnia; nie powinien sugerować, że zna harmonogram, nastrój ani aktywność danej osoby.
Samo powitanie nie sprawi, że asystent wyda się uważny. Jego wartość zależy od tego, czy zawarte w nim drobne twierdzenie zgadza się z resztą interfejsu. Trafne, powściągliwe sformułowanie zapewnia spójny początek interakcji, pozostawiając osobisty kontekst osobie, która może go rzeczywiście podać.