Onlineformularer er et af de mest vanskelige områder inden for webstedsudvikling for at komme rigtigt, især med så mange ting, der kan gå galt. Den skiftende karakter af, hvordan folk får adgang til onlineindhold, har også haft indflydelse på en teknologi, der blev udviklet mange år, før folk forventede at kunne med en telefon, hvad de normalt kun ville gøre med en computer. Det er en teknologi, der har gennemgået meget lidt evolution.
Design af webformularer skal være et selvstændigt erhverv. Webstedsdesignere skulle være engagerende i tjenester af professionelle webformedesignere på fuld tid til at hjælpe dem i deres opgave. Men dette betragtes ikke som økonomisk nok, og derfor er site designer oftest ansvarlig for design af alle former, der bruges på webstedet.
Men at designe formularer er en højt specialiseret færdighed. Det kræver forståelse for, hvordan mennesker interagerer med indeformation og forståelse af de bedste måder at indsamle og præsentere iformation. Hvor generelt webdesign hovedsageligt er centreret omkring præsentation iformation og billeder på attraktive, men praktiske måder, formdesign kræver, at vi fokuserer vores opmærksomhed på indets naturformation og derefter beslutte den bedste måde at strukturere den på siden, så den fungerer efter hensigten. Æstetik er en mindre vigtig overvejelse i dette tilfælde, men bør stadig ikke være forgotten.
I denne artikel skal vi se på kunsten at forme webform og se, om vi kan finde en måde at gøre vores webformer smartere på både med hensyn til hvordan de ser ud og hvordan de fungerer.
Værktøjer til webform bygning
De standardværktøjer, som browserudviklere og W3C har fået til at sammensætte vores webformularer, er ikke nøjagtigt ideelle, og før de anvender CSS på dem, er de faktisk ret grusomme. Sådan ser de ud:
Der er også en anden standardindgangskontrol kaldet Vælg, men du bør undgå at bruge dette, medmindre det er et alvorligt problem at spare plads. Der er bedre måder at håndtere den opgave, der udføres af den valgte kontrol, som vi vil diskutere senere. Textarea-kontrol bør også undgås, når det er muligt, fordi de er så problematiske og antikvariske.
Ud over disse standardinputelementer er der også specielle nye oprettet til HTML5. Bortset fra når et dokument forberedes strengt til intern brug, og hvor browsermiljøet er kendt, skal kun komponenter, der fungerer i både Firefox og Chrome, bruges. Det er godt, hvis en komponent også fungerer i andre browsere, men det bør ikke kun arbejde i andre browsere. Her er HTML5-komponenterne, som de vises i Firefox:
Og deres lidt anderledes udseende i Chrome:
Nu er det naturligvis meget vigtigt at være opmærksom på, at dine HTML5-indgange vil se og fungere forskelligt mellem Chrome og Firefox, men de fungerer stadig. Standardindgangskontrollerne ser også lidt pænere ud i Chrome end i Firefox. Bemærk, at Chrome indfører den nordamerikanske datostandard, som brugerne muligvis ikke værdsætter. Også Chrome-versionen af datostyringen gør den uegnet til visning og bør kun bruges til input. Tilføjelsen af en datovælger er den største forbedring i Chrome, men vi kan sandsynligvis forvente at se dette i fremtidige versioner af Firefox.
Da Firefox er open source, kan du faktisk lave din egen personlige version af Firefox gengive inputene på samme måde som Chrome gør ved at downloade den åbne kildekode Chromium-kildekode, som Chrome er baseret på, og porte det relevante afsnit af koden til Firefox-kilden kode (men så skal du gøre det hver gang du opgraderer Firefox til en ny version).
Hovedpointen er imidlertid, at selv med Chromes forbedringer, er inputudstyrets standardudseende lille og uattraktiv. Der er et par andre kontroller tilgængelige, men fordi de ikke fungerer i både Chrome og Firefox, skal de ikke bruges på websteder, der er beregnet til offentligheden.
Bootstraps (næsten passende) svar
Bootstrap anvender styling på standardkontrollerne, der forbedrer deres udseende til en vis grad. Men på grund af Bootstraps mobil-centriske designfilosofi forårsager det nogle uønskede effekter på formularer, der ikke er beregnet til at blive vist som en enkelt kolonne, og får korte inputfelter til at se sjove ud, når de som standard spænder over en hel kolonne. Verden er muligvis gået mobil, men formularer blev ikke opfundet med mobilbrugere i tankerne.
Bootstrap udvider kontrollerne for at udfylde den vandrette bredde på deres container, hvilket betyder, at alle kontroller har samme bredde, uanset om du kan lide det eller ej (medmindre du manuelt overkører denne opførsel), og giver dig mulighed for at pynte nogle kontroltyper med yderligere bling. Bootstraps løsning er elegant og overvinder nogle af problemerne med kontroller, der har forskellige optrædener i forskellige browsere, men den fungerer kun med standardkontrollerne. HTML5-kontrollerne implementeres ikke i nuværende versioner af Bootstrap, så du bliver nødt til at style dem på egen hånd.
Bootstrap giver dig også mulighed for at kombinere kontroller sammen. Nogle gange er dette godt og undertiden ikke så godt. Kombination af en tekstindtastning med en knap og et afkrydsningsfelt kan se godt ud, men det kan forvirre brugeren til, hvordan de skal interagere med en sådan ukendt kontrol.
Hvad Bootstrap tilbyder er to af mine foretrukne bygningsindretninger, panel og godt. Disse er meget nyttige til gruppering af formdata for at give en visuel indikation af, hvilke data der er relateret til hvilke andre data, og også til at adskille data.
Smart formbygning 101
Nu er vi klar til at tænke over, hvordan former kan konstrueres på smartere måder. For at gøre dette skal vi tænke langt forbi standardindstillingerne. Vi skal være opmærksomme på desktop-bundne rødder af formularkontroller, og også behovet for mobil kompatibilitet. Og vi skal bekymre os om ting som brugervenlighed og validering (hvis formularen skal bruges til dataindsamling).
Det sidste punkt er godt, for mens formularkontroller bruges til at indsamle input, bruges de også til at vise lagrede data. Den gennemsnitlige webbruger er (og burde være) mere interesseret i at komme indformation fra dig end at give efterformation til dig.
Dataindsamling er let. Folk udfylder alt, hvad du holder dig foran, selvom det er et rod. Men når det kommer til datavisning, er de mere kræsen. Derfor vil vi her fokusere mere på brugen af formularer til at vise data end at indsamle dem, da skærm kræver mere omhu og mere "smartness".
1. Har vi brug for en formular?
Inden vi bygger en formular, skal vi kontrollere, at vi faktisk har brug for en. Hvis dataene kan repræsenteres tilstrækkeligt og uforvirrende som en tabel, vil en tabel normalt være mere effektiv og praktisk.
En formular er nødvendig, hvis:
- Vi indsamler input fra brugeren
- Vi har en masse data at vise
- Dataene skal være tydeligt segmenteret
- Det er sandsynligt, at brugeren får adgang til dataene fra en mobilenhed
Hvis nogen af ovenstående punkter ikke er sandt, er det ikke nødvendigt at bruge en formular, og en tabel vil være tilstrækkelig. Udfordringen, vi står over for med mobilkompatibilitet, er, at hverken tabeller eller formularer virkelig er egnet til en mobil skærm. Det faktum, at smartphone-designere gav deres brugere mulighed for at bruge en browser i portrætorientering, og at de fleste brugere foretrækker at holde deres telefoner på den måde forårsager de fleste af de mobile kompatibilitetsproblemer, som webstedsdesignere er nødt til at klare.
Uanset hvad er formularer mere tilpasselige til en mobil skærm end tabeller. Så hvis du virkelig skal sikre dig, at alle data let kan ses på en mobilskærm, er formularer et bedre valg end tabeller ... nogle gange!
2. Design desktop layout
Det er sandt, at man generelt skal udforme et mobilt layout først, men når det kommer til formularer, er det ikke den bedste måde, fordi vi har brug for at vide, hvordan data skal grupperes, og det kan vi kun gøre, hvis vi kan se alle felterne på én gang, hvilket er noget, der ikke kan udføres på en mobil, medmindre du viser så lidt data, at vi ikke behøver at gider med at designe formularen.
Den hurtigste måde at håne et formulardesign på er med InkScape. I dette eksempel bygger vi et system til styring af HR-registreringer. Her er mock up for desktop prototype:
Det udvendige rektangel repræsenterer hele rummet på en 1024 x 768 px skærm. På enhver desktop browser, har vi ikke adgang til så mange pixels, medmindre brugeren er i fuldskærmstilstand (hvilket sjældent er tilfældet). Så vores
design er 900 x 600px, hvilket burde passe i det tilgængelige område for de fleste desktop skærme.
Når det tilgængelige område er mindre end 900px bredt, brydes vores 2 x 450px kolonner og vises som en kontinuerlig 450px kolonne. Dette løser problemet med mobilkompatibilitet, i det mindste indtil Google kræver, at vi gør alle vores websteder i stand til at passe på en armbåndsur.
Du vil bemærke, at det meste af skærmen bare er sammensat af almindelige inputbokse, som kan virke kedelige, men i virkeligheden er næsten altid den bedste måde at gøre det på. Bemærk også brugen af en font med fast bredde. Dette hjælper med at bevare ensartethed i formdesign.
Vores kolonner vil faktisk være lidt mere end 450 px, mere som 600 px hver, men hvis vi ville tvinge søjlebredden til at være omkring 450 px, reducerer vi bare vores kolonnestørrelse fra 6 til 5. Men en 600 px kolonne skulle passe på en mobilskærm i portrættilstand uden indpakning alligevel.
Vi tester vores layout med denne kode:
Og vi kan se, at alt ser godt ud (fordi vi midlertidigt tilføjede grænser for at vise os).
Linux-skærmlinealwidget er tydeligvis ikke en del af websiden, men den er der for at vise os, at vores kolonner ikke går i stykker på et mindre display. Lad os hvad der sker med forskellige almindelige skærmbredder:
3. Oprettelse af tilpassede inputstørrelser og etiketposition
Hvis vi bare forlader alt som standard, uden at tilføje noget tilpasset CSS, er det dette, der vil ske, når vi tilføjer vores første række af inputkontroller:
Dette sker, fordi etiketten for hver input er standard til venstre for inputen, og fordi vi ikke har indstillet en brugerdefineret bredde til inputkontrollerne. Vi kan løse begge problemer med CSS.
Nu indstiller vi bare visningsegenskaben for etiketelementer til "blok", indstiller felterne Første og Sidste til klasse "in40w" og felt MI til klasse "in10w", og alt skal se meget pænere ud.
Som du kan se, ser det bedre ud, men layoutet er ikke længere korrekt. Nu er kasserne stablet. Så hvordan vi løser det, er ved at fjerne ideen om at bruge etiketelementet overhovedet, fordi vi ikke virkelig har brug for det. Vi anvender bare vores i40w , i10w klasser, plus lav en ny klasse kaldet inLeftOf.
Som, når den først blev anvendt, løser problemet, vi så tidligere, som dette:
Men dette giver ikke plads nok til SSN-feltet. Det skyldes, at vores venstre kolonne er større end forventet, så 40% er faktisk mere plads end vi har brug for til disse felter, så vi faktisk kan skære dem ned til i30w, og det midterste felt er større, end det skal være, så vi kan gøre det i5w. Her er hvad der sker:
Så nu er der mere end nok plads til at tilføje SSN-feltet, der udfylder den første linje i vores inputformular. Når du har udjævnet alle disse detaljer, skal det være meget let at bygge resten af venstre kolonne. Vi kan slippe af med den midlertidige grænse nu og også anvende den rigtige baggrund på kolonnen. Her er den øverste halvdel af panelet, inden vi kommer til særlige områder af formen:
Et par ting er sket på dette trin. Den første var den lette del af indstillingen af baggrundsfarve for kolonnen (rgb (235,235,246)), og selvom du ikke kan se den her, er tekstfarven for alle input blevet indstillet til # 427DB4, og fontvægten blev indstillet til at være fed med det formål at reducere øjenbelastningen. Teksten blev indstillet til automatisk at transformere til store bogstaver ved hjælp af CSS-tekst-transform-egenskaben for at fremskynde dataindtastning og reducere fejl.
Det mere komplekse spørgsmål om justering af kontrollerne og at sikre, at de holder en anstændig justering på enhver skærmtype krævede mere tanke. Du så allerede teknikken, der blev brugt til den første linje med input og deres etiketter. Denne teknik fungerer, når der ikke behøver at være nogen yderligere afstand mellem input, men hvis vi har brug for at tilføje plads, er det bedre at bruge en anden teknik.
Denne anden teknik involverer at skabe en indlejret række af kolonner inde i vores hovedkolonne, som vil hjælpe med at holde kontrollerne korrekt fordelt. Antallet af kolonner og deres størrelser ændres afhængigt af kravene til hvert sæt kontrolelementer. Husk alt er responsive, så når størrelsen på en kolonne ændres, vil alt inde i kolonnen forsøge at ændre størrelsen for at matche ændringen. Dette er gode nyheder for synshandicappede brugere, da de kan zoome forstørrelsen op på deres skærm, og alt vil blive stillet korrekt op som for enhver anden bruger.
For at gå videre til den mere komplekse del af venstre kolonne krævede det originale koncept, der blev skitseret i mock-up, en struktur, der ville have været svært at implementere. Heldigvis indså jeg, at dataene på rettighedspanelet kunne blive fordoblet, hvis der blev anvendt standard afkrydsningsfelter, og dette løste layoutkompleksitetsproblemet pænt:
De lettere paneler omkring specialsektionerne er blot almindelige Bootstrap-brønde. For at indtaste religionsdata er det nødvendigt at vælge fra en sæt liste over foruddefinerede officielle religioner (inklusive "andre"). Det var endnu nemmere at udvikle kolonnerne i højre side, og man brugte bare de samme teknikker fra det første sæt kontrolelementer i venstre kolonne, og organiserede kontrollerne i en tabel format, men uden brug af bord.
For at dette projekt skulle blive en succes, skulle det give perfekt responsiveness på alle officielle displaystørrelser. Lad os se, hvordan resultatet blev. Først med versionen i fuld opløsning:
Det er tæt nok på prototypen til, at vi kan være tilfredse med den. Faktisk er det endda en forbedring. Lad os nu se responsive layout på hver af de forskellige sektioner af siden:
Bootstrap og HTML5 har gjort formularudvikling hurtigere og nemmere end alle før, men mange udviklere underminerer disse fremskridt ved at gøre formularer for komplicerede (ved at bruge de specielle HTML5 formularelementer, bare fordi de er der for at blive brugt i stedet for fordi de er nødvendige for projektet ), og ved at skabe helt endimensionelle former, som ikke engang forsøger at udnytte responsive design. Med bare lidt omhu og ekstra arbejde kan alle data fås til at se mere præsentable ud på enhver skærmstørrelse.
Du kan få et par mindre fejl på den mindste skærmstørrelse i portrætlayout på den mindste skærmstørrelse (i tilfælde af dette projekt er det midterste startfelt på den første række lidt mindre, end det ville være ideelt), men mobile brugere generelt accepterer, at dette er den afvejning, de er nødt til at gøre for ikke at holde deres telefoner korrekt.
Gør det rigtigt, og dine dataformularer kan se sådan ud:
I stedet for, åh, dette:
header image med tilladelse fra
Kommentarer 0 Responses