DI pokalbių botas svetainės formoms: laukų pagalba, klaidos ir saugus perdavimas

Sudėtingos svetainės formos retai būna neatsiųstos dėl vieno vienintelio įvesties lauko. Dažniausiai nepatogumų kyla dėl kelių smulkių neaiškumų: apie kokį dokumentą kalbama? Kokiu formatu tikimasi datos? Kodėl tam tikra informacija buvo atmesta? Ir kas nutinka, jei išskirtinis atvejis netelpa į numatytas parinktis? DI pokalbių botas svetainės formoms gali padėti būtent šiose vietose – paaiškindamas formą, tačiau neišgalvodamas jos taisyklių ir nepriimdamas sprendimų už vartotoją.

Teisingas požiūris nėra botas, kuris „tiesiog kažkaip padeda pildyti“. Reikalingas aiškiai apibrėžtas pagalbos sluoksnis su patikrinta laukų informacija, suprantamais klaidų pranešimais, prieinamu valdymu, duomenų apsaugos ribomis ir patikimu būdu gauti žmogaus pagalbą. Šis gidas parodo, kaip svetainių, produktų ir klientų aptarnavimo komandos gali planuoti, testuoti ir valdyti šį sluoksnį.

Forma išlieka vienintelis autoritetingas šaltinis

Pokalbių botas gali paaiškinti, tačiau neturi apsimesti, kad žino serverio tikrinimo būseną, kurios nemato. Forma arba atitinkama paslauga išlieka privalomų laukų, leistinų reikšmių, terminų, teisių ir faktinio pateikimo šaltinis. Botas naudoja tik patvirtintą informaciją ir atvirai įvardija nežinomuosius.

Šis atskyrimas apsaugo nuo pavojingų klaidingų išvadų. Pavyzdžiui, naudingas atsakymas skambėtų taip: „Šiam laukui numatytas formatas MMMM-MM-DD.“ Tačiau problemiškas būtų pasakymas: „Data tikrai galioja“, nors turinio patikra atliekama tik išsiunčiant formą. Taip pat botas neturėtų be leidimo perkelti asmens duomenų iš pokalbio į formos laukus ir neturėtų tvirtinti pateikimo, kurio forma dar nepatvirtino.

Pradėkite nuo laukų pagalbos matricos

Prieš kuriant užklausas (promptus), kiekvienam svarbiam laukui reikia trumpo, versijuojamo žinių įrašo. Praktiška laukų pagalbos matrica apima:

• stabilią lauko ID ir matomą pavadinimą;
• įvesties tikslą suprantama kalba;
• privalomumo arba neprivalomumo būseną bei leistinus formatus;
• neutralų pavyzdį be tikrų asmens duomenų;
• žinomus išskirtinius ir nenumatytus atvejus;
• atsakingą šaltinį ir jo atnaujinimo datą;
• tinkamą klaidų pagalbą ir eskalavimo kelią.

Pokalbių botas turėtų gauti tik dabartinio formos žingsnio ir konkretaus pagalbos klausimo kontekstą. Jam nereikia žinoti viso iki šiol užpildyto prašymo, jei vartotojas tiesiog teiraujasi apie datos formatą. Tai sumažina duomenų perdavimą, blaškymą ir daro atsakymus lengviau patikrinamus.

Pagalba turi išlikti šalia lauko

Pokalbių botas nepakeičia tvarkingų pavadinimų (labels), užuominų ir klaidų pranešimų pačioje formoje. W3C Web Accessibility Initiative rekomenduoja būtinas įvestis, formatus ir susijusias instrukcijas tiesiogiai ir programiškai susieti su atitinkamu valdymo elementu. Pavyzdžiui, užuominos gali būti priskirtos laukui naudojant aria-describedby. Botas papildo šią informaciją paaiškinimu ar pavyzdžiu, tačiau neturi būti vienintelė vieta, kurioje ji randama.

Todėl suplanuokite du lygius: trumpą, nuolat matomą pagalbą šalia lauko visiems ir išsamesnę pokalbio pagalbą konkretiems klausimams. Tie, kurie negali arba nenori atidaryti pokalbio lango, vis tiek turi gebėti sėkmingai užpildyti formą. Daugiau informacijos rasite WCAG patikros sąraše prieinamiems DI pokalbių botams.

Klaidų pranešimai tampa konkrečiais tolesniais veiksmais

„Neteisinga įvestis“ nepaaiškina nei problemos, nei sprendimo. Pagal WCAG 2.2 sėkmės kriterijų 3.3.1, automatiškai aptikta įvesties klaida turi būti identifikuota ir aprašyta tekstu. W3C gairės taip pat rodo, kad tikslus aprašymas dažnai kartu pateikia ir pataisymo galimybę. Jungtinės Karalystės GOV.UK Design System rekomenduoja neištrinti neteisingos įvesties ir naudoti tą patį aiškų pranešimą tiek prie lauko, tiek klaidų santraukoje.

Botas gali paaiškinti esamą pranešimą kasdienio vartojimo kalba, tačiau neturėtų keisti jo reikšmės. Pavyzdžiui, iš „Gimimo data: formato klaida“ tampa: „Įveskite dieną, mėnesį ir metus po du skaitmenis, pavyzdžiui, 1990-04-08.“ O esant pranešimui „Paslauga šiuo metu nepasiekiama“, jis neturi teigti, kad vartotojo įvestis neteisinga. Techniniai sutrikimai, teisių trūkumas ir turinio įvesties klaidos reikalauja skirtingų atsakymų ir skirtingų tolesnių veiksmų.

Tikrinimas išlieka deterministinis ir atliekamas serveryje

Privalomiems laukams, reikšmių rėžiams, failų tipams ar dalykinėms taisyklėms deterministinis tikrinimas (validacija) tinka geriau nei laisva teksto generacija. W3C formų gairėse pažymima, kad tikrinimas kliento pusėje gali pagerinti naudojimą, tačiau yra lengvai apeinamas; todėl saugumui svarbus tikrinimas privalo vykti ir serveryje. Pokalbių botas paaiškina šių taisyklių rezultatą, tačiau jų nepakeičia.

Patikima seka atrodo taip: forma patikrina įvestį, pateikia stabilų klaidos kodą, sąsaja rodo aiškų pranešimą, o botas, remdamasis tuo pačiu kodu, gali pasiūlyti papildomą pagalbą. Taip informacija išlieka nuosekli skirtingose kalbose ir kanaluose. Jei žinomo klaidos kodo nėra, botas atsako atsargiai ir nukreipia į matomą pranešimą arba klientų aptarnavimą, užuot spėliojęs priežastį.

Asmens duomenys neturi automatiškai patekti į pokalbį

Formose gali būti tvarkomi kontaktiniai duomenys, sutarčių numeriai, sveikatos duomenys, tapatybės dokumentai ar kitas jautrus turinys. Todėl pagalbos funkcija turėtų vadovautis duomenų mažinimo principu. Atsakant į klausimą „Koks datos formatas taikomas?“, modeliui nereikia tikros gimimo datos. Klausimui „Kurią dokumento pusę turėčiau įkelti?“, kaip taisyklė, nereikia dokumento kopijos.

Suformuluokite užuominas, kurios padeda išvengti nereikalingo duomenų atskleidimo: „Nenurodykite čia viso asmens kodo. Aprašykite tik tai, kuris pavadinimas neaiškus.“ Neregistruokite daugiau konteksto, nei būtina palaikymui ir kokybės kontrolei. Jei saugiam apdorojimui reikalingi autentiškumo patvirtinti duomenys, jie turi būti tvarkomi tam skirtoje apsaugotoje sistemoje, o ne viešame svetainės pokalbyje.

Trinties signalai padeda – bet be spaudimo

Botas gali pasiūlyti pagalbą, jei kas nors pakartotinai gauna tą patį klaidos pranešimą, ilgai užtrunka viename žingsnyje arba tikslingai ieško pagalbos. Tačiau jis neturėtų kurti skubos, baimės ar dirbtinio trūkumo pojūčio vien dėl vartotojo dvejonių. Gera pagalba siūlo pasirinkimo galimybes: perskaityti užuominą, tęsti vėliau, patikrinti duomenis arba susisiekti su žmogumi.

Venkite tokių formuluočių kaip „Užbaikite tik dabar“ arba automatinių žinučių po kiekvienos trumpos pauzės. Vietoj to matuokite, ar pagalba iš tiesų padeda atlikti aiškesnius pataisymus: mažiau pakartotinių klaidų kodų, sėkmingas grįžimas prie atitinkamo lauko, savanoriškai panaudota pagalba ir suprantami perdavimai. Vien tik didesnis formos pateikimo rodiklis nėra kokybės įrodymas, jei vartotojai tuo metu pateikia neteisingus duomenis.

Prieinamumas galioja ir pokalbio pagalbai

Botas turi būti pasiekiamas klaviatūra, aiškiai pranešti apie fokuso pasikeitimą ir veikti padidinus vaizdą bei mažuose ekranuose. Atsakymai turi būti aiškiai struktūruoti, pakankamai trumpi ir be nereikalingo profesinio žargono. Jei pagalba atsidaro, ji neturi uždengti klaidingo lauko ar ištrinti įvesto turinio. Uždarius langą, fokusas turi prasmingai grįžti į formą.

W3C pamokose rekomenduojama ilgesnėse formose naudoti logiškus žingsnius ir atpažįstamą pažangos indikatorių. Būtent tuo turėtų vadovautis ir botas: jis įvardija dabartinį žingsnį, paaiškina daugiausiai kitą svarbų žingsnį ir netvirtina, kad visas procesas jau baigtas. Jei įmanoma, reikėtų vengti laiko apribojimų arba leisti juos pratęsti, kad žmonės galėtų dirbti savo tempu.

Apibrėžkite saugų perdavimą žmogui

Perdavimas būtinas, kai taisyklės prieštarauja viena kitai, išskirtinis atvejis nedokumentuotas, pakartotinė pagalba nepadeda, įvyko techninė klaida arba reikalingas privalomas specialistų sprendimas. Perduodama tik būtiniausia informacija: formos pavadinimas, žingsnis, stabilus klaidos kodas, jau pasiūlyta pagalba ir savanoriškas problemos aprašymas. Visos pokalbių istorijos ar visų formos įvesčių perduoti nereikia.

Vartotojas iš anksto turėtų matyti, koks kanalas bus naudojamas, kokie duomenys perduodami ir ar tikėtinas laukimo laikas. Perdavimo žmogui gidas parodo, kaip dera konteksto paketas, nukreipimas ir atsakomybė. Potencialių klientų arba kontaktų formose taip pat padeda aiškus, minimalus klausimų kelias, kaip aprašyta straipsnyje apie daugiakalbį leadų kvalifikavimą.

Testuokite taisykles, kalbą ir sąsają kartu

Izoliuoto užklausų (prompt) testavimo neužteks. Sukurkite testavimo matricą iš tikrų formos būsenų ir tikėtinų atsakymų. Tai apima tuščius privalomus laukus, neteisingus formatus, ribines reikšmes, nežinomus klaidų kodus, serverio sutrikimus, pasibaigusią sesiją, mobiliojo įrenginio klaviatūrą, navigaciją klaviatūra, ekrano skaitytuvą ir kiekvieną palaikomą kalbą. Taip pat patikrinkite, ar pakeitus formą botas vis dar nurodo teisingą lauko ID ir taisyklės versiją.

Kiekvienam atvejui reikalingas aiškus rezultatas: naudingas paaiškinimas, jokių išgalvotų sprendimų, jokių nereikalingų duomenų reikalavimų, teisinga kalba, tinkamas fokusas ir pasiekiamas eskalavimas. Versijos pakeitimai formoje reikalauja iš naujo patikrinti susijusią pagalbą. Anonymizuotų klaidų pavyzdžių patikra gali parodyti, kur trūksta turinio; tačiau tai neturi tapti tyliu jautrių įvesčių rinkimu.

Patikros sąrašas naudojimui gamyboje

1. Forma ir serveris išlieka autoritetingas taisyklių ir būsenos šaltinis.
2. Kiekvienas palaikomas laukas turi patikrintą, versijuojamą lauko pagalbą.
3. Pavadinimai, užuominos ir klaidos išlieka suprantami ir be pokalbio lango.
4. Klaidų kodai pateikia konkrečius, nuoseklius pataisymo patarimus.
5. Asmens duomenys tvarkomi tik esant pagrįstam poreikiui.
6. Botas atpažįsta techninius sutrikimus nekaltindamas vartotojų.
7. Pagalba kilus kliūtims išlieka savanoriška ir be dirbtinio spaudimo.
8. Klaviatūra, ekrano skaitytuvas, vaizdo mastelis, mobilusis vaizdas ir visos kalbos yra patikrinti.
9. Perdavimas žmogui perduoda tik būtiną kontekstą.
10. Formos pakeitimai reikalauja tikslingų žinių ir regresinių testų.

Geras formų pokalbių botas nėra autopilotas. Tai suprantamas, apribotas pagalbos sluoksnis tarp dokumentuotų taisyklių ir konkretaus vartotojo klausimo. Tie, kurie kartu planuoja laukų žinias, klaidų kodus, prieinamumą, duomenų apsaugą ir perdavimą žmogui, sumažina neaiškumus neprarasdami įvesčių ir sprendimų kontrolės.

Šaltiniai ir susiję standartai

• W3C WAI: Forms Tutorial
• W3C WAI: Form Instructions
• W3C WAI: Validating Input
• W3C WAI: User Notification
• W3C WAI: WCAG 2.2 Error Identification
• GOV.UK Design System: Error message