Döntse el, mit csinál valójában az űrlap
Képzeljen el egy budapesti fordítóirodát, amely ajánlatkérő űrlapot tervez. Az űrlap válaszcímet, forrás- és célnyelvet, valamint rövid projektleírást kér. Az irodának először arról kell döntenie, hogy az oldal a látogató levelezőprogramját nyissa meg, vagy a weboldalhoz működtetett szolgáltatásnak továbbítsa a megkeresést.
A levelezőprogramnak történő átadás egyszerűbbé teheti a weboldalt, de az üzenetet a látogatónak még el kell küldenie. Ezt jelezze a művelet mellett, és alternatívaként adjon meg olvasható e-mail-címet. A szerveres űrlap rögzített beküldést kínálhat, de karbantartást és a hibákért felelős személyt igényel. Az iroda tervezett ügyintézési folyamata alapján válasszon megoldást.
Egyeztesse a beviteli szabályokat mindkét oldalon
Az MDN szerint a böngészős ellenőrzés segíti az adatok javítását, a szerveres ellenőrzés azonban továbbra is szükséges, mert a böngésző ellenőrzése megkerülhető. Az iroda szerveres megoldásánál kérje meg a fejlesztőt, hogy tesztadatokkal mutassa be mindkét réteget. A mező zöld körvonala még nem igazolja a megkeresés beérkezését.
Minden mező kapjon látható címkét, és egyeztesse, milyen válaszokra van szüksége a csapatnak az első válaszlevélhez. Ha a projektleírás túllépi az elfogadott korlátot, magyarázza el, hogyan rövidíthető, miközben a többi megadott adat elérhető marad. A tényleges magyar és angol üzeneteket azokkal próbálja ki, akik a megkereséseket megválaszolják.
A visszaigazolás feleljen meg a rögzített eseménynek
A szerveres példában határozza meg, melyik rögzített esemény alapján igazolhatja vissza az oldal a beérkezést. Kérje ugyanannak a tesztmegkeresésnek a bemutatását a munkatársak rendszerében. Az MDN HTTP 202 leírása megkülönbözteti a feldolgozásra átvételt a befejezett feldolgozástól; a technikai sikerjelzés önmagában nem ígérheti, hogy valaki elolvasta a kérést.
A W3C világos hiba- és sikerjelzéseket javasol. Írjon külön üzenetet a mező javításához, az igazolt átvételhez és a bizonytalan kimenetelhez. Ha az iroda hivatkozási azonosítót rögzít, jelenítse meg másolható helyen. Várható válaszidőt csak akkor adjon meg, ha a fogadó csapat vállalta, hogy ezt az ígéretet tartani tudja.
Próbálja ki a bizonytalanságot és az ismételt kísérleteket
Kérje meg a fejlesztőt, hogy szimuláljon elveszett visszajelzést azután, hogy a szerver megkapta a tesztmegkeresést. A látogató ilyenkor bizonytalan lehet a küldés sikerében, miközben a munkatársak már látják a megkeresést. Egyeztesse a helyreállítás menetét, ismételje meg a kísérletet, majd ellenőrizze a belső nyilvántartásban a duplikátumokat. Egy letiltott gomb önmagában nem teljes helyreállítási terv.
Amíg a látogató az oldalon marad, az üzenet maradjon elérhető javításhoz vagy másoláshoz. Kínáljon másik kapcsolatfelvételi módot, ha az űrlap nem tudja igazolni az eredményt. Ha a látogató kapott azonosítót, kérje annak megadását az iroda megkeresésekor. Jóváhagyás előtt a munkatársak magyarázzák el, hogyan egyeztetik az ismételten beérkező kéréseket.
Működő ügyintézési folyamatot adjon át
Az utolsó próbát azzal végezze, aki a beérkező megkeresésekre válaszol. Használjon kitalált projektrészleteket, és valódi ügyféladatok nélkül rögzítse az eredményt. Az űrlapszolgáltatás vagy a címzett beállításainak módosítása után ismételje meg a kézbesítés ellenőrzését.
- Küldjön be érvényes megkeresést, és keresse meg a hozzá tartozó belső bejegyzést.
- Javítson egy elutasított mezőt a teljes projektleírás újbóli begépelése nélkül.
- A fejlesztővel együtt ellenőrizze a bizonytalan kimeneteleket és az ismételt kísérleteket.
- Ellenőrizze, hogy az alternatív elérhetőség látható, és valaki figyeli az oda érkező üzeneteket.
- Jelölje ki a sikertelen beküldések és a válaszra váró megkeresések felelősét.