Miért van szükség érvényes kódra, és hogyan lehet kiküszöbölni az érvényesítési hibákat. Mobil jelentkezési lapok hibái és érvényesítése Függő mezők érvényesítése

Az emberek hajlamosak hibázni. A hibák akkor fordulnak elő, amikor az emberek kapcsolatba lépnek vele felhasználói felületek. Néha ez azért történik, mert a felhasználók hibáznak. Néha hibák lépnek fel magában az alkalmazásban. Az októl függetlenül a hibák és azok kezelése óriási hatással van az UX-re. A helytelen hibakezelés, valamint a haszontalan hibaüzenetek negatív reakciót válthatnak ki a felhasználó részéről, ami a későbbiekben arra késztetheti a felhasználót, hogy megtagadja az alkalmazás használatát.

Ebben a cikkben megvizsgáljuk, hogyan optimalizálhatja alkalmazását a megelőzés érdekében egyedi hibákés hogyan lehet hatékony hibaüzeneteket létrehozni arra az esetre, ha hiba történne, függetlenül attól, hogy a felhasználó mit ad meg. Azt is megvizsgáljuk, hogy egy jól kezelt hiba hogyan változtathatja a kudarcot csodálatba. Az Adobe bemutatta az Experience Design (Adobe XD) új tervező és fejlesztő alkalmazást, amely lehetővé teszi interaktív projektek és hibaállapotok tervezését. Ingyenesen letöltheti és kipróbálhatja az Adobe XD-t.

Mi a hibaállapot?

A hibaállapot egy képernyő, amely akkor jelenik meg a felhasználó számára, ha valami elromlott. Ez egy példa arra a helyzetre, amikor a felhasználó a kívánt állapottól eltérő dolgot tesz. Mivel a hibák váratlan kombinációkban is előfordulhatnak, ezek a feltételek egészen más problémákat is magukban foglalhatnak, a következetlen felhasználói műveletektől (például helytelen adatbevitel) egészen addig, amíg az alkalmazás nem tud kapcsolódni a szerverhez, vagy akár nem tudja feldolgozni a felhasználó kérését.

Hibás képernyők

Minden hiba, az okától függetlenül, buktatóvá válik a felhasználó számára az UX útja során. Szerencsére egy jól formált hiba csökkentheti a kellemetlen hatást.

A megelőzés jobb mint az orvoslás

Ha alkalmazást készít, meg kell értenie, hogy melyek azok a főbb felhasználói interakciók az alkalmazással, amelyek hibához vezethetnek. Például általában nagyon nehéz az első próbálkozásra helyesen kitölteni egy űrlapot, vagy lehetetlen az adatok helyes szinkronizálása, ha az eszköz gyenge. internetkapcsolat. Az ilyen szempontokat figyelembe kell vennie, hogy minimálisra csökkentse a hibák lehetőségét. Más szóval, tanácsokkal, megszorításokkal és rugalmassággal jobb megelőzni a tévedés lehetőségét.

Például, ha engedélyezi az embereknek, hogy szállodákat keressenek és foglaljanak, miért hagyja a szabad dátumokat a múltban, és miért ad ki hibát, ha a felhasználó ilyen dátumot választ?

Ahogy a Booking.com példáján is látható, egyszerűen használhat egy dátumválasztót, amely lehetővé teszi a felhasználók számára, hogy csak a mai dátumot és a jövőbeni dátumokat válasszák ki. Ez arra ösztönzi a felhasználókat, hogy csak érvényes dátumokat válasszanak.

Dátumválasztó a Booking.com alkalmazásban. A teljes hónap megjelenik, de a múltbeli dátumok nem érhetők el.

Hibaképernyő az űrlap érvényesítéséhez

A forma a kommunikáció. Mint minden kommunikációnak, ennek is soros kommunikációnak kell lennie két fél – a felhasználó és az alkalmazás között. Ebben a kommunikációs folyamatban a validálásnak nagy szerepe van. Az űrlapellenőrzés célja, hogy segítse a felhasználókat a bonyolultságokon, hibákon és félreértéseken. Megfelelő érvényesítéssel az ilyen kommunikáció egyértelművé és érthetővé válik. Általában a jó űrlap érvényesítése négy fontos elemből áll:

• A megfelelő idő a hibákról (vagy a sikeres befejezésről) való tájékoztatásra
• Az érvényesítő üzenet megfelelő helye
• Helyes üzenet színe
• Üzenet nyelvének törlése

Helyes idő (karakterlánc érvényesítése)

Az űrlaphiba ellenőrzése elkerülhetetlen, és a felhasználói bevitel logikai része (mivel a felhasználói bevitel hibás lehet). Természetesen minimalizálni kell azokat az állapotokat, amelyek hibát okozhatnak, de a hibaellenőrzést nem lehet eltávolítani. Tehát a legfontosabb kérdés: "Hogyan egyszerűsíthető le a hiba helyreállítási folyamata a felhasználó számára?"

A felhasználók nem szeretik az űrlap kitöltésének folyamatát, különösen akkor, ha a végén hibaértesítést kapnak. Különösen elkeserítő, ha egy hosszú űrlap kitöltése után több mezőben hibaüzenetet kapunk. És a legbosszantóbb az az egyértelműség hiánya, hogy milyen hibákat követett el és hol.

Az érvényesítés során az adatbevitelt követően haladéktalanul tájékoztatni kell a felhasználót a megadott válasz helyességéről. A jó érvényesítés fő elve: „Beszélj a felhasználókkal! Mondd el nekik, mi a baj!" a valós idejű karakterlánc-ellenőrzés pedig tájékoztatja a felhasználókat a bevitt adatok helyességéről. Ez a megközelítés lehetővé teszi a felhasználók számára, hogy gyorsan kijavítsák a hibákat, és ne várják meg a hibák megjelenését a megerősítő gomb megnyomása után.

Azonban kerülje az egyes billentyűleütések érvényesítését, mert a legtöbb esetben nem tudja ellenőrizni az adatokat, amíg a felhasználó be nem fejezi a válasz beírását. Azok az űrlapok, amelyek beírás közben érvényesítenek egy értéket, bosszantani kezdik a felhasználót, amint elkezdi az adatbevitelt.

A Google Űrlapok e-mail hibaüzenetet jelenít meg akkor is, ha még nem fejezte be a gépelést.

Másrészt az adatbevitel után érvényesítő űrlapok nem tájékoztatják elég gyorsan a felhasználót a hibáról.

Az Apple Store-ban történő érvényesítés az adatbevitelt követően történik.

Mihail Konzsevics „String validation in forms – élményteremtés” című cikkében! különböző validációs stratégiákat vizsgált, és egy hibrid stratégiát javasolt: korai jutalmazás, késői büntetés.

Hibrid - korai jutalom, késői büntetés - megközelítés

Jó helyen

A felhasználó orientáció egy másik fontos eszköz. Ha azon tűnődik, hová helyezze el az érvényesítő üzenetet, kövesse ezt a tanácsot: mindig helyezze az üzenetet egy művelet kontextusába. Ha egy adott mező hibájáról szeretné tájékoztatni a felhasználót, mutassa meg mellette. A gyors érvényesítést legjobban a beviteli mezőtől jobbra, vagy alatta lehet elhelyezni.

Hibák az űrlapon valós időben.

Megfelelő szín (intuitív tervezés)

A szín az egyik legjobb eszközök használni az érvényesítés létrehozásakor. intuitív szinten működik, a piros a hibát, a sárga a figyelmeztetést és a zöld a sikert különösen erős. Ügyeljen azonban arra, hogy a színeket jól érzékeljék a felhasználók. Ez a jó látványtervezés kritikus szempontja.

A hiba szövegének világosnak kell lennie, és egyértelműen ki kell állnia az alkalmazás hátteréből.

világos üzenet

Egy tipikus hibaüzenet azt mondhatja, hogy "az e-mail érvénytelen" anélkül, hogy elmagyarázná a felhasználónak, hogy az e-mail miért érvénytelen. (Tipográfia? Az e-mail egy másik felhasználóval van elfoglalva?) Az egyértelmű utasítások vagy iránymutatások másként is működhetnek. A példában láthatja, hogy az űrlap hogyan tájékoztatja a felhasználót arról, hogy az e-mailje már foglalt. Ezenkívül számos javaslat jelenik meg (bejelentkezés vagy jelszó helyreállítása).

Tehát itt az ideje, hogy megjelenítsen egy hibaoldalt annak jelzésére, hogy valami hiba történt. Példaként képzeljünk el egy olyan helyzetet, amikor a kapcsolat megszakad, és a felhasználó az egyetlen elérhető képernyőn van. Használnod kell ez a lehetőség annak érdekében, hogy az emberek tudomást szerezzenek arról, hogy mi történik, és gyors súgómodellt kínálhat – a bejegyzése segítő kezet jelent a felhasználók számára. Ezért soha ne jelenítse meg a következőket:

• Kritikus hibaüzenet. Azok az üzenetek, amelyek az alkalmazás kódjában lévő belső hibáról beszélnek, vagy olyan szöveget tartalmaznak, mint például: „2-es típusú hiba történt”, rejtélyesek és ijesztőek.

Egy fejlesztő által fejlesztőnek írt hibaüzenet.

• Zsákutca hiba. Egyszerűen azért, mert az ilyen üzenetek nem nyújtanak semmit hasznos információ a felhasználó számára.

A Spotify hibaképernyője „Hiba történt”, és nem tartalmaz lehetőségeket és lépéseket a probléma megoldására.

• Meghatározatlan hibaüzenet. Egy ilyen képernyő (az alábbi példában) annyi információt ad a felhasználónak, mint az előző. A felhasználóknak fogalmuk sincs, hogy ez mit jelent, vagy mit tegyenek ellene.

A Buffer alkalmazásnak van egy szép hibaüzenete, de nem ad semmilyen információt a felhasználónak.

Ne ijesztgesse a felhasználót hibákkal. Ezenkívül ne próbálja a felhasználót rávezetni a probléma technikai részleteire. Beszéljen a hibáról egyszerű és érthető nyelven. Ehhez ne használjon szakzsargont, és a felhasználó nyelvén fejezze ki gondolatait.

Tegye olvashatóvá és hasznossá posztjait – a hibáknak udvariasaknak, világosnak és tanulságosnak kell lenniük, és olyan információkat kell tartalmazniuk, mint például:

• Mi romlott el és miért (valószínűleg).
• Mit kell tennie a felhasználónak a hiba kijavításához.

A Remote alkalmazás elmagyarázza, miért nem látnak semmit a felhasználók, és megoldást kínál.

Tartalmazzon humort és képeket a hibaüzenetekben

A hibaüzenetek nagyszerű lehetőséget kínálnak ikonok és illusztrációk használatára, mert az emberek jobbak vizuális információ mint csak szöveg. De még tovább is léphet, és olyan képeket adhat az alkalmazásához, amelyek hasznosak lesznek a felhasználók számára. Ez személyre szabja az alkalmazást, és lágyabbá teszi az üzenetet.

Az Azendoo illusztrációkat és humort használ, hogy inspirálja a felhasználót egy probléma megoldására.

A humor meghosszabbítja az életet. Egy kis humor soha nem árt, és segít enyhíteni a tévedés okozta zavart. Rengeteg példát találhat vicces üzenetekre a Littlebigdetails oldalon. Íme néhány kedvencem:

• Basecamp: Ha az űrlap érvényesítése sikertelen, a bal oldali karakter meglepett kifejezést ad.

• Kissé szemtelen hibaüzenet jelenik meg, ha túl sok pontot próbál beírni egy új Gmail-fiók létrehozásakor.

Legyen azonban óvatos a humorral, mert előfordulhat, hogy nem mindig szerepel a hibaüzenetben; a hiba súlyosságától függ. A humor például jól működik olyan egyszerű ellenőrzési problémáknál, mint a „404-es hiba” (az oldal nem található). De amikor a felhasználó egy bizonyos időt tölt az „Ó!” feliratú oldal megtekintésével. - nem látszik a helyén.

Átfogó ellenőrzőlista a tökéletes hibaoldalhoz

A jó hibaoldalak segítő kezet jelentenek a felhasználók számára, és meg kell felelniük a következő hat feltételnek:

1. A hibaüzenet dinamikusan jelenik meg, közvetlenül a hiba észlelése után. Tájékoztatnia kell a felhasználót a problémáról.
2. Legyen biztonságban a megadott adatokkal. Az alkalmazás nem törheti meg, törölheti vagy vonhatja vissza azt, amit a felhasználó a hiba észlelésekor megadott vagy feltöltött.
3. Beszéljen a felhasználóval ugyanazon a nyelven. Az üzenetnek világosan meg kell értenie, hogy mi és miért ment rosszul; mit tegyen a felhasználó a hiba kijavításához?
4. Ne sokkolja vagy zavarja meg a felhasználókat. (Az üzenet ne legyen túl provokatív).
5. Ne veszítse el az irányítást a rendszer felett. (Ha a probléma nem kritikus, a felhasználónak hozzá kell férnie az alkalmazás többi részéhez).
6. Használd a humorérzékedet a probléma enyhítésére.

Megoldások a legnépszerűbb hibákra

404-es hiba (az oldal nem található)

A 404-es hibaoldal fő célja, hogy a lehető leghamarabb átirányítsa a felhasználót a keresett oldalra. A 404-es oldalnak több kulcsfontosságú hivatkozást kell tartalmaznia, ahová a felhasználó eljuthat. A legbiztonságosabb lehetőség az, ha hivatkozunk a „ kezdőlap” oldalon a 404-es oldalon. Ezenkívül beállíthat egy „probléma bejelentését” is, hogy a felhasználó értesítse Önt az oldal leállásáról. De ügyeljen arra, hogy a főoldalra való áttérés inkább egyértelmű átmenet legyen, és vizuálisan is jobban kiemelkedjen.

Bejelentkezési probléma

A bejelentkezési űrlap képernyője gyakran minimalista megjelenésű, és tartalmaz egy felhasználónév és egy jelszó mezőt. De a minimalizmus nem egyenlő az egyszerűséggel. Számos oka lehet annak, hogy a felhasználó elakad a bejelentkezési képernyőn. A bejelentkezési oldal fő szabálya - ne kényszerítse a felhasználót találgatásokra.

Nézzük a legtöbb megoldást gyakori problémák a MailChimp példáit használva, amely igen Nagyszerű munka hibaüzenetek felett.

• A felhasználó elfelejtette a nevét az oldalon. Ha hasonló hibát talál, adjon meg egy linket, ahol a felhasználó kijavíthatja. Mondja el a felhasználónak, hol szerezheti be (például: „nézze meg a leveleit, küldtünk Önnek egy e-mailt”), vagy adjon meg egy linket a név visszaállításához az oldalon.

A felhasználók sokszor megpróbálnak rossz jelszóval belépni az oldalra. Az ilyen szervertámadások megelőzése érdekében a felhasználói fiókokat túl sok sikertelen próbálkozás után blokkolja. Ez egy általános biztonsági gyakorlat, de a felhasználót figyelmeztetni kell a fiók letiltása előtt.

Hitelkártya elutasítása

A hitelkártya elutasítása több okból is előfordulhat: adatformázási hiba (elírás vagy hiányzó adatok), vagy a kártya elutasítása lejárt vagy ellopott. Gabriel Tomescu Egy hitelkártya alakzat anatómiája című cikkében a következő stratégiát javasolta mindkét hibára:

Az első probléma esetén kövesse a szabványos karakterlánc-ellenőrzést és a vizuális hibajelzést:

Ha azonban a hitelkártyát elutasítják fizetési rendszer valamiért általában emberrablásnak tűnik. Világos adatokra van szüksége a felhasználótól. És még ezután is értesítenie kell a felhasználót a történtekről; a hibaüzenetnek nagyon egyértelműnek kell lennie.

Csatlakozási probléma

Az internetkapcsolat nem mindenhol érhető el, és az offline támogatásnak mindenki életében kulcsfontosságúnak kell lennie. modern alkalmazás. Amikor a kapcsolat megszakad, alaposan át kell gondolnia az offline felhasználói élményt. A felhasználóknak képesnek kell lenniük arra, hogy a lehető legtöbb alkalmazással kommunikáljanak. Ez azt jelenti, hogy az alkalmazásnak gyorsítótárba kell helyeznie a tartalmat jó offline UX.

Címkék: , , ,

Az érvényesítés a felhasználó által megadott értékek érvényesítése és a talált hibák megjelenítése.

Alapelvek

A tervező feladata, hogy megbizonyosodjon arról, hogy a felhasználó nem hibázik, és ehhez nincs szükség érvényesítésre:

1. Korlátozza a nyilvánvalóan helytelen értékek kiválasztását a listában: blokkolja ezeket az értékeket, vagy ne jelenítse meg őket a listában.
2. Korlátozza a nem megfelelő karakterek bevitelét. Ha egy mezőbe csak számokat kell beírni, és ez nyilvánvaló a felhasználó számára, a hiba megjelenítése helyett hagyja figyelmen kívül a betűket. Használjon helyettesítő karaktereket azokban a mezőkben, ahol az értékek formátuma ismert.
3. Írjon felszólításokat az űrlap kitöltéséhez. Például egy helyőrző a beviteli mezőkben.

Az újonnan megnyitott üres űrlapon az érvényesítés tilos. Kivételt képeznek a piszkozatok, amikor a felhasználó már kitöltötte ezt az űrlapot, majd egy idő után visszatért hozzá, és az megtelt hibákkal.

Az érvényesítés típusai

Az érvényesítésnek három típusa van: azonnali, fókusz elvesztése esetén és űrlap elküldésekor.

Minél hamarabb jelez hibát az interfész, annál jobb – a felhasználó könnyebben visszatérhet és kijavíthatja a hibát.

A legtöbb gyors út hiba bejelentése – azonnali érvényesítés. De ez csak azokban az esetekben lehetséges, amikor a beviteli folyamat során egyértelmű, hogy az érték hibás. Az ilyen hibák jellemzően helytelen billentyűzetkiosztással (latin helyett cirill) vagy numerikus mezőbe írt betűkkel (TIN, KPP stb.) társulnak. Ilyen esetekben maszkos mezőket használunk: a nem megfelelő karakterek bevitele blokkolva van. . Ezért a felületeinken csak kétféle érvényesítés létezik:

• fókusz elvesztésével- az érvényesítés fő típusa
• az űrlap leadásakor- azokra az esetekre, amikor a fókusz elvesztésével történő érvényesítés nem lehetséges.

Fókuszvesztés érvényesítése

Mikor kell használni

Hogyan működik

Ne érvényesítse a mezőket, hogy üresek legyenek a fókusz elvesztése esetén – ne jelenjen meg hibaüzenet, ha a mező üres, a felhasználó visszatérhet, és egy kicsit később kitölti a mezőt. Ilyen esetekben csak az űrlap elküldése után jeleníthet meg hibát.

Az érvényesítés azonnal elindul a fókusz elvesztése után, ha a mezőben lévő érték ki van töltve. Ha hibát talál, a mező piros színnel lesz kiemelve. A fókusz nem tér vissza automatikusan erre a mezőre:

A hibaszöveg megjelenik az eszköztippben, ha a mezőre rámutat vagy fókuszál:

A hibás mezőnek kiemelten kell maradnia, ha fókuszt kapott, értéke nem lett javítva, majd elvesztette a fókuszt.

A piros kiemelés azonnal eltűnik a mezőből, amint a felhasználó elkezdi javítani a hibás értéket.

Űrlap benyújtásának ellenőrzése

Mikor kell használni

Használja ezt a fajta érvényesítést, ha nem tudja érvényesíteni a mezőket a fókusz elvesztése esetén. Például annak ellenőrzésére, hogy a kötelező mezők ki vannak-e töltve.

Hogyan működik

Az ellenőrzés az adatküldés gomb megnyomása után történik: az űrlapon az összes hibás mező kiemelésre kerül, az oldal az első hibás mezőre gördül, a fókusz erre a mezőre kerül, a kurzor a sor végére kerül , a mező mellett megjelenik egy tippet tartalmazó tipp.

Az ablak felső szegélyétől a hibás mezőig tartó első mezőre görgetve 48 képpont – hat egység – behúzás marad.

A küldés gomb blokkolása

Kisűrlapokon a kötelező mezők ellenőrzése helyett az űrlap beküldése gombját blokkolhatja. Használja ezt a viselkedést, ha nyilvánvaló, hogy miért van letiltva az űrlap elküldése gombja. Például a bejelentkezési űrlapon:

Amint minden kötelező mezőt kitöltött, a gomb aktívvá válik. Ha ezt követően a felhasználó törölte az értéket valamelyik mezőben, a gomb ismét inaktívvá válik.

Hibaüzenetek

A hibákat kétféleképpen lehet jelenteni:

Eszköztippek

Hogyan működnek

A tippelem két esetben jelenik meg:

1. Amikor az egérmutatót egy hibás mező fölé viszi.
2. Amikor a hibás mező fókuszba kerül.

Ha a hibás mezőben megváltozott az érték, elvesztette a fókuszt, majd ismét a fókuszba került, akkor a régi hiba szövegét tartalmazó elemleírás többé nem jelenik meg. Ez a szabály ugyanúgy működik minden típusú ellenőrzésnél: mind a fókusz elvesztése, mind az űrlap elküldése esetén.

A mutató elemleírás felülírja a fókusz elemleírást.

Az eszköztipp megjelenhet a vezérlőelem tetején vagy jobb oldalán hibával, így nem fedi át a hasznos információkat:

Egységes viselkedés és megjelenés

Eszköztippek megjelenítése a mezőktől jobbra. Ha ebben az esetben átfedik az oldal fontos tartalmát, jelenítse meg az eszköztippeket a tetején. Ragaszkodjon a következetességhez, de ne feledje, hogy a tartalom fontosabb, mint a tartalom.

Piros szövegek az oldalon

Hogyan működnek

A piros hibaszöveg azonnal megjelenik, amint az érvényesítés megtörtént, és a hibamező ki van jelölve.

Amint a felhasználó elkezdi javítani az értéket, a mező piros kiemelése eltűnik, és a hibaszöveg színe -  #333-ra változik.

A hibaszöveg eltűnik, ha a fókusz elveszik, és nem jelenik meg újra, ha a mező ismét fókuszba kerül. Ez a szabály ugyanúgy működik minden típusú ellenőrzésnél: mind a fókusz elvesztése, mind az űrlap elküldése esetén.

Jelenítse meg a hibaszöveget a jobb oldalon, ha van hely az űrlapon, és maga az üzenet rövid. Így az űrlapot nem kell kibontani a hiba megjelenítéséhez.

Ha a mező jobb oldalán nincs hely a szöveg számára, bontsa ki az űrlapot, és jelenítse meg az üzenetet a mező alatt.

Bonyolultabb űrlapokon jelenítsen meg hibaüzenetet az elemleírásban.

Függő mezők érvényesítése

A függő mezők olyan mezők, amelyek értéke egymástól függ.

A mezőfüggőség megsértésével kapcsolatos hibák az űrlap elküldése után jelennek meg. Például TIN és KPP. Ha a felhasználó 10 számjegyű TIN-t adott meg, és az ellenőrzőpontot tartalmazó mezőt üresen hagyta, az űrlap elküldése után az ellenőrzőpontot tartalmazó üres mező lesz kiemelve.

A TIN kétféle lehet:

• 10 számjegyű y jogalanyok
• 12 számjegyű IP.

Ha a felhasználó 12 számjegyű TIN-t adott meg, akkor a szervezet egyéni vállalkozó, és nem rendelkezik ellenőrző ponttal, így az ellenőrzőpont mezőt nem kell kitölteni. És fordítva, ha az ellenőrző pont ki van töltve, és a TIN 12 számjegyű, előfordulhat, hogy a TIN hibásan van feltüntetve.

A függő mezők kiemelése eltűnik, amint a felhasználó elkezdi javítani az értéket ezen mezők egyikében.

Ha egy függő mező kitöltésekor megsértik az értékformátumot, jelentse az ilyen hibát, ha a fókusz elveszett. Például a felhasználó 3 számjegyet írt be a TIN mezőbe, és eltávolította a fókuszt. Ezt a mezőt azonnal ki kell emelni.

Példa

Van egy űrlap 5 mezővel:

• A szervezet neve- egyszerű szöveg, kötelező
• ÓN- 10 vagy 12 számjegy, ellenőrizze ellenőrző összeg fókusz elvesztése esetén kötelező
• ellenőrző pont- 9 számjegyből álló ellenőrző összeg ellenőrzésével a fókusz elvesztése esetén kötelező, ha a TIN 10 számjegyből áll
• Email- e-mail cím, ellenőrizze a fókusz elvesztését maszkkal [e-mail védett], választható
• Telefon- nemzetközi formátum, a fókusz elvesztésének ellenőrzése maszkkal +00000000000, kötelező

Nincs fárasztóbb, mint kitölteni egy írástudatlan lead űrlapot nyitóoldal. Emlékezzen arra, hogy hányszor kellett minden mezőt kitöltenie azért, mert az Ön által kitalált jelszó bizonyos kritériumok szerint nem illett a rendszerbe, amiről senki sem próbált előre értesíteni.

Ne feledje, hogy a potenciális ügyfelek űrlapjának optimalizálása a konverzióoptimalizálási folyamat kulcsfontosságú összetevője, és itt a helyszíni érvényesítésre kell összpontosítani.

Mi az a potenciális ügyfelek űrlapjának érvényesítése?

A lead űrlap érvényesítése egy technikai folyamat, melynek során a rendszer ellenőrzi a felhasználó által megadott adatok helyességét. Ha valaki hibát követett el az űrlap kitöltésekor (például rossz formátumban adta meg az adatokat), a rendszer rámutat erre a hibára (vagy egyszerűen annak jelenlétére), és felajánlja a javítást. Ha a felhasználó minden adatot helyesen adott meg, akkor további üzenetek nem jelennek meg (vagy pipa jelenik meg a mező mellett), és továbblép a regisztráció következő szakaszába.

Például a Twitter nem engedi, hogy a következő regisztrációs lépésre lépjen, ha megadja a címet Email rossz formátumban:

Amikor az e-mail címet a rendszernek megfelelő formátumban adja meg, a mező mellett egy pipa jelenik meg, amely jelzi, hogy a megadott adatok formátuma helyes:

Az érvényesítés lényege, hogy a felhasználók a rendszer által megkívánt formátumban adják meg az adatokat (például a mail címnek meg kell felelnie a szabványnak [e-mail védett], de például a jelszónak legalább 7 karakterből kell állnia).

Az űrlap érvényesítésének két fő típusa van.

A webhely érvényesítési hibáinak elemzése

Végre volt szabadidőm a végtelen számú rendelés között, és úgy döntöttem, elindítom a blogomat. Próbáljuk meg javítani az érvényesítés szempontjából. Az alábbiakban a cikkben elmondom, mi az a webhely érvényesítése, html kódotés css, miért van rá szükség, és hogyan lehet szabványosítani a webhelyet egy konkrét példa segítségével.

Mi az a webhely érvényesítése?

Egyszerűen fogalmazva, ez a szabványoknak való megfelelés ellenőrzése. Annak érdekében, hogy bármely böngésző megfelelően megjeleníthesse webhelyét. Az oldal érvényessége nincs nagy hatással a promócióra, de biztosan nem lesz rosszabb.

Egy konkrét példa egy webhely oldalának érvényesítésének átadására

Vegyük az első oldalt a webhelyemen - Base64 kódolás és dekódolás Java 8-ban. Töltsük be az oldal címét a validátorba, és nézzük meg az eredményt:

Hibákat találtunk a dokumentum HTML 4.01 Transitionalként való ellenőrzése során! Eredmény: 105 hiba, 67 figyelmeztetés Igen, csúnya a kép: több mint száz hiba és 67 figyelmeztetés – hogyan indexelik a keresők a blogomat és hogyan látogatják meg az emberek? De ne idegeskedjünk, hanem tanuljuk meg az érvényesítést, a hibák kijavítását. Tehát az első figyelmeztetés:

Nem lehet meghatározni az elemzési módot! Az érvényesítő a dokumentumokat XML-ként (például XHTML, SVG stb.) vagy SGML-ként (HTML 4.01 és korábbi verziók esetén) tudja feldolgozni. Ennél a dokumentumnál a rendelkezésre álló információk nem voltak elegendőek az elemzési mód egyértelmű meghatározásához, mert: a MIME Media Type (text/html) használható XML vagy SGML dokumentumtípusokhoz. Ismert dokumentumtípus nem észlelhető Nincs XML deklaráció (pl.) található a dokumentum elején. Nincs XML névtér (pl ) a dokumentum gyökerében található. Alapértelmezés szerint az érvényesítő visszaáll SGML módba. Figyelmeztetés Nem található DOCTYPE! Ellenőrzés az alapértelmezett HTML 4.01 átmeneti dokumentumtípussal. Ebben a dokumentumban nem található vagy ismerhető fel DOCTYPE nyilatkozat. Ez általában azt jelenti, hogy a dokumentum tetején nem deklarálja a dokumentumtípust. Ez azt is jelentheti, hogy a DOCTYPE deklaráció helyesírási hibát tartalmaz, vagy nem a megfelelő szintaxist használja. A dokumentum ellenőrzése egy alapértelmezett „tartalék” dokumentumtípus-definícióval történt, amely nagyon hasonlít a „HTML 4.01 Transitional”-ra. Ez ugyanaz. A javítás pedig egyszerű: az oldal legelejére adja hozzá a címkét:

Ellenőrizzük, mit tettünk, és azt látjuk, hogy csak ezzel a címkével 105 hibát és 3 figyelmeztetést távolítottunk el! Már csak 64 figyelmeztetésünk maradt. Kezdjük el egyenként szétszedni őket.

Figyelmeztetés: A style elem típus attribútuma nem szükséges, ezért ki kell hagyni. 5. sor 1. oszlopából; az 5. sor 23. oszlopához /x-icon">↩