Kontrollerer obligatoriske felt. Obligatoriske og valgfrie felt ved utfylling av skjemaer Obligatoriske felter url http c

Det ser ut til at det ikke er noe komplisert i utformingen av inndatafelt: tegn tomme rektangler for å legge inn data, brukeren vil gjøre resten selv. Alt er imidlertid ikke så enkelt. Å dømme etter lengden på artikkelen er det tydelig at det er ganske mange regler og funksjoner. Brukeren må bli nøye "veiledet av hånden", vist alt, forklart og hjulpet. Da og først da vil vi kunne få de ønskede dataene fra ham. Vel, la oss begynne!

7+ regler for inndatafelt

Den mest grunnleggende regelen, som alle andre steder, er å sette deg selv i stedet for den besøkende. Er alt klart? Er det mulig å forstå ved første øyekast hva som må legges inn i feltet? Reagerer feltet tilstrekkelig på informasjonen som er lagt inn?

Skriv beskrivelser og tips

Hint og beskrivelser er nødvendig for å vise hvilke data som må legges inn, hvordan de skal legges inn riktig, og hvordan nettstedet vil bruke denne informasjonen i fremtiden.

Det er flere typer hint:

1) Ikoner

Ikoner er et universelt visuelt språk. De hjelper deg å forstå hva du skal skrive inn selv med et raskt blikk. Og ja, ikoner er en designfetisj =)

Vi bør imidlertid ikke glemme at de alltid må forklares.

2) Eksempler

Den enkleste måten å fortelle hvordan du fyller ut et felt er å vise et eksempel. Eksempeleksempel: " [e-postbeskyttet]»

3) Forklaringer

Denne typen beskrivelse tjener til å forklare hvordan nettstedet vil bruke dataene og hva det er nødvendig for. For eksempel: «Vi trenger post for å varsle deg om statusen til bestillingen din. Vi vil ikke sende spam."

Bruk masker

For felt som krever data formatert på en bestemt måte (for eksempel et bankkortnummer eller telefonnummer), bør masker brukes. Dermed flytter vi arbeidet med å formatere informasjon fra den besøkendes skuldre til en sjelløs maskin.

Her er noen eksempler på forskjellige masker:

Uthev obligatoriske felt

Hvis det blant de valgfrie feltene er felt som må fylles ut, bør de blant annet fremheves og det bør legges vekt på obligatorisk utfylling. Som regel er obligatoriske felt angitt med en stjerne - *.

Det er bedre å gruppere alle obligatoriske felt og plassere dem i begynnelsen av skjemaet.

Eksempelet ovenfor viser forresten også 2 typer tips: eksempler og forklaringer.

Fokus og tastatur

Det aktive feltet som markøren er plassert i, må ha et særpreg. Som regel fremhever nettlesere uavhengig aktive felt. Du bør imidlertid ikke overlate alt til tilfeldighetene og sjekke funksjonaliteten til denne funksjonen selv.

Når siden laster, skal det første inndatafeltet automatisk bli aktivt. Som om du inviterer deg til å fylle ut hele skjemaet. Ved utfylling av skjema skal det være mulig å bytte mellom inndatafelt uten å bruke musen. Dette skjer vanligvis ved å trykke på Tab-knappen.

Ved bruk av hint med autofullføring (for eksempel i et søk), skal det være mulig å velge et element ved hjelp av piler og bekrefte det ved å trykke på Enter-tasten.

Ved inntasting av hemmelige data (for eksempel et passord), skal det være mulig å skjule og vise disse dataene på brukerens forespørsel.

Bruk dataene som allerede er lagt inn

Inndatafelt må huske ting som vanlige folk glemmer. Det er frekt å be om samme informasjon to ganger. Hvis du en gang abonnerte på nettstedets e-postliste, bør nettstedet huske deg når du registrerer deg og skrive inn e-postadressen din i det aktuelle feltet.

Gruppeinndatafelt

For å lette utfyllingen er det bedre å gruppere lignende felt sammen. For eksempel er felt for å legge inn personlig informasjon (fornavn, etternavn, e-post) én blokk, felt med leveringsadresse er en annen blokk.

Vær oppmerksom på feltstørrelsen

Feltstørrelsen tjener i de fleste tilfeller til å estimere mengden data som kreves av brukeren. De. der du må legge inn en lang adresse, er feltet stort. Så der en 6-sifret indeks er nødvendig, er feltet lite.

Endelig

Utformingen av inndatafeltene er ikke så enkel som den ser ut ved første øyekast. Du må huske mange nyanser og stadig stille deg selv spørsmålet: "vil alt være klart for brukeren?"

Mange grundige gutter vil si at det ikke var 7 regler i det hele tatt (og noen la ikke engang merke til det, ha ha ha). Imidlertid er mange av reglene små, så jeg regnet dem som halvparten. Og generelt sett liker jeg bare tallet 7 =)

HTML-skjemaer er kontroller som brukes til å samle informasjon fra besøkende på nettstedet.

Nettskjemaer består av en samling tekstfelt, knapper, lister og andre kontroller som aktiveres med et museklikk. Teknisk sett sender skjemaer data fra brukeren til en ekstern server.

For å motta og behandle skjemadata, webprogrammeringsspråk som f.eks PHP, Perl.

Før bruken av HTML5 var nettskjemaer en samling av flere elementer , avsluttes med en knapp . Det tok mye arbeid å style skjemaer på tvers av forskjellige nettlesere. I tillegg krevde skjemaene JavaScript for å validere inndata og manglet spesifikke inndatafelttyper for å spesifisere daglig informasjon som datoer, e-postadresser og URL-er.

HTML5-skjemaer løste de fleste av disse vanlige problemene med tilstedeværelsen av nye attributter, og ga muligheten til å endre utseendet til formelementer ved å CSS3.

Ris. 1. Forbedrede nettskjemaer med HTML5

Opprette et HTML5-skjema

1. Element

Grunnlaget for enhver form er elementet .... Det krever ingen inndata siden det er en beholder som holder alle skjemakontrollene sammen - Enger. Attributtene til dette elementet inneholder informasjon som er felles for alle skjemafelt, så felt som er logisk kombinert må inkluderes i ett skjema.

Tabell 1. Tag-attributter
Egenskap Betydning/beskrivelse
aksept-tegnsett Attributtverdien er et mellomrom atskilt liste over tegnkodinger, som vil bli brukt til å sende inn skjemaet, for eksempel, .
handling Obligatorisk attributt, som spesifiserer url-en til skjemabehandleren på serveren som dataene sendes til. Det er en fil (for eksempel action.php) som beskriver hva som må gjøres med skjemadataene. Hvis attributtverdien ikke er spesifisert, vil skjemaelementene få standardverdiene etter at siden er lastet inn på nytt.
Hvis alt arbeidet skal gjøres på klientsiden av JavaScript-skript, kan du spesifisere verdien # for handlingsattributtet.
Du kan også sørge for at skjemaet fylt ut av den besøkende sendes til deg på e-post. For å gjøre dette må du skrive inn følgende:
autofullfør

enctype Brukes til å indikere MIME-type data sendt sammen med skjemaet, for eksempel enctype="multipart/form-data" . Spesifisert kun i tilfelle av method="post" .
application/x-www-form-urlencoded er standardinnholdstypen, noe som indikerer at dataene som sendes representerer en liste over URL-kodede skjemavariabler. Mellomromstegn (ASCII 32) vil bli kodet som + , og et spesialtegn som ! vil bli kodet i heksadesimal som %21 ​​.
multipart/form-data - brukes til å sende inn skjemaer som inneholder filer, ikke-ASCII-data og binære data, består av flere deler, som hver representerer innholdet i et eget skjemaelement.
text/plain - indikerer at ren (ikke html) tekst blir overført.
metode Angir hvordan skjemadata sendes inn.
Get-metoden sender data til serveren gjennom nettleserens adresselinje. Når du genererer en forespørsel til serveren, danner alle variabler og deres verdier en sekvens som www.anysite.ru/form.php?var1=1&var2=2 . Er variabelnavn og verdier lagt til serveradressen etter skiltet? og er atskilt med &. Alle spesialtegn og ikke-latinske bokstaver er kodet i formatet %nn, mellomrommet erstattes med +. Denne metoden bør brukes hvis du ikke overfører store mengder informasjon. Hvis du skal sende en fil sammen med skjemaet, vil ikke denne metoden fungere.
Postmetoden brukes til å sende store mengder data, samt konfidensiell informasjon og passord. Dataene som sendes ved hjelp av denne metoden er ikke synlige i URL-overskriften fordi de finnes i meldingens brødtekst.
Navn Settene skjemanavn, som vil bli brukt for å få tilgang til skjemaelementer via skript, for eksempel name="opros" .
novalidate Deaktiverer validering i knappen for innsending av skjema. Attributtet brukes uten å spesifisere en verdi
mål Angir vinduet som informasjonen skal sendes til:
_blank - nytt vindu
_selv - samme ramme
_parent — overordnet ramme (hvis den eksisterer, hvis ikke, så til den gjeldende)
_top er vinduet på øverste nivå i forhold til denne rammen. Hvis anropet ikke kommer fra en barneramme, så til samme ramme.

2. Gruppering av skjemaelementer

Element

...
designet for å gruppere elementer relatert til hverandre, og dermed dele formen inn i logiske fragmenter.

Hver gruppe med elementer kan navngis ved hjelp av elementet , som kommer rett etter taggen

. Gruppenavnet vises i øvre venstre kantlinje
. For eksempel hvis i et element
Kontaktinformasjon lagres:

Kontaktinformasjon


Ris. 2. Gruppering av skjemaelementer ved hjelp av

Tabell 2. Tag-attributter
Egenskap Betydning/beskrivelse
funksjonshemmet Hvis attributtet er til stede, er en gruppe relaterte skjemaelementer plassert inne i beholderen
, deaktivert for utfylling og redigering. Brukes til å begrense tilgangen til visse skjemafelt som inneholder tidligere innlagte data. Attributtet brukes uten å spesifisere en verdi -
.
form
i samme dokument. Angir en eller flere former som denne gruppen av elementer tilhører. Attributtet støttes for øyeblikket ikke av noen nettleser.
Navn Definerer Navn, som vil bli brukt til å referere til elementer i JavaScript, eller for å referere til skjemadata etter at skjemaet er fylt ut og sendt inn. Det er analogt med id-attributtet.

3. Opprett skjemafelt

Element oppretter de fleste skjemafelt. Et elements attributter varierer avhengig av hvilken type felt elementet brukes til å lage.

Ved å bruke CSS-stiler kan du endre skriftstørrelse, skrifttype, farge og andre egenskaper for teksten, samt legge til kantlinjer, bakgrunnsfarge og bakgrunnsbilde. Bredden på feltet er spesifisert av width-egenskapen.

Tabell 3. Tag-attributter
Egenskap Betydning/beskrivelse
aksepterer Bestemmer hvilken type fil som kan sendes til serveren. Angitt kun for . Mulige verdier:
file_extension - tillater nedlasting av filer med den angitte filtypen, for eksempel accept=".gif" , accept=".pdf" , accept=".doc"
audio/* - tillater nedlasting av lydfiler
video/* - tillater nedlasting av videofiler
image/* - lar innlasting av bilder
media_type - indikerer medietypen til de nedlastede filene.
alt Definerer alternativ tekst for bilder, kun angitt for .
autofullfør Ansvarlig for å huske verdiene som er lagt inn i tekstfeltet og automatisk erstatte dem neste gang du skriver dem inn:
på - betyr at feltet ikke er beskyttet og verdien kan lagres og hentes,
av - deaktiverer autofyll for skjemafelt.
autofokus Lar deg forsikre deg om at et eller annet inndatafelt allerede har fokus (har blitt valgt) i den innlastede formen, og er klar til å angi en verdi.
krysset av Attributtet sjekker om standardavmerkingsboksen er merket av ved sideinnlasting for felt som type="checkbox" og type="radio" .
funksjonshemmet
form Attributtverdien må være lik elementets id-attributt i samme dokument. Identifiserer ett eller flere skjemaer som dette skjemafeltet tilhører.
formasjon Spesifiserer nettadressen til filen som skal behandle dataene som legges inn i feltene når skjemaet sendes inn. Angis bare for feltene type="submit" og type="image" . Attributtet overstyrer verdien av handlingsattributtet til selve skjemaet.
formenctype Bestemmer hvordan skjemafeltdata skal kodes når de sendes til serveren. Overstyrer verdien til skjemaets enctype-attributt. Angis bare for feltene type="submit" og type="image" . Alternativer:
application/-x-www-form-urlencoded er standardverdien. Alle tegn kodes før sending (mellomrom erstattes med +-tegnet, spesialtegn konverteres til ASCII HEX-verdier)
multipart/form-data - tegn er ikke kodet
tekst/vanlig - mellomrom erstattes med +-symbolet, og spesialtegn er ikke kodet.
formmetode Attributtet spesifiserer metoden nettleseren vil bruke for å sende inn skjemadata til serveren. Angis bare for feltene type="submit" og type="image" . Overstyrer verdien av skjemaets metodeattributt. Alternativer:
get er standardverdien. Dataene fra skjemaet (navn/verdi-par) legges til url-en og sendes til serveren: URL?navn=verdi&navn=verdi
post - skjemadata sendes som en http-forespørsel.
formnovalidate Spesifiserer at skjemafeltdata ikke skal valideres når skjemaet sendes inn. Overstyrer verdien av skjemaets novalidate-attributt. Kan brukes uten å spesifisere en attributtverdi.
formatmål Bestemmer hvor svaret mottatt etter innsending av skjemaet skal vises. Angis bare for feltene type="submit" og type="image" . Overstyrer verdien av skjemaets målattributt.


_parent – ​​laster svaret inn i den overordnede rammen
_top – laster svaret i fullskjerm
rammenavn – laster svaret inn i en ramme med det angitte navnet.
høyde Attributtverdien inneholder antall piksler uten å spesifisere en måleenhet. Angir høyden på et skjemafelt av typen type="image" , for eksempel, . Det anbefales å stille inn både høyde og bredde på feltet samtidig.
liste Er en referanse til et element , inneholder sin id . Lar deg gi brukeren flere alternativer å velge mellom når han begynner å skrive inn en verdi i det tilsvarende feltet.
maks Lar deg begrense tillatt inntasting av numeriske data til en maksimal verdi; attributtverdien kan inneholde et heltall eller et brøktall. Det anbefales å bruke dette attributtet sammen med min-attributtet. Fungerer med følgende felttyper: tall, rekkevidde, dato, datetime, datetime-local, month, time and week.
maks lengde Attributtet spesifiserer maksimalt antall tegn som legges inn i feltet. Standardverdien er 524288 tegn.
min Lar deg begrense tillatt numerisk inndata til en minimumsverdi.
flere Lar brukeren angi flere attributtverdier, atskilt med komma. Gjelder filer og e-postadresser. Spesifisert uten attributtverdi.
Navn Angir navnet som skal brukes for å få tilgang til elementet , for eksempel i css-stilark. Det er analogt med id-attributtet.
mønster Lar deg bestemme bruken vanlig uttrykk syntaksen til dataene som må tillates å legges inn i et bestemt felt. For eksempel, pattern="(3)-(3)" - hakeparenteser angir rekkevidden av akseptable tegn, i dette tilfellet - alle små bokstaver, tallet i krøllede parenteser indikerer at tre små bokstaver er nødvendig, etterfulgt av en bindestrek, deretter tre sifre i området fra 0 til 9.
plassholder Inneholder teksten som vises i inntastingsfeltet før den fylles ut (oftest er dette et verktøytips).
skrivebeskyttet Tillater ikke brukeren å endre verdiene til skjemaelementer; valg og kopiering av tekst er fortsatt tilgjengelig. Spesifisert uten attributtverdi.
nødvendig Viser en melding som indikerer at dette feltet er obligatorisk. Hvis brukeren prøver å sende inn skjemaet uten å angi ønsket verdi i dette feltet, vil en advarsel vises på skjermen. Spesifisert uten attributtverdi.
størrelse Angir den synlige bredden av feltet i tegn. Standardverdien er 20. Fungerer med følgende felttyper: tekst, søk, tel, url, e-post og passord.
src Angir nettadressen til bildet som brukes som innsendingsknapp for skjema. Angitt kun for feltet .
steg Brukt for elementer som krever inntasting av numeriske verdier, indikerer hvor mye verdiene økes eller reduseres med i løpet av rekkeviddejusteringsprosessen (trinn).
type knapp - oppretter en knapp.
avkrysningsboks – gjør et inndatafelt til en avkrysningsboks som kan krysses av eller fjernes, f.eks.
jeg har en bil
farge - Genererer fargepaletter i støttende nettlesere, slik at brukere kan velge fargeverdier i heksadesimalt format.
dato — lar deg angi en dato i formatet dd.mm.åååå.
Fødselsdag:
datetime-local - lar deg angi dato og klokkeslett atskilt med stor engelsk bokstav T ved å bruke mønsteret dd.mm.åååå tt:mm.
Fødselsdag - dag og tid:
e-post – Nettlesere som støtter dette attributtet vil forvente at brukeren legger inn data som samsvarer med syntaksen til e-postadresser.
E-post:
fil - lar deg laste ned filer fra brukerens datamaskin.
Velg Fil:
skjult - Skjuler kontrollen, som ikke vises av nettleseren og hindrer brukeren i å endre standardverdiene.
bilde - oppretter en knapp, slik at du kan sette inn et bilde i stedet for tekst på knappen.
måned – Lar brukeren angi år og månedsnummer ved å bruke mønsteret åååå-mm.
tall - beregnet for å legge inn heltallsverdier. Attributtene min , maks og trinn spesifiserer henholdsvis øvre, nedre grenser og trinn mellom verdier. Disse attributtene antas for alle elementer som har numeriske indikatorer. Standardverdiene deres avhenger av elementtypen.
Vennligst oppgi mengde (fra 1 til 5):
passord - oppretter tekstfelt i skjemaet, mens tegnene som legges inn av brukeren erstattes med stjerner, kuler eller andre ikoner installert av nettleseren.
Oppgi passord:
radio - lager en bryter - en kontroll i form av en liten sirkel som kan slås av eller på.
Vegetarisk:
rekkevidde - lar deg lage et grensesnittelement som en glidebryter, min / maks - lar deg angi utvalgsområdet
tilbakestill - oppretter en knapp som sletter skjemafelt for brukerangitte data.
søk - betegner et søkefelt, som standard er inndatafeltet rektangulært i form.
Søk:
send - lager en standardknapp som aktiveres med et museklikk. Knappen samler informasjon fra skjemaet og sender det til behandling.
tekst - Oppretter tekstfelt på et skjema, og skriver ut et enkeltlinjes tekstfelt for tekstinntasting.
tid - lar deg legge inn tid i 24-timers format ved å bruke tt:mm-mønsteret. I støttende nettlesere vises det som en numerisk inndatafeltkontroll med en museredigerbar verdi og lar bare tidsverdier angis.
Spesifiser tid:
url – feltet er ment for å spesifisere URL-er.
Hjemmeside:
uke - Det tilsvarende pekerverktøyet lar brukeren velge én uke i året, hvoretter det vil gi datainntasting i nn-åååå-format. Avhengig av år kan antall uker være 52 eller 53.
Spesifiser uke:
verdi Bestemmer teksten som vises på en knapp, i et felt eller i tilknyttet tekst. Ikke spesifisert for felt av typen fil.
bredde Attributtverdien inneholder antall piksler. Lar deg angi bredden på skjemafeltene.

4. Tekstinntastingsfelt

Element brukes i stedet for element når du skal lage store tekstfelt. Teksten som vises som den opprinnelige verdien er plassert inne i taggen. Feltedimensjonene settes ved hjelp av attributtene cols - horisontale dimensjoner, rader - vertikale dimensjoner. Høyden på feltet kan stilles inn ved hjelp av høydeegenskapen. Alle størrelser beregnes basert på størrelsen på ett tegn i en monospace-font.

Tabell 4. Tag-attributter

7. Knapper

Element oppretter klikkbare knapper. I motsetning til opprettede knapper ( , , , ), inne i elementet .

Knapper lar brukere sende inn data til et skjema, slette skjemainnhold eller utføre andre handlinger. Du kan lage rammer, endre bakgrunnen og justere tekst på en knapp.

Tabell 9. Tag-attributter
Egenskap Betydning/beskrivelse
autofokus Setter fokus på knappen når siden lastes inn.
funksjonshemmet Deaktiverer knappen, slik at den ikke kan klikkes.
form Indikerer ett eller flere skjemaer som denne knappen tilhører. Attributtverdien er identifikatoren til det tilsvarende skjemaet.
formasjon Attributtverdien inneholder URL-en til skjemadatabehandleren som sendes når knappen klikkes. Bare for knapptype type="submit" . Overstyrer verdien til handlingsattributtet som er spesifisert for elementet .
formenctype Angir kodingstypen for skjemadata før de sendes til serveren når knapper som type="submit" klikkes. Overstyrer verdien til enctype-attributtet spesifisert for elementet . Mulige verdier:
application/x-www-form-urlencoded er standardverdien. Alle tegn vil bli kodet før sending.
multipart/form-data - tegn er ikke kodet. Brukes når filer lastes opp ved hjelp av et skjema.
tekst/vanlig - tegn er ikke kodet, og mellomrom erstattes med +-symbolet.
formmetode Attributtet spesifiserer metoden nettleseren skal bruke for å sende inn skjemaet. Overstyrer verdien til metodeattributtet som er spesifisert for elementet . Spesifisert kun for knapper av typen "submit". Mulige verdier:
get - data fra skjemaet (navn/verdi-par) legges til url og sendes til serveren. Denne metoden har begrensninger på størrelsen på dataene som sendes og er ikke egnet for sending av passord og konfidensiell informasjon.
post - data fra skjemaet legges til som en http-forespørsel. Metoden er mer pålitelig og sikker enn få og har ingen størrelsesbegrensninger.
formnovalidate Attributtet spesifiserer at skjemadata ikke skal valideres ved innsending. Spesifisert kun for knapper av typen "submit".
formatmål Attributtet spesifiserer i hvilket vindu resultatet skal vises etter innsending av skjemaet. Spesifisert kun for knapper av typen "submit". Overstyrer verdien til målattributtet som er spesifisert for elementet .
_blank - laster svaret inn i et nytt vindu/fane
_self - laster svaret inn i samme vindu (standard)
_parent – ​​laster svaret inn i den overordnede rammen
_top - laster svaret i fullskjerm
rammenavn - laster svaret inn i en ramme med det angitte navnet.
Navn Angir navnet på knappen, attributtverdien er tekst. Brukes for å lenke til skjemadata etter at skjemaet er sendt inn, eller for å lenke til en gitt knapp(er) i JavaScript.
type Definerer knappetypen. Mulige verdier:
knapp - klikkbar knapp
reset — tilbakestillingsknapp, returnerer den opprinnelige verdien
send - knapp for å sende inn skjemadata.
verdi Angir standardverdien som sendes når knappen klikkes.

8. Avmerkingsbokser og alternativknapper i skjemaer

Avmerkingsbokser i skjemaer settes ved hjelp av konstruksjonen , og bryteren - ved hjelp av .

Avmerkingsbokser, i motsetning til alternativknapper, kan settes til flere i én form. Hvis det avmerkede attributtet er spesifisert for avmerkingsbokser, vil avmerkingsboksene på de tilsvarende skjemafeltene allerede være valgt når siden lastes inn.

Element

Det er mange myter og misoppfatninger i verden av programvareutvikling. For å komme videre og ikke stagnere, er det helt nødvendig å ødelegge dem. I dag snakker vi om en av de mest rotfestede misoppfatningene, som også er ganske skadelig, kalt "Myten om obligatorisk sex."

Vi vil snakke om nesten alle system som bruker skjemaer for å legge inn informasjon. Et obligatorisk felt er et skjemafelt, uten hvilket systemet ikke godtar informasjonen din. Blant de aller fleste programvareutviklere er det en oppfatning at de obligatoriske feltene bør være:

  1. Alle felter som er nødvendige fra emnets synspunkt (for eksempel fullt navn og fødselsdato til en person, hvis vi snakker om passkontoret);
  2. Alle felter som er nødvendige for at systemet skal fungere (de som algoritmene ikke vil fungere uten - for eksempel datoen da leveringen av tjenester begynner for å periodisere dem);
  3. Viktige felt er de som ikke er nødvendige, men helst fyll ut (for eksempel begrunnelsen for endringen som gjøres) - med motivasjonen om at det er bedre for brukeren å svette når det ikke er nødvendig enn å glemme å legge inn en verdi når det er nødvendig.
Som du kan se, er det et helt kompleks av myter her som må avlives nøye og systematisk. Så la oss starte med to andre misoppfatninger.

Tradisjonelt tror programmerere at de gjør resten av verden en tjeneste ved å lage et så flott produkt for dem som et "erstatter et produktnavn." Programmet deres er nesten en platonisk eidos, en ren abstraksjon, en matematisk formel, som selvfølgelig kan beregnes strengt på et sett med parametere fra dets definisjonsdomene. Fra dette synspunktet er obligatoriske felter en irriterende liten ting som må settes inn for å lære dumme og ufine brukere hvordan Ikke sant legge inn informasjon i systemet som de har privilegiet til å jobbe med.

Det antas også at feil (ufullstendig) data er så forferdelig at selv å lagre dem i en database ikke lenger er riktig. Vel, latskap, selvfølgelig - fra utviklerens synspunkt er det lettere å kontrollere riktigheten av dataene på inndatatrinnet og sende brukeren til å dobbeltsjekke dataene sine enn å skrive feilhåndtering der disse dataene faktisk skal brukes i systemet.

Hva har moderne å si om dette? For det første ble det klart (jeg vet ikke til hvem og når, men for ganske lenge siden sikkert, se og) at tross alt er programmer utviklet for brukere. Slik sett dikterer ikke programmereren lenger forholdene, men skaper beskjedent et rent utilitaristisk produkt, et verktøy som folk vil bruke for å løse deres oppgaver og prestasjoner deres mål. Som et strykejern - hvis du trenger å stryke noe, slår du det på. Hvis den, i stedet for å stryke, modalt tilbyr å laste ned oppdateringer fra Internett, er det klart hvor et slikt strykejern vil fly. Alan Cooper anbefaler å fremstille produktets brukere som veldig smarte, men veldig travle mennesker. De sier at de ikke er dumme og vil forstå hvordan de bruker produktet ditt, det viktigste er at du bare ikke kommer i veien for dem.

Generelt tror jeg at enhver programmerer (designer, leder, analytiker) bør gjøre meditasjonen nevnt av Sergei Bodrov Jr.:

Du står på hjørnet av en travel gate og innbiller deg at du ikke er der. Eller rettere sagt, du eksisterer ikke i det hele tatt. Fotgjengere går, biler tuter, butikkdører åpnes, passasjerer bytter på bussholdeplassen. Det vil si at i prinsippet fortsetter verden å leve uten deg. Dette er vondt å forstå. Men det er viktig...
Selvfølgelig vil jeg ikke si at det å være programmerer er et unødvendig yrke; Jeg er programmerer selv og jeg tror ikke det i det hele tatt. Det er bare et utakknemlig yrke. Ingen vil komme og rose deg for en godt implementert algoritme. Hvis programmet er bra, vil det bli brukt uten ytterligere spørsmål. Slik skal det være, bare for å være programmerer må du venne deg til det. Og disse menneskene som går nedover gaten og bytter på bussholdeplassen er brukerne dine. De bruker ting slik de gjør dem behov for. Inkludert produktet ditt. Uten deg. De vet ingenting om deg, vil ikke vite det og vil aldri vite det. Sergei Vitalievich, når han er i den polare tundraen og prøver å legge inn målingene tatt fra måleren inn i systemet, er ikke i det hele tatt interessert i hvorfor systemet forteller ham at du først må indikere en type tariffering, selv om på det tidspunktet av design virket det som uten en tarifftype, vel det er ingen vei utenom det. Når det gjelder eksempelet om oppdateringene for nedlasting av jern, ble det ikke tatt fra løse luften - vær oppmerksom på hvordan Firefox-nettleseren oppfører seg når den er slått på.

Vil det i det hele tatt være noe om obligatoriske felter, spør Habrowser? Det er i ferd med å starte.

Saken er at vår virkelige verden ikke er en matematisk modell hvis parametere er kjent til enhver tid. Det virkelige liv er preget av mangel på informasjon snarere enn dets tilstedeværelse. Personen som fyller ut skjemaet har kanskje ikke de nødvendige dataene - og kan ikke ha dem innenfor alle påregnelige grenser for rekkevidde, det vil si at de endelig ikke eksisterer. Dette problemet kan ikke løses ved ganske enkelt å gjøre feltet obligatorisk - verdien vil ikke bli trukket ut av løse luften. Ved å innføre obligatoriske felt på skjemaer av hensyn til dataintegritet og fullstendighet, har vi faktisk vi forstyrrer bruken av systemet. I en slik situasjon vil brukeren enten ikke fylle ut skjemaet (og ikke kunne jobbe med systemet i det hele tatt), eller fylle ut manglende data med fisk - fiktive eller meningsløse data. Og dette indikerer ikke at brukeren er dårlig eller ikke prøvde hardt, men bare at det utviklede systemet ikke fleksibel nok for bruk under forhold ekte fred. Det som skjedde i det andre tilfellet (introduksjon av fisk) er et totalt bedrag. Systemutvikleren kan late som han vil at alt er i orden, men faktisk er det han som har skylden for dette bedraget. Dessuten er det ikke klart hvem som vant og hva - brukeren hadde hodepine, og feil data kom inn i systemet. Ja, de kom i en slik situasjon at det ikke lenger er mulig å oppdage, filtrere eller rydde opp automatisk – i motsetning til tilfellet hvis brukeren bare antydet at informasjonen manglet.

Hva å gjøre? Du må lage gode programmer. Nemlig, ja, ikke sett integriteten til databaseskjemaet i høysetet, men sett målene og målene til brukerne der. Med andre ord aksepterer ufullstendige og i noen tilfeller ukorrekte data fra brukeren, naturligvis, med mulighet for å korrigere dem i fremtiden. I motsetning til misforståelse (ja, en annen) er det mulig, det er ikke så vanskelig og det fungerer til og med. I tillegg må du fortsatt hjelpe på en eller annen måte, fortelle brukeren hvor, hvilke data og hvorfor han mangler. Slik at han kan se og kontrollere situasjonen.

Hvor mange obligatoriske felt skal det være på skjemaet? Ideelt sett null. Er dette alltid mulig? For meg er et av eksemplene på kunstflyging operasjonen med å lage en mappe i Windows. Det ser ut til at du ikke kan gjøre mindre enn ett felt her, men nei, de klarte å implementere opprettelsen på en slik måte at systemet ikke ber om noe - selv om tekniske begrensninger ikke tillater systemet å lage en mappe uten navn. Dette er et ideal å strebe etter.

Naturligvis bør systemet være minimalt intelligent, og spørre brukeren kun hva som er relevant for brukerens oppgaver, og ikke for selve systemets behov. Systemet er som et verktøy, husker du? Omtrent eksemplet med Firefox – Google Chrome, for eksempel, løste Firefox-problemet ved å oppdatere stille i det øyeblikket brukeren starter den på nytt. Brukeren trenger ikke vite om dette i det hele tatt - han vet ikke. Et verdig eksempel å følge. Jeg må innrømme, jeg skjønte ikke engang med det første, hvorfor spurte han meg aldri når han skulle oppdatere?

Det var også en myte om viktige felt (dette er de som er valgfrie, men ønskelig å fylle ut). Her er alt enda enklere - du kan ikke tvinge feltet til å fylles ut. Derfor, selv om du merker feltet som obligatorisk, eller ikke merker det, vil de fortsatt skrive fisk, tull, melde deg av hvis de ikke vil fylle det ut. Det er ingen grensesnittløsning for dette problemet. Betydningen av felt må kommuniseres til feltpersonalet. Og utvikleren bør merke feltet som valgfritt. Og la meg redigere.

Litteratur:

  1. Alan Cooper om grensesnittet. Grunnleggende om interaksjonsdesign. Symbol-Plus, 2009
  2. Jeff Raskin. Grensesnitt: nye retninger i design av datasystemer. Symbol-Plus, 2005

UPD: I kommentarene ble hovedmoralen til emnet formulert tydeligere: vi snakker om systemet med utkast, om å fjerne kravet om å legge inn alle dataene på en gang og konsekvent. Det vil si, ja, gjør valgfrie selv de feltene som systemet ikke vil fungere uten. Naturligvis vil det ikke fungere, men i det minste vil det lagre dataene.

UPD #2: La meg presisere en ting til som jeg selv ikke var helt klar over da jeg skrev emnet. Jeg diskuterer ikke her hensiktsmessigheten av enkelte felt på skjemaet (dette er et viktig, men likevel litt annerledes tema enn det jeg ønsker å formidle). Jeg foreslår heller å revurdere selve konseptet med å legge inn informasjon ved hjelp av skjemaer, den tradisjonelle tilnærmingen når du trenger å fylle ut hele skjemaet på en gang og riktig. I stedet foreslår jeg at mellomtilstanden (ufullstendig, feil, motstridende) også tillates lagret i databasen, eksplisitt markere en slik tilstand som ufullstendig/feilaktig/inkonsekvent. Dermed kan alle situasjoner «Jeg vet ikke alt nå, men kanskje i morgen», som tradisjonelt løses ved å skrive dem ned på et stykke papir, behandles ved hjelp av et informasjonssystem. Naturligvis bør slike data ikke slippes inn i forretningsprosessen på grunn av feil - alt forblir som før. De vil rett og slett ligge i databasen til bedre tider – de vil ikke være nyttige, vel, Gud velsigne dem.

Maksimal informasjon i et minimum av ord.

Måten felt merkes på, påvirker i stor grad hvordan brukere oppfatter skjemaet og hvordan de fyller ut det.

Fra et psykologisk synspunkt er alt ganske enkelt: å peke på positive aspekter er bedre, fordi brukeren når en avgjørelse tror han har et valg.

På den annen side, hvis du angir obligatoriske felt, vil brukeren føle seg fanget, begrenset og ukomfortabel.

Merk valgfrie felt, ikke omvendt

De fleste designere bruker stjerner for å indikere obligatoriske felt. Men du må slutte å gjøre dette. Forskning på dette problemet indikerer tydelig at bruk av stjerner for obligatoriske felt er en vanlig feil.

Det er bedre å merke valgfrie felt i stedet for obligatoriske felt fordi:

  • Stjernen er åpenbar for deg og ikke for alle, tro meg, det er alltid de som ikke forstår
  • Det er alltid flere obligatoriske felt enn valgfrie
  • Jo mindre visuell støy skjemaet ditt har, jo mer lesbart er det, og derfor raskere å fylle ut.

Ikke nødvendig vs Valgfri

Hvis du skriver en tekst på engelsk, husk at negativer i alle tilfeller er mindre tydelige. Bruk derfor ordet "Valgfritt" i stedet for "Ikke nødvendig" for å beskrive valgfrie felt.

Ikke be brukere om å oppgi ubrukelig informasjon. Hvis du har for mange ekstra (ikke-påkrevde) felt, er det dårlig og du vet det. Verken du eller jeg liker former for toalettpapirruller.

POSISJON

Om å holde åpne lag- og individuelle konkurranser

For styrkeløft og bar benkpress,

Podolsk og Moskva-regionen

1. Mål og målsettinger

· Det arrangeres konkurranser for å popularisere styrkeløft i Podolsk og Moskva-regionen

· Oppdra en fysisk utviklet yngre generasjon og fremme en sunn livsstil

· Involvere unge i systematisk kroppsøving og idrett

· Skape motivasjon blant ungdom og unge til å engasjere seg i kroppsøving

· Forbedre sportsånden til idrettsutøvere i Podolsk og Moskva-regionen

· Identifikasjon av de sterkeste idrettsutøverne i Podolsk og Moskva-regionen

· Dannelse av et lag for å prestere på åpne styrkeløftkonkurranser i Podolsk

2. Dato og sted

Konkurransen avholdes 16. november 2013 på Kulturpalasset 1. mai: Moskva-regionen, Klimovsk, Zavodskaya gate, 3. Konkurransestart og innveiing vil bli annonsert i tillegg (på e-post eller SMS).

3. Organisasjon og ledelse

Den generelle organiseringen av konkurransen utføres av MU Center for Civic and Patriotic Education of Youth "Fakel" og treningsstudioet "Good Lift", med deltakelse av Podolsk-grenen av den all-russiske all-unionsorganisasjonen "Combat Brotherhood". ” og veldedige stiftelsen “Healthy Nation”.



Direkte tilsyn utføres av den atletiske gymnastikktreneren til Fakel MU Popov S.A., og direktøren for Good Lift gym P.S. Yakovlev. og representanten for veldedige stiftelsen "Healthy Nation", I.F. Rabotkin.

4. Konkurransedeltakere

Interesserte organisasjoner og institusjoner, samt individuelle utøvere som har fylt 16 år og har sendt inn personlige søknader om å delta i konkurransen, inviteres til å delta i konkurransene.

Arrangørene forbeholder seg retten til senere å kunngjøre standarder for opptak til konkurranser, med obligatorisk varsling til utøvere (på e-post eller SMS).

Arrangørene forbeholder seg retten til, dersom antall søknader overstiger, senest 9. november 2013 å kunngjøre standarder for opptak til konkurranser, med obligatorisk varsling til utøvere ved å legge ut informasjon i åpne kilder, samt sende SMS og e-postmeldinger .

5. Prosedyre for avholdelse av konkurranser og vilkår for å sende inn søknader

Søknad om deltakelse i konkurranser må sendes inn innen 9. november 2013 på epost: [e-postbeskyttet] eller via SMS-melding til nummeret +79099250337 (kostnaden for en SMS er lik kostnaden for en SMS-melding fra din teleoperatør).

Merk følgende! Se vedlegg 1 for riktig søknadsskjema.

6. Prosedyre for å kåre vinnerne

Merk følgende! Konkurransebedømmelse utføres i henhold til IPFs regler (se vedlegg 2)

Konkurranser avholdes i kategorien åpen alder (Åpen).

i det individuelle mesterskapet:

Kvinner konkurrerer i kategorien absolutt vekt, vinnerne (som tar 1.-2.-3.-plasser) bestemmes av Wilks-formelen.

Vinnere hos menn er bestemt i kategorier opptil 75 kg, opptil 90 kg, opptil 110 kg og over 110 for det beste resultatet. Vinnere i absolutt mesterskap (utøvere som tok 1-2-3 plasser) i triatlon og benkpress bestemmes etter Wilks-formelen.

I lagmesterskapet 4 beste resultater av mannlige lagmedlemmer og 1 kvinnelig resultat er tatt i betraktning

Poeng tildeles etter følgende skjema:

1. plass – 6 poeng

2. plass – 4 poeng

3. plass – 3 poeng

4. plass – 2 poeng

5. plass – 1 poeng

Vinneren av lagmesterskapet er laget som scorer maksimalt antall poeng blant alle lag.

7. Vinners belønningsseremoni

Vinnerne og prisvinnerne i enkelt- og lagmesterskapet som tok 1-3 plasser i nominasjonene premieres med minnesertifikater og medaljer.

8. Finansiering

Kostnadene knyttet til organisering, gjennomføring og premiering av vinnerne bæres av arrangørene av konkurransen, interesserte organisasjoner og sponsorer. Utgifter knyttet til reiser og måltider for deltakere dekkes av utsendende organisasjoner. Det er ingen inngangsavgift.

Vedlegg 1

Eksempel på søknad (sendes på e-post eller SMS):

1. nominasjon: for eksempel benkpress eller triatlon.

2. lagnavn eller merk personlig *

3. Fullt navn *–

4. Fødselsår *–

6. siffer *–

7. beste resultat * (i løpet av de siste 6 månedene) -

8. alder* -

9. trener -

10. kontakttelefonnummer (helst mobiltelefon)* -

Felt som er merket med stjerne (*) må fylles ut.

Merk følgende! Alle deltakere på konkurransedagen må ha visum sertifisert av lege, og pass eller identitetskort (lisens, militær ID). Uten disse dokumentene vil ikke utøvere få lov til å konkurrere.

Vedlegg 2

Konkurranseregler:

  1. Opptreden på konkurranser foregår uten bruk av utstyr (pressskjorter, kjeledresser, knebandasjer for styrkeløft).
  2. Du kan bruke: håndleddsbandasjer, belter (maksimal beltebredde – 10 cm).
  3. Om nødvendig kan du bruke en ikke-støttende bandasje (på ett ben eller en arm). Ikke-støttende bandasjer er vanlige medisinske bandasjer. Bandasjen skal fremvises for dommeren før bruk.
  4. Øvelser utføres i henhold til IPF-regler

Knebøy(regler og rekkefølge for utførelse).

Etter å ha fjernet stangen (assistenter kan gi assistanse), tar utøveren startposisjonen.

Etter at utøveren har akseptert startposisjonen, gir dommeren kommandoen om å SITTE NED.

Utøveren setter seg på huk slik at toppen av bena ved hofteleddene er lavere enn toppen av knærne. Kun ett forsøk på å gjøre en nedadgående bevegelse er tillatt.

Idrettsutøveren må uavhengig gå tilbake til vertikal stilling med bena helt rettet i knærne. Dobbeltstående oppreist ("hopping" er forbudt).

Så snart utøveren inntar en stasjonær stilling, gir dommeren kommandoen om å returnere vektstangen til stativene - RACKS.

- Forbudt- Manglende overholdelse av seniordommerens signaler ved start eller avslutning av en øvelse. Dobbelt oppreisning (hopp) fra bunnen av en knebøy eller en nedadgående bevegelse mens du står opp. Feilen er å bøye bena ved knærne og senke kroppen til en posisjon der den øvre overflaten av bena ved hofteleddene er lavere enn toppen av knærne.

Benkpress(regler og rekkefølge for utførelse)

Utøveren skal ligge på ryggen, med hodet, skuldrene og "hele" baken i kontakt med overflaten av benken. Sålen og hælene på skoene hans må være i kontakt med overflaten på plattformen eller blokkene (så langt formen på skoene tillater det).

Fingrene skal vikle rundt stangen som ligger på stativene, med tomlene plassert "låst" rundt stangen. Denne stillingen må opprettholdes under

utfører øvelsen. Bruk av omvendt grep er forbudt.

For å sikre fast støtte for bena, kan utøveren bruke flate plater eller blokker som ikke er høyere enn 30 cm fra overflaten av plattformen.

Avstanden mellom hendene på stangen, som måles mellom pekefingrene, bør ikke overstige 81 cm (begge pekefingrene skal være innenfor 81 cm-merkene).

Etter å ha fjernet stangen fra stativene med eller uten hjelp av assistenter, må utøveren vente på signalet fra seniordommeren med armene helt utrettet ("på") ved albuene.

Signalet om å starte pressen må gis så snart løfteren inntar en stasjonær stilling.

posisjon og stangen vil være i riktig posisjon. Signalet for å starte øvelsen er kommandoen – START.

Etter å ha mottatt signalet, må utøveren senke vektstangen til brystet og holde den i en stasjonær stilling på brystet (vanligvis bunnen av brystbenet), hvoretter dommeren gir kommandoen - TRYKK. Da må utøveren presse vektstangen opp i strake armer. Etter å ha festet stangen i denne posisjonen, gir dommeren kommandoen - RACKS.

- Forbudt– Enhver feil ved å følge dommerens kommandoer. Enhver endring i startposisjonen når du utfører en øvelse (enhver løfting (separasjon) av hodet, skuldrene, baken fra benken eller bevegelse av bena på plattformen eller blokkene, eller bevegelse av armene langs stangen). Enhver nedadgående bevegelse av vektstangen under en benkpress. Mangel på å klemme vektstangen med helt utrettede armer på slutten av øvelsen.

6. Markløft (regler og rekkefølge for utførelse)

Utøveren må vende seg foran plattformen. Vektstangen, som er plassert horisontalt foran utøverens ben, holdes med et fritt grep med begge hender og reiser seg til utøveren står oppreist.

Etter å ha løftet vektstangen i markløft, skal knærne rettes helt opp og skuldrene trekkes tilbake.

Dommeren gir kommandoen - NED.

Enhver løfting av vektstangen eller ethvert bevisst forsøk på å løfte den regnes som en tilnærming. Når løftet har begynt, tillates ingen nedadgående bevegelse av vektstangen før løfteren når en vertikal stilling med knærne helt utstrakt. Hvis stangen synker når skuldrene trekkes bakover, er ikke dette en grunn til å ikke telle vekten som løftes.

- Forbudt– enhver nedadgående bevegelse til den endelige posisjonen er nådd. Støtt vektstangen med lårene mens du løfter opp. Går frem eller tilbake. Senker vektstangen til kommandoen. Slipp vektstangen fra hendene når du utfører kommandoen nedover.