De zoektocht naar slimmere webformulieren

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 gespecialiseerde vaardigheid. Het vereist inzicht in hoe mensen omgaan met informatie en inzicht krijgen in de beste manieren om informatie te verzamelen en te presenteren. Waar algemeen webontwerp voornamelijk is gericht op het presenteren van informatie en afbeeldingen op aantrekkelijke maar praktische manieren, vereist vormontwerp dat we onze aandacht richten op de aard van de informatie en vervolgens beslissen hoe deze op de pagina het beste kan worden gestructureerd, zodat deze zal werken zoals de bedoeling was. Esthetiek is in dit geval een minder belangrijke overweging, maar moet toch niet worden vergeten.

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 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 de goed. 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 op slimmere manieren kunnen worden geconstrueerd. Om dit te doen, moeten we goed nadenken over de standaardwaarden. We moeten ons bewust zijn van de op de desktop gebaseerde wortels van formulierbesturingselementen en ook van de behoefte aan mobiele compatibiliteit. En we moeten ons zorgen maken over zaken als bruikbaarheid en validatie (als het formulier wordt gebruikt voor het verzamelen van gegevens).

Dat laatste punt is een goed punt, 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 moet) meer geïnteresseerd zijn in het verkrijgen van informatie van u dan het verstrekken van informatie aan u.

Gegevens verzamelen is eenvoudig. Mensen vullen alles in wat je voor ze neerzet, zelfs als het een puinhoop is. Maar als het gaat om gegevensweergave, zijn ze kieskeuriger. Daarom concentreren we ons hier meer op het gebruik van formulieren om gegevens weer te geven dan om het te verzamelen, omdat 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, vormen zijn meer aan te passen aan een mobiel scherm dan tabellen. Dus als je echt moet zorgen dat alle gegevens gemakkelijk kunnen worden bekeken op een mobiel scherm, dan zijn formulieren een betere keuze dan tabellen ... soms!

2. Ontwerp de desktoplay-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 ​​vormontwerp te bespotten, is met InkScape. In dit voorbeeld bouwen we een systeem voor het beheren van HR-records. Hier is de mock-up voor het desktopprototype:

De buitenste rechthoek vertegenwoordigt de volledige ruimte van een 1024 x 768 px-scherm. In elke desktopbrowser hebben we geen toegang tot zoveel pixels tenzij de gebruiker in de modus Volledig scherm staat (wat zelden het geval is). Zo onze

ontwerp is 900 x 600px, dat in het beschikbare gebied van de meeste desktopschermen zou moeten passen.

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 stellen we de weergave-eigenschap van labelelementen in op "block", stellen we de velden First en Last in op class "in40w", en field MI op class "in10w", en alles zou er veel leuker 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 houdt in dat er een geneste rij kolommen in onze hoofdkolom wordt gemaakt, zodat de bedieningselementen op de juiste afstand van elkaar staan. Het aantal kolommen en hun afmetingen veranderen afhankelijk van de vereisten van elke reeks besturingselementen. Onthoud dat alles reageert, dus wanneer de grootte van een kolom wordt gewijzigd, wordt alles in de kolom aangepast zodat de wijziging overeenkomt met de wijziging. Dit is goed nieuws voor gebruikers met een visuele beperking, omdat ze de vergroting op hun beeldscherm kunnen vergroten en alles netjes op één lijn ligt met die van andere gebruikers.

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 rondom de speciale secties zijn gewoon gewone bootstrapputjes. Voor het invoeren van religieuze gegevens, is het noodzakelijk om te kiezen uit een vaste lijst van vooraf gedefinieerde officiële religies (inclusief "andere"). Het ontwikkelen van de kolommen aan de rechterkant was nog eenvoudiger en gebruikte dezelfde technieken uit de eerste reeks besturingselementen in de linkerkolom, waarbij de besturingselementen werden georganiseerd in een tabelindeling, maar zonder een tabel te gebruiken.

Om dit project een succes te maken, moest het een perfecte respons bieden op alle officiële weergavegroottes. Laten we eens kijken hoe het resultaat bleek. Eerst met de volledige resolutieversie:

Dat is zo dichtbij het prototype dat we er tevreden mee kunnen zijn. In feite is het zelfs een verbetering. Laten we nu de responsieve lay-out bekijken op elk van de verschillende secties van de pagina:

Bootstrap en HTML5 hebben het ontwikkelen van formulieren sneller en eenvoudiger gemaakt dan ooit tevoren, maar veel ontwikkelaars ondermijnen deze voortgang door formulieren te ingewikkeld te maken (met behulp van de speciale HTML5 formulierelementen 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 maken die zelfs niet proberen te profiteren van responsief 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

Bogdan Rancea

Bogdan is een van de oprichters van Inspired Mag en heeft in die periode bijna 6 jarenlange ervaring opgebouwd. In zijn vrije tijd studeert hij graag klassieke muziek en onderzoekt hij beeldende kunst. Hij is ook behoorlijk geobsedeerd door fixies. Hij is al eigenaar van 5.