Share
I dag publiseres mest vellykkede mobile applikasjoner på flere plattformer. Det er en sterk tendens til å prøve å designe applikasjons arbeidsflyter som fungerer, uavhengig av plattformen. Men dette kan være en feil.
Mange programmer kan finne seg opphevet fra "bare noen app jeg lastet ned" til "en viktig app jeg må ha på enheten min!" ganske enkelt ved å gjøre noen tweaks til måten brukerne får tilgang til programmet.
Ved å gi forskjellige, smart utformede inngangspunkter til søknaden din, kan søknaden din meget godt bli brukt mye mer og bli uvurderlig for brukerne dine.
Grunnleggende applikasjonsinngangspunkter er ganske standardiserte på de forskjellige mobilplatformene, og utviklere fokuserer ofte på disse. Det er imidlertid også plattformsspesifikke mekanismer for å få brukeren til å bruke søknaden din oftere, som for det meste er ganske grei å implementere, og ofte vel verdt innsatsen.
I denne opplæringen vil vi gi en oversikt over vanlige inngangspunkter for Android-applikasjoner. Disse inngangspunkter vil fokusere på å sikre at søknaden din maksimerer verktøyet til brukeren.
I denne diskusjonen bruker vi terminologien søknadspunkt å bety "en måte som brukeren kommer til din søknad og bruker den." De fleste av disse metodene resulterer i at programmet lanseres og kjører, men det er også noen subtile måter du kan oppfordre brukeren til å bruke og sette pris på søknaden din uten å måtte starte den.
Jeg tror ikke det er urimelig å si at jo mer en bruker bruker søknaden din, jo mer vellykket vil søknaden din sannsynligvis bli. Hvordan du får nytte av denne bruken, enten ved å lade avgift, gjennom kjøp i app eller ved å vise annonser, er ved siden av punktet.
Det vi snakker om her, gjør søknaden din så nyttig eller viktig for brukeren at de ikke kan leve uten den. Hvis de kjøper en ny enhet, er det første som de gjør, laste ned appen din.
Android-operativsystemet er godt utformet for at applikasjoner skal kunne integreres dypt med brukerens arbeidsmiljø, mens de fortsatt er fleksible nok til ikke å anta eksistensen av bestemte applikasjoner eller tjenester.
"Del" -funksjonen er et godt eksempel på denne smarte designen. Et program som lager innhold trenger ikke å skrive spesifikk kode for å dele det innholdet på Facebook, Twitter eller SnapChat. Programmet forteller bare operativsystemet "Hei, jeg har dette til å dele!" og operativsystemet sjekker hvilke applikasjoner som kan håndtere denne forespørselen.
De fleste applikasjoner drar nytte av å ha mer enn ett inngangspunkt. Hvis søknaden din ikke vises til brukeren på de riktige tidspunktene, mangler du viktige muligheter for å forbedre brukeropplevelsen. Dette er spesielt viktig for applikasjoner i verktøy og livsstilskategorier.
En annen grunn til å vurdere flere inngangspunkter har å gjøre med brukerens raffinement. Hvis du noen gang har brukt tid på å se på noen bruker en mobil enhet, spesielt noen som er minst en generasjon eldre eller yngre enn du er, så har du sikkert allerede innsett at folk bruker enheter på en annen måte.
De navigerer annerledes, og de har forskjellige nivåer av forståelse for operativsystemet deres enheten kjører. Derfor er det fornuftig at du ønsker å imøtekomme disse forskjellige typer brukere.
Det andre argumentet er at jo flere måter du gir brukeren, jo mer vil de bruke søknaden din, noe som er bra, riktig?
Selvfølgelig har forskjellige applikasjoner forskjellige behov. Ikke alle strategier gir mening for hver applikasjon, men generelt sett, når du bare stoler på lanseringsmetoden for søknaden din, selger du deg selv - og brukerne dine kort.
Programmer kan ikke ha for mange inngangspunkter, men du bør sørge for at alle inngangspunkter du bruker bruker, gir mening for produktet. Du bør ikke vise søknaden som et alternativ for lansering hvis det ikke gjør noe nyttig for brukeren.
Det du ikke vil ha er for din søknad å være et ordensforstyrrelser. Så det er ikke fornuftig, for eksempel at de fleste musikkappene støtter visning av tekstdokumenter, eller for et spill for å aktivere videoavspilling.
Du vil få din søknad lansert og brukt av brukeren din så mye som mulig. En uunnværlig søknad er en vellykket. Ikke bekymre deg om å forvirre brukeren ved å gi for mange inngangspunkter. På grunn av måten Android-operativsystemet er designet på, vil søknaden din rett og slett være tilgjengelig ved brukerens fingertupper akkurat når de trenger det, og forbli stille i bakgrunnen når det ikke er nødvendig.
I denne delen presenterer vi en liste over noen av de vanligste måtene å få brukeren til å samhandle med Android-applikasjonen din. Denne listen er på ingen måte omfattende og nye metoder oppfinnes på nesten daglig basis. Men i brede slag er det noen av de mest effektive metodene for å lokke brukere inn og få dem avhengige av søknaden din.
Omtrent hver mobil bruker forstår standard app lanseringsscenario: brukeren navigerer til app listen, tapper appens ikon og lanserer den. Ferdig!
Det spiller ingen rolle hvilken plattform vi snakker om. Hvis du trykker på et programs ikon og har applansering, forstås det godt av de fleste brukere. Fordi det er en måte din søknad vil helt sikkert bli brukt, må du sørge for at du bruker tid på å få dette til riktig. Fokuser på effektivisering av lanseringsprosessen, noe som gjør det så raskt og responsivt som mulig, samtidig som du minimerer kranene som er nødvendige for at brukeren skal kunne komme seg til virksomheten.
Den store fordelen med standard lanseringsmetoden er at omtrent alle brukere vet hvordan det fungerer. Ulempen er selvsagt at brukeren må huske å gjøre dette på egen hånd.
Prøv denne lille øvelsen: Ta tak i enheten din og gå gjennom alle appene du har installert. Hvor mange lastet du ned, kanskje løp en eller to ganger, og så glem alt? Har du lyst til å lansere dem nå, eller spilder de bare plass på enheten din?
De fleste applikasjoner fungerer på denne måten. Spillene pleier spesielt å bruke denne metoden, lansere, starte eller fortsette spill, spill spill, lagre og lukk spill.
En enkel måte å få brukerne til å "huske" for å komme tilbake til appen er å bruke varsler. Android varslingssystemet gjør at rike meldinger kan leveres til brukeren. Brukeren kan lese meldingen og, hvis den er tilbøyelig, starter programmet.
En god tommelfingerregel er å gi det rikeste og mest relevante innholdet i varsler. Meldingsfrekvens er også svært viktig. Du må finne en balanse mellom å minne brukere om å holde dem fra å glemme søknaden din, men ikke så mye at du spammer eller misbruker varslingssystemet.
Det finnes en rekke beste fremgangsmåter for varsler og bestemte no-nos som for eksempel brukerne dine med markedsføringsvarsler.
En e-postklient, for eksempel, kan varsle brukeren hver gang en ny e-post ankommer, men stable og kollaps disse varslene etter behov. Hvis jeg for eksempel forlater telefonen uten tilsyn for dagen, kan jeg motta 55 nye e-postmeldinger, men når jeg ser på meldingene mine, bør det bare være ett varsel som angir at jeg har 55 nye e-postmeldinger i stedet for 55 meldinger jeg må gå gjennom en etter en.
Vær oppmerksom på at disse varslene er rike: de inneholder ofte informasjon om avsenderen og emnelinjen og til og med de første setningene i meldingen. De sier ikke bare "Du har en ny e-post."
Hvis søknaden din er mindre et verktøy og mer den frittstående typen, som et spill, kan du fortsatt bruke varsler for å forbli brukeren tilbake til søknaden din. Jeg har et spill jeg spiller noen ganger, og hvis jeg går noen dager uten å spille, tilbyr de meg noen gratis spill i spillet. En strategi som dette bør brukes med forsiktighet. Du må unngå å plage brukeren din, kanskje ved å la dem slå av disse varslene.
Android-brukere tilpasser enhetene sine med widgets på deres hjem- og låseskjermer. Å lage en widget som utfyller søknaden din, er en utmerket måte å holde brukerobjektene trent på din søknad.
Ulike applikasjoner vil ha forskjellige widgetkrav. Widgets kan gjøre mer enn visningsdata. Du kan aktivere dem slik at brukeren din kan samhandle med dem for snarvei hyppige oppgaver, for eksempel å oppdatere statusen til sosial media eller holde seg orientert om eventuelle endringer i programmet. Widgets kan til og med starte i hele programmet, hvis flere funksjoner trengs.
Et værprogram kan for eksempel bruke en widget for å gi oppdaterte prognosedata for din nåværende posisjon. Vær kreativ om hvordan du bruker widgets. For eksempel kan et bildegalleri-program vise søte fotografier. Et spill kan ha en leaderboard-widget, noe som kan lokke brukerne tilbake når vennene deres slo sin høyeste poengsum. Et reiseprogram kan inneholde en widget som angir det nåværende TSA-trusselsnivået eller omtrentlig ventetid for sikkerhetslinjen på nærmeste flyplass.
Standard lanseringssekvens er en hvor applikasjonen bare lanserer uten noen reell kjennskap til brukerens hensikt i applikasjonen. Du kan imidlertid også konfigurere søknaden din for å starte rett inn i bestemte funksjoner ved å gi noen metadata med lanseringen.
Slike lanseringer kan være implisitte eller eksplisitte. Det vil si at du kan opprette forespørsler om å starte et bestemt program og sende det til dataene, eller du kan fortelle operativsystemet "Hei, jeg har denne dataen jeg vil gjøre noe med, hvilke apper kan håndtere det?"
La oss først snakke om den eksplisitte metoden. I dette tilfellet vil du sannsynligvis være eieren av dataene til å begynne med. For eksempel kan et musikkspillingsprogram ha en app-widget som lar brukeren spille av musikk fra en spilleliste. Brukeren kan imidlertid klikke på den widgeten, og hele musikkspilleren kan starte og vise alle spillelister - eller innholdet i den spillelisten. I dette tilfellet vil widgeten din forårsake en eksplisitt lansering, fordi du ikke vil overlate den til operativsystemet, da det kan tilby brukeren andre musikkspillere i tillegg til deg. Det er ikke en standard lansering, i stedet vil du passere i spillelisten data for gjeldende spilleliste som vises i widgeten og bringe brukeren rett til spilleliste redigeringsskjermen for å gjøre sine ting.
På samme måte kan widgeten vise den nåværende sangen som spilles av den spillelisten, og hvis hun tapper albumikonet for sangen, kan programmet din eksplisitt starte i albumoppføringsskjermbildet.
Android's virkelige kraft begynner virkelig å vise når vi begynner å snakke implisitte hensikter. I dette tilfellet spesifiserer ikke den søkende applikasjonen hvilket program som skal håndtere en forespørsel. I stedet beskriver det bare forespørselen til operativsystemet, som bruker intentfiltreringsreglene for å bestemme hvilke applikasjoner som er i stand til å håndtere forespørselen. Dette er også hvordan operativsystemet viser hvilke applikasjoner som kan håndtere et vedlegg fra en e-post eller tekstmelding.
For eksempel kan en bruker motta en musikkfil fra en venn og ønsker å spille den. Det er usannsynlig at e-postprogrammet kan spille av lydfilen. I stedet er det mer sannsynlig at klienten bruker en implisitt hensikt å få operativsystemet til å vise en liste over programmene som kan spille av lydfiler. Så det er ganske tydelig at hvis din søknad er i stand til å spille musikk, vil du at operativsystemet skal kjenne det slik at brukeren kan velge søknaden din over andre konkurrerende apper.
Din søknad kan lytte etter bestemte hendelser som sendes av operativsystemet og opprette hensiktsfiltre for å angi hvilke typer aktiviteter og hvilke typer data det kan fungere med.
Et medieprogram kan for eksempel angi at det kan spille av bestemte musikkformater som mp3- eller wav-filer. På samme måte kan et tekstbehandlingsprogram være i stand til å vise eller redigere dokumenter, for eksempel doc og txt-filer.
Det ville imidlertid ikke gi mye mening for et tekstbehandlingsprogram som tilbyr å lansere når brukeren prøver å spille musikk, så du vil konfigurere søknaden din for å filtrere ut forespørsler som ikke samsvarer med kjørkriteriene.
Intentfiltreringsmekanismen på Android er veldig kraftig og fleksibel. Det er en av de mer karakteristiske og unike egenskapene til Android-plattformen, og det er vel verdt å bruke, selv om programmet også er tilgjengelig på plattformer som ikke støtter implisitte hensikter. Dette gjelder spesielt hvis søknaden din kan håndtere vanlige typer innhold, for eksempel tekst eller lyd. En musikkspiller bruker musikk. En sosial media-applikasjon kan forbruke tekst, bilder og videoer. Du får ideen.
Som nevnt tidligere, er dette hvordan Android-funksjonen "Del" fungerer. La oss si at du lager et sosialt medieprogram som lar brukerne legge inn tekstmeldinger, bilder, videoklipp og lydfiler. Den enkleste versjonen av dette programmet kan støtte standard lanseringsscenariet:
Dette er et rimelig brukerscenario, og det er absolutt en som noen sosiale medier app skal støtte, men det er ikke veldig spennende. Det tar ikke hensyn til alle de andre appene som brukeren har kjørt på enheten, og genererer spennende og relevant innhold som brukeren kanskje vil dele.
Med noen få enkle modifikasjoner kan du la operativsystemet vise søknaden din til enhver applikasjon som genererer innhold som er viktig for din tjeneste.
Vi har snakket om hvordan du klargjør søknaden din for å godta data fra andre applikasjoner, men det er også viktig å vurdere omvendt situasjon - aktivere "Del" -funksjonen i din egen applikasjon.
Du kan i utgangspunktet føle deg litt skeptisk til at brukerne i utgangspunktet kan eksportere data fra applikasjonen til andre apper. Det kan til og med være programmer som prøver å forhindre dette. Men de fleste applikasjoner trives når de spiller pent med resten av operativsystemet.
Her er et eksempel. Et grafikkprogram kan ha funksjoner som lar deg lage fantastisk kunst. Hvis denne applikasjonen ikke gir mulighet til å dele brukerens kreasjoner, er brukerens innhold fast i applikasjonen.
Når brukere krever noen måte å eksportere bildene sine, kan utviklere som ikke er veldig kjent med Android, fristes til å utvikle sin egen eksportfunksjonalitet. Dette er sjelden nødvendig. Ved å bruke implisitte hensikter til å dele brukerens innhold, trenger ikke dette grafikkprogrammet å vite noe om hvilke applikasjoner som kan håndtere del forespørselen, eller hvis de er installert på brukerens enhet. Det er operativsystemets ansvar. Grafikkprogrammet oppretter en forespørsel som sier "Hei, jeg har denne bitmapfilen. Kan noen gjøre noe med det?"
La oss si at jeg har et zombie spill jeg elsker å spille og spillet lar meg lage korte videoklipp. Så jeg bestemmer meg for å ta et lite klipp av min Zombie Hobbing-spree for vennene mine, og prøv å dele den. I denne situasjonen kan din sosialmedia søknad settes opp som frivillig for å hjelpe brukeren når de velger å dele innholdet. Din søknad sier i utgangspunktet "Hei, jeg kan dele videoklipp, gi det her!"
Konfigurere din søknad som et delmål kan være rettferdig, eller du kan bli sofistikert ved å prøve å få søknaden din tilpasning til nye medietyper som de kommer med. Vurdere om du kan gi nyttige nye måter å få brukerne til å bruke søknaden din på denne måten. Du kan bli ganske smart og nyskapende med denne typen ting. Hvis for eksempel applikasjonen din er en musikkbutikk og en spiller, kan den akseptere tekstdata og forsøke å samsvare med sangtitler eller album, og opprette en slags hyperkoblingsmekanisme.
Ulike applikasjoner skal finne ut at forskjellige lanseringsmetoder er mest effektive. Noen av disse metodene krever imidlertid betydelig utvikling og kan komplisere programmets kodebase, slik at du vil veie fordelene mot ulempene når det gjelder kodekompleksitet og vedlikehold.
En annen nyttig måte å bestemme hvilke måter som fungerer best er å samle bruksdata i søknaden din. Det er enkelt å legge til kroker til alle dine lanseringsmekanismer. Det vil gjøre det mulig for deg å se hvordan brukerens bruker bruker og ikke bruker søknaden din.
Bare husk at ikke å bruke en metode betyr ikke nødvendigvis at det ikke er en god ide, det kan bare kreve litt utdanning for å få brukerne til å innse at de kan utføre bestemte oppgaver. Dette håndteres enkelt med en hjelpeskjerm eller bruker tips og forslag til rett tid.
Bruk disse mulighetene for å integrere søknaden din tettere med Android-operativsystemet. Jo mer brukerne bruker programmet i sine daglige oppgaver, desto mer verdifullt blir søknaden din til dem. Men som applikasjoner blir mer sosialt oppmerksomme og innhold genereres av applikasjoner - enten det er tekst, bilder, lyd, videoklipp eller hva har du - mange apputviklere lærer å finne interessante måter å opprette og dele, eller konsumere dette innholdet med sine egne applikasjoner.
Accentsconagua