Fout bij bestandsvalidatie. Validatie van leadformulieren - De complete gids. Consistentie van gedrag en uiterlijk

laat een reactie achter 6,950

Mensen hebben de neiging om fouten te maken. Fouten treden op wanneer mensen interactie hebben met gebruikersinterfaces. Dit gebeurt soms omdat gebruikers fouten maken. Soms treden er fouten op in de applicatie zelf. Ongeacht de oorzaak hebben fouten en hun afhandeling een enorme impact op UX. Onjuiste foutafhandeling, in combinatie met nutteloze foutmeldingen, kan een terugslag van de gebruiker veroorzaken, wat vervolgens kan leiden tot de weigering van de gebruiker om uw applicatie te gebruiken.

In dit artikel zullen we onderzoeken hoe u uw toepassingsontwerp kunt optimaliseren om aangepaste fouten te voorkomen en hoe u effectieve foutberichten kunt maken wanneer fouten optreden, ongeacht wat de gebruiker invoert. We zullen ook bekijken hoe een goed afgehandelde fout een mislukking kan veranderen in bewondering. Adobe heeft een nieuwe ontwerp- en engineeringtoepassing Experience Design (Adobe XD) geïntroduceerd, waarmee u interactieve projecten en foutstatussen kunt ontwerpen. U kunt Adobe XD gratis downloaden en uitproberen.

Wat is een foutstatus?

Een foutstatus is een scherm dat aan de gebruiker wordt getoond wanneer er iets mis is gegaan. Dit is een voorbeeld van een situatie waarin de gebruiker iets anders doet dan de gewenste status. Aangezien fouten kunnen optreden in onverwachte combinaties, kunnen deze toestanden zeer verschillende problemen omvatten, van incompatibele gebruikersbewerkingen (bijvoorbeeld onjuiste gegevensinvoer) tot het onvermogen van de toepassing om verbinding te maken met de server of zelfs het onvermogen om het gebruikersverzoek te verwerken.

Foutschermen

Elke fout, ongeacht de oorzaak, wordt een struikelblok voor de gebruiker op weg naar vooruitgang door de UX. Gelukkig kan een welgevormde fout het onaangename effect verminderen.

Voorkomen is beter dan genezen

Als u een toepassing bouwt, moet u weten welke basisinteracties van gebruikers met de toepassing tot een fout kunnen leiden. Het is bijvoorbeeld meestal erg moeilijk om een formulier bij de eerste poging correct in te vullen, of het is onmogelijk om gegevens correct te synchroniseren als het apparaat een slechte netwerkverbinding heeft. Houd deze punten in gedachten om de kans op fouten te minimaliseren. Met andere woorden, het is beter om fouten te voorkomen door tips te geven, beperkingen te hanteren en flexibiliteit.

Als u mensen bijvoorbeeld de mogelijkheid geeft om hotels te zoeken en te reserveren, waarom zou u dan beschikbare data in het verleden laten en een foutmelding weergeven als de gebruiker een dergelijke datum selecteert?

Zoals te zien is in het voorbeeld van Booking.com, kunt u eenvoudig een datumkiezer gebruiken, waarmee gebruikers alleen de datum van vandaag en toekomstige datums kunnen selecteren. Dit zal gebruikers vragen om alleen geldige datums te selecteren.

Datumkiezer in de Bocking.com-app. De volledige maand wordt weergegeven, maar datums in het verleden zijn niet beschikbaar.

Scherm met formuliervalidatiefout

Vorm is communicatie. Zoals elke communicatie moet het een seriële communicatie zijn tussen twee partijen - de gebruiker en uw toepassing. Validatie speelt een grote rol in deze communicatie. Formuliervalidatie is ontworpen om gebruikers door complexiteiten, fouten en misverstanden te leiden. Wanneer deze goed gevalideerd is, wordt deze communicatie duidelijk en begrijpelijk. Over het algemeen heeft goede formuliervalidatie vier belangrijke elementen:

Correcte tijd om fouten te melden (of succesvolle afronding)
De juiste plaats voor het validatiebericht
Correcte berichtkleur
Begrijpelijke taal van het bericht

Correcte tijd (string validatie)

Formuliervalidatie is onvermijdelijk en is een logisch onderdeel van gebruikersinvoer (aangezien gebruikersinvoer foutgevoelig kan zijn). Staten die een fout kunnen veroorzaken, moeten natuurlijk worden geminimaliseerd, maar foutvalidatie kan niet worden verwijderd. De belangrijkste vraag is dus: "Hoe kunt u het de gebruiker gemakkelijker maken om van een fout te herstellen?"

Gebruikers houden niet van het proces van het invullen van het formulier, vooral niet wanneer ze aan het einde een foutmelding krijgen. Het is vooral frustrerend om foutmeldingen in meerdere velden te krijgen na het invullen van een lang formulier. En het meest vervelende is het gebrek aan duidelijkheid over welke fouten je hebt gemaakt en waar.

Validatie dient de gebruiker onmiddellijk te informeren over de juistheid van dit antwoord onmiddellijk nadat de gebruiker de gegevens heeft ingevoerd. Het belangrijkste principe van een goede validatie is: “Praat met gebruikers! Vertel ze wat er aan de hand is!” en stringvalidatie in realtime informeert gebruikers over de juistheid van de ingevoerde gegevens. Met deze aanpak kunnen gebruikers snel fouten herstellen en niet wachten tot fouten worden weergegeven nadat ze op de verzendknop hebben geklikt.

U moet echter voorkomen dat u elke toetsaanslag valideert, omdat u in de meeste gevallen de gegevens niet kunt verifiëren voordat de gebruiker klaar is met het typen van zijn antwoord. Formulieren die de waarde onmiddellijk valideren tijdens het typen, beginnen de gebruiker te irriteren zodra hij gegevens begint in te voeren.

Google Formulieren geeft een e-mailfout weer, zelfs als u nog niet klaar bent met typen.

Aan de andere kant informeren formulieren die valideren na gegevensinvoer de gebruiker niet onmiddellijk over de fout.

Apple Store-validatie vindt plaats na gegevensinvoer.

Mikhail Konzhevich in zijn artikel "String Validation in Forms - Creating Experience! onderzocht verschillende validatiestrategieën en stelde een hybride strategie voor: vroege beloning, late straf.

Hybride - vroege beloning, late straf - benadering

De juiste plek

Gebruikersoriëntatie is een ander belangrijk hulpmiddel. Als je je afvraagt waar je heen moet voor je validatiebericht, volg dan deze tip: Plaats je bericht altijd in de context van een actie. Als u de gebruiker op de hoogte wilt stellen van een fout in een specifiek veld, toont u dit ernaast. Het is het beste om snelle validatie rechts van het invoerveld te plaatsen, of eronder.

Vormfouten in realtime.

Correcte kleur (intuïtief ontwerp)

Kleur is een van de beste tools om te gebruiken bij het maken van validatie. Omdat het op een intuïtief niveau werkt, is rood voor fouten, geel voor waarschuwing en groen om succes aan te geven bijzonder krachtig. Maar zorg ervoor dat de kleuren goed worden ontvangen door de gebruikers. Dit is een cruciaal aspect van een goed visueel ontwerp.

De fouttekst moet begrijpelijk zijn en duidelijk afsteken tegen de achtergrond van de applicatie.

Bericht wissen

Een typisch foutbericht zou kunnen zijn "e-mail is ongeldig", zonder aan de gebruiker uit te leggen waarom de e-mail onjuist is. (Typografie? E-mail bezet door een andere gebruiker?) Duidelijke instructies of richtlijnen kunnen dingen anders doen. U kunt in een voorbeeld zien hoe het formulier de gebruiker informeert dat zijn e-mail al in gebruik is. Ook verschijnen er verschillende suggesties (login of wachtwoordherstel).

Dit is dus het moment om de foutpagina weer te geven om te laten zien dat er iets mis is gegaan. Laten we ons als voorbeeld een situatie voorstellen waarin de verbinding wordt verbroken en de gebruiker zich op het scherm bevindt, het enige dat beschikbaar is. U moet deze gelegenheid aangrijpen om mensen te laten weten wat er aan de hand is en een snel hulpmodel te bieden - uw bericht moet een helpende hand zijn voor gebruikers. Laat daarom nooit het volgende zien:

Fatale foutmelding. Berichten die spreken over een interne fout in de applicatiecode of tekst bevatten zoals "er is een fout van type 2 opgetreden" zijn cryptisch en eng.

Een foutbericht geschreven door de ontwikkelaar voor de ontwikkelaar.

Doodlopende fout. Simpelweg omdat dergelijke berichten geen bruikbare informatie voor de gebruiker opleveren.

Het foutscherm op Spotify leest "Er is een fout opgetreden" en bevat geen opties of stappen om het probleem op te lossen.

Een ongedefinieerde foutmelding. Zo'n scherm (in onderstaand voorbeeld) geeft de gebruiker evenveel informatie als het vorige. Gebruikers hebben geen idee wat dit betekent of wat ze eraan moeten doen.

De Buffer-app bevat een mooie foutmelding, maar geeft geen informatie door aan de gebruiker.

Schrik de gebruiker niet af met fouten. Probeer de gebruiker ook niet kennis te laten maken met de technische details van het probleem. Spreek over de fout in eenvoudige en begrijpelijke taal. Probeer hiervoor geen technisch jargon te gebruiken en druk uw mening uit in de taal van de gebruiker.

Maak uw berichten leesbaar en nuttig - fouten moeten beleefd, duidelijk en didactisch zijn en de volgende informatie bevatten:

Wat ging er mis en waarom (mogelijk).
Wat de gebruiker moet doen om de fout te herstellen.

De Remote-app legt uit waarom gebruikers niets kunnen zien en stelt een oplossing voor.

Voeg humor en afbeeldingen toe aan foutmeldingen

Foutrapportage is een geweldige kans om pictogrammen en illustraties te gebruiken, omdat mensen meer ontvankelijk zijn voor visuele informatie dan alleen tekst. Maar u kunt nog verder gaan en afbeeldingen aan uw toepassing toevoegen, wat handig zal zijn voor gebruikers. Dit zal uw aanvraag personaliseren en uw bericht verzachten.

Azendoo gebruikt illustratie en humor om de gebruiker te inspireren een probleem op te lossen.

Humor verlengt het leven. Een beetje humor kan nooit kwaad, en zal helpen de verwarring van een fout weg te nemen. Je kunt talloze voorbeelden van grappige berichten vinden op Littlebigdetails. Hier zijn enkele van mijn favorieten:

Basecamp: Bij een validatiefout maakt de held aan de linkerkant een verbaasde uitdrukking.

Er wordt een ietwat brutale foutmelding weergegeven wanneer u probeert te veel stippen in te voeren bij het maken van een nieuw Gmail-account.

Wees echter voorzichtig met humor, want het is misschien niet altijd gepast in uw bugrapport; het hangt af van de ernst van de fout. Humor werkt bijvoorbeeld goed voor een eenvoudig validatieprobleem zoals een 404-fout (pagina niet gevonden). Maar wanneer een gebruiker een bepaalde hoeveelheid tijd besteedt aan het kijken naar een pagina met de tekst "Oh!" - het ziet er niet op zijn plaats uit.

Een uitgebreide checklist voor de perfecte foutpagina

Goede foutpagina's zijn een helpende hand voor gebruikers en moeten aan de volgende zes criteria voldoen:

De foutmelding verschijnt dynamisch, onmiddellijk nadat de fout is gedetecteerd. Het moet de gebruiker op de hoogte stellen van het probleem.
Wees veilig voor de ingevoerde gegevens. Uw toepassing mag niet breken, verwijderen of annuleren wat de gebruiker heeft ingevoerd of gedownload toen de fout werd gedetecteerd.
Praat met de gebruiker in dezelfde taal. De boodschap moet duidelijk maken wat er fout is gegaan en waarom; wat moet de gebruiker doen om de fout te herstellen?
Schok of verwar gebruikers niet. (Het bericht mag niet te provocerend zijn).
Verlies de controle over het systeem niet. (Als het probleem niet kritiek is, zou de gebruiker dit met de rest van de applicatie moeten kunnen).
Gebruik een gevoel voor humor om het probleem te verminderen.

Oplossingen voor de meest voorkomende fouten

404-fout (pagina niet gevonden)

Het belangrijkste doel van een 404-pagina is om uw gebruiker zo snel mogelijk om te leiden naar de pagina waarnaar hij op zoek was. Uw 404-pagina moet verschillende belangrijke links bieden waar de gebruiker naartoe kan gaan. De veiligste optie is om een link naar de "homepage" van de site op een 404-pagina te hebben. Ook kunt u een “meld een probleem” plaatsen zodat de gebruiker u laat weten dat de pagina niet werkt. Maar zorg ervoor dat de overgang naar de startpagina een meer expliciete overgang is en visueel meer opvalt.

Inlogprobleem

Het inlogformulierscherm is vaak minimalistisch en bevat een veld voor het invoeren van een gebruikersnaam en een veld voor een wachtwoord. Maar minimalisme staat niet gelijk aan eenvoud. Er zijn veel redenen waarom een gebruiker vast kan komen te zitten in het inlogscherm. De hoofdregel van de inlogpagina is om de gebruiker niet te laten raden.

Laten we eens kijken naar oplossingen voor de meest voorkomende problemen aan de hand van voorbeelden van MailChimp, dat uitstekend werk levert op het gebied van foutrapportage.

De gebruiker is zijn naam op de site vergeten. Als u een vergelijkbare fout vindt, moet u een link aanbieden waar de gebruiker deze kan oplossen. Vertel de gebruiker waar hij het kan krijgen (bijvoorbeeld: "controleer je mail, we hebben je een brief gestuurd") of geef een link om de naam op de site te herstellen.

Gebruikers doen veel pogingen om op de site in te loggen met het verkeerde wachtwoord. Om dergelijke serveraanvallen te voorkomen, worden gebruikersaccounts geblokkeerd na te vaak mislukte pogingen. Dit is een gebruikelijke beveiligingspraktijk, maar de gebruiker moet worden gewaarschuwd voordat zijn account wordt vergrendeld.

Creditcard afwijzing

Een afwijzing van een creditcard kan om verschillende redenen plaatsvinden: een gegevensopmaakfout (typfout of gebrek aan gegevens), of de kaart kan worden geweigerd omdat deze is verlopen of gestolen. Gabriel Tomescu suggereerde in zijn artikel "Anatomy of a Credit Card Shape" de volgende strategie voor beide fouten:

Voor het eerste probleem moet u de standaard tekenreeksvalidatie en visuele foutindicatie volgen:

Wanneer een creditcard echter om de een of andere reden wordt geweigerd door een betalingssysteem, lijkt dit meestal op diefstal. Je hebt duidelijke gegevens nodig van de gebruiker. En zelfs daarna moet je de gebruiker nog steeds op de hoogte stellen van wat er is gebeurd; de foutmelding moet heel duidelijk zijn.

Verbindingsprobleem

Internetverbinding is niet overal beschikbaar en offline ondersteuning zou een belangrijk aspect moeten zijn in het leven van elke moderne applicatie. Wanneer de verbinding wegvalt, moet je goed nadenken over de offline UX. Gebruikers moeten zoveel mogelijk van uw toepassing kunnen gebruiken. Dit betekent dat de app inhoud moet cachen voor een goede offline UX.

Labels:,,,

Validatie is een van de belangrijkste aspecten van goed webdesign. Laten we eens kijken naar wat het is en hoe we de HTML-code kunnen controleren op geldigheid. Laten we het meest voorkomende content management systeem (CMS) - WordPress als voorbeeld nemen. Daarna zullen we een lijst met fouten delen die we in de praktijk zijn tegengekomen en, belangrijker nog, we zullen onze eigen beproefde methoden aanbieden om ze te elimineren.

Waarom is het nodig om de geldigheid van de site te controleren?

Simpel gezegd, het controleren van een webpagina bepaalt of deze voldoet aan de normen van het World Wide Web Consortium (W3C). Dit wordt meestal gedaan door afzonderlijke pagina's op geldigheid te controleren met behulp van de online validatieservice van W3C.

Net als grammaticaregels in verschillende talen, zijn er ook regels bij het programmeren. Validatie stelt u in staat om te zien of de pagina aan deze regels voldoet, en als er fouten of waarschuwingen zijn, worden aanbevelingen gedaan om deze te verhelpen. We zullen hieronder nader ingaan op de noodzaak van een dergelijke controle.

Wat is van invloed op de validiteit van de site?

Heb je je ooit afgevraagd hoe browsers een webpagina "lezen"? Ze hebben motoren om code te analyseren en om te zetten in visuals voor mensen. Helaas heeft elke browser zijn eigen codeverwerkingsmechanisme, en dit kan ertoe leiden dat uw pagina's anders worden weergegeven.

Een ongeldige webpagina kan door browsers anders worden gelezen. Dit zal ertoe leiden dat uw bezoekers de pagina-inhoud in hun browser mogelijk niet eens correct kunnen zien. Verdere validatie zal bijna alle grote verschillen corrigeren en uw webpagina leesbaar maken voor bijna alle webbrowsers (meestal zijn oudere versies van Internet Explorer de uitzondering). Dit is waar de term "cross-browser layout" vandaan komt - dat wil zeggen. lay-out die even goed (compatibel) is voor alle populaire browsers.

Wat voor invloed heeft dit op SEO? Het is belangrijk om te begrijpen dat robots van zoekmachines dol zijn op semantische webpagina's. Semantische lay-out is volgens Wikipedia een benadering voor het maken van webpagina's in HTML, gebaseerd op het gebruik van HTML-tags in overeenstemming met hun semantiek (doel). Bovendien stelt een structurele semantische webpagina zoekrobots in staat om het belang van zowel afzonderlijke elementen van een webpagina als de gehele tekst als geheel nauwkeuriger te bepalen. Volgens Google heeft de geldige code op geen enkele manier invloed op de paginarangschikking. Maar tegelijkertijd kan de aanwezigheid van fouten in de code een negatieve invloed hebben op het scannen van micro-markup en het aanpassingsvermogen voor mobiele apparaten.

Validatietools voor uw site

Als we begrijpen dat er geen validatiefouten op sitepagina's nodig zijn, gaan we kijken hoe u naar deze fouten kunt zoeken.

Er zijn veel gratis sitevalidatieservices zoals de W3C Markup Validation Service, Web Page Analyzer, Browsershots en andere.

Er is niets vervelender dan het invullen van een slecht geschreven leadformulier op een bestemmingspagina. Onthoud hoe vaak u alle velden opnieuw moest invullen omdat het door u bedachte wachtwoord niet in het systeem paste volgens bepaalde criteria, niemand heeft geprobeerd u van tevoren op de hoogte te stellen.

Houd er rekening mee dat optimalisatie van leadformulieren een belangrijk onderdeel is van het conversie-optimalisatieproces en dat de focus hier moet liggen op veldvalidatie.

Wat is leadformuliervalidatie?

Leadformuliervalidatie is een technisch proces waarbij het systeem de juistheid van de door de gebruiker ingevoerde gegevens controleert. Als een persoon een fout heeft gemaakt bij het invullen van het formulier (hij heeft bijvoorbeeld de gegevens in het verkeerde formaat aangegeven), dan zal het systeem hem op deze fout wijzen (of gewoon op de aanwezigheid ervan) en aanbieden om deze te corrigeren. Als de gebruiker alle gegevens correct heeft ingevoerd, verschijnen er geen extra berichten (of verschijnt er een vinkje naast het veld) en gaat hij door naar de volgende registratiefase.

Twitter staat u bijvoorbeeld niet toe om door te gaan naar de volgende registratiestap als u uw e-mailadres in het verkeerde formaat invoert:

Wanneer u het e-mailadres invoert in het formaat dat het systeem nodig heeft, verschijnt er een vinkje naast het veld om aan te geven dat het formaat van de ingevoerde gegevens correct is:

De essentie van validatie is ervoor te zorgen dat gebruikers gegevens invoeren in het formaat dat door het systeem wordt vereist (het e-mailadres moet bijvoorbeeld voldoen aan de standaard [e-mail beveiligd], maar het wachtwoord moet bijvoorbeeld minimaal 7 tekens bevatten).

Er zijn twee hoofdtypen formuliervalidatie.

Validatie is het valideren van door de gebruiker aangeleverde waarden en het weergeven van gevonden fouten.

Principes

De taak van de ontwerper is ervoor te zorgen dat de gebruiker geen fouten maakt en er geen validatie nodig is, hiervoor:

Beperk de selectie van opzettelijk onjuiste waarden in de lijst: blokkeer deze waarden of toon ze niet in de lijst.
Beperk de invoer van ongepaste tekens. Als u alleen cijfers in een veld hoeft in te voeren, en dit is duidelijk voor de gebruiker, negeer dan de invoer van letters in plaats van een fout weer te geven. Gebruik maskers in velden waarvan het formaat bekend is bij de waarden.
Schrijf tips voor het invullen van het formulier. Bijvoorbeeld tijdelijke aanduiding in invoervelden.

Validatie op een nieuw geopend leeg formulier is verboden. De uitzondering zijn concepten, wanneer de gebruiker dit formulier al heeft ingevuld, er na enige tijd op terugkwam en het met fouten was ingevuld.

Soorten validatie

Er zijn drie soorten validaties: direct, onscherp en formulierverzending.

Hoe eerder de interface de fout meldt, hoe beter - het is gemakkelijker voor de gebruiker om terug te gaan en de fout te herstellen.

De snelste manier om een bug te melden is met onmiddellijke validatie. Maar het is alleen mogelijk in die gevallen dat tijdens het invoerproces duidelijk is dat de waarde niet klopt. Meestal worden dergelijke fouten geassocieerd met een onjuiste toetsenbordindeling (Cyrillisch in plaats van Latijn) of het invoeren van letters in een digitaal veld (TIN, KPP, enz.). In deze gevallen gebruiken we velden met maskers: het invoeren van ongepaste tekens daarin is geblokkeerd. Daarom zijn er slechts twee soorten validatie in onze interfaces:

op verlies van focus- het belangrijkste type validatie
door het formulier in te dienen- voor die gevallen waarin validatie op verlies van focus niet mogelijk is.

Verlies van focus validatie

Wanneer te gebruiken

Hoe werkt het

Valideer geen velden op leegte bij verlies van focus - toon geen fout als het veld niet is ingevuld, misschien komt de gebruiker terug en vult het veld iets later in. U kunt in dergelijke gevallen alleen een fout laten zien na het verzenden van het formulier.

Validatie wordt onmiddellijk geactiveerd na verlies van focus, als de waarde in het veld is ingevuld. Als er een fout wordt gevonden, wordt het veld rood gemarkeerd. De focus keert niet automatisch terug naar dit veld:

De fouttekst verschijnt in de tooltip wanneer het veld een hover of focus krijgt:

Het foutveld moet gemarkeerd blijven als het de focus heeft gekregen, de waarde niet is gecorrigeerd en vervolgens de focus heeft verloren.

De rode markering wordt uit het veld verwijderd zodra de gebruiker de foutieve waarde begon te corrigeren.

Validatie bij indiening van formulier

Wanneer te gebruiken

Gebruik dit soort validatie wanneer u velden niet kunt valideren op verlies van focus. Bijvoorbeeld om de voltooiing van verplichte velden te controleren.

Hoe werkt het

Validatie vindt plaats nadat de gebruiker op de verzendknop heeft gedrukt: alle velden met fouten op het formulier worden gemarkeerd, de pagina scrolt naar het eerste veld met een fout, de focus gaat naar dit veld, de cursor gaat naar het einde van de regel, een tooltip met een hint verschijnt naast het veld.

Bij het scrollen naar de eerste marge van de bovenrand van het venster naar de foutieve marge, is er een inspringing van 48px - zes modules.

De verzendknop blokkeren

In kleine formulieren kunt u, in plaats van te controleren of de vereiste velden zijn ingevuld, de verzendknop voor formulieren blokkeren. Gebruik dit gedrag als het duidelijk is waarom de verzendknop van het formulier inactief is. Op het inlogformulier bijvoorbeeld:

Zodra alle verplichte velden zijn ingevuld, wordt de knop actief. Als de gebruiker daarna de waarde in een van de velden heeft gewist, moet de knop weer inactief worden.

Foutmeldingen

Bugs kunnen op twee manieren worden gemeld:

Knopinfo

Hoe werken ze

In twee gevallen verschijnt er knopinfo met een hint:

Bij het zweven over een veld met een fout.
Wanneer een foutveld focus krijgt.

Als de waarde in het veld met de fout is gewijzigd, de focus verloor en vervolgens weer in focus kwam, verschijnt de knopinfo met de tekst van de oude fout niet meer. Deze regel werkt hetzelfde voor alle soorten validaties: zowel bij verlies van focus als bij het indienen van formulieren.

De zwevende knopinfo overschrijft de focusknopinfo.

De tooltip kan boven of rechts van de foutcontrole verschijnen, zodat deze geen nuttige informatie overlapt:

Consistentie van gedrag en uiterlijk

Toon tooltips rechts van de velden. Als ze in dit geval belangrijke inhoud op de pagina overlappen, geef dan tooltips bovenaan weer. Zorg voor consistentie, maar onthoud dat inhoud belangrijker is dan dat.

Rode teksten op de pagina

Hoe werken ze

De rode fouttekst verschijnt zodra de validatie heeft plaatsgevonden en het foutveld is gemarkeerd.

Zodra de gebruiker de waarde begint te corrigeren, verdwijnt de rode markering van het veld en verandert de kleur van de fouttekst in -  # 333.

De fouttekst verdwijnt wanneer de focus verloren gaat en verschijnt niet meer als het veld opnieuw focus krijgt. Deze regel werkt hetzelfde voor alle soorten validaties: zowel bij verlies van focus als bij het indienen van formulieren.

Druk de fouttekst rechts af als er ruimte op het formulier is en het bericht zelf kort is. Op deze manier hoeft het formulier niet uit elkaar te worden geduwd om de fout te tonen.

Als er rechts van het veld geen ruimte is voor tekst, vouwt u het formulier uit en geeft u een bericht weer onder het veld.

Geef bij complexere formulieren een foutmelding weer in de knopinfo.

Afhankelijke velden valideren

Afhankelijke velden zijn velden waarvan de betekenis van elkaar afhangt.

Fouten die verband houden met de schending van de veldafhankelijkheid, tonen we na het indienen van het formulier. Bijvoorbeeld TIN en KPP. Als de gebruiker het TIN van 10 cijfers heeft opgegeven en het veld met het controlepunt leeg heeft gelaten, wordt na het indienen van het formulier het lege veld met het controlepunt gemarkeerd.

TIN kan van twee soorten zijn:

10-cijferig voor rechtspersonen
12-cijferig IP-adres.

Als de gebruiker het TIN van 12 cijfers heeft opgegeven, dan is de organisatie een individuele ondernemer en heeft deze geen controlepunt, dan hoeft het controlepuntveld niet te worden ingevuld. En vice versa, als het controlepunt is ingevuld en het TIN wordt aangegeven met een 12-cijferig nummer, is het mogelijk dat het TIN verkeerd wordt aangegeven.

De markering van de afhankelijke velden verdwijnt zodra de gebruiker begint met het corrigeren van de waarde in een van deze velden.

Als het waardeformaat niet in orde is bij het invullen van een afhankelijk veld, rapporteer deze fout dan wanneer u de focus verliest. De gebruiker heeft bijvoorbeeld 3 cijfers in het veld TIN ingevoerd en de focus verwijderd. Een dergelijk veld moet onmiddellijk worden gemarkeerd.

Voorbeeld

Er is een formulier met 5 velden:

Naam van de organisatie- platte tekst, vereist
CAFE- 10 of 12 cijfers, controleer som op verlies van focus, verplicht
Controlepunt- 9 cijfers met controle van de checksum op verlies van focus, verplicht als de INN uit 10 cijfers bestaat
E-mail- e-mailadres, controleer op verlies van focus met masker [e-mail beveiligd], optioneel
Telefoon- internationaal formaat, controleer op verlies van focus met masker +000000000, verplicht

Analyse van sitevalidatiefouten

Eindelijk was er wat vrije tijd tussen een eindeloze reeks bestellingen en besloot ik mijn blog te starten. Laten we proberen het te verbeteren in termen van validatie. Hieronder in het artikel zal ik je vertellen wat validatie van een site, html en css code is, waarom het nodig is en hoe je een site naar de standaarden brengt aan de hand van een specifiek voorbeeld.

Wat is sitevalidatie?

In eenvoudige bewoordingen is het een test voor naleving van normen. Zodat elke browser uw site correct kan weergeven. De geldigheid van de site heeft geen grote invloed op de promotie, maar slechter zal het zeker niet zijn.

Een specifiek voorbeeld van het doorgeven van validatie voor een webpagina

Laten we de eerste pagina nemen die we op mijn site tegenkomen - Base64-codering en -decodering in Java 8. Laten we het pagina-adres in de validator invullen en het resultaat bekijken:

Fouten gevonden bij het controleren van dit document als HTML 4.01 Transitional! Resultaat: 105 fouten, 67 waarschuwing(en) Ja, het beeld is onaangenaam: meer dan honderd fouten en 67 waarschuwingen - hoe indexeren zoekmachines mijn blog en bezoeken mensen? Maar laten we niet boos zijn, maar we zullen leren om validatie door te geven, om fouten te corrigeren. Dus de eerste waarschuwing:

Kan de parseermodus niet bepalen! De validator kan documenten verwerken als XML (voor documenttypes zoals XHTML, SVG, enz.) of SGML (voor HTML 4.01 en eerdere versies). Voor dit document was de beschikbare informatie niet voldoende om de parseermodus ondubbelzinnig te bepalen, omdat: het MIME-mediatype (tekst / html) kan worden gebruikt voor XML- of SGML-documenttypes Geen bekend documenttype kon worden gedetecteerd Geen XML-declaratie (bijv.) kan worden gevonden aan het begin van het document. Geen XML-naamruimte (bijv ) kan worden gevonden in de hoofdmap van het document. Standaard valt de validator terug naar de SGML-modus. Waarschuwing Geen DOCTYPE gevonden! Controleren met standaard HTML 4.01 Transitional Document Type. In dit document kon geen DOCTYPE-verklaring worden gevonden of herkend. Dit betekent over het algemeen dat het document het documenttype bovenaan niet aangeeft. Het kan ook betekenen dat de DOCTYPE-declaratie een spelfout bevat, of dat deze niet de juiste syntaxis gebruikt. Het document is gecontroleerd met behulp van een standaard "fallback" documenttypedefinitie die sterk lijkt op "HTML 4.01 Transitional". Dit is hetzelfde. En de oplossing is eenvoudig: voeg helemaal aan het begin van de pagina de tag toe:

We controleren of het ons is gelukt en zien dat we met deze ene tag 105 fouten en 3 waarschuwingen hebben verwijderd! Nu hebben we nog maar 64 waarschuwingen over. We beginnen ze een voor een te demonteren.

Waarschuwing: Het type attribuut voor het stijlelement is niet nodig en moet worden weggelaten. Vanaf regel 5, kolom 1; naar regel 5, kolom 23 / x-pictogram "> ↩