Brukbarhetslaboratorium: ekspertvurdering av en mobilapplikasjon for iOS. Hvordan det fungerer? Sjekk hvordan appen ber om tillatelser

Den utrolige veksten i popularitet til mobile applikasjoner og tjenester har gjort arbeidet til en UX-designer mer komplekst og interessant. Applikasjoner blir mer interessante, mer komplekse, og som et resultat blir det vanskeligere ikke bare å utvikle dem, men også å teste dem. Å teste en app fra et brukerperspektiv er nå viktigere enn noen gang. viktig stadium utvikling.

Dessverre, i motsetning til situasjonen med utviklingen av skrivebordsapplikasjoner, for testing og registrering av brukervennlighetstester av mobilapplikasjoner, er det ingen slik spesiell programvare, som Silverback eller Camtasia, som du kan "ta ut av esken" og begynne å teste.

Selv om du ikke utvikler en mobilapp, er sjansen stor for at mesteparten av trafikken til nettstedet ditt kommer fra mobilkanaler. Å gjennomføre vanlige mobilbrukstester er praktisk talt den eneste måten å evaluere hvor godt denne kanalen fungerer for kundene dine, hvor nyttig og praktisk den er for dem.

Litt hacking vil være nødvendig. Nei, vi snakker ikke om hacking, men heller om ikke-trivielle metoder for å bruke visse ting. Vi tror at det er et slikt "hack" som trygt kan kalles den beste i sitt slag. Hvis du vil teste brukervennligheten til en iPhone-applikasjon eller en Android OS-enhet, vil du finne at løsningen vi snakker om er svært høy kvalitet, produktiv og rimelig.

En liten historie: ledninger og teip

I gamle dager brukte vi en «slede» for å plassere smarttelefonen og kameraet i en posisjon som gjorde at vi kunne ta opp hva som skjedde på smarttelefonskjermen mens brukeren brukte den. For å lage sleden kjøpte vi noe (se bildet under) laget av akryl som passet til formen vår og bøyde den på en bestemt måte.

Vi festet webkameraet til sleden med gaffatape og telefonen på motsatt side med borrelås. Når vi ser tilbake, kan vi si at enheten så ganske kjedelig og grov ut. Dette var lite naturlig og enda mindre praktisk for brukere som er vant til å holde en smarttelefon med begge hender samtidig.

Teknisk sett var det ikke idiotsikkert. Vi brukte to kameraer koblet til en bærbar PC (kameraet på sleden og det innebygde kameraet på den bærbare datamaskinen), og vi måtte ha to kameraapplikasjoner i gang samtidig. Alt dette førte til en reduksjon i ytelsen til hele systemet, og det oppsto ofte vanskeligheter med driften.

Det var mange andre problemer, for eksempel gjenskinn på skjermen og kamerafokus. Generelt tok det mye tid å sette opp og stabilisere et slikt system kombinert med testmiljøet, men dette Den beste avgjørelsen, som vi visste på den tiden. For brukere som ifølge scenariet skulle bruke applikasjonen "on the record", så en slik installasjon imidlertid veldig unaturlig ut.

En kanskje mer moderne og passende måte er trådløs kommunikasjon

Ideelt sett bør testing av maskinvare og programvare være usynlig for brukerne. Vi ønsker å simulere et mest mulig naturlig miljø for smarttelefonbrukere – uten ledninger, kameraer og andre improviserte enheter.

UX-team må fokusere på læring og forståelse. Vi ønsker ikke å svette installasjonen og bekymre oss for strømbrudd.

La oss fortelle deg om et enkelt oppsett som lar oss nå alle disse målene. Det vil tillate UX-designteamet å fokusere på det som virkelig betyr noe og brukere å fokusere på telefonene sine. Dette systemet er så pålitelig som mulig og kan trygt brukes i arbeid, og det er det vi gjør.

Vi vil fokusere på brukervennlighetstesting på smarttelefoner som bruker en MacBook som opptaksenhet. Men fra PC til Windows-system fungerer også.

For å finne ut hvor praktisk et nettsted eller annet programvare for brukere må du spørre dem selv om det. Men det antas at testing på "levende mennesker" tar mye krefter og tid fra utvikleren og/eller eieren av ressursen.

For denne saken er det online verktøy s for brukervennlighetstesting. De hjelper til med å finne ut hvor godt produktet oppfyller brukernes forventninger, og sparer samtidig tid og penger på forskning.

Denne artikkelen gir en oversikt over ti enkle og tilgjengelige verktøy for brukervennlighetstesting av nettsider. Det som er fint er at alle applikasjonene som er beskrevet, med unntak av den siste, kan brukes gratis: de krever ikke betaling i det hele tatt eller har gratisversjoner med begrenset funksjonalitet.

Først er det en beskrivelse av alle ti søknadene, og deretter sammenligningstabell, som gjenspeiler deres hovedegenskaper.

UsabilityHub

Det er tre nettbaserte verktøy tilgjengelig på nettstedet som lar deg teste brukervennligheten til et nettsted eller nettapplikasjon ved å bruke skjermbilder av sider.

Optimalt verksted

På OptimalWorkshop-nettstedet kan du optimalisere nettstedet ditt ved å bruke tre forskjellige verktøy:

Optimalsort er et verktøy som hjelper deg med å organisere nettstedstrukturen ved hjelp av kortsorteringsmetoden.
Treejack - testapplikasjon på flere nivåer informasjonsarkitektur(IA) nettsted. For å begynne å teste, må nettstedstrukturen organiseres som en tabell og lastes inn i Treejack.
Calkmark er designet for å teste brukervennligheten til nettsider. Det hjelper deg å forstå hvor enkelt (eller vanskelig) det er for brukere av nettstedet å finne nødvendig informasjon. For å komme i gang laster vi opp et skjermbilde av nettsiden og setter en oppgave for brukerne. Calkmark samler svar og viser testresultater som et varmekart over klikk, og rapporterer også gjennomsnittlig tid det tar å fullføre hver oppgave.

For hver type testing setter vi selv oppgavene, og så finner vi brukere selv og inviterer dem til å delta i studien.

I gratis versjon Du kan bare lage små prosjekter, med følgende begrensninger:

OptimalSort: ti deltakere og 30 kort per undersøkelse.
Chalkmark and Treejack: 10 deltakere og 3 undersøkelsesoppgaver per undersøkelse.

Dette gratis nettverktøyet kan integreres i nettstedet ditt. Den lager en kort spørreundersøkelse for besøkende på nettstedet, bestående av kun 4 spørsmål. Spørsmålene er formulert på en slik måte at det er mulig å identifisere de mest pålitelige tilbakemelding fra brukere.

Integrerer med Google Analytics og er tilgjengelig på 10 språk, selv om russisk, dessverre, ikke er blant dem ennå.

Feng-GUI

Feng-GUI simulerer brukerens blikk i løpet av de første 5 sekundene av eksponeringen visuell effekt. Denne appen lager et varmekart av øynene på siden basert på en algoritme som forutsier hva en ekte person sannsynligvis vil se på.

Rett på hjemmeside nettstedet, kan du laste opp et skjermbilde og se de sannsynlige områdene med økt oppmerksomhet fra besøkende.

ClickHeat

Det er gratis programvare Med åpen kilde integreres i nettsiden og lager et visuelt varmekart over klikk av nettsidebesøkende. Og siden ClickHeat-koden er plassert direkte på serveren, gjenspeiler kartet resultatet av arbeidet ekte brukere nettstedet.

WebVisor

Et russisk system som, etter å ha installert javasript-kode på sidene, lar deg spore og analysere brukeratferd.

Med dens hjelp kan du:

Registrer handlingene til besøkende på nettstedet: klikk, rulling, tastetrykk, fylle ut skjemaer, utheving og kopiering av tekst.
Spill av innspilte handlinger i live video-modus.
Utfør detaljerte analyser av oppførselen til besøkende på nettstedet.
Lag brukeraktivitetskart: varmekart over klikk, oppmerksomhetskart og rullekart.

I gratisversjonen registreres 100 besøk per dag, 2 av dem gjengis for analyse, og dataene lagres i WebVisor-systemet i to dager.

SitePolice

Et annet russiskspråklig nettverktøy for testing av nettsidens brukervennlighet. Det lar nettstedeiere teste ressursene sine ved hjelp av revisorer, og revisorer å tjene penger med arbeidskraften sin.

Hvordan det fungerer?

Kunden sender inn nettsiden sin til «polititjenestemenn», formulerer flere spørsmål som han ønsker svar på og velger tariffplan revidere.
Revisorer skriver en rapport på nettstedet i nesten fri form. Rapporten har bare to nødvendige deler: "analyse av nettstedets brukervennlighet og måter å løse problemer på" og "generell konklusjon." For sine rapporter og aktivitet på siden får «politifolk» poeng, som de deretter kan gjøre om til penger.
Hvis revisjonskunden ikke har noe imot det, forblir alle "polititjenestemenn"-rapporter på tjenestenettstedet for generell visning.

Dessverre finnes det ingen gratis- eller prøveversjon av tjenesten for revisjonskunder.

Sammenligningstabell over testverktøy for brukervennlighet

Navn	russisk språk	Hvem tester	Test objekter	Testresultater	Tilgjengelighetgratisversjoner
UsabilityHub	Spise	Service testere; andre UsabilityHub-brukere	Skjermbilde av en nettside	Svar på spørsmål formulert i begynnelsen av testen; varmekart klikker	Gratis med restriksjoner – brukere av gratisversjonen må teste andres nettsteder selv
UserPlus	Spise	På egen hånd ved hjelp av et spørreskjema; tjenestetestere (i betaversjon)	Skjermbilde av en nettside	Vurdere siden for samsvar med internasjonale standarder	Gratis med en grense på ett skjermbilde per måned

Navigering av mobilversjoner av nettsider og applikasjoner skal være visuell, forståelig og i tillegg ta minimalt med plass på skjermen. I hovedsak bør det utfylle søkeverktøy, og noen ganger erstatte dem, og det er flere grunner til dette:

Brukere vet noen ganger ikke hva de vil finne på nettstedet ditt, så målet ditt er å hjelpe dem med å finne ut av det ved å begrense søket, for eksempel produktkategorier.
Formuler det riktige søkeord er ikke en så enkel oppgave som det kan virke, og folk er også late av natur. Det ville vært mye mer effektivt å tilby dem ferdige løsninger i form av navigasjonslenker.
Til slutt, et nettsteds søkefelt fungerer ofte ikke så effektivt som brukerne forventer.

På mobile enheter Riktig navigering er enda mer relevant: den opptar en betydelig del av skjermen, tiltrekker seg mye mer oppmerksomhet enn på et skrivebord. På grunn av plassbegrensninger kan søkefeltet og menykoblingene øverst på siden gjøre det vanskelig å raskt komme til informasjonen du trenger. Ikke tving brukere til å rulle, vær nøye med disse elementene - de skal være merkbare ved første øyekast, men ikke krenke prioriteringen av innhold over grensesnittet.

Dette er et av hovedproblemene i dag mobile grensesnitt: Hvordan gjøre navigasjon synlig og enkel å bruke uten å distrahere fra innholdet. La oss vurdere sentrale prinsipper bygge navigering av mobilnettsteder og applikasjoner ved å bruke spesifikke eksempler.

Øverste navigasjonslinje

Den øverste navigasjonslinjen ble arvet av mobilnettsteder fra stasjonære enheter. Denne stripen øverst på skjermen, som inneholder de viktigste navigasjonslenkene, er populær og rolig effektivt verktøy har imidlertid to betydelige mangler. For det første er det bare bra når det er relativt få andre navigasjonselementer på siden, og for det andre tar det for verdifull plass øverst på skjermen.

Her er for eksempel hvordan hovedsidene til mobilversjonen av BBC-nettstedet ser ut og Google-apper Spill-apper:

noter det Google Play klarte å passe flere elementer i navigasjonslinjen ved å bruke "karusell"

Fanelinje

Fanelinjen er den nærmeste slektningen til den øverste navigasjonslinjen og brukes ofte i applikasjoner. Den kan plasseres enten øverst
sider (for det meste Android) og nederst (IOS).

Fanelinjer er vanligvis til stede i de fleste mobilapper og har de samme ulempene som navigasjonslinjen. Den vesentlige forskjellen er at fanelinjen er forankret, det vil si konstant synlig på skjermen, selv når brukeren ruller nedover siden, mens navigasjonslinjen som regel bare ruller sammen med sideinnholdet. Selv om noen ganger den såkalte "klebrige navigasjonen" brukes, når navigasjonslinjen forblir øverst på skjermen eller automatisk vises der når brukeren begynner å rulle opp på siden.

Eksempler inkluderer Facebook-nyhetsstrømmen på mobile plattformer. Facebook på iPhone (venstre) og Android (høyre) bruker fanelinjen for grunnleggende appnavigering. Fanene er plassert i samsvar med de offisielle prinsippene for disse operativsystemene: nederst - på iPhone og øverst på siden - på Android. Samtidig er navigasjonsikoner på iOS også merket:

Hvis det er flere enn fem, blir det vanskelig å få plass til alle på panelet samtidig som det opprettholdes optimalt touch-skjerm størrelse. Selvfølgelig kan du bruke en "karusell", som i eksemplet med Google Play - det vil si dele navigasjonselementene inn i kategorier, men dette er ikke alltid hensiktsmessig. Brukeren kan ikke alltid gjette hvilke gjenstander som er skjult bak neste karusellelement, og vil ikke alltid sjekke dem.

Eksempel - gammel versjon Vær-apper Kanal: her er fanelinjen implementert på en slik måte at det ikke umiddelbart er tydelig at hver fane nederst skjuler flere. Og det er enda vanskeligere å gjette nøyaktig hvilke gjenstander som finnes der:

Hvis du velger å bruke en navigasjonslinje eller fanelinje, bør det være hovedelementet i grensesnittet, men du bør også dedikere litt plass til andre verktøy, for eksempel søkeboksen.

Hvis nettstedet ditt har 4-5 hovednavigasjonsalternativer, kan det være fornuftig å gjøre dem synlige til enhver tid, spesielt hvis de fører til ofte brukte sider og alternativer. Husk imidlertid at navigasjonen må passe til konteksten til applikasjonen. Så hvis det er andre nødvendige elementer - for eksempel et handlekurvikon, logg inn regnskap osv., så må de også tas i betraktning slik at det generelle grensesnittet ikke tar for mye plass.

Slik ser for eksempel søkeresultatsiden for AutoZone ut:

Selv om navigasjonslinjen kun inneholder fire hovedpunkter (Butikk, Reparasjonskonsultasjoner, Bestill og Finn en butikk), vises det i tillegg til flere grensesnittelementer på siden (logo, handlekurv, søkefelt, faner med søkeresultater osv.). .), så totalt tar de omtrent en tredjedel av skjermen.

Skjulte menyer (smørbrød og andre alternativer)

En sandwichmeny eller hamburgermeny er navigasjonsmenyen, som inneholder flere elementer eller til og med flere undermenyer og utvides bare når brukeren klikker på den. Når den er brettet, tar den minimalt med plass, og dette er både fordelen og ulempen siden dette elementet navigasjon er mindre merkbar enn en vanlig meny.

Et eksempel på bruk av en sandwich-meny er USA Today-nettstedet. Her brukes den til grunnleggende navigasjonsalternativer. Åpnes ved å klikke på ikonet til venstre øverste hjørne skjerm:

Et annet alternativ for skjult navigering er at menyen bare vises når brukeren sveiper skjermen. For eksempel i Sephora-appen på interne sider Menyen kan hentes frem ved å sveipe fingeren fra venstre til høyre:

Men selve menyknappen er ikke synlig, så mange brukere oppdager sannsynligvis ikke denne funksjonen og begrenser seg til funksjonalitet ved kun å bruke synlige knapper.

Generelt, som nevnt ovenfor, skjult meny har en betydelig fordel fremfor navigasjonslinjen- den tar minimalt med plass. Men husk at navigasjonslenkene for det meste vil være skjult. For å bruke dem må brukeren målbevisst gå til menyen og velge ett av elementene, noe han ikke er helt vant med ennå, til tross for at hamburgermenyer allerede er ganske vanlig i mobilversjoner av nettsider. I denne forbindelse er det verdt å forbedre navigasjonssystemet ved å bruke ekstra verktøy- for eksempel kryssreferanser.

Navigasjonshub

Dette er navnet på siden (vanligvis hovedsiden til nettstedet) der alle de viktigste navigasjonselementene er plassert. Dette er knutepunktet, krysset mellom alle veier, der brukeren kommer tilbake hver gang han skal til en annen strekning.

Ulempen med denne tilnærmingen er at hjemmeside må være fullstendig viet til behovene til navigasjon, og brukeren er tvunget til å gjøre ekstra trinn(retur hjem) når du beveger deg rundt på stedet.

Dette er først og fremst nettsteder og applikasjoner som ikke brukes for å se innhold, men for å oppnå svært spesifikke oppgaver— for eksempel sjekke inn for en flytur eller endre en billettpris mobil kommunikasjon. I slike tilfeller fullfører brukeren sjelden mer enn én oppgave per besøk, så det vil ikke være irriterende å måtte gå tilbake til hovedsiden for å velge en annen navigasjonsgren.

Et godt eksempel - mobilversjon United airline nettsted. Hovedsiden inneholder viktige navigasjonselementer, og de interne har en "Hjem"-knapp øverst på siden for å gå tilbake til hovedsiden. Dessuten utfører brukere sjelden to typer handlinger (for eksempel kjøpe en billett og sjekke inn for en flytur) i ett besøk. Så de fleste av dem trenger ikke denne knappen.

konklusjoner

Å gjøre mobilnavigering enkel og praktisk er ikke så lett på grunn av begrensningene knyttet til små skjermstørrelser. Du kan prøve å løse dette problemet på forskjellige måter, men nesten alltid vil du støte på brukervennlighetsproblemer.

Poenget er å velge løsninger hvis mangler er minst sannsynlig å manifestere seg spesifikt på nettstedet ditt:

Sandwichmeny vil bli forstyrret et stort nummer av navigasjonslenker, men de blir kun synlige når brukeren henter frem menyen. Denne tilnærmingen er relevant for nettsteder som primært er fokusert på å se innhold.
Navigasjonslinjen og fanelinjen spiser opp litt skjermplass, men fungerer bra når det er få alternativer å velge mellom.
På nettsteder som er fokusert på å løse spesifikke problemer, kan du bruke hjemmeside som navigasjonsknutepunkt.

Brutfører denne typen verifisering for å hjelpe utviklere med å lage applikasjoner som er raske og enkle å bruke. hovedmålet– sikre brukervennlighet av applikasjonen, lag et grensesnitt som oppfyller generelle standarder.

Når du utfører brukervennlighetstesting, må testeren:

sørg for at knappene har riktig størrelse og at de er komfortable for tommelen;
plasser knapper i ett område av skjermen for ikke å forvirre brukere;
sjekk om bilder og ikoner er ordnet i samsvar med applikasjonsmiljøet;
sørg for at fargen på knappene som utfører de samme funksjonene stemmer overens;
sikre at systemet fungerer korrekt når du zoomer inn og ut;
gi minimal tastaturinngang;
finn ut om du kan gå tilbake eller avbryte en handling hvis du trykker på feil tast;
finne ut om de er overbelastet kontekstmenyer, siden de involverer rask bruk;
sjekke om teksten er enkel, forståelig og synlig for brukeren;
sørg for at korte setninger og avsnitt er lesbare;
finne optimal størrelse skrifttype;
sørg for at hvis en stor mengde informasjon lastes ned, advarer applikasjonen brukeren om mulige feil;
sjekk om det er mulig å avslutte applikasjonen i en hvilken som helst driftsmodus, og om den vil gjenoppta driften i samme modus;
sjekk om alle rader vises på nødvendig språk, og om applikasjonen inneholder et oversettelsesalternativ;
sikre at applikasjonskomponenter er synkronisert med brukerhandlinger;
gi veiledning som kan hjelpe deg å forstå applikasjonen og bruke den effektivt.

Testing mobil applikasjon utføres gjennom brukermedvirkning, siden kun ekte folk kan forstå de subjektive følelsene forårsaket av å jobbe med applikasjonen.

Mobilapplikasjonstesting er en testmetode som tar sikte på å bestemme nivået av brukervennlighet, lærebarhet, forståelighet og attraktivitet for målgruppe et produkt utviklet i sammenheng med visse forhold.

Nivået av brukervennlighet vurderes ut fra følgende punkter:

Produktivitet og effektivitet - hvor mye tid og trinn det vil ta brukeren å fullføre hovedoppgavene til applikasjonen; for eksempel legge ut nyheter, registrere deg, foreta et kjøp (jo mindre tid og trinn som kreves, jo bedre).
Nøyaktighet – hvor mange feil gjør brukeren mens han kjører applikasjonen?
Minneaktivering (påminnelse) – Hvor lenge husker brukeren hvordan applikasjonen skal brukes etter å ha stått ubrukt over lengre tid? (Gjentatte operasjoner etter en forsinkelse bør være raskere enn for en ny bruker).
Emosjonell retur - hvordan føler brukeren seg etter å ha fullført oppgaven: opplever han blandede følelser, stress, eller tvert imot, likte han alt? Ville han anbefale systemet til vennene sine?

To prinsipper for å forbedre brukervennligheten:

"Fool proof" - hvis et felt ber deg om å angi et telefonnummer, bør rekkevidden begrenses til kun tall, og tastaturet bør utformes deretter. Det samme bør gjøres for E-post og andre elementer som krever dataregistrering.
Deming Cycle (Plan-Do-Study-Act) - Dette betyr at design- og brukervennlighetsinformasjon bør tas fra eksisterende brukere og basert på deres meninger bør endringer i applikasjonen planlegges.

Ingen liker et råprodukt, og når det oppstår problemer med en mobilapplikasjon, husker de gale utviklere. Kunden og brukerne bryr seg ikke om hvor mye krefter som ble brukt på å implementere en smart applikasjonsbufringsalgoritme bakgrunn. I de fleste tilfeller vil de bare virkelig sette pris på den visuelle delen og arbeidet med grensesnittet.

For våre ansatte har vi laget en sjekkliste over vanlige feil i brukervennligheten til en mobilapplikasjon. Denne listen har blitt praktisk verktøy for en prøvekjøring av neste produkt før levering. Mine medutviklere tester seg selv ved å bruke det, og testere aksepterer arbeidet til programmerere.

Så la oss komme i gang.

Arbeid med skjermer

Alle navigasjonselementer på skjermen må være av tilstrekkelig størrelse og være plassert på optimal avstand fra hverandre (slik at brukeren definitivt kommer til de rette);

Applikasjonen skal ikke krasje når du raskt trykker på én eller flere knapper samtidig;

Ingen blanke skjermer. Det er viktig at brukeren, på hvert trinn av arbeidet med applikasjonen, forstår hva som skal gjøres videre og hva som skjer akkurat nå.

Minneressurser

Minnelekkasjer kan oppstå under langvarig arbeid i en applikasjon, og på vinduer med et betydelig antall bilder. Oppstår ofte når bildebufring ikke fungerer riktig;

Applikasjonsfeil kan vises som svar på mangel på minne for funksjonen til smarttelefon-operativsystemet - test både mens du kjører i bakgrunnen og i aktiv modus;

Systemfeil ved overføring eller installasjon av et program til et SD-kort er et åpenbart, men vanlig problem;

Tekniske funksjoner for skjermer og mobilenhets OS

På netthinneskjermer vises tekst og andre grensesnittelementer mindre enn på vanlige skjermer. Følgelig, hvis bilder for en netthinneskjerm ender opp i en versjon uten netthinne, kan de fremstå som ganske store;

Applikasjonen må tilpasses liggende og portrettmoduser på smarttelefonen;

Kontroll av OS-versjonen under installasjonen bør utelukke muligheten for å installere applikasjonen på en ikke-støttet mobilenhet;

Det er viktig at de visuelle komponentene i applikasjonen samsvarer med deres formål når det gjelder plattformens betydning og konsepter (løsninger som er optimale for en plattform kan lett bli upassende i en annen);

Reaksjon på ytre stimuli

Varsler fra andre applikasjoner, anrop, SMS, MMS;

Lader enheten.

utlade, slå av eller ta ut enhetens batteri;

Tid og betingelser for enheten for å gå inn i standby-modus, inkludert passordbeskyttelse;

Deaktiver og aktiver mobilnettverk, flymodus, Bluetooth, GPS.

Koble til og fra USB-kabel, SD-kort og andre eksterne enheter;

Mistet forbindelse med proxy eller server;

Lokalisering

Kontrollere nøyaktigheten og korrektheten av oversettelsen;

Klargjøre korrespondansen mellom alle etiketter og skjemaene og knappene som de er relatert til;

Sjekke spesifikke funksjoner ved internasjonalisering, skilletegn i tall, datoformater. For eksempel er vi vant til datoen i formatet DD.MM.RR, mens for amerikanere er den allment aksepterte datoen MM.DD.RR.

Tilbakemelding

Responshastigheten til grensesnittelementer bør være ganske høy, selv på de fleste svake enheter av alt som applikasjonen din støtter;

En indikator for innholdslasting eller tilsvarende melding om nødvendig tid skal vises i hvert ventingsøyeblikk;

Varsler med feil ved tilgang til mobilnettverket, Bluetooth, GPS skal vises riktig;

Forsiktighetsmeldinger bør være åpenbare for brukeren hvis de prøver å slette viktig informasjon;

Varsler om slutten av et spill eller en prosess skal alltid vises riktig;

Det er viktig at varsler (applyder og vibrasjoner) synkroniseres med andre hendelser som vises på skjermen.

Oppdateringer

Den samme versjonen må støttes operativsystem, som i forrige versjon applikasjoner - hvis oppdatert versjon applikasjoner bruker ny funksjonalitet operativsystem, så må du lage en nedstrippet versjon av applikasjonen for tidligere støttede OS-versjoner.

Alle brukerdata i applikasjonen må lagres etter installasjon av den oppdaterte versjonen.

La oss gi et enkelt eksempel fra selskapets praksis - Livsstilsapplikasjon TRENDMEON. I den opprinnelige versjonen av applikasjonen, da du først startet applikasjonen, ble hele databasen med rabatter lastet ned på en gang, og deretter vist lokalt.

Men snart ble et problem oppdaget - hvis brukeren hadde Sakte internett, rabattdatabasen lastet sakte. Brukere oppfattet dette som en feil. De mente at søknaden var frosset og gikk ut av den. Etter de første negative anmeldelser Vi har endret algoritmen for å vise rabatter (nå er ikke hele databasen lastet på en gang), og dermed redusert ventetiden ved første pålogging til 1 sekund. I tillegg varsler vi brukeren om mulige forsinkelser når de går inn i applikasjonen første gang.

Det var mange eksempler på småting som viste seg å være sentrale i vår praksis. Vi vil være glade hvis vår generaliserte liste over de viktigste hjelper andre selskaper med å utvikle sine egne mobilapplikasjoner. Vi inviterer deg til å dele dine erfaringer i kommentarene.