Online formulieren zijn een van de lastigste gebieden van website-ontwikkeling om goed te krijgen, vooral met zoveel dingen die fout kunnen gaan. De veranderende aard van hoe mensen toegang hebben tot online content heeft ook een impact gehad op een technologie die jaren geleden werd ontwikkeld voordat mensen verwachtten dat ze met een telefoon konden doen wat ze normaal gesproken alleen met een computer zouden doen. Het is een technologie die weinig evolutie heeft doorgemaakt.
Het ontwerp van webformulieren moet een zelfstandig beroep zijn. Siteontwerpers moeten fulltime professionele webformulierontwerpers inschakelen om hen te helpen bij hun taak. Maar dit wordt niet als zuinig genoeg gezien, en dus is de ontwerper van de site ook verantwoordelijk voor het ontwerp van alle formulieren die op de site worden gebruikt.
Maar het ontwerpen van vormen is een zeer specialistische vaardigheid. Het vereist inzicht in hoe mensen omgaan met informatie en inzicht in de beste manieren om te verzamelen en te presenteren information. Waar algemeen webdesign vooral draait om presenteren information en afbeeldingen op aantrekkelijke maar praktische manieren, vormontwerp vereist dat we onze aandacht richten op de aard van het information en bepaal vervolgens de beste manier om het op de pagina te structureren, zodat het werkt zoals bedoeld. Esthetiek is in dit geval een minder belangrijke overweging, maar zou dat nog steeds niet moeten zijngotten.
In dit artikel bekijken we de kunst van webformulierontwerp en kijken of we een manier kunnen vinden om onze webformulieren slimmer te maken, zowel in termen van hoe ze eruit zien als hoe ze werken.
De hulpmiddelen voor het bouwen van webformulieren
De standaardhulpmiddelen die we hebben gekregen van browserontwikkelaars en W3C om onze webformulieren bij elkaar te zetten, zijn niet bepaald ideaal en voordat ze CSS op hen toepassen, zijn ze eigenlijk nogal afgrijselijk. Dit is hoe ze eruit zien:
Er is ook een andere standaard invoerbesturing genaamd kiezen, maar u moet dit vermijden, tenzij het sparen van ruimte een ernstige zorg is. Er zijn betere manieren om de taak uit te voeren die door het select-besturingselement wordt uitgevoerd, zoals we later zullen bespreken. Textarea-controles moeten ook worden vermeden wanneer mogelijk omdat ze zo problematisch en antiquair zijn.
Naast deze standaard invoeritems zijn er ook speciale nieuwe items gemaakt voor HTML5. Behalve wanneer een document strikt wordt voorbereid voor intern gebruik en de browseromgeving bekend is, mogen alleen componenten worden gebruikt die zowel in Firefox als Chrome werken. Het is goed als een component ook in andere browsers werkt, maar dat zou niet moeten Slechts werken in andere browsers. Dit zijn de HTML5-componenten die in Firefox verschijnen:
En hun iets andere uiterlijk in Chrome:
Nu is het natuurlijk heel belangrijk om je ervan bewust te zijn dat je HTML5-ingangen er anders uitzien en anders zullen werken tussen Chrome en Firefox, maar ze zullen nog steeds werken. De standaard invoerbesturingselementen zien er in Chrome ook een beetje mooier uit dan in Firefox. Merk op dat Chrome de Noord-Amerikaanse datumnorm oplegt, die gebruikers misschien niet waarderen. Ook de Chrome-versie van het datumbesturingselement maakt het ongeschikt voor weergave en zou alleen voor invoer moeten worden gebruikt. De toevoeging van een datumkiezer is de belangrijkste verbetering in Chrome, maar we kunnen dit waarschijnlijk verwachten in toekomstige versies van Firefox.
Omdat Firefox open source is, kunt u uw eigen persoonlijke versie van Firefox de invoer op dezelfde manier laten renderen als Chrome doet door de broncode van de open source Chromium-browser waarop Chrome is gebaseerd te downloaden en het relevante gedeelte van de code naar de Firefox-bron te porteren code (maar dan moet je dat telkens doen als je Firefox bijwerkt naar een nieuwe versie).
Het belangrijkste punt is echter dat, zelfs met de verbeteringen van Chrome, het standaard uiterlijk van invoerbesturingselementen klein en onaantrekkelijk is. Er zijn een paar andere besturingselementen beschikbaar, maar omdat ze niet werken in zowel Chrome als Firefox, mogen ze niet worden gebruikt op sites die bedoeld zijn voor het publiek.
Bootstrap's (bijna voldoende) antwoord
Bootstrap past styling toe op de standaardbesturingselementen die hun uiterlijk tot op zekere hoogte verbeteren. Maar vanwege Bootstrap's mobielgerichte ontwerpfilosofie, veroorzaakt het enkele ongewenste effecten op formulieren die niet bedoeld zijn om te worden weergegeven als een enkele kolom, en maakt korte invoervelden er grappig uit wanneer ze standaard een hele kolom omspannen. De wereld is misschien mobiel geworden, maar formulieren zijn niet uitgevonden met mobiele gebruikers in gedachten.
Bootstrap breidt de bedieningselementen uit om de horizontale breedte van hun container te vullen, wat betekent dat alle bedieningselementen dezelfde breedte hebben, ongeacht of u het leuk vindt of niet (tenzij u dit gedrag handmatig overschrijft), en stelt u in staat om bepaalde besturingstypen met extra bling aan te kleden. Bootstrap's oplossing is elegant en overwint een aantal van de problemen van besturingselementen met verschillende verschijningen in verschillende browsers, maar het werkt alleen met de standaardbesturingselementen. De HTML5-besturingselementen zijn niet geรฏmplementeerd in de huidige versie van Bootstrap, dus je moet ze zelf stylen.
Met Bootstrap kunt u ook de bedieningselementen combineren. Soms is dit goed en soms niet zo goed. Het combineren van een tekstinvoer met een knop en een selectievakje ziet er misschien goed uit, maar het kan de gebruiker verwarren over hoe ze moeten omgaan met een dergelijke onbekende besturing.
Wat Bootstrap wel biedt, zijn twee van mijn favoriete vormgevende apparaten, de paneel en well. Deze zijn erg handig voor het groeperen van formuliergegevens om een โโvisuele indicatie te krijgen van welke gegevens gerelateerd zijn aan welke andere gegevens, en ook voor het scheiden van gegevens.
Smart Form Building 101 bouwen
Nu zijn we klaar om na te denken over hoe vormen slimmer kunnen worden geconstrueerd. Om dit te doen, moeten we ver voorbij de standaardwaarden denken. We moeten ons bewust zijn van de desktop-gebonden wortels van formulierbesturingselementen, en ook de behoefte aan mobiele compatibiliteit. En we moeten ons zorgen maken over zaken als bruikbaarheid en validatie (als het formulier wordt gebruikt voor gegevensverzameling).
Dat laatste punt is een goede, want hoewel formulierbesturingselementen worden gebruikt voor het verzamelen van invoer, worden ze ook gebruikt voor het weergeven van opgeslagen gegevens. De gemiddelde internetgebruiker is (en zou meer geรฏnteresseerd moeten zijn) om binnen te komenformatvan jou dan toegevenformatie voor jou.
Het verzamelen van gegevens is eenvoudig. Mensen zullen alles invullen wat je voor hen neerzet, zelfs als het een puinhoop is. Maar als het gaat om gegevensweergave, zijn ze kieskeuriger. Daarom zullen we ons hier meer richten op het gebruik van formulieren om gegevens weer te geven dan op het verzamelen ervan, aangezien weergave meer zorg en meer 'slimheid' vereist.
1. Hebben we een formulier nodig?
Voordat we een formulier maken, moeten we controleren of we er echt een nodig hebben. Als de gegevens adequaat en onfeilbaar als een tabel kunnen worden weergegeven, zal een tabel meestal efficiรซnter en praktischer zijn.
Een formulier is nodig als:
- We verzamelen input van de gebruiker
- We hebben veel gegevens om weer te geven
- De gegevens moeten duidelijk worden gesegmenteerd
- De gebruiker heeft waarschijnlijk toegang tot de gegevens vanaf een mobiel apparaat
Als een van de bovenstaande items niet waar is, is het niet nodig om een โโformulier te gebruiken en is een tabel voldoende. De uitdaging voor mobiele compatibiliteit is dat tabellen en formulieren niet echt geschikt zijn voor een mobiel scherm. Het feit dat smartphone-ontwerpers hun gebruikers de mogelijkheid gaven om een โโbrowser in portretoriรซntatie te gebruiken en dat de meeste gebruikers hun telefoons op die manier willen houden, veroorzaakt de meeste problemen met de mobiele compatibiliteit waar ontwerpers van de site mee te maken hebben.
Hoe dan ook, formulieren zijn beter aanpasbaar aan een mobiel display dan tafels. Dus als u er echt voor moet zorgen dat alle gegevens gemakkelijk op een mobiel display kunnen worden bekeken, dan zijn formulieren een betere keuze dan tabellenโฆ soms!
2. Ontwerp de desktop lay-out
Het klopt dat je in het algemeen eerst een mobiele lay-out moet ontwerpen, maar als het gaat om formulieren, is dat niet de beste manier, omdat we moeten weten hoe gegevens worden gegroepeerd, en dat kunnen we alleen als we kan alle velden tegelijkertijd bekijken, iets wat niet op een mobiel kan worden gedaan, tenzij u zo weinig gegevens weergeeft dat we ons niet bezig hoeven te houden met het ontwerpen van het formulier.
De snelste manier om een โโformulierontwerp te maken, is met InkScape. In dit voorbeeld bouwen we een systeem voor het beheren van HR-records. Hier is de mock-up voor de desktop prototype:
De buitenste rechthoek vertegenwoordigt de volledige ruimte van een scherm van 1024 x 768 px. Op elke desktop browser hebben we geen toegang tot zoveel pixels, tenzij de gebruiker zich in de modus Volledig scherm bevindt (wat zelden het geval is). Zo onze
ontwerp is 900 x 600px, wat zou moeten passen in het beschikbare gebied van de meeste desktop -schermen.
Wanneer het beschikbare gebied kleiner is dan 900px breed, zullen onze 2 x 450px-kolommen breken en worden weergegeven als รฉรฉn ononderbroken 450px-kolom. Dit lost het probleem van mobiele compatibiliteit op, in ieder geval totdat Google eist dat we al onze sites geschikt maken voor weergave op een polshorloge.
U zult merken dat het grootste deel van het display alleen uit gewone invoerdozen bestaat, wat misschien saai lijkt, maar in werkelijkheid is dit bijna altijd de beste manier om het te doen. Let ook op het gebruik van een lettertype met een vaste breedte. Dit helpt uniformiteit te behouden bij het ontwerpen van formulieren.
Onze kolommen zullen in feite iets meer zijn dan 450px, meer zoals elk 600px, maar als we de kolombreedte zouden willen dwingen over 450px, verkleinen we gewoon onze kolomgrootte van 6 naar 5. Maar een 600px-kolom zou in elk geval op een mobiel scherm in portretmodus moeten passen zonder te wikkelen.
We zullen onze layout testen met deze code:
En we kunnen zien dat alles er goed uitziet (omdat we tijdelijk grenzen hebben toegevoegd om ons dat te laten zien).
De linoliner-widget van Linux is duidelijk geen onderdeel van de webpagina, maar is er om ons te laten zien dat onze kolommen niet slecht zullen breken op een kleiner scherm. Laten we eens kijken wat er gebeurt bij verschillende algemene schermbreedten:
3. Aangepaste invoerformaten en labelpositie maken
Als we alles standaard laten staan, zonder aangepaste CSS toe te voegen, is dit wat er gebeurt als we onze eerste rij invoerbesturingselementen toevoegen:
Dit gebeurt omdat het label voor elke invoer standaard links van de invoer staat en omdat we geen aangepaste breedte voor de invoerbesturingselementen hebben ingesteld. We kunnen beide problemen met CSS oplossen.
Nu zetten we gewoon de weergave-eigenschap van labelelementen op "block", stellen we de velden First en Last in op class "in40w" en veld MI op class "in10w", en alles zou er veel mooier uit moeten zien.
Zoals je ziet, ziet het er beter uit, maar de lay-out is niet langer correct. Nu zijn de dozen gestapeld. Dus hoe we dit oplossen, is door het idee van het gebruik van het labelelement helemaal af te schaffen, omdat we dat niet echt nodig hebben. We zullen onze in40w en in10w klassen, plus maak een nieuwe klasse genaamd inLeftOf.
Wat, eenmaal toegepast, het probleem oplost dat we eerder zagen, zoals dit:
Maar dit laat niet genoeg ruimte over voor het SSN-veld. Dat komt omdat onze linkerkolom groter is dan verwacht, dus 40% is eigenlijk meer ruimte dan we voor deze velden nodig hebben, dus we kunnen ze echt verlagen tot in30wen het middelste veld is groter dan het moet zijn, dus we kunnen dat maken in5w. Dit is wat er gebeurt:
Dus nu is er meer dan genoeg ruimte om het SSN-veld toe te voegen, waarmee de eerste regel van ons invoerformulier wordt ingevuld. Na het gladstrijken van al deze details, zou het bouwen van de rest van de linkerkolom zeer eenvoudig moeten zijn. We kunnen nu de tijdelijke grens verwijderen en de juiste achtergrond van de kolom toepassen. Hier is de bovenste helft van het paneel, voordat we bij speciale gebieden van het formulier komen:
Een paar dingen zijn in deze fase gebeurd. De eerste was het makkelijke deel van het instellen van de achtergrondkleur voor de kolom (rgb (235,235,246)), en hoewel je het hier niet kunt zien, is de tekstkleur voor alle ingangen ingesteld op #427DB4 en het lettertype-gewicht was ingesteld op vet om minder inspanning te leveren. De tekst is zo ingesteld dat deze automatisch in hoofdletters wordt omgezet met behulp van de CSS-teksttransformatie-eigenschap, om de gegevensinvoer te versnellen en fouten te verminderen.
De meer complexe kwestie van het uitlijnen van de bedieningselementen en ervoor zorgen dat ze een goede uitlijning zouden behouden op elk weergavetype, vereiste meer aandacht. U hebt de techniek al gezien die werd gebruikt voor de eerste regel invoer en hun labels. Deze techniek werkt als er geen extra afstand tussen de ingangen nodig is, maar als we ruimte nodig hebben, is het beter om een โโandere techniek te gebruiken.
Deze andere techniek omvat het maken van een geneste rij kolommen in onze hoofdkolom, wat zal helpen om de bedieningselementen op de juiste afstand te houden. Het aantal kolommen en hun grootte verandert afhankelijk van de vereisten van elke set besturingselementen. Onthoud dat alles is responsive, dus wanneer het formaat van een kolom wordt gewijzigd, zal alles in de kolom proberen het formaat aan te passen aan de wijziging. Dit is goed nieuws voor visueel gehandicapte gebruikers, omdat ze de vergroting op hun scherm kunnen vergroten en alles correct zal worden uitgelijnd zoals voor elke andere gebruiker.
Overgaand naar het meer complexe deel van de linkerkolom, riep het oorspronkelijke concept dat in de mock-up werd geschetst op tot een structuur die moeilijk te implementeren was. Gelukkig besefte ik dat de gegevens van het paneel Rechten kunnen worden verdubbeld als standaard selectievakjes werden gebruikt, en dit loste het problemen met de layoutcomplexiteit op:
De lichtere panelen rond de speciale secties zijn gewone Bootstrap-putten. Voor het invoeren van religiegegevens is het noodzakelijk om te kiezen uit een vaste lijst van vooraf gedefinieerde officiรซle religies (inclusief "overige"). Het ontwikkelen van de rechterkolommen was nog eenvoudiger en gebruikte gewoon dezelfde technieken uit de eerste set besturingselementen in de linkerkolom, waarbij de besturingselementen in een tabel werden geordend format, maar zonder een tabel te gebruiken.
Om dit project tot een succes te maken, moest het perfect zijn responsiveness op alle officiรซle schermformaten. Laten we eens kijken hoe het resultaat is geworden. Eerst met de versie met volledige resolutie:
Dat ligt dicht genoeg bij het prototype dat we er tevreden mee kunnen zijn. Sterker nog, het is zelfs een verbetering. Laten we nu eens kijken naar de responsive lay-out in elk van de verschillende secties van de pagina:
Bootstrap en HTML5 hebben de ontwikkeling van formulieren sneller en gemakkelijker gemaakt dan ooit tevoren, maar veel ontwikkelaars ondermijnen deze vooruitgang door formulieren te ingewikkeld te maken (de speciale HTML5-formulierelementen gebruiken alleen omdat ze er zijn om te worden gebruikt in plaats van omdat ze nodig zijn voor het project ), en door volledig eendimensionale vormen te creรซren die niet eens proberen te profiteren van responsive ontwerp. Met slechts een beetje zorg en extra werk, kunnen alle gegevens worden gemaakt om er beter uit te zien op elk schermformaat.
Op de kleinste schermgrootte kunt u een paar kleine foutjes krijgen in de kleinste schermgrootte in staande lay-out (in dit geval is het veld Middle Initial op de eerste rij iets kleiner dan ideaal zou zijn), maar mobiele gebruikers in het algemeen accepteer dat dit de wisselwerking is die ze moeten hebben om hun telefoons niet goed vast te houden.
Doe het goed, en uw gegevensformulieren kunnen er als volgt uitzien:
In plaats van, uh, dit:
header afbeelding met dank aan
Heb je vragen? Stel ze hier. 0 Reacties