Online-skjemaer er et av de vanskeligste områdene for utvikling av nettsteder for å komme riktig, spesielt med så mange ting som kan gå galt. Den endrede karakteren av hvordan folk får tilgang til nettinnhold, har også hatt innvirkning på en teknologi som ble utviklet år før folk forventet å kunne med en telefon det de normalt bare ville gjort med en datamaskin. Det er en teknologi som har gjennomgått veldig liten evolusjon.
Utforming av nettformer skal være et frittstående yrke. Nettstedsdesignere bør være engasjert i tjenester fra profesjonelle webformet designere på heltid for å hjelpe dem i oppgaven sin. Men dette blir ikke sett på som økonomisk nok, og det meste av tiden er nettsteddesigneren også ansvarlig for utformingen av alle former som brukes på nettstedet.
Men å designe skjemaer er en svært spesialisert ferdighet. Det krever å forstå hvordan folk samhandler med innformation og forstå de beste måtene å samle og presentere iformation. Der generell webdesign hovedsakelig er sentrert rundt presentasjon iformation og bilder på attraktive, men praktiske måter, formdesign krever at vi fokuserer vår oppmerksomhet på innsidens naturformation og deretter bestemme den beste måten å strukturere den på siden slik at den vil fungere etter hensikten. Estetikk er en mindre viktig vurdering i dette tilfellet, men bør fortsatt ikke være forgotten.
I denne artikkelen skal vi se på kunsten å lage webformdesign, og se om vi kan finne en måte å gjøre webformene våre smartere både når det gjelder hvordan de ser ut og hvordan de fungerer.
Verktøyene til bygging av nettformer
Standardverktøyene vi har fått av nettleserutviklere og W3C for å sette sammen webskjemaene våre er ikke helt ideelle, og før de bruker CSS på dem, er de faktisk ganske heslige. Slik ser de ut:
Det er også en annen standard inngangskontroll som heter velg, men du bør unngå å bruke dette med mindre det er en alvorlig bekymring å spare plass. Det er bedre måter å håndtere oppgaven utført av valgt kontroll, som vi vil diskutere senere. Textarea-kontroller bør også unngås når det er mulig fordi de er så problematiske og antikvariske.
I tillegg til disse standardinngangselementene er det også spesielle nye opprettet for HTML5. Bortsett fra når et dokument utarbeides strengt for intern bruk og der nettlesermiljøet er kjent, skal bare komponenter som fungerer i både Firefox og Chrome brukes. Det er bra hvis en komponent også fungerer i andre nettlesere, men det bør ikke bare arbeid i andre nettlesere. Her er HTML5-komponentene slik de vises i Firefox:
Og deres litt forskjellige utseende i Chrome:
Nå er det tydeligvis veldig viktig å være klar over at HTML5-inngangene dine vil se og fungere annerledes mellom Chrome og Firefox, men de vil fortsatt fungere. Standardinngangskontrollene ser også litt finere ut i Chrome enn i Firefox. Legg merke til at Chrome innfører den nordamerikanske datostandarden, noe brukerne kanskje ikke setter pris på. Også Chrome-versjonen av datokontrollen gjør den uegnet for visning, og bør bare brukes til inndata. Tillegg av en datovelger er den viktigste forbedringen i Chrome, men vi kan antagelig forvente å se dette i fremtidige versjoner av Firefox.
Fordi Firefox er åpen kildekode, kan du faktisk lage din egen personlige versjon av Firefox gjengi inngangene på samme måte som Chrome gjør ved å laste ned kildekoden for åpen kildekode i Chromium som Chrome er basert på, og portere den relevante delen av koden til Firefox-kilden kode (men da må du gjøre det hver gang du oppgraderer Firefox til en ny versjon).
Hovedpoenget er imidlertid at selv med Chrome-forbedringer, er standardutseendet til inngangskontroller lite og lite attraktivt. Det er noen få andre kontroller tilgjengelig, men fordi de ikke fungerer i både Chrome og Firefox, bør de ikke brukes på nettsteder som er ment for publikum.
Bootstraps (nesten tilstrekkelig) svar
Bootstrap bruker styling på standardkontrollene som forbedrer utseendet til en viss grad. Men på grunn av Bootstraps mobil-sentriske designfilosofi, forårsaker det noen uønskede effekter på skjemaer som ikke er ment å vises som en enkelt kolonne, og får korte innmatingsfelt til å se morsomme ut når de spenner over en hel kolonne som standard. Verden kan ha gått mobil, men skjemaer ble ikke oppfunnet med mobile brukere i tankene.
Bootstrap utvider kontrollene for å fylle den horisontale bredden på beholderen, noe som betyr at alle kontroller har samme bredde uansett om du vil eller ikke (med mindre du manuelt overkjører denne oppførselen), og lar deg kle på noen kontrolltyper med ekstra bling. Bootstraps løsning er elegant og overvinner noen av problemene med kontroller som har forskjellige utseende i forskjellige nettlesere, men den fungerer bare med standardkontrollene. HTML5-kontrollene implementeres ikke i nåværende versjoner av Bootstrap, så du må style dem på egen hånd.
Bootstrap lar deg også kombinere kontroller sammen. Noen ganger er dette bra og andre ganger ikke så bra. Det kan se bra ut å kombinere en tekstinndata med en knapp og en avkrysningsrute, men det kan forvirre brukeren til hvordan de skal samhandle med en så ukjent kontroll.
Det Bootstrap gir er to av mine favorittformbyggingsenheter, panel og godt. Disse er veldig nyttige for gruppering av skjemadata for å gi en visuell indikasjon på hvilke data som er relatert til hvilke andre data, og også for å skille data.
Smart formbygning 101
Nå er vi klare til å tenke på hvordan former kan konstrueres på smartere måter. For å gjøre dette, må vi tenke langt forbi standardverdiene. Vi må være klar over desktop-Bundte røttene til skjemakontroller, og også behovet for mobilkompatibilitet. Og vi må bry oss om ting som brukervennlighet og validering (hvis skjemaet skal brukes til datainnsamling).
Det siste punktet er bra, for mens skjemakontroller brukes til å samle inn input, brukes de også til å vise lagrede data. Den gjennomsnittlige nettbrukeren er (og burde være) mer interessert i å komme innformation fra deg enn å gi etterformation til deg.
Datainnsamling er enkelt. Folk vil fylle ut alt du holder deg foran, selv om det er et rot. Men når det gjelder datavisning, er de mer masete. Derfor vil vi her fokusere mer på bruk av skjemaer for å vise data enn å samle inn, siden visning krever mer forsiktighet og mer "smartness".
1. Trenger vi et skjema?
Før vi bygger et skjema, bør vi sjekke at vi faktisk trenger et. Hvis dataene kan være tilstrekkelig og uforvirrende representert som en tabell, vil en tabell vanligvis være mer effektiv og praktisk.
Et skjema er nødvendig hvis:
- Vi samler innspill fra brukeren
- Vi har mye data å vise
- Dataene må være tydelig segmentert
- Det er sannsynlig at brukeren får tilgang til dataene fra en mobil enhet
Hvis noen av elementene ovenfor ikke stemmer, er det ikke nødvendig å bruke et skjema, og en tabell vil være tilstrekkelig. Utfordringen vi står overfor med mobilkompatibilitet er at verken tabeller eller skjemaer virkelig egner seg til en mobil skjerm. Det faktum at smarttelefondesignere ga sine brukere muligheten til å bruke en nettleser i portrettorientering, og at de fleste brukere foretrekker å holde telefonene sine på den måten fører til at de fleste mobilkompatibilitetsproblemer nettsteddesignere må takle.
Uansett er skjemaer mer tilpassbare til en mobilskjerm enn tabeller. Så hvis du virkelig må sørge for at all data lett kan sees på en mobilskjerm, så er skjemaer et bedre valg enn tabeller ... noen ganger!
2. Design desktop layout
Det er sant at du generelt sett skal utforme en mobillayout først, men når det kommer til skjemaer, er det ikke den beste måten, fordi vi trenger å vite hvordan data skal grupperes, og vi kan bare gjøre det hvis vi kan se alle feltene på en gang, noe som ikke kan gjøres på en mobil med mindre du viser så lite data at vi ikke trenger å bry oss om å utforme skjemaet.
Den raskeste måten å håne opp et skjemadesign på er med InkScape. I dette eksemplet skal vi bygge et system for å administrere HR-poster. Her er mock up for desktop prototype:
Det ytre rektangelet representerer hele plassen til en 1024 x 768 px skjerm. På hvilken som helst desktop nettleser, vi har ikke tilgang til så mange piksler med mindre brukeren er i fullskjermmodus (noe som sjelden er tilfelle). Så vår
utformingen er 900 x 600 piksler, som bør passe i det tilgjengelige området for de fleste desktop skjermer.
Når det tilgjengelige området er mindre enn 900px bredt, vil våre 2 x 450px kolonner brytes og vises som en kontinuerlig 450px kolonne. Dette løser problemet med mobilkompatibilitet, i det minste til Google krever at vi gjør at alle nettstedene våre kan passe på en armbåndsur.
Du vil merke at det meste av skjermen bare er sammensatt av vanlige inputbokser, som kan virke kjedelige, men i virkeligheten er nesten alltid den beste måten å gjøre det på. Legg også merke til bruken av en skrift med fast bredde. Dette bidrar til å opprettholde ensartethet i formdesign.
Kolonnene våre vil faktisk være litt mer enn 450px, mer som 600px hver, men hvis vi ønsket å tvinge kolonnebredden til å være omtrent 450px, reduserer vi bare kolonnestørrelsen fra 6 til 5. Men en 600 px kolonne skal passe på en mobilskjerm i portrettmodus uten innpakning, uansett.
Vi tester oppsettet med denne koden:
Og vi kan se at alt ser bra ut (fordi vi midlertidig la grenser for å vise oss).
Linux-skjermlinjalwidgeten er åpenbart ikke en del av websiden, men den er der for å vise oss at kolonnene våre ikke vil gå brakk på et mindre skjerm. La oss gjøre hva som skjer med forskjellige vanlige skjermbredder:
3. Opprette tilpassede inputstørrelser og etikettposisjon
Hvis vi bare lar alt være som standard, uten å legge til noe tilpasset CSS, er det dette som vil skje når vi legger til vår første rad med inngangskontroller:
Dette skjer fordi etiketten for hver inngang er standard til venstre for inngangen, og fordi vi ikke har angitt en tilpasset bredde for inngangskontrollene. Vi kan fikse begge problemene med CSS.
Nå setter vi bare visningsegenskapene til etikettelementer til "blokkere", setter feltene Første og Siste til klasse "in40w" og felt MI til klasse "in10w", og alt skal se mye bedre ut.
Som du ser ser det bedre ut, men oppsettet er ikke lenger riktig. Nå er boksene stablet. Så hvordan vi fikser det er ved å fjerne bort ideen om å bruke etikettelementet i det hele tatt, fordi vi ikke egentlig trenger det. Vi bruker bare vårt i 40w og i 10w klasser, pluss lage en ny klasse som heter inLeftOf.
Som en gang har løst problemet vi så tidligere, slik:
Men dette gir ikke nok rom for SSN-feltet. Det er fordi venstre kolonne er større enn forventet, så 40% er faktisk mer plass enn vi trenger for disse feltene, slik at vi faktisk kan kutte dem ned til i 30w, og midtfeltet er større enn det trenger å være, så vi kan lage det i 5w. Her er hva som skjer:
Så nå er det mer enn nok plass til å legge til SSN-feltet, som fullfører den første linjen i inndataformen vår. Etter å ha glattet ut alle disse detaljene, bør det være veldig enkelt å bygge resten av venstre kolonne. Vi kan kvitte oss med den midlertidige grensen nå, og også bruke riktig bakgrunn på kolonnen. Her er den øverste halvdelen av panelet, før vi kommer til spesielle områder av skjemaet:
Noen få ting har skjedd på dette stadiet. Den første var den enkle delen av å stille inn bakgrunnsfargen for kolonnen (rgb (235,235,246)), og selv om du ikke kan se den her, har tekstfargen for alle inngangene blitt satt til # 427DB4, og skriftvekten var satt til å være fet for å redusere belastningen på øynene. Teksten ble satt til å automatisk transformere til store bokstaver ved hjelp av CSS-teksttransformasjonsegenskapen, for å øke hastigheten på datainnføring og redusere feil.
Det mer komplekse spørsmålet om å justere kontrollene og sørge for at de vil holde en anstendig justering på hvilken som helst skjermtype, krever mer ettertanke. Du har allerede sett teknikken som ble brukt for den første linjen med innganger og etiketter på dem. Denne teknikken fungerer når det ikke trenger å være noen ekstra avstand mellom inngangene, men hvis vi trenger å legge til plass, er det bedre å bruke en annen teknikk.
Denne andre teknikken innebærer å lage en nestet rad med kolonner inne i hovedkolonnen vår, som vil bidra til å holde kontrollene på riktig avstand. Antall kolonner og deres størrelser endres avhengig av kravene til hvert sett med kontroller. Husk at alt er responsive, så når størrelsen på en kolonne endres, vil alt i kolonnen prøve å endre størrelsen for å matche endringen. Dette er gode nyheter for synshemmede brukere, ettersom de kan zoome opp forstørrelsen på skjermen og alt vil være riktig stilt opp som for alle andre brukere.
For å gå videre til den mer komplekse delen av venstre kolonne, ba det originale konseptet som ble skissert i mock-up for en struktur som ville vært vanskelig å implementere. Heldigvis innså jeg at dataene på rettighetspanelet kunne dobles opp hvis standard avkrysningsbokser ble brukt, og dette løste layoutkompleksitetsproblemet pent:
De lettere panelene rundt spesialseksjonene er bare vanlige Bootstrap-brønner. For å legge inn religionsdata er det nødvendig å velge fra en sett liste over forhåndsdefinerte offisielle religioner (inkludert "andre"). Å utvikle kolonnene på høyre side var enda enklere, og brukte bare de samme teknikkene fra det første settet med kontroller i venstre kolonne, og organiserte kontrollene i en tabell format, men uten bruk av bord.
For at dette prosjektet skulle bli en suksess, måtte det gi perfekt responsiveness på alle offisielle skjermstørrelser. La oss se hvordan resultatet ble. Først med fulloppløsningsversjonen:
Det er nær nok til prototypen til at vi kan være fornøyd med den. Faktisk er det til og med en forbedring. La oss nå se responsive layout på hver av de forskjellige delene av siden:
Bootstrap og HTML5 har gjort skjemautvikling raskere og enklere enn før, men mange utviklere undergraver denne fremgangen ved å gjøre skjemaer for kompliserte (ved å bruke de spesielle HTML5-skjemaelementene bare fordi de er der for å brukes i stedet for fordi de er nødvendige for prosjektet ), og ved å lage helt endimensjonale former som ikke en gang prøver å dra nytte av responsive design. Med bare litt forsiktighet og ekstra arbeid, kan alle data gjøres til å se mer presentable ut på alle skjermstørrelser.
Det kan hende du får noen få små glitches på den minste skjermstørrelsen i portrettoppsett på den minste skjermstørrelsen (i tilfelle av dette prosjektet er feltet Middle Initial på første rad litt mindre enn det som ville vært ideelt), men mobile brukere generelt aksepterer at dette er avveiningen de må gjøre for at de ikke holder telefonene sine ordentlig.
Gjør det riktig, og dataformene dine kan se slik ut:
I stedet for, åh, dette:
header image med tillatelse fra
Kommentar 0 Responses