Filvalideringsfeil. Lead Form Validering – Den komplette veiledningen. Konsistens i oppførsel og utseende

Legg igjen en kommentar 6,950

Mennesker har en tendens til å gjøre feil. Feil oppstår når folk samhandler med brukergrensesnitt. Dette skjer noen ganger fordi brukere gjør feil. Noen ganger oppstår feil i selve applikasjonen. Uavhengig av årsak, har feil og deres håndtering en enorm innvirkning på UX. Feil feilhåndtering, kombinert med ubrukelige feilmeldinger, kan forårsake tilbakeslag fra brukeren, som i ettertid kan føre til at brukeren nekter å bruke applikasjonen din.

I denne artikkelen skal vi utforske hvordan du kan optimalisere applikasjonsdesignet ditt for å forhindre tilpassede feil og hvordan du lager effektive feilmeldinger når feil oppstår uavhengig av hva brukeren skriver inn. Vi skal også se på hvordan en godt håndtert feil kan gjøre fiasko til beundring. Adobe har introdusert en ny design- og ingeniørapplikasjon Experience Design (Adobe XD), som lar deg designe interaktive prosjekter og feiltilstander. Du kan laste ned og prøve Adobe XD gratis.

Hva er en feiltilstand?

En feiltilstand er en skjerm som vises til brukeren når noe gikk galt. Dette er et eksempel på en situasjon der brukeren gjør noe annet enn ønsket tilstand. Siden feil kan oppstå i uventede kombinasjoner, kan disse tilstandene inkludere svært forskjellige problemer, fra inkompatible brukeroperasjoner (for eksempel feil datainntasting) til applikasjonens manglende evne til å koble til serveren eller til og med manglende evne til å behandle brukerforespørselen.

Feilskjermer

Hver feil, uansett årsak, blir en snublestein for brukeren på veien til å komme seg gjennom UX. Heldigvis kan en velformet feil redusere den ubehagelige effekten.

Det er bedre å forebygge enn å helbrede

Hvis du bygger en applikasjon, må du forstå hvilke grunnleggende brukerinteraksjoner med applikasjonen som kan føre til en feil. For eksempel er det vanligvis svært vanskelig å fylle ut et skjema riktig ved første forsøk, eller det er umulig å synkronisere data riktig hvis enheten har en dårlig nettverksforbindelse. Du bør huske på disse punktene for å minimere muligheten for feil. Med andre ord er det bedre å forhindre muligheten for feil ved å vise tips, bruke begrensninger og fleksibilitet.

Hvis du for eksempel gir folk muligheten til å søke og reservere hoteller, hvorfor la datoer være tilgjengelige i fortiden og vise en feilmelding hvis brukeren velger en slik dato?

Som vist i eksemplet med Booking.com, kan du ganske enkelt bruke en datovelger, som bare lar brukere velge dagens dato og fremtidige datoer. Dette vil be brukere om å velge kun gyldige datoer.

Datovelger i Boocking.com-appen. Hele måneden vises, men datoer i fortiden er ikke tilgjengelige.

Skjemavalideringsfeilskjerm

Form er kommunikasjon. Som all kommunikasjon må det være en seriell kommunikasjon mellom to parter – brukeren og applikasjonen din. Validering spiller en stor rolle i denne kommunikasjonen. Skjemavalidering er utviklet for å veilede brukere gjennom kompleksitet, feil og misforståelser. Når den er riktig validert, blir denne kommunikasjonen klar og forståelig. Generelt har god formvalidering fire viktige elementer:

Riktig tidspunkt for å rapportere feil (eller vellykket gjennomføring)
Riktig sted for valideringsmeldingen
Riktig meldingsfarge
Forståelig språk i meldingen

Riktig tid (strengvalidering)

Skjemavalidering er uunngåelig og er en logisk del av brukerinndata (siden brukerinndata kan være utsatt for feil). Selvfølgelig bør tilstander som kan forårsake en feil minimeres, men feilvalidering kan ikke fjernes. Så det viktigste spørsmålet er: "Hvordan kan du gjøre det lettere for brukeren å komme seg etter en feil?"

Brukere liker ikke prosessen med å fylle ut skjemaet, spesielt når de mottar en feilmelding på slutten. Det er spesielt frustrerende å motta feilmeldinger i flere felt etter å ha fylt ut et langt skjema. Og det mest irriterende er mangelen på klarhet om hvilke feil du har gjort og hvor.

Validering bør umiddelbart informere brukeren om riktigheten av dette svaret umiddelbart etter at brukeren har lagt inn dataene. Hovedprinsippet for god validering er: «Snakk med brukerne! Fortell dem hva som er galt!" og strengvalidering i sanntid informerer brukere om riktigheten av de innlagte dataene. Denne tilnærmingen lar brukere raskt fikse feil og ikke vente på at feil skal vises etter å ha klikket på send-knappen.

Du bør imidlertid unngå å validere hvert tastetrykk fordi du i de fleste tilfeller ikke vil være i stand til å bekrefte dataene før brukeren er ferdig med å skrive inn svaret. Skjemaer som validerer verdien umiddelbart under skriveprosessen begynner å irritere brukeren så snart han begynner å legge inn data.

Google Forms viser en e-postfeil selv når du ikke er ferdig med å skrive ennå.

På den annen side informerer ikke skjemaer som validerer etter datainntasting brukeren om feilen.

Apple Store-validering finner sted etter datainntasting.

Mikhail Konzhevich i sin artikkel "String Validation in Forms - Creating Experience! forsket på ulike valideringsstrategier og foreslo en hybridstrategi: tidlig belønning, sen straff.

Hybrid - tidlig belønning, sen straff - tilnærming

Det rette stedet

Brukerorientering er et annet viktig verktøy. Når du lurer på hvor du skal henvende deg for valideringsmeldingen din, følg dette tipset: Plasser alltid meldingen i konteksten av en handling. Hvis du vil fortelle brukeren om en feil i et spesifikt felt, vis den ved siden av. Det er best å plassere rask validering til høyre for inntastingsfeltet, eller under det.

Skjemafeil i sanntid.

Riktig farge (intuitivt design)

Farge er et av de beste verktøyene du kan bruke når du lager validering. Siden det fungerer på et intuitivt nivå, er rødt for feil, gult for advarsel og grønt for å indikere suksess spesielt kraftig. Men sørg for at fargene blir godt mottatt av brukerne. Dette er et kritisk aspekt ved god visuell design.

Feilteksten skal være forståelig og tydelig skille seg ut mot bakgrunnen av søknaden.

Tydelig melding

En typisk feilmelding kan lese "e-post er ugyldig", uten å forklare brukeren hvorfor e-posten er feil. (Typografi? E-post opptatt av en annen bruker?) Enkle instruksjoner eller retningslinjer kan gjøre ting annerledes. Du kan se i et eksempel hvordan skjemaet informerer brukeren om at e-posten hans allerede er tatt. Det vises også flere forslag (pålogging eller gjenoppretting av passord).

Så nå er det på tide å vise feilsiden for å vise at noe gikk galt. Som et eksempel, la oss forestille oss en situasjon der tilkoblingen avbrytes og brukeren er på skjermen, som er den eneste tilgjengelige. Du bør bruke denne muligheten til å fortelle folk hva som skjer og gi en rask hjelpemodell – budskapet ditt skal være en hjelpende hånd for brukerne. Derfor bør du aldri vise følgende:

Fatal feilmelding. Meldinger som snakker om en intern feil i applikasjonskoden eller inneholder tekst som "en feil type 2 har oppstått" er kryptiske og skumle.

En feilmelding skrevet av utvikleren for utvikleren.

Blindveisfeil. Ganske enkelt fordi slike meldinger ikke gir noen nyttig informasjon til brukeren.

Feilskjermen på Spotify viser "En feil har oppstått" og inneholder ingen alternativer eller trinn for å løse problemet.

En udefinert feilmelding. En slik skjerm (i eksemplet nedenfor) gir brukeren like mye informasjon som den forrige. Brukere har ingen anelse om hva dette betyr eller hva de skal gjøre med det.

Buffer-appen inneholder en fin feilmelding, men den formidler ingen informasjon til brukeren.

Ikke skrem brukeren med feil. Ikke prøv å introdusere brukeren til de tekniske detaljene rundt problemet. Snakk om feilen på et enkelt og forståelig språk. For å gjøre dette, prøv å ikke bruke teknisk sjargong og uttrykke tankene dine på brukerens språk.

Gjør meldingene dine lesbare og nyttige – feil bør være høflige, tydelige og didaktiske, og inkludere følgende informasjon:

Hva gikk galt og hvorfor (eventuelt).
Hva brukeren bør gjøre for å fikse feilen.

Remote-appen forklarer hvorfor brukere ikke kan se noe og foreslår en løsning.

Inkluder humor og bilder i feilmeldinger

Feilrapportering er en flott mulighet til å bruke ikoner og illustrasjoner fordi folk er mer mottakelige for visuell informasjon enn bare tekst. Men du kan gå enda lenger og legge til bilder i applikasjonen din, noe som vil være nyttig for brukerne. Dette vil tilpasse applikasjonen din og myke opp budskapet ditt.

Azendoo bruker illustrasjon og humor for å inspirere brukeren til å løse et problem.

Humor forlenger livet. Litt humor skader aldri, og vil bidra til å dempe forvirringen av en feil. Du kan finne tonnevis av eksempler på morsomme innlegg på Littlebigdetails. Her er noen av mine favoritter:

Basecamp: Ved skjemavalideringsfeil gir helten til venstre et overrasket uttrykk.

En litt frekk feilmelding vises når du prøver å skrive inn for mange prikker når du oppretter en ny Gmail-konto.

Vær imidlertid forsiktig med humor fordi det kanskje ikke alltid passer i feilrapporten din; det avhenger av alvorlighetsgraden av feilen. For eksempel fungerer humor godt for et enkelt valideringsproblem som en 404-feil (side ikke funnet). Men når en bruker bruker en viss tid på å se på en side som sier "Oh!" – Det ser malplassert ut.

En omfattende sjekkliste for den perfekte feilsiden

Gode feilsider er en hjelpende hånd for brukerne og må oppfylle følgende seks kriterier:

Feilmeldingen vises dynamisk umiddelbart etter at feilen er oppdaget. Den skal informere brukeren om problemet.
Vær trygg for de angitte dataene. Applikasjonen din skal ikke bryte, slette eller avbryte det brukeren skrev inn eller lastet ned da feilen ble oppdaget.
Snakk med brukeren på samme språk. Budskapet skal gi en klar forståelse av hva som gikk galt og hvorfor; hva må brukeren gjøre for å fikse feilen?
Ikke sjokker eller forvirr brukere. (Beskjeden skal ikke være for provoserende).
Ikke mist kontrollen over systemet. (Hvis problemet ikke er kritisk, bør brukeren kunne gjøre det med resten av applikasjonen).
Bruk en sans for humor for å dempe problemet.

Løsninger på de vanligste feilene

404-feil (side ikke funnet)

Hovedmålet med en 404-side er å omdirigere brukeren til siden de så etter så snart som mulig. 404-siden din bør tilby flere nøkkellenker som brukeren kan gå til. Det sikreste alternativet er å ha en lenke til "hjemmesiden" til nettstedet på en 404-side. Du kan også plassere en "rapporter et problem" slik at brukeren vil varsle deg om at siden ikke fungerer. Men pass på at overgangen til hjemmesiden er en mer eksplisitt overgang og skiller seg mer ut visuelt.

Påloggingsproblem

Skjermen på innloggingsskjemaet er ofte minimalistisk og inneholder et felt for å angi brukernavn og et felt for passord. Men minimalisme er ikke det samme som enkelhet. Det er mange grunner til at en bruker kan bli sittende fast ved påloggingsskjermen. Hovedregelen for påloggingssiden er ikke å tvinge brukeren til å gjette.

La oss ta en titt på løsninger på de vanligste problemene ved å bruke eksempler fra MailChimp, som gjør en god jobb med feilrapportering.

Brukeren har glemt navnet sitt på siden. Hvis du finner en lignende feil, bør du tilby en lenke der brukeren kan fikse den. Fortell brukeren hvor han kan få det (for eksempel: "sjekk e-posten din, vi har sendt deg et brev") eller oppgi en lenke for å gjenopprette navnet på nettstedet.

Brukere gjør mange forsøk på å logge inn på siden med feil passord. For å forhindre slike serverangrep, blokkeres brukerkontoer etter for hyppige mislykkede forsøk. Dette er en vanlig sikkerhetspraksis, men brukeren må advares før kontoen deres låses.

Kredittkortavvisning

En kredittkortavvisning kan oppstå av flere årsaker: en dataformateringsfeil (skrivefeil eller mangel på data), eller kortet kan bli avvist fordi det er utløpt eller stjålet. Gabriel Tomescu foreslo i sin artikkel «Anatomy of a Credit Card Shape» følgende strategi for begge feilene:

For det første problemet bør du følge standard strengvalidering og visuell feilindikasjon:

Men når et kredittkort av en eller annen grunn blir avvist av et betalingssystem, ser det vanligvis ut som et tyveri. Du trenger tydelige data fra brukeren. Og selv etter det, må du fortsatt varsle brukeren om hva som skjedde; feilmeldingen skal være veldig tydelig.

Forbindelsesproblem

Internett-tilkobling er ikke tilgjengelig overalt, og offline-støtte bør være et nøkkelaspekt i livet til enhver moderne applikasjon. Når tilkoblingen faller, må du tenke nøye over den offline UXen. Brukere skal kunne samhandle med så mye av applikasjonen som mulig. Dette betyr at appen må bufre innhold for en god offline UX.

Tags:,,,

Validering er en av de viktigste aspektene ved god webdesign. La oss ta en titt på hva det er og hvordan du sjekker HTML-koden for gyldighet. La oss ta det vanligste innholdsstyringssystemet (CMS) – WordPress som eksempel. Etter det vil vi dele en liste over feil som vi har møtt i praksis, og viktigst av alt, vi vil tilby våre egne velprøvde metoder for å eliminere dem.

Hvorfor er det nødvendig å sjekke gyldigheten til nettstedet

Enkelt sagt, å sjekke en nettside vil avgjøre om den oppfyller standardene satt av World Wide Web Consortium (W3C). Dette gjøres vanligvis ved å sjekke individuelle sider for gyldighet ved å bruke W3Cs online valideringstjeneste.

Som grammatikkregler på forskjellige språk, er det også regler i programmering. Validering lar deg se om siden overholder disse reglene, og hvis det er feil eller advarsler, vil det bli gitt anbefalinger om hvordan du kan fikse dem. Vi vil vurdere mer detaljert behovet for en slik kontroll nedenfor.

Hva påvirker nettstedets gyldighet?

Har du noen gang lurt på hvordan nettlesere "leser" en nettside? De har motorer for å analysere kode og transformere den til bilder for mennesker. Dessverre har hver nettleser sin egen kodehåndteringsmekanisme, og dette kan føre til at sidene dine vises annerledes.

En ugyldig nettside kan leses annerledes av nettlesere. Dette vil føre til at de besøkende kanskje ikke en gang kan se sideinnholdet riktig i nettleserne deres. Ytterligere validering vil korrigere nesten alle store forskjeller og gjøre nettsiden din lesbar av nesten alle nettlesere (oftest er eldre versjoner av Internet Explorer unntaket). Det er her begrepet «cross-browser layout» kom fra – altså. layout som er like bra (kompatibelt) for alle populære nettlesere.

Hvordan påvirker dette SEO? Det er viktig å forstå at søkemotorroboter elsker semantiske nettsider. Semantisk layout er ifølge Wikipedia en tilnærming til å lage nettsider i HTML, basert på bruk av HTML-tagger i samsvar med deres semantikk (formål). I tillegg lar en strukturell semantisk nettside søkeroboter mer nøyaktig bestemme viktigheten av både individuelle elementer på en nettside og hele teksten som helhet. Ifølge Google påvirker ikke den gyldige koden sidens rangering på noen måte. Men samtidig kan tilstedeværelsen av feil i koden negativt påvirke skanningen av mikromarkering og tilpasningsevne for mobile enheter.

Valideringsverktøy for nettstedet ditt

For å forstå behovet for ingen valideringsfeil på nettstedssider, la oss se på hvordan du søker etter disse feilene.

Det finnes mange gratis nettstedsvalideringstjenester som W3C Markup Validation Service, Web Page Analyzer, Browsershots og andre.

Det er ikke noe mer kjedelig enn å fylle ut et dårlig skrevet kundeemneskjema på en landingsside. Husk hvor mange ganger du måtte fylle ut alle feltene på nytt på grunn av at passordet du fant opp ikke passet til systemet i henhold til visse kriterier, ingen prøvde å varsle deg på forhånd.

Husk at optimering av potensielle kunder er en nøkkelkomponent iessen, og fokus her bør være på feltvalidering.

Hva er validering av potensielle skjemaer?

Leadskjemavalidering er en teknisk prosess der systemet kontrollerer riktigheten av dataene som er lagt inn av brukeren. Hvis en person gjorde en feil da han fylte ut skjemaet (for eksempel indikerte han dataene i feil format), vil systemet henvise ham til denne feilen (eller ganske enkelt til dens tilstedeværelse) og tilby å rette den. Hvis brukeren skrev inn alle dataene riktig, vises ingen ytterligere meldinger (eller et hakemerke vises ved siden av feltet), og han vil fortsette til neste trinn i registreringen.

For eksempel vil ikke Twitter tillate deg å gå videre til neste registreringstrinn hvis du skriver inn e-postadressen din i feil format:

Når du skriver inn e-postadressen i formatet som systemet trenger, vil et hakemerke vises ved siden av feltet, som indikerer at formatet på de angitte dataene er riktig:

Essensen av validering er å sikre at brukere legger inn data i formatet som kreves av systemet (for eksempel må e-postadressen være i samsvar med standarden [e-postbeskyttet], men for eksempel må passordet inneholde minst 7 tegn).

Det er to hovedtyper av skjemavalidering.

Validering er validering av brukerleverte verdier og visning av funnet feil.

Prinsipper

Designerens oppgave er å sørge for at brukeren ikke gjør en feil og at det ikke er nødvendig med validering, for dette:

Begrens utvalget av bevisst ukorrekte verdier i listen: blokker disse verdiene eller ikke vis dem i listen.
Begrens inntastingen av upassende tegn. Hvis du bare trenger å skrive inn tall i et felt, og dette er åpenbart for brukeren, ignorer inntasting av bokstaver i stedet for å vise en feil. Bruk masker i felt der formatet er kjent for verdiene.
Skriv tips for å fylle ut skjemaet. For eksempel plassholder i inndatafelt.

Validering på et nyåpnet tomt skjema er forbudt. Unntaket er utkast, når brukeren allerede har fylt ut dette skjemaet, etter en tid returnert til det, og det ble fylt ut med feil.

Typer validering

Det er tre typer valideringer: øyeblikkelig, ute av fokus og skjemainnsending.

Jo raskere grensesnittet rapporterer feilen, jo bedre – det er lettere for brukeren å gå tilbake og fikse feilen.

Den raskeste måten å rapportere en feil på er med umiddelbar validering. Men det er bare mulig i de tilfellene når det er klart under inndataprosessen at verdien er feil. Vanligvis er slike feil knyttet til feil tastaturoppsett (kyrillisk i stedet for latin) eller inntasting av bokstaver i et digitalt felt (TIN, KPP, etc.) For disse tilfellene bruker vi felt med masker: inntasting av upassende tegn i dem er blokkert. Derfor er det bare to typer validering i grensesnittene våre:

på tap av fokus- hovedtypen validering
ved å sende inn skjemaet- for de tilfellene hvor validering på tap av fokus ikke er mulig.

Tap av fokus validering

Når du skal bruke

Hvordan virker det

Ikke valider felt for tomhet ved tap av fokus - ikke vis feil hvis feltet ikke er fylt ut, kanskje brukeren kommer tilbake og fyller ut feltet litt senere. Du kan vise en feil i slike tilfeller først etter at du har sendt inn skjemaet.

Validering utløses umiddelbart etter tap av fokus, dersom verdien i feltet er fylt ut. Hvis det oppdages en feil, er feltet uthevet i rødt. Fokuset returneres ikke automatisk til dette feltet:

Feilteksten vises i verktøytipset når feltet mottar hover eller fokus:

Feilfeltet skal forbli uthevet hvis det fikk fokus, verdien ikke ble korrigert, og så mistet det fokus.

Den røde markeringen fjernes fra feltet så snart brukeren begynte å korrigere den feilaktige verdien.

Validering ved innsending av skjema

Når du skal bruke

Bruk denne typen validering når du ikke kan validere felt ved tap av fokus. For eksempel for å sjekke utfyllingen av obligatoriske felt.

Hvordan virker det

Validering skjer etter at brukeren har trykket på send-knappen: alle felt med feil på skjemaet er uthevet, siden ruller til det første feltet med en feil, fokus flyttes til dette feltet, markøren flyttes til slutten av linjen, en verktøytips med et hint vises ved siden av feltet.

Når du ruller til den første margen fra øvre kant av vinduet til den feilaktige margen, er det et innrykk på 48px - seks moduler.

Blokkering av send-knappen

I små skjemaer, i stedet for å sjekke at de obligatoriske feltene er fylt ut, kan du blokkere innsendingsknappen. Bruk denne virkemåten når det er åpenbart hvorfor skjemaets send-knapp er inaktiv. For eksempel på påloggingsskjemaet:

Så snart alle obligatoriske felt er fylt ut, blir knappen aktiv. Hvis brukeren etter det slettet verdien i et av feltene, skal knappen bli inaktiv igjen.

Feilmeldinger

Feil kan rapporteres på to måter:

Verktøytips

Hvordan fungerer de

Et verktøytips med et hint vises i to tilfeller:

Når du holder musepekeren over et felt med feil.
Når et feilfelt får fokus.

Hvis verdien i feltet med feilen ble endret, mistet fokus og deretter returnert til fokus - vises ikke lenger verktøytipset med teksten til den gamle feilen. Denne regelen fungerer på samme måte for alle typer valideringer: både ved tap av fokus og ved innsending av skjema.

Hoververktøytipset overstyrer fokusverktøytipset.

Verktøytipset kan vises over eller til høyre for feilkontrollen slik at det ikke overlapper nyttig informasjon:

Konsistens i oppførsel og utseende

Vis verktøytips til høyre for feltene. Hvis de i dette tilfellet overlapper viktig innhold på siden, viser du verktøytips øverst. Oppretthold konsistens, men husk at innhold er viktigere enn det.

Røde tekster på siden

Hvordan fungerer de

Den røde feilteksten vises så snart valideringen har funnet sted og feilfeltet er uthevet.

Så snart brukeren begynner å korrigere verdien, forsvinner den røde uthevingen av feltet og fargen på feilteksten endres til -  # 333.

Feilteksten forsvinner når fokus mistes og vises ikke lenger hvis feltet får fokus igjen. Denne regelen fungerer på samme måte for alle typer valideringer: både ved tap av fokus og ved innsending av skjema.

Skriv ut feilteksten til høyre hvis det er plass på skjemaet og selve meldingen er kort. På denne måten trenger ikke skjemaet å skyves fra hverandre for å vise feilen.

Hvis det ikke er plass til tekst til høyre for feltet, utvider du skjemaet og viser en melding under feltet.

På mer komplekse skjemaer, vis en feilmelding i verktøytipset.

Validerer avhengige felt

Avhengige felt er felt hvis betydning avhenger av hverandre.

Feil som er relatert til brudd på feltavhengigheten, viser vi etter innsending av skjemaet. For eksempel TIN og KPP. Hvis brukeren spesifiserte TIN på 10 sifre, og lot feltet med sjekkpunktet stå tomt, etter å ha sendt inn skjemaet, vil det tomme feltet med sjekkpunktet bli uthevet.

TIN kan være av to typer:

10-sifret for juridiske personer
12-sifret IP.

Hvis brukeren spesifiserte TIN på 12 sifre, så er organisasjonen en individuell gründer, og den har ikke et sjekkpunkt, trenger ikke sjekkpunktfeltet å fylles ut. Og omvendt, hvis sjekkpunktet er fylt ut, og TIN er angitt med et 12-sifret nummer, er det mulig at TIN er angitt feil.

Uthevingen av de avhengige feltene forsvinner så snart brukeren begynner å korrigere verdien i et av disse feltene.

Hvis verdiformatet er ute av funksjon når du fyller ut et avhengig felt, rapporter denne feilen når du mister fokus. For eksempel skrev brukeren inn 3 tall i TIN-feltet og fjernet fokuset. Et slikt felt bør utheves umiddelbart.

Eksempel

Det er et skjema med 5 felter:

Navn på organisasjonen- ren tekst, påkrevd
VERTSHUS- 10 eller 12 sifre, sjekksum for tap av fokus, obligatorisk
Kontrollpunkt- 9 sifre med kontroll av sjekksum ved tap av fokus, obligatorisk hvis INN består av 10 sifre
E-post- e-postadresse, se etter tap av fokus ved maske [e-postbeskyttet], valgfritt
Telefon- internasjonalt format, sjekk for tap av fokus med maske +00000000000, obligatorisk

Analyse av nettstedsvalideringsfeil

Endelig ble det litt ledig tid mellom en endeløs rekke med bestillinger, og jeg bestemte meg for å starte bloggen min. La oss prøve å forbedre det når det gjelder validering. Nedenfor i artikkelen vil jeg fortelle deg hva validering av et nettsted, html og css-kode er, hvorfor det er nødvendig og hvordan du bringer et nettsted til standarder ved å bruke et spesifikt eksempel.

Hva er nettstedsvalidering?

Med enkle ord er det en test for samsvar med standarder. Slik at enhver nettleser kan vise nettstedet ditt riktig. Gyldigheten til nettstedet har ikke stor innvirkning på kampanjen, men det vil absolutt ikke bli verre.

Et spesifikt eksempel på bestått validering for en nettside

La oss ta den første siden vi kommer over på nettstedet mitt - Base64-koding og dekoding i Java 8. La oss fylle inn sideadressen i validatoren og se resultatet:

Feil funnet under kontroll av dette dokumentet som HTML 4.01 Transitional! Resultat: 105 feil, 67 advarsel(er) Ja, bildet er ubehagelig: mer enn hundre feil og 67 advarsler – hvordan indekserer søkemotorer bloggen min og folk besøker? Men la oss ikke bli opprørt, men vi vil lære å bestå validering, å rette opp feil. Så den første advarselen:

Kan ikke bestemme analysemodus! Validatoren kan behandle dokumenter enten som XML (for dokumenttyper som XHTML, SVG, etc.) eller SGML (for HTML 4.01 og tidligere versjoner). For dette dokumentet var den tilgjengelige informasjonen ikke tilstrekkelig til å bestemme analyseringsmodusen entydig, fordi: MIME-medietypen (tekst / html) kan brukes for XML- eller SGML-dokumenttyper. Ingen kjent dokumenttype kunne oppdages Ingen XML-erklæring (f.eks.) finnes i begynnelsen av dokumentet. Ingen XML-navneområde (f.eks ) finnes i roten av dokumentet. Som standard faller validatoren tilbake til SGML-modus. Advarsel Ingen DOCTYPE funnet! Sjekker med standard HTML 4.01 Transitional Document Type. Ingen DOCTYPE-erklæring ble funnet eller gjenkjent i dette dokumentet. Dette betyr vanligvis at dokumentet ikke oppgir sin dokumenttype øverst. Det kan også bety at DOCTYPE-deklarasjonen inneholder en stavefeil, eller at den ikke bruker riktig syntaks. Dokumentet ble sjekket med en standard "reserve" dokumenttypedefinisjon som ligner mye på "HTML 4.01 Transitional". Dette er det samme. Og løsningen er enkel: helt på begynnelsen av siden legger du til taggen:

Vi sjekker at vi har lykkes og ser at vi med denne ene taggen har fjernet 105 feil og 3 advarsler! Nå har vi bare 64 advarsler igjen. Vi begynner å demontere dem en etter en.

Advarsel: Typeattributtet for stilelementet er ikke nødvendig og bør utelates. Fra linje 5, kolonne 1; til linje 5, kolonne 23 / x-ikon "> ↩