Share
Webskjemaer er stadig et hett tema når det gjelder webdesign og brukerinteraksjon. Årsakene til dette er store, men en av de mer åpenbare årsakene er at skjemaer er den mest grunnleggende måten en bruker kan legge inn informasjon i din søknad. I denne artikkelen diskuterer vi noen teknikker som gjør at skjemaene dine kan svare på brukerens innspill, samtidig som de hjelper til å skjule unødvendig forvirrende eller overveldende elementer.
La oss komme i gang!
Tenk deg et skjema som en samtale du har med brukeren din. I en samtale er det en følelse av frem og tilbake som oppstår, hvor hver part beder den andre parten om å svare. For eksempel, la oss si at brukeren kommer til å enten registrere seg eller logge på. I begge tilfeller trenger du e-posten deres, så konversasjonelt, hvorfor ikke starte med det bare?
Gi meg din epost, og jeg skal sjekke og se om du har en konto. I så fall spør jeg deg om passordet ditt, ellers vil jeg gi deg et nytt passord og bekreft det passordet med meg.
Så når brukeren kommer til siden med skjemaet, har de en veldig klar melding: "Hva er din e-postadresse?"
Vi kjenner alle den fyren. Han er fyren du unngår fordi han snakker uopphørlig, og synes egentlig ikke å lytte til hva du må si. Oppriktig, den fyren er virkelig overveldende, og jeg er ikke sikker på at noen nyter det. Ikke vær den fyren.
I skjemaene dine lærer du en leksjon fra ham. I stedet for å konfrontere brukeren med et stort antall innganger, bør du vurdere å redusere brukerens innsatsbelastning ved å opprette reaktive innganger.
La oss ta en titt på et enkelt eksempel.
Påloggingsprosessen ser noe ut som dette: Jeg skriver inn e-postadressen min, så legger jeg inn passordet mitt, så trykker jeg på enter. I dette eksemplet lærer du hvordan du viser hvert av disse feltene først etter at forrige felt er fullført, ved hjelp av bare HTML og CSS. Vi skal bygge dette, og deretter en endret versjon.
La oss starte med et første skudd ved oppslaget.
Hvis det ser litt skremmende ut, ikke bekymre deg, jeg forklarer hvert stykke. La oss starte med e-postinngangen. Vi ser noen attributter lagt til taggen utover bare navnet. Først av alt er inngangstypen satt til "email"; Dette er en relativt ny type innspill som gir oss noen spesiell oppførsel i å støtte nettlesere. For eksempel, på iPhone, vises "@" symbolet på det primære tastaturet.
Et annet trekk ved inngangstyper er at HTML5-skjemaene har valideringsegenskaper på nettleserenivå. Dette betyr at du ikke trenger å skrive JavaScript for å utføre validering på grunnleggende formelementer! Legg merke til at vi har et "nødvendig" attributt på både e-post og passordelementene. Når disse to elementene er fylt ut og deres verdier anses å være gyldige av nettleseren, kan du til og med målrette dem med :gyldig pseudovelger.
Dette er kjempebra, men vi kan gjøre det bedre. For eksempel aksepterer nettleseren "a @ b" som en akseptabel e-post. Årsaken til dette er fordi en e-postadresse kan settes opp for å gå til noe som "noe @ localhost". Vårt passord kan være alt vi legger inn, så et enkelt tegn passord som "a" vil bli ansett som gyldig. La oss legge til noen vanlige uttrykk for å fikse disse problemene.
Merk: hvis du ikke er kjent med regex, er det greit! Vi dekker en liten mengde her for å vise hvordan du kan tilnærmet bruke den til vanlige oppgaver i HTML5-skjema validering, men du kan holde fast i nettleserimplementeringene og fortsatt følge opplæringen. Bare hopp over denne delen, og fortsett å gå!
Et annet notat: Du kan også sjekke ut Regular Expressions for Dummies: Screencast Series av Jeffrey Way.
La oss gå gjennom hver del av disse mønstrene. Regelmessige uttrykk er en måte å beskrive og sammenligne formatet av en streng.
Vi starter med e-postmønsteret.
mønster = "[^ @] * @ [^ @] * \. [a-zA-Z] 2,"
Accentsconagua
[^ @] * - matche et hvilket som helst antall tegn som er ikke et @ tegn eller et mellomrom.@ - et bokstavelig @ tegn\. - en bokstavelig .[A-zA-Z] - et hvilket som helst brev, både store og små bokstaver[A-zA-Z] 2 - enhver kombinasjon av to eller flere bokstaverNår vi setter alt sammen, kan vi se at dette uttrykket sier at en e-post er et sett med tegn bortsett fra et @ -tegn, etterfulgt av et @ -tegn, etterfulgt av et hvilket som helst sett med tegn bortsett fra et @ -tegn, etterfulgt av en periode etterfulgt av minst to bokstaver.
Vi kan bruke en mye enklere regex hvis vi bare vil validere basert på lengden på verdien:
mønster = "5"
De . betyr "ethvert tegn", og 5 sier at det må være minst fem av dem.
Med disse mønstrene på plass, vil elementet ikke anses som gyldig til en verdi som tilfredsstiller mønsteret er oppgitt.
Vi ringer ut merkingen med litt ekstra polsk og noen flere ikke-formede elementer.
Logg Inn
:gyldig CSS MagicNå som vi har noen markering for vårt påloggingsskjema, la oss se hva vi kan gjøre med CSS for å svare på brukerens innspill.
Vi vil vise det neste skjemaelementet når gjeldende er gyldig. La oss begynne å skjule skjemaelementene selv, på en tilgjengelig måte, slik at skjermleserne fortsatt vil se hele skjemaet, og slik at autofullføring vil kunne fylle verdiene inn. (Chris Coyier snakker om hvorfor ikke bruke display: none på slike ting her.) Vi bruker visuallyhidden metode beskrevet i Chris 'innlegg.
.visuelt skjult posisjon: absolutt; overløp: skjult; klips: rekt (0 0 0 0); høyde: 1px; bredde: 1px; margin: -1px; polstring: 0; grense: 0;
Vi starter med noen grunnleggende stiler.
kropp bakgrunnsfarge: # 245245; font-familie: 'Varela Round', sans-serif; h3 farge: # 555; skriftstørrelse: 2em; tekst-transformer: store bokstaver; brevavstand: .3em; .login bredde: 300px; margin: 50px auto; bakgrunn: # f5f9fa; polstring: 50px; border-radius: 8px; tekst-align: center; input [type = passord], skriv inn [type = email] bredde: 100%; grense: 1px solid #ccc; polstring: 8px; boks-størrelse: border-box; input [type = passord]: fokus, input [type = email]: fokus border: 1px solid # 888; oversikt: ingen; input [type = submit] bakgrunnsfarge: # F29E1E; bredde: 50%; grense: ingen; polstring: 8px; boks-størrelse: border-box; farge: #fff; font-familie: "Varela Round"; skriftstørrelse: 1em; tekst-transformer: store bokstaver; input [type = submit]: svever bakgrunnsfarge: # DB8F2A; markør: pointer; input margin: 6px 0;
Dette gir oss et enkelt sentrert innloggingsskjema. La oss ta det visuelt skjulte konseptet og bruke det til elementene vi vil gjemme.
input [type = passord], input [type = submit] overflow: hidden; klips: rekt (0 0 0 0); høyde: 1px; bredde: 1px; margin: -1px; polstring: 0; grense: 0; opasitet: 0; overgang: opacity 0.4s, height .4s, padding-top .4s, polstring-bunn .4s;
Vi skal utføre litt animasjon, så vi har utvidet klassen litt for å også inkludere opacity, fjernet den absolutte posisjoneringen, og lagt til overgangsdefinisjonen.
Merk: Vi inkluderer ikke leverandørens prefikser for overgangen, men du bør!
La oss vise dem når de skal vises, ved hjelp av :gyldig pseudovelger og + søskenvelger.
input [type = email]: gyldig + inngang [type = passord] opacity: 1; stilling: relativ; høyde: 30px; bredde: 100%; klipp: ingen; margin: 12px auto; grense: 1px solid #ccc; polstring: 8px; input [type = passord]: gyldig + inngang [type = send] opacity: 1; stilling: relativ; høyde: 40px; bredde: 50%; klipp: ingen; margin: 12px auto; polstring: 8px;
Det er viktig å vurdere brukerens mål og forventninger i et webskjema. Noen ganger er det en tilstrekkelig løsning for å helt skjule inngangene fra brukeren. Men i noen tilfeller kan dette ha en negativ effekt, noe som får brukeren til å føle seg som om de ikke er et tydelig veikart for prosessen med å fylle ut skjemaet, og at det kan ta lengre tid enn de er villige til å gi opp.
En løsning på dette problemet ville være å bruke noen form for obskurering uten å gjemme helt de innspillene som bidrar til å lage narrative tilbakemelding til former som har et klart mål og relativt forutsigbare forventninger. Her er en endret versjon som bruker skalering, webkits slørfilter, opasitet og Pekeren-events: ingen å "presentere" inngangene til brukeren som de er tilgjengelige. Vi må også sørge for at pekeren-hendelsene blir gjenopprettet når inngangene er tilgjengelige, slik at brukeren kan klikke på dem.
kropp bakgrunnsfarge: # 245245; font-familie: 'Varela Round', sans-serif; h3 farge: # 555; skriftstørrelse: 2em; tekst-transformer: store bokstaver; brevavstand: .3em; .login bredde: 300px; margin: 50px auto; bakgrunn: # f5f9fa; polstring: 50px; border-radius: 8px; tekst-align: center; input [type = passord], skriv inn [type = email] bredde: 100%; grense: 1px solid #ccc; polstring: 8px; boks-størrelse: border-box; input [type = passord]: fokus, input [type = email]: fokus border: 1px solid # 888; oversikt: ingen; input [type = submit] bakgrunnsfarge: # F29E1E; bredde: 50%; grense: ingen; polstring: 8px; boks-størrelse: border-box; farge: #fff; font-familie: "Varela Round"; skriftstørrelse: 1em; tekst-transformer: store bokstaver; input [type = submit]: svever bakgrunnsfarge: # DB8F2A; markør: pointer; input margin: 6px 0; input [type = passord], skriv inn [type = send] -webkit-filter: uskarphet (1px); transformere: skala (0,9); opacity: .4; overgang: alle .4s; peker-hendelser: ingen; input [type = passord]: gyldig + inngang [type = send], skriv inn [type = email]: gyldig + inngang [type = passord] peker-hendelser: auto; -webkit-filter: ingen; transformere: skala (1); opasitet: 1;
En rask feil å påpeke: Når en bruker trykker på kategorien, kommer de inn i neste formelement. Vi forhindrer å klikke inn i neste formelement med Pekeren-events: ingen, men det er ikke et "fokusabelt" attributt i CSS. I stedet må vi kontrollere denne oppførselen med et snev av JavaScript (jQuery-flavored).
var innganger = $ ("input"); $ (dokument) .on ("tastetrykk", "input", funksjon () inputs.each (funksjon (i, el) var $ el = $ (el) )) $ el.next ("input") [0] .disabled = false; else $ el.next ("input") [0] .disabled = true;);); Denne JavaScript ser på skjemainngangene våre og deaktiverer / aktiverer innganger basert på deres tidligere søskenes ": gyldige" tilstand. Dette vil forby oss fra å fokusere elementet. De peker-hendelser: ingen Fungerer fortsatt for å beholde innsendingsinngangen fra å motta hover-tilstanden.
Tenk deg et skjema som har flere "spor", som i vår "logg inn eller registrer" -eksempel. En bruker kan velge flere alternativer som ville nødvendiggjøre et nytt utvalg av formelementer, for eksempel å velge en tilstand for frakt eller et tidsrom for en middagsbestilling. I disse tilfellene kan det hende at enkel validering ikke er nok, og i stedet ville vi bruke en JavaScript-drevet løsning.
La oss ta for eksempel "logg inn" mot "registrere" -eksempel. For å løse dette må vi spørre serveren hvis det er en bruker som samsvarer med den angitte e-postadressen.
var timeout; $ (dokument) .on ("keyup", "input [type = email]" funksjon () clearTimeout (timeout); var input = $ (dette); timeout = setTimeout "(gyldig")) var email = input.val (); $ .getJSON ("/ check_for_user", email: email, funksjon (data) if (data.user_exists) input.parents ) .attr ("action", "/ login") input.addClass ("user_exists"); $ ("input [type = passord]") funksjon (i, el) el.required = true;) else input.parents ("form"). Attr ("action", "/ sign_up") input.addClass ("user_not_exists"); $ inntast [type = passord]).) filter ("[name * = 'signup']"). hver (funksjon (i, el) el.required = true;;)); I ovennevnte JavaScript sender vi e-postadressen til serveren på "/ check_for_user" url. Serveren ville returnere en enkel JSON-respons, som ligner på følgende.
tilbakeringing (user_exists: true);
Basert på denne verdien, legger vi til en klasse i inngangen, og endrer sluttpunktet for skjemaet. Vi angir også de relevante passordene som kreves. Vi kan da bruke CSS på en rekke måter å definere hva som skjer neste. For eksempel kan vi bruke en lignende tilnærming fra tidligere til å vise eller skjule innganger.
Hvis du registrerer deg for en ny konto, kan det hende du må vise passordfeltet for pålogging (i stedet for innloggingspassordfeltet). For å gjøre det, ville vi bruke ~ selector, som er den generelle velgeren for søsken, og lar oss "hoppe" over de irrelevante søskenelementene.
input [name = "signup_password"] / * visuelt skjulte stiler her * / input [type = email] .user_not_exists: valid ~ input [name = "signup_password"] / * "synlige" stiler gå her * / [type = email] .user_exists: valid ~ input [name = "login_password"] / * "synlige" stiler gå her * /
Når vi skyver nye teknikker i front-end-utviklingen, kommer de ikke til å jobbe hele tiden, i alle nettlesere. Heldigvis er det veldig enkelt å håndtere en god nedgang i denne situasjonen. Vi er dekket i de fleste større nettlesere, men dette valget inneholder dessverre ikke iOS 7 eller Android. For ikke-støttende nettlesere faller vi helt enkelt tilbake til standard skjemaadferd.
For å gjøre dette kan vi bruke Modernizr til å oppdage om nettleseren støtter validering av formelementer eller ikke. Det er best å bruke Modernizr for denne typen funksjonsdeteksjon, men vi kan også skrive en rask funksjon for nå. Modernizrs "Non-Core Detects" inkluderer et alternativ for "forms-validering", så du må bygge en tilpasset nedlasting. Når du har satt opp dette, bære nettlesere vil bli gitt klassen av skjema validering på html element. Du kan målrette dette formvalidation klassen for å forbedre skjemaet for å støtte nettlesere.
.formvalidation input [type = passord], .formvalidation input [type = submit] / * Skjul eller skjul inntastene dine og deaktiver peker-hendelser her * /
Siden :gyldig og :ugyldig pseudo-elementer vil bare fungere i støttende nettlesere, CSS som skjuler inngangene, er det eneste CSS vi trenger for å bruke progressiv forbedring med. Inngangene vil fungere med standardfunksjonen i ikke-støttende nettlesere.
Du har nå noen kule måter å ta skjemaene dine til et nytt nivå av interaktiv samtalemodell med brukerne. Hvilke andre kraftige ting har du tenkt å bruke :gyldig og :ugyldig pseudoklasser? Snakk om det i kommentarene!
