Vanlige mobile webdesign feil
Mobil Internett-bruk stiger, og verden av webdesign fortsetter å utvikle seg, så designere må lære å imøtekomme mobile enheter. Tenker "Å, mine brukere vil ikke besøke nettstedet mitt på en mobil enhet" er den verste feilen til alle.
Ingen kan stoppe mobilbruk fra å øke, og sjansen er at hver nettside vil motta besøkende på mobile enheter. Så den beste strategien er å være så forberedt som mulig.
Bare å tenke på mobilbrukere er ikke nok til å løse situasjonen. Mange feil er fortsatt begått under prosessen, og å vite hva de er er det første skrittet i å effektivt unngå dem i fremtidige prosjekter.
Følgende er de vanligste feilene på mobile nettsteder.
Ikke regner med enhetens bredde
Dette høres kanskje tydelig ut, men en rekke nettsteder ser slik ut på en mobil enhet (i dette tilfellet, iPhone):
Du bør forstå maksimal bredde som elementene på en side burde ha, samt kunne formatere et helt HTML-dokument for å regne for ulike skjermstørrelser.
I skjermbildet over til venstre, er nettstedet formatert for variable enhetsbredder, men elementene er ikke. Nettstedet til høyre er ikke formatert for variable enhetsbredder, så elementene ser altfor små ut. Selv om body elementet ble satt til en smalere bredde (for eksempel 320 piksler), det ville bare bli presset helt til venstre på skjermen og fortsatt være lite og ulastelig.
Dette kan løses med en enkel HTML-linje i av hvert dokument:
Denne lille detalj, sammen med formaterte elementer, vil gi en god mobilopplevelse.
Gjør brukerne fylle ut lange skjemaer
Å fylle ut skjemaer er irriterende selv på stasjonære datamaskiner, og det er enda mer kjedelig på en mobil skjerm. Utforming av et webskjema for mobile enheter er en komplisert oppgave; fokus på å bygge enkle former som ikke spør mye om brukere.
Angi typen innspill som blir bedt om fra brukeren, slik at tastaturet har elementene som brukeren trenger når de fokuserer på feltet. For eksempel angir du et feltets inntastingstype som number vil angi tastaturet for å vise tall som standard, i stedet for bokstaver.
Ikke omtanke innholdet
Overføring av innhold fra store webmiljøer har kommet for å involvere sin egen strategi, som når innholdet måtte overføres fra utskrift til web. Plass- og fokusbegrensninger på mobile enheter er langt mer signifikante enn de på datamaskiner.
Luke Wroblewskis "design for mobile first" -metode definerer en sterk tilnærming vi kan ta. Det fraråder oss fra å generere et sett med innhold for skrivebordsbussen og et annet sett for mobilnett. Et mobildesignteam bør vurdere om innhold som ikke vil vises i mobilversjonen, er enda nødvendig? Kanskje det ikke engang trenger å vises i desktop-versjonen.
Bruke innhold til dekorative formål eller bare for å fylle plass garanterer nesten at det blir fjernet senere, så hvorfor ikke bare vurdere viktig innhold fra begynnelsen?
Å gå gjennom denne prosessen kan avdekke andre vanlige feil og problemer.
Eliminerer innhold og funksjonalitet uten grunn
Å revidere innhold kan være vanskelig, og tette tidsplaner kan tvinge det til å skje raskere enn det skal. Dette resulterer ofte i å fjerne innhold og funksjonalitet feilaktig, faktisk nesten tilfeldig.
Prosessen innebærer grundig analyse før redigerings- og curating-begynnelsen. Eksisterende innhold må vurderes for å skille innhold som legger til verdi og oppfyller brukerens forventninger fra innhold som bare distraherer eller fyller ut plass.
For å bedre forstå strategien for å generere og redigere innhold, sjekk ut boken Innholdsstrategi for Internett av Kristina Halvorson. Den dekker alle detaljer, fra grunnleggende innholdsstrategi til revisjon og redigering av vesentlig materiale.
Glemmer størrelsen og begrensningene av en finger
Når du bruker en datamaskin, bruker vi presise museklikk for hver oppgave. Vi kan enkelt klikke på et 16 × 16 ikon; prosessen innebærer ingen vanskeligheter.
En mobil bruker, derimot, har presisjonen til en finger, en finger som nesten ikke er tynn.
Apple har bestemt seg for 44 piksler som minimum akseptabel størrelse for mobile kontroller (44 × 30, for å være presis) og har implementert denne standarden på tvers av sine produkter.
I tillegg til størrelsen på elementene blir plassen mellom elementene ofte ignorert. Tenk på en liste over alternativer, hver med en radioknapp, med en linjehøyde på 0 mellom dem. Brukere er bundet til å gjøre feil, selv om de tar sin tid. Hvorfor ville vi komplisere ting på denne måten?
Luke Wroblewski har kanskje gått videre enn noen som identifiserer standardstørrelser for mobil design, ved å kompilere anbefalinger fra flere plattformer. I følge Windows Phone UI og Interaction Guide bør standardstørrelsen mellom elementene være 8 piksler, minimum.
Langside-lastetider: Sterke bildefiler
Sterke bildefiler har vært et problem fra begynnelsen i webdesign. Og mobilwebben presenterer enda større utfordringer, fordi lastetider har en tendens til å øke når du kombinerer de begrensede egenskapene til enkelte enheter med variable dataoverføringssignaler (som avhenger av typen Internett-tilkobling).
Bildeoptimalisering fortsetter også å være et viktig hensyn i mobildesign.
Langside-lastetider: For mange bilder
Mange små bilder har samme funksjonsevne som et enkelt tungvektbilde.
Dette er spesielt et problem når designere prøver å etterligne utseendet til innfødte smarttelefonprogrammer, inkludert gradienter og avrundede hjørner av iOS-overskrifter og knapper.
Det fører til enda en vanlig feil ...
Ikke dra nytte av CSS3 og HTML5 evner
Mange typer bilder kan unngås helt siden nå at HTML5 og CSS3 er rundt. I tillegg gir mobilbrowsere oss mye mer frihet enn desktop-nettlesere fordi nesten alle av dem ble bygget på Webkit motor, som støtter både HTML5 og CSS3.
Hvorfor ikke dra nytte av dette? De element i HTML5 kan redusere behovet for bilder, som de nye CSS3-egenskapene som gir grunnleggende stiler som gradienter og avrundede hjørner. Det er en viktig måte å lagre på sidetilpasningstider.
Nok med grafikken nå. Å bruke for mange bilder er ikke den eneste måten å skade en mobil design, og bilder er ikke de eneste tingene som senker det heller.
Langside-belastningstider: For mye import
Vi ser dette hovedsakelig med rammer (og plug-ins for disse rammene). La oss innse det: det skjer mye nå, og det har skjedd siden ankomsten av de så nødvendige og hjelpsomme AJAX-rammene som jQuery og MooTools. jQuery-utviklere gikk selv så langt som å lage en mobilforbedring kalt jQuery Mobile.
Disse gjør jobben så mye enklere at mange designere ikke bekymrer seg om konsekvensene av å avhenge sterkt av dem. Du har sikkert sett noe slikt i a stikkord:
Og la oss ikke glemme importen av jQuery Mobile:
Hver enkelt import i denne heisen er tilbakering til serveren, og den senker siden, akkurat som et lastebilde ville.
Det finnes måter rundt dette problemet. Du kan syntetisere importen. Hvorfor importere flere små skript hvis du kan ringe en stor en? Du kan også vurdere om du trenger et rammeverk i det hele tatt. Er det virkelig verdt det? Kan du få jobben gjort deg selv med mindre kompleksitet ?.
Langsidetid: Ikke kommuniserer handlinger tydelig
La oss si at bestemte handlinger på mobilwebområdet ditt tar lengre tid å laste enn andre. Det er greit; Det er ikke noe å bli gal hvis du har gjort en reell innsats for å få fart på det. Det viktige å vurdere nå, er hvordan å gjøre ventetiden mer utholdelig for brukeren?
Løsningen er å gjøre designet så gjennomsiktig som mulig. Hva skjer? Brukeren skal kunne svare på dette spørsmålet til enhver tid. For hver belastning i designen, bør det være en klar uttalelse som forteller brukeren om den.
Undervurder aldri kraften til den enkle "Loading ..." -strengen.
Ikke satt inn et startskjermikon
Ingen vil at snarveien til mobilwebapplikasjonen skal se ut som noen av dem til venstre over. DeviantART-ikonet til høyre er mye mer attraktivt og mer sannsynlig å bli klikket på.
Tingen om brukere er at de har en tendens til ikke å lese. Og en hjemmeskjerm full av snarveier uten kjennetegnende ikoner gjør at brukerne er 100% avhengige av titlene. (Og selv da blir lange titler komprimert og fylt inn med ellipser, sett ovenfor, noe som gjør dem enda mindre identifiserbare).
Angi et startskjermikon er ikke vanskelig i det hele tatt. Når du har opprettet ikonet som en PNG-fil (som skal være 158 × 158 piksler), legg til følgende linje med kode til av HTML-dokumentet ditt:
Enkel og nyttig. Denne linjen med kode fungerer også på Android-telefoner. Du trenger ikke engang å legge til glans eller avrundede hjørner; iPhone legger til det automatisk.
Ikke å være lydhør
Responsive webdesign er ett svar på alle disse problemene. Det er vanskelig å implementere, men effektivt når det gjøres bra. Ethan Marcotte skrev nylig en hel bok på emnet. Jeg anbefaler det hvis du vil komme inn på dette i mye mer detalj.
Responsive design handler om å skape et design som justerer pent, uansett størrelsen på beholderen. Det innebærer overveier som fluidnett (hvor elementene omorganiseres ettersom nettleseren endrer seg i størrelse) og bilder som tilpasser seg siden utvider og kontrakterer.
Marcotte skrev også en detaljert introduksjon til responsiv design , som kan hjelpe deg med å forstå emnet bedre.
Har du personlig erfaring med mobile designutfordringer? Hvilke problemer har du oppstått? Har du som mobilbruker møtt andre problemer enn de som er nevnt her?