Android, iOS eller webapp: vælg platform efter opgaven
Platformvalget for en app skal følge brugernes opgave og de enheder, de har. Android, iOS og en webapp kan løse forskellige behov med forskelligt ansvar for udvikling, distribution og drift. Start med det nødvendige forløb, før du vælger teknologien.
Undersøg de faktiske enheder og adgangsforhold
Et internt værktøj på virksomhedens egne enheder har andre forudsætninger end en app til alle kunder. Registrér enhedstyper, eksisterende login og de situationer, løsningen skal bruges i. En medarbejder uden stabil forbindelse stiller andre krav end en kunde, der blot skal læse produktinformation.
Afklar også hjælpemidler og tilgængelighed. Brugere kan have større tekst, skærmlæser eller begrænset motorik. Det påvirker interaktion og test, uanset platform. En prototype på én ny telefon er ikke et tilstrækkeligt billede af hele målgruppen.
Sammenlign forløbet frem for løse platformløfter
| Valg | Kan være relevant når | Det skal undersøges |
|---|---|---|
| Native iOS | Opgaven retter sig mod iPhone eller iPad og deres muligheder | Enhedsfunktioner, systemversioner og distributionsform |
| Android-app | Android-enheder er en nødvendig del af målgruppen | Enhedsvariation, tilladelser og test på relevante modeller |
| Delt kode | Flere platforme skal løse beslægtede opgaver | Hvor fælles koden reelt kan være, og hvor platformstilpasning kræves |
| Webapp | Et link og browseradgang kan opfylde behovet | Browserfunktioner, installation og eventuel offlineadfærd |
Offline kræver regler for data
At vise en gemt skærm er ikke det samme som at understøtte en hel opgave uden forbindelse. Beskriv hvilke data der skal kunne læses og ændres, hvad der gemmes på enheden, og hvad der sker, når forbindelsen kommer tilbage.
Hvis to medarbejdere ændrer samme sag, skal konflikten have en aftalt behandling. Planlæg genkørsel og stabile identifikatorer, så en handling ikke bliver oprettet to gange. Afklar også tabt enhed, logout og sletning af lokale data. Det er en del af produktet, ikke en detalje til sidst.
Et app-brief til en første version
- Bruger og vigtigste opgave er beskrevet.
- Nødvendige enheder og platforme er kendte.
- Login, data og integrationer har en ansvarlig ejer.
- Offlinebehov og konflikter er afgrænset.
- Fejl, tomme tilstande og langsom forbindelse indgår i forløbet.
- Distribution, konti, test og drift er en del af planen.
- Den første version kan vurderes på konkrete opgaver.
Butiksudgivelse og drift er selvstændige leverancer
Hvis appen skal gennem en appbutik, skal konti, materiale, nødvendige erklæringer og platformskrav være afklaret. En afleveret binær fil er ikke en garanti for godkendelse eller en bestemt udgivelsesdato. Et internt distributionsforløb kan have andre krav.
Efter lancering skal nogen følge fejl, ændringer i platforme og nødvendige opdateringer. I bør eje kildekode, udgivelseskonti og dokumentation i jeres egne systemer. Det gør det muligt at vedligeholde appen og skifte leverandør uden at starte fra et ukendt grundlag.