Share
Designere vs utviklere - det er et argument som er gammelt som datamaskiner. Sannheten er, men verken kan leve uten den andre. En strålende UI-design er like verdiløs uten funksjonalitet som det er den beste koden med en stygg, ubrukelig frontend. I dette første innlegget på grensesnittgrensesnitt for utviklere skal jeg prøve å legge ut noen enkle grunnregler som devs kan følge for å sikre at deres apps, maler og prototyper er like vakre som selve koden - og kan brukes til å starte opp.
Tenk: Første inntrykk er siste inntrykk.
Justering refererer til posisjon eller orientering av et element i forhold til et annet element eller til seg selv. Når vi refererer til to elementer som er justert til hverandre, refererer justering vanligvis til hvilken side av begge elementene er i kø. I sammenheng med tekst refererer tilpasning til siden som tekst er forankret i en rett linje.
I bildet over viser det andre eksempelet på en enkel formutforming etiketter som er rettjustert til hverandre med inntastingsfelt som er venstrejustert. Dette sikrer at sammenhengen mellom hver etikett og dens inntastingsfelt er tydelig, og brukeren blir ikke forvirret hvis noen etiketter er for små mens andre er lange.
Tenk: Pass på at inntaksfeltene ikke er for langt unna den lengste etiketten. Hvis variasjonen i bredden er liten, kan du prøve å justere etiketter og innrette felt som vender inn mot venstre.
For tekst, er det ideelt å bruke venstrejustering når desigen for skjermen. Siden de fleste skjermtype-gjengivelsesmetoder ikke er i stand til å distribuere plass på riktig måte når du begrunner tekst til begge sider, holder venstrejustering tekstlesbar og godt organisert. Du kan selvsagt bruke midt- og høyrejustering der design krever det, men de er vanligvis reservert for spesielle tilfeller og mindre tekststykker.
Hovedformålet med ethvert brukergrensesnitt er å la brukergrensesnittet med applikasjonen. Dette, tro det eller ikke, kommer ikke til å bli mulig med mindre du forteller brukeren hva han trenger å gjøre og i hvilken rekkefølge. Siden du ikke vil være der bak hver bruker for å hjelpe dem med dette, må grensesnittet gi alle signalene. Her er noen spørsmål å spørre når du vurderer om den tiltenkte arbeidsflyten er riktig:
La oss ta eksemplet på et søkekategorivalg på iStockPhoto. I dette tilfellet kan jeg enten søke i alt eller velge en bestemt kategori for å begrense søkene mine til den typen informasjon. Siden den primære handlingen er å skrive inn et søkeord og trykke på Søk, bør de være ganske åpenbare. Et mulig trinn i mellom er å velge en kategori, som kan være en rullegardinliste mellom (du gjettet det riktig) søkefeltet og søkeknappen.
Et annet eksempel er inntekts / inntastingsdialogboksen i cashbase-appen. Feltene er ordnet etter den typiske arbeidsflyten som en vil bruke til å logge inn slik informasjon: Skriv inn beløpet (som er det viktigste elementet), velg en kategori, legg til et notat om nødvendig, og klikk Legg til. Sekundær informasjon som vil bli brukt mye sjeldnere - som datoen som standard er i dag, og muligheten til å gjenta eller avbryte - er tilgjengelig, men mye mer subtil.
Beslektede elementer i et grensesnitt bør grupperes sammen. Dette kan høres ut som sunn fornuft når jeg nevner det, men det er ikke alltid godt forstått. Årsaken til at alle sidens navigasjonskoblinger på de fleste nettsteder er lagt ut i en enkelt horisontal linje, slik at brukeren kan identifisere forholdet på et øyeblikk og gjøre valget om å samhandle med dem uten forvirring.
La oss se på dette eksemplet fra Gmail - en app som mange bruker regelmessig. Dette er verktøylinjen som vises øverst når du åpner en e-post. Selv om alle disse knappene utfører noen handling på den åpne meldingen, blir de videre gruppert sammen basert på hva de gjør - handlinger man ville bruke for å kvitte seg med meldingen (arkiv, spam, slette), for å endre meldingenes betydning (når bruker prioritetsinnboks), etikettrelaterte handlinger, og til slutt en rullegardin med sekundære alternativer.
Et annet eksempel på god bruk av nærhet er alternativstangen i Zootool. Verktøylinjen nederst er delt inn i tre sett, hver som svarer til de tre rutene i appen: listen pakker til venstre, postvinduet i midten som inneholder alle bokmerkene dine, og detaljruten til høyre.
Ikke alt i et brukergrensesnitt, eller noe layout for den saks skyld, har samme betydning som alt annet. Hierarki er ordningen av elementer på en måte som angir hva som er høyere i orden, hva som kommer neste og så videre.
La oss se på dette eksemplet her, og prøv å identifisere hva prioritetsordningen er. Siden alt - titler, etiketter og teksttekst - ser det samme, må man lese gjennom alt for å gi mening. Hvis det samme grensesnittet var tweaked bare litt som nedenfor, er den generelle innvirkningen på lesbarheten og igjen bruken av grensesnittet enormt.
Som regel bør sidens overskrift være størst og mest synlig på skjermen. Dette følges av seksjonstitler, undertitler og så små etiketter. Stikktekst kan være mer eller mindre fremtredende avhengig av formålet. Det er heller ikke begrenset til tekst. Primær handlingsknapper kan differensieres fra sekundære handlinger ved å gjøre dem lysere, større eller mer avanserte. Inngang felt for obligatoriske innganger kan gjøres mer åpenbare enn de andre. Jeg kunne fortsette, men jeg tror du får ideen.
Et annet svært viktig hensyn når du designer grensesnitt, er å sikre en klar differensiering mellom elementene. Selvfølgelig vil du at teksten skal kunne leses i bakgrunnen, men kontrast går utover bare ved å bruke lett tekst på en mørk bakgrunn eller omvendt. Overskrifter og avsnitt tekst bør være tydelig skille mellom. Paneler og navigasjonsbarer må være segregerte fra hverandre, slik at brukeren vet hva som er hva. Listen fortsetter.
Kontrast kan etableres ved hjelp av ett eller flere av følgende egenskaper:
Dette burde være åpenbart, men det er utrolig hvor ofte folk glir på dette punktet. Hvis bakgrunnen din er lys, vil du åpenbart at teksten skal være mørk for å sikre lesbarhet. Selv om komplekse farger i teorien skal fungere godt sammen, er det ikke alltid så lett. Prøv å plassere lys grønn tekst på en rød bakgrunn, og du vil vite hva jeg sier.
Mulighetene her er ubegrensede, så min første anbefaling til alle som ønsker å velge farger, er å hente en populær fargepalett fra nettsteder som Adobe Kuler eller ColourLovers. De blir bidratt, evaluert og stemt opp av lidenskapelige brukere som vanligvis kjenner seg rundt fargen. Alt grunnleggende om fargematching og kontrast blir vanligvis tatt vare på, så det handler bare om å bestemme hvilken fargeskjema som fungerer i appens sammenheng.
Ett varsel om å være forsiktig - vær veldig forsiktig med å gå over bord med farge. Du vil ikke at de skal overskygge verktøyet og brukervennligheten til appen din.
En annen god måte å skille mellom elementer - basert på hierarki, kategorisering eller visuell flyt - er å bruke forskjellige størrelser. Dette gjelder tekst så mye som det gjør for bilder, bakgrunner og statiske eller interaktive elementer. Du vil kanskje legge større vekt på den primære handleknappen, for eksempel, og holde sekundærknappene relativt mindre tilgjengelige. Eller valgfrie spørsmål kan være mindre og lettere enn de primære etikettene i et skjema.
TeuxDeux appen gjør en strålende jobb med å bruke farge for å skille mellom fortid, nåtid og fremtidige dager. Siden utformingen er rettet mot en arbeidsuke, brukes forskjellige størrelser på tekst for å sikre at navn på dager er enkle å identifisere, mens datoene er relativt mer subtile.
Siden det primære formålet med ethvert brukergrensesnitt er å gjøre det mulig for brukere å kommunisere med appen, er det avgjørende at elevene intuitivt vet hva de skal gjøre. Som skapere av grensesnittet er det veldig enkelt å glemme at du ikke vil være der for hver bruker å fortelle dem hva de skal gjøre. Brukerne har heller ikke tålmodigheten mer å lese manualer og hurtigstart før de går inn i bruk av en app. Grensesnittet er nødvendig for å gjøre det tydelig hvilke deler av det som er klikkbare, berørbare, dragerbare - kort sagt, interaktive.
Alle vet hvordan man kan slå en elektrisk bryter, ikke sant? Saken som gjør det åpenbart for alle som en bryter må trykkes på et bestemt tidspunkt for å endre tilstand, kalles affordance. På den flate overflaten på en skjerm - desktop, mobil eller på annen måte - kan forskjellige teknikker brukes for å gjøre det mulig for brukerne å intuitivt klikke på en knapp eller skrive inn et inputfelt. Når du lager tekstlinks, er det å legge til en underlinje for lenken den vanligste standarden, selv om det finnes mange andre kreative måter å gjøre det på.
Her er noen eksempler:
Å gå med brytereksemplet, hvordan vet du om flicking bryteren gjorde hva den skulle gjøre? Lyset lyser eller går av, eller i noen tilfeller kan et lys inne i bryteren gjøre det klart om bryteren er på eller av.
I en applikasjon kan slike tilbakemeldinger være svært åpenbare i tilfeller hvor en knapp navigerer til en annen side eller åpner en popup, men hva med situasjoner der alt det gjør er å behandle noen data i bakgrunnen - som når du lagrer endringer i brukerinnstillingene? En slags tilbakemelding mekanisme er viktig for å la brukerne vite at deres handling var vellykket. Dette kan være så enkelt som en "innstillingene dine ble lagret", et kort varsel øverst på siden, eller et raskt høydepunkt rundt området som ble oppdatert.
Når du legger til en ny oppgave i Remember the Milk, kan den enten vises i listen på samme side, eller bare bli lagt til i en annen liste i bakgrunnen (hvis for eksempel oppgaven har blitt tildelt en annen kategori). Tilbakemeldingen til handlingen er derfor gitt på to nivåer:
Teksten i appen din - alt fra logoen til titlene, etikettene og kopiene - er din primære kommunikasjonsmodus med brukerne. Siden det er hvordan brukerne får tilgang til informasjon om appen eller gjennom den, kan du angi forskjellen mellom suksess og feil, hvordan du angir typen. Selvfølgelig må titlene være større enn kroppsteksten, og den fine utskriften må være bra, bra. men mange andre beslutninger påvirker også hvordan brukerne forbruker informasjon.
Trinn ett: Definer skrifter. Det overrasker meg hvor mange utviklere ganske enkelt aldri bryter med å endre hvilken skrifttype deres tekst blir generert i. Standardfonter endres fra OS til OS og nettleser til nettleser, noe som betyr at med mindre du uttrykkelig oppgir hvilken skrifttype du vil bruke, vil teksten din se forskjellig ut i alle OS- og nettleserkombinasjoner. Dessuten, Times New Roman - som mange nettlesere fortsatt bruker som standard font - er bare ikke en god skrift for lesing på skjermen. Min første anbefaling er ofte å bruke en sans-serif-skrifttype, selv om Georgia eller den nye Cambria-skrifttypen i Windows 7 også ser bra ut.
Hvis du bestemmer deg for å bruke andre fonter enn de trygge, finnes universelt tilgjengelige som Arial / Helvetica, Georgia, Tahoma etc., og det er en måte å få dem til å gjøre på samme måte på alle plattformer. Hvis Flash er ditt utviklingsmiljø, kan du legge dem inn når det er nødvendig. For HTML / JS-baserte apper, bruk @ font-face i CSS eller noen av nettfontetjenester som Typekit eller Google WebFonts. Husk at disse teknikkene kommer med en advarsel av ekstra filstørrelser for de innebygde skrifttyper. Hvis hastighet og respons er avgjørende for deg, er det best å satse på basenes skrifttyper.
Ansvarsfraskrivelse: Ja, jeg vet at Arial og Helvetica ikke er nøyaktig like, men de er like de fleste brukere ikke merker forskjellen på.
Mengden mellomrom mellom to linjer med tekst er den ledende. Du vil at ledelsen av din paragraftekst (linjehøyde i CSS-snakk) skal være minst 140% av skriftstørrelsen for å sikre at den er lettlestelig. Noen mindre og teksten din blir mye vanskeligere å lese og - mer viktig - å skanne gjennom.
Hvis du planlegger å oversette appen din til forskjellige språk - og du virkelig burde - er det best å teste grensesnittet tidlig med forskjellige skript. I det minste kan mengden plass en viss melding krever variere drastisk over forskjellige skript. De østasiatiske skriptene bruker færre ord i gjennomsnitt, men trenger en større skriftstørrelse. Indiske (Indikator) skript må også være litt større for å kunne leses, og midt østlige skript (som arabisk) går fra høyre til venstre i stedet for den vanlige venstre -til høyre.
Det handler om det for nå. Jeg håper disse tipsene dekket nok grunnleggende for deg å begynne å bruke dem i dine prosjekter med en gang. Som med de fleste designrelaterte fagområder, er det ikke noen vanskelige og raske regler å følge, og alle har sin egen vurdering av hvordan ting skal fungere. Så hvis du er uenig med noen av mine forslag ovenfor - eller selv om du er enig med dem, men har et annet perspektiv - la vi høre om dem i kommentarene.
Neste opp, vil vi ta all denne visdommen og prøve å bruke den til et faktisk grensesnitt. Følg med!
Accentsconagua