Share
Enten du jobber internt, kontraherende eller for et byrå, trenger bedrifter av mange forskjellige grunner. Etablerte selskaper i særdeleshet trenger å ta vare på eksisterende kunder og enhetene de bruker. Ofte betyr det en ny app for både Android og iPhones.
I en ideell verden ville vi tilbringe måneder med å designe to apper. Men i realiteten tillater mange prosjekter ikke så mye tid. For noen av programene jeg har jobbet med, har tidsfristen vært tett nok til å designe en app, enn si å dele prosjektet helt inn i to.
Ofte utformer du en app, med tweaks blir laget før du overleverer det til to utviklingsgrupper. Hvis du designer en app på denne måten, er det viktig å forstå forskjellen mellom de to plattformene tidlig, og de raske måtene du kan få opplevelsen til å føle seg hjemme hos hver.
Det er sannsynlig at du vil ha en personlig preferanse for ett system. Jeg har alltid brukt iPhones, så jeg har en mer naturlig forståelse av brukergrensesnittet på IOS. Det første du må gjøre er å ta tak i den andre plattformen, og den beste måten å gjøre dette på er å kjøpe en annen enhet, en Android i mitt tilfelle. Det kan også være en god ide å bruke dette som din primære enhet for lengden av prosjektet, for virkelig å få en følelse for plattformen.
Hvis du jobber internt, få dem til å kjøpe deg en testenhet. Hvis det er noen problemer, kommuniser med ledelsen den verdien som forståelse av den alternative plattformen vil legge til designarbeidet ditt (kostnaden er dyr for to enheter ute av din egen lomme, men for en bedrift er det en lav kostnad i forhold til utlegget på design og utvikling av en ny app). Hvis du jobber frilans, bør du kunne skrive det mot din skatteregning.
Som vi designer for begge plattformene samtidig, mens vi arbeider med den virkelige verden hvor tiden er begrenset, må du akseptere realiteten av å prioritere en plattform fra begynnelsen. Gjør denne avgjørelsen ikke basert på din personlige preferanse, men basert på markedet for appen din. Gjør flere personer i markedet ditt Android-telefoner? Er det en betalt app? Hva er målgruppen? Å stille disse spørsmålene vil hjelpe deg med å bestemme hvilken som helst å foretrekke.
Les opp UI-retningslinjer for Android og iOS. Tidligere var Apple kjent for å være strengere med sine retningslinjer. For å få en app i appbutikken, er det en godkjenningsprosess som tar omtrent to uker. Det er ingen godkjenningsprosess for Play-butikken. Men på grunn av denne nedre hindringen for oppføring på Android har kvaliteten på design tradisjonelt vært dårligere. Google ønsker å endre dette med retningslinjene for Material Design.
Material Design Estetikk har blitt kjent for webdesignereDet er mange gode og gratis, brukergrensesnitt som du kan bruke til prosjektene dine (du finner noen oppført på slutten av denne artikkelen). Ved å bruke disse komponentene vil det naturligvis gi appen din en naturlig følelse. Men selv når du får UI-kittene, kan det være vanskelig å vite hvor du skal avvike og hvor du skal være den samme mellom plattformer, så det er der jeg vil hjelpe.
Følg disse enkle trinnene, og appen din vil være på riktig spor for å passe inn på både Android- og IOS-enheter.
Siden iOS7 har Apple skiftet til en flatere designstil, og dyttet de skeuomorfe skyggene, teksturer og effekter som definerte iPhones tidlige år. Android, etter å ha vært mer systematisk i stil i begynnelsen, har gått litt den andre veien. Googles nye retningslinjer for materialdesign skaper mer subtile referanser til den virkelige verden, med en lagdelt "papir" -tilnærming som gir mer hierarki.
Android-telefoner har en tilbakeknapp, som kan brukes til å gå tilbake til forrige skjermer i appen.
Kom tilbakeiPhones har ikke denne knappen, så det må være en måte å reise tilbake til forrige skjermbilde. Dette gjøres vanligvis av en "tilbake" chevron øverst til venstre på skjermen, men må vurderes gjennom de ulike reisene i appen din.
Det finnes globale elementer (som en statuslinje og overskrift) som vises på alle sider i designet. Du bør ikke endre høyden eller stilen på disse stolpene i det hele tatt hvis du vil at appen skal føles innfødt, så jeg vil anbefale å definere dem en gang i ditt første side design for hver plattform. Deretter kan du bruke en plassholder (eller status og topplinjen fra ditt primære operativsystem) på hver av dine mockups, men indikere for utviklere at det skal være det samme over hele linja.
Det er små forskjeller mellom navigasjonsfeltene på hver plattform. På Android er teksten justert, mens iOS er sentrert. På IOS erstatter mange selskaper tittelen på hovedsiden med selskapets logo, men dette er ikke best praksis på Android. Statuslinjen (med nettverks-, batteri- og tidsinformasjon) er en innfødt komponent, og du trenger ikke å vurdere designen. Bare vær sikker når du presenterer mockups for å bruke den riktige for å unngå forvirring eller distraksjon.
Kanskje det største punktet med forskjellen mellom iOS og Android-plattformer er navigering. Det primære navigasjonsmønsteret på Android er en skuffemeny. Android-brukere går naturligvis til dette for menyelementer, og det pleier å være allestedsnærværende gjennom hele opplevelsen. Apples retningslinjer er mer for en tabulator, som ligger nederst på skjermen, og gir enkel tilgang til toppnivåområdene i appen. Når du bestemmer topparkitekturen til appen din, kan du planlegge to separate menyer for de to plattformene.
Å tenke på arkitekturen til appen er uten tvil viktigere enn menyens layout - et punkt jeg laget i en annen artikkel om noen av disse problemene. Hvis strukturen din er lyd, følger navigasjonen.
Som du ser her, er det to navigasjonsmønstre: en skuffemeny for Android og en faneboks for iOS. Det er noen ganger lettere å bare skjule navigasjonslaget mens du arbeider med individuelle visninger.
Kort blir det primære brukergrensesnittet i digital design. De er allsidige og lar brukerne forbruke raske biter av innhold på en måte som passer til mobil oppførsel. Visuelt passer kortene godt sammen med Apples materielle design (inspirert av papir). Å bruke dropshadows og rimelige takrenner mellom kortene vil skape et naturlig utseende og en naturlig følelse.
På IOS trenger bruk av kort mer omsorg og hensyn. Selv store apper som Facebook og Pinterest bruker kort på en måte som er litt i tråd med IOS-retningslinjene. IOS-retningslinjene antyder bruk av dybde i transparenter og overlegg, men grunnvisningen er vanligvis mer flat. Instagram bruker en helt flat designstil, selv om hvert innlegg kan betraktes som et kort fra arkitektonisk synspunkt. Det er verdt å se på hvordan Instagram får den samme komponentfølelsen i en iOS-stil. Hvis du går med kort på iOS, vær veldig forsiktig med bruk av skygge, og prøv å holde dem så subtile som mulig.
Kort for Android og iOS, gir noen dimensjon litt rådighetSystemfontefamilien på iOS er Helvetica Neue. På Android er det Roboto. Selv om stilen på skrifttypene er merkbart forskjellig, er typene av skriftene ganske like. Hvis du sparer tid, vil du være trygg nok til å jobbe med bare én, men kommunisere til utviklere for å implementere riktig skrift for systemet. Når du arbeider med viktige layouter og ekstremer i typeformat, anbefales det at du i det minste teste layoutet ditt med begge skrifttyper.
Hvis du vil gå den ekstra milen, må du ta nærmere oppmerksomhet til typografiske og layoutkonvensjonene på hver plattform, igjen med henvisning til retningslinjene ovenfor. Noen få generaliseringer:
Dette er et veldig enkelt eksempel, for å understreke hvordan selv på enkle måter typografien umiddelbart kan fortelle deg om du har å gjøre med en Android eller en iOS-app.
IOS (44px @ 1x) og Android (48dp - 48px ved 1: 1-forhold) har litt forskjellige retningslinjer for berøringsmål. Retningslinjer for materialeutforming foreslår også å justere alle elementene til et 8 dp kvadratisk grunnlinje.
På det siste prosjektet jeg jobbet med, fant vi det sikrere å følge disse Android-retningslinjene fordi (a) det større 48px berøringsmål er trygt for begge plattformene, og (b) layoutet for Material design er mer definert og oppdatert. Uansett vil du trenge et rutenett for å jobbe med, men med Android å være mer strengt definert, fant vi 8 dp å fungere bra. Dette betyr at du skal sette opp dokumentet med 8dp inkrementer i både horisontale og vertikale planer for å lage et flislagt gridoppsett.
Det finnes flere knappestiler som er definert i Material Design:
Sammenlignet med Materielldesign, er iOS-apper vanligvis flate i utseende, uten bruk av dybde- eller dropskygger. De primære knappene har en fyllfarge, mens sekundærknappene reverseres, ved hjelp av et slag av samme farge. Denne metaforen kan bli noe begrenset, spesielt i forhold til tabber og andre elementer som skal følges. For å få denne svært flate stilen riktig, er det viktig å ha klare og konsistente metaforer for hvilke farger som betyr i appen din.
IOS har også en vanlig tekststiltast, men den deler ikke Android's store stiler, og er lettere i skrifttypevekt.
Handlingsark lar brukerne velge mellom en rekke handlinger fra ett UI-element. For eksempel, når jeg berører (eller lenge trykker) på et bilde, vil jeg kanskje dele, laste opp, kopiere eller slette bildet.
IOS og Android håndterer dette på litt forskjellige måter. For det første finnes det lignende handlingsark som vises nederst på skjermen, som et overlegg på den nåværende visningen.
Med handlingsark, overlegg og varsler, bruker iOS og Android forskjellige detaljer for å angi dybde i lag:
Eksisterende bare på Android, dette er en rask brannmetode for å gjøre et valg. Vær imidlertid oppmerksom på at det ikke er en innfødt iOS-ekvivalent. I eksemplet nedenfor trykker brukeren på "profil" i trinn 1, og presenteres med en enkel meny på den aktuelle plasseringen for å velge en av de tilgjengelige profilene. Disse menyene brukes også ofte fra overleggsknappen i handlingslinjen, angitt med tre vertikale punkter.
For spesielle innganger som dato og klokkeslett kommer Android nå med innebygde dialoger. Disse ser ut som varslings popup-vinduer, men med brukergrensesnittet er det spesielt tatt hensyn til å legge inn denne typen data. Et eksempel er vist på en kalenderinngang. Android har et optimalisert overlegg for å legge inn en dato. IOS omhandler dette ganske annerledes, som et hjul som kommer opp som et bunnplate. Vær forsiktig med å planlegge disse, og kommuniser med utviklere tidlig på inputkomponenter.
Segmenterte kontroller brukes til å bytte mellom annet innhold i en enkelt visning. Deres bruk er mye det samme, men de er veldig særegne visuelt på hver plattform, så det er viktig å bruke riktig stil. På IOS er det tre faner, utformet på samme måte som linjeknappene som ble diskutert tidligere. På Android er de betegnet med en enkel understreking, og gitt mye mer hvitt plass for å betegne deres interaksjon.
Det er viktig å få stilen til disse rettene fordi de kan kontrollere viktige handlinger som å registrere seg, godta vilkår eller til og med bekrefte betaling. Vi vil at de skal føle seg pålitelige og innfødte.
Android-varslene bruker flatknappestablene som ble vist tidligere, dimensjoner som finnes i retningslinjer for materialdesign. Handlingene sitter nederst til høyre for varselet. "Knappene" er faktisk helt tekstbaserte. De bruker alle caps for å gi dem mer struktur, og de har den primære handlingsfargen på appen din.
På iOS blir handlingene skilt av delere. De er vanligvis i setning eller tittel tilfelle, som de får sin struktur fra de separate blokkene. De er sentrert i feltet, og igjen vil de arve din aktive farge.
Ikon design er ganske spesialisert område i UI design. Enten du bruker gratis ikoner, påbegynner en ikondesigner eller designer ikonene selv, er det en distinkt stil som er naturlig for hver plattform. IOS populære linjepiktogrammer, med svært tynne streker. Android-systemikonene har tykkere streker, eller er helt solide ikoner. Tidligere brukte Android-ikoner perspektiv eller en tredimensjonal vri, men nå angir de retningslinjene de todimensjonale ikonene ser direkte på. Her er et raskt eksempel med flere ikoner for sammenligning, eller bruk de direkte koblingene til ikonretningslinjer for Android eller iOS
Uheldig 13. Det er noen UI-detaljer som kan gå gjennom sprekker. Vanlige som varsler og lasting av ikoner blir ofte overlatt til utviklere. Du har kanskje opplevd rogue spinnere og merkelige varsler som har følt seg i orden med resten av appen. Det pleier å være innfødte løsninger for disse, men de kan tilpasses stilen til appen din. Dette er definitivt et område hvor samarbeid med utviklere er den beste måten å bestemme hvilken vei din skal fungere.
Radio knapper, boksene, feltene og bryterne er funksjonelle komponenter som bør gis en innfødt følelse. Som med varsler og dialoger, er disse kontrollene og inngangene et område av tillit og kjennskap til brukeren. Bruk de opprinnelige komponentene så mye som mulig for disse, slik at folk (a) vet hvordan de skal brukes, og (b) stoler på appen din med deres sensitive data eller betalingsdetaljer.
I eksemplet nedenfor ser vi bryter- og radioknappekvivalenter for Android og iOS. Igjen er forskjellene små nok til at du skal utvikle seg med ett design, og tweak for den andre senere, men de subtile forskjellene er avgjørende for et innfødt utseende. Bruk brukergrensesnittet ditt så mye som mulig for disse komponentene, og kommuniser igjen med utviklere tidlig i prosessen.
Android (venstre) og iOS (høyre)Det er ikke en umulig oppgave å skape en innfødt følelse for appen din på både iOS og Android med ett design. Prøv å holde deg oppdatert på disse tweaks fra begynnelsen, hold øye med komponenter som ikke synkroniseres på en plattform, og jobber alltid så tett som du kan med utviklere.
Denne artikkelen vil forhåpentligvis gi deg raske svar på hvor du skal skille ut design for to apper, men du må også ha verktøy og maler for å kunne utføre designet ditt riktig. Det er mange tilgjengelige ressurser som du kan bruke som utgangspunkt, her er noen av de beste:
Hvis du vil vite mer, har mye av informasjonen jeg har oppgitt, funnet i plattformens retningslinjer. De er ganske omfattende, så jeg har nettopp trukket ut de delene som er viktige å sammenligne. Men hvis du har mer spesifikke spørsmål, er dette det beste stedet å starte:
Disse brukergrensesnittene sparer deg for å gjenopprette grunnleggende innfødte kontroller og matchende størrelser. Du kan plukke ut brikkene du trenger og deretter bytte mellom dem for Android og iPhone-utgangen av designene dine.
Selv om du lager dine egne eller påloggingsikoner, er de nyttige å ha som plassholdere mens du jobber. Ikondesign kan være en jobb i seg selv, og du vil ikke at ikoner skal bremse deg mens du får en generell følelse for appen din. Jeg har nylig funnet linkene under på ikoner8 ser ganske bra ut, eller flaticon.com er flott for flere generelle ikoner.
Det er alltid nyttig å ha enhetsmockups for å presentere appen din. Disse kommer i mange kategorier. Du vil kanskje ha en grunnleggende enhetskonfigurasjon for kontekst, en forenklet flat enhet for å la appen din skinne, eller en livsstilsmockup for å presentere en brukskasse. Her er noen ressurser jeg har funnet nyttig, det er mange flere der ute. Når det gjelder Android-enheter, vær forsiktig som du velger. Jeg vil lene seg mot Nexus-serien, da de er Googles egne telefoner og ikke vil gi en ide om andre produsenter.
Accentsconagua