Android VS. iOS: Sammenlign 20 UI-komponenter og -mønstre (Del 1)

20 forskelle mellem Android og iOS skal du vide, når du designer til apps på tværs af platforme

中文 版 Original kinesisk version udgivet den 10. december 2016

Android VS. iOS: Sammenlign 20 UI-komponenter og -mønstre (Del 2)

Der er flere og flere apps, der er lanceret til både Android og iOS. Men vi kan finde ud af, at disse appdesign muligvis ikke takler eller bemærker forskellene mellem Android og iOS på UI-komponenter eller adfærdsmønstre. Nogle gange kunne vi finde, at iOS-komponenterne bruges på Android-apps, eller Android-mønstre anvendes på iOS-apps. De misbrugte komponenter / mønstre kan forårsage forvirring af brugere.

For at lade udviklerne eller designerne forstå den grundlæggende forskel mellem Android og iOS lettere. Jeg vil gerne introducere og sammenligne UI-mønstre / -komponenter, der engang har forskellige navne på de to platforme, med nogle skærmbilleder som eksempler:

1. Navigationsskuffe, faner & bundnavigation VS. Fanebarer

Vi vil først tale om navigationsdesign, fordi det er et væsentligt spørgsmål om informationsstruktur, som designere har brug for at tackle, når de designer apps i begyndelsen.

Navigationsskuffe var den mest repræsentative for Android-design i 2013. Kategorielementerne i det øverste niveau af informationsstruktur sættes i en skuffe, som kan skjules for at gøre brugergrænsefladerne enkle og rene. Men senere, med masser af undersøgelser, der afslørede brugervenlighedsproblemerne i navigationsskuffen, begyndte Google at flytte vigtige funktioner / kategoriemner fra navigationsskuffer til faner i deres apps; Youtube var et eksempel på det. I 2016 optrådte bundnavigation i Retningslinjer for materialedesign, og det viser, at nogle brugergrænsefladekomponenter i Android kommer nærmere iOS-dem.

Youtube's strukturudvikling: De vigtige funktioner, Mine abonnementer, historie og afspilningsliste lægges i en skuffe -> Appstrukturen er omorganiseret, skuffen fjernes, og hovedfunktionerne flyttes til faner -> Trending føjes til faner.Google Fotos strukturudvikling: Hovedfunktioner sættes i skuffen -> Hovedfunktioner flyttes til knapnavigation -> Søg flydende handlingsknap, der kan afbryde gennemsøgning af fotos, omdannes til en søgelinje.

Bemærk, at der stadig er nogle forskelle mellem Android-faner og nederste navigation :

  1. Faner kan bruges i højere eller lavere niveauer i hierarkiet med information, men bundnavigation bruges kun på øverste niveau.
  2. Faner understøtter ikke kun at tappe men skubbe gestus for at skifte visninger, men bundnavigation understøtter kun at tappe.
  3. Varemængden i faner er fleksibel. Du kan placere 2-5 elementer i faste faner eller flere poster i rullbare faner. Men kun 3-5 varer kan sættes i bundnavigation. 2 eller over 5 varer er forbudt。

I nogle apps med dybe og komplicerede navigationsstrukturer finder vi muligvis navigationsskuffe, bundnavigation og faner vises på samme tid. Jeg anbefaler ikke, at navigationsskuffe og bundnavigation bruges på samme tid i apps, fordi det er svært at fortælle de hierarkiske strukturer mellem dem. Niveauet for navigationsskuffe er højere eller lavere end den nederste navigation? Eller er de på det parallelle niveau? De tvetydige strukturer ville forvirre brugerne. Google Plus er et negativt eksempel for mig. Jeg føler mig virkelig forvirret efter at have opdateret Google Plus og så se navigationsskuffen og den nederste navigation på samme tid i begyndelsen.

Ved at analysere aktuelle Google-apps kunne vi finde navigationsskuffe og bundnavigation er i det parallelle niveau. Tag Google Fotos og Google Plus som eksempler, efter at du har afsløret navigationsskuffen på hovedskærmen, er der ingen fremhævning på nogen kategori. Android ser ud til at placere kategorier som konto, indstillinger og andre sekundære funktioner i en skuffe og lokalisere ofte anvendte / hovedfunktioner i bundnavigation.

Google Plus

iOS har brugt de nederste ”fanebjælker” som en standardnavigation i lang tid og aldrig ændret. Fanebarer, ligesom Android-bundnavigation, har 3 til 5 kategoriemner, og du kan skifte kategorivisninger ved at trykke på elementer.

Det er værd at bemærke, at fanebjælker normalt findes, selv når du indtaster de næste eller dybere niveauer fra det øverste. Hvis du trykker på det fremhævede element på fanebjælken, kommer du tilbage til det øverste niveau. Fanebjælker forsvinder, når du er i modal visning eller indtaster detaljerede visninger med bundværktøjslinjer. I Android-apps forsvinder imidlertid både faner og bundnavigation, når du går ind på næste side i dybere niveauer.

2. App-barer (action-barer) VS. Navigationsbarer

Søjlerne på det øverste område af Android-appskærme kaldes appbjælker, f.eks. Handlingsbjælker og værktøjslinjer, som hovedsageligt bruges til at anbringe det aktuelle skærmnavn eller appnavne og handlingsknapper. Navnene sættes i venstre side af handlingsbjælker og handlingsknapper, som normalt ikke er mere end 3, placeres i højre side. Hvis handlingerne er mere end 3, vil vi bruge overløbssymbolet og sætte de mindre vigtige handlinger i overløbsmenuen.

Både Android og iOS har deres egne rygikonstilarter. Men iOS lægger normalt en streng, tilbage eller navnet på den forrige side ved siden af ​​ikonet bagpå, som lader brugerne vide, hvor de vil gå tilbage mere præcist.

Flere almindelige appbarer & navigationsbarer

3. Værktøjslinjer

Handlingsknapper kan ikke kun sættes på handlingsbjælker / navigationsbjælker, men i bunden af ​​”værktøjslinjer” på både Android og iOS.

Selvom de nederste værktøjslinjer ikke er nævnt i Retningslinjer for materialedesign (De taler kun værktøjslinjer som appbjælker), kan vi stadig finde, at de nederste værktøjslinjer bruges i Google Keep og Google Fotos.

Nederste værktøjslinjer er en af ​​de almindelige iOS UI-komponenter og kan findes i mange apps. Både ikoner og tekst som handlingsknapper og statusbeskrivelser kan lægges i værktøjslinjer.

4. Faner VS. Segmenterede kontroller

Sider i det sekundære eller lavere niveau af hierarki kan bruge "faner" på Android og "segmenterede kontroller" på iOS-apps.

Både Android-faner og iOS-segmenterede kontroller kan placeres i handlingslinjen / navigationslinjen.

Android-faner kan kun være med tekst, kun med ikoner eller med både ikoner og tekst, som sjældent findes i nuværende apps. Både ikoner og tekst kan placeres i iOS-segmenterede kontroller. Blanding af tekst og ikoner i en segmenteret kontrol skal undgås.

Al tekst, der kan tappes i Android, er OPPERCASE, og derfor er tekster på faner store. iOS-segmenterede kontroller bruger Title Case.

Om mængden af ​​varer på Android-faner, vil det være 2–5 i en fast fanebjælke. En rullbar fanebjælke kan bruges, når der er lange strenge eller mere end 5 genstande. En segmenteret kontrol skal have fem eller færre segmenter på iPhone for at sikre nok plads til let at tappe.

5. Knapper

Grundlæggende er den eneste forskel mellem Android- og iOS-knapper streng kapitalisering og udseende stil.

Android-knapper har hovedsageligt 2 stilarter, "flade" og "hævede" knapper, der bruges i forskellige situationer. For eksempel er det ikke godt at bruge hævede knapper på UI'er i kortstil, fordi de hævede knapper vises for fremtrædende på kort, og overflødige skygger gør også brugergrænsefladerne ikke enkle og rene. Flade knapper anbefales at bruge ikke kun på kort, men også dialoger og sidefødder. Android har også flydende handlingsknapper, som vil blive introduceret i det næste afsnit.

Selvom Retningslinjer for materialedesign kun definerer de visuelle stilarter for flade og hævede knapper, findes spøgelsesknapper, der er flade figurer uden udfyldning og en enkel kontur, og hævede knapper-lignende billeder uden skygger også i Google Play. Spøgelsesknapperne kan sammenlignes med iOS-normal knap; hævede knapper-lignende knapper til presset knap.

Teksten i Android-knapper er UPPERCASE; iOS-knapper bruger hovedsageligt Title Case. Nogle gange bruger spøgelsesknapper UPPERCASE, som OPEN og UPDATE-knappen i App Store, men engang bruger de Title Case, ligesom “Book a Table” og “Routes” i kort iOS 10. Kapitaliseringsreglen i iOS ser ud til at være uoverensstemmende.

6. Flydende handlingsknapper VS. Knapper til opfordring

Flydende actionknapper, FAB dukkede først op med Material Design i Android 5.0. FAB'er, der er placeret i nederste højre hjørne af skærme, bruges til at løse brugervenlighedsspørgsmålet ved enkelthåndsbetjening. Det er vanskeligt at nå knapper på handlingslinjer, mens du bruger telefoner med en enkelt hånd. FAB'er er undertiden også placeret i krydset mellem to områder, og det gør FAB'er mere iøjnefaldende.

En knap med flydende handling repræsenterer den primære handling i et program. Som eksempler er komponeringsknappen i mail-appen og den nye postknap i det sociale netværksapp egnet til at bruge FAB'er.

Det lignende design til den primære handling i iOS-apps er en call to action-knap, der er placeret i midten af ​​fanebjælkerne. CTA-knapper brugte i tidligere tid forskellige farver eller design til at skelne dem fra andre faner. Men nu, da brugere er mere og mere fortrolige med mønsteret, er CTA-knapens stil den samme som faner 'i mange apps. Knapperne til nyt indlæg i Medium og offentliggør et nyt foto på Instagram er eksemplerne.

7. Nederste ark VS. Handlingsark og aktivitetsvisninger

Android-bundark vises fra 2015, men iOS har dette lignende design i lang tid. Android har denne form for design, fordi den ønsker at løse problemet med enkelt håndbetjening.

Android bundark har 2 former: modale bundplader og vedvarende bundplader.

Android-modale bundplader har to indhold: 1) Modale bundplader med forskellige handlinger og 2) App-liste, der vises, når brugerne trykker på “Del” -ikonet. Den første er ligesom iOS Action Sheets; sidstnævnte er som iOS-aktivitetsvisninger efter at have tappet på “Handlinger” -ikonet. Indholdslayoutet på Android-modalbundne bundark kan være liste eller gitter.

Vedvarende bundplader bruges, når bundplader har samme betydning som hovedindholdet ovenfor, og brugere kan være nødt til at se begge informationer på samme tid. Når man tager kortappen som et eksempel, viser det øverste område et kort, og det nederste ark viser detaljerne om placeringen. I en musik-app viser det øverste område albumomslag, og det nederste område kan have kontroller til afspilning af musik.

Selvom jeg ikke kan finde de komponenter som Android Persistent Bottom Sheets, der er defineret i iOS Human Interface Guidelines, kan du stadig se det lignende design i iOS-indbyggede apps, Map og Music.

Billedkredit: Google Material Guideline & Facebook Design

8. Dialoger VS. Advarsler

Android-dialoger har hovedsageligt 3 funktioner: 1) Ændringer: afbryd, hvad brugerne prøver at gøre, og informer brugeren om en situation. 2) Menuer: give brugerne mulighed for at vælge en mulighed eller ændre enkle indstillinger. 3) Bekræftelse: som en poka-åg, bekræft brugernes valg, før det er forpligtet til at forhindre fejl.

Android-dialoger består af titler, indhold og knapper. Nogle gange kan titler udelades. Indholdet kan ikke kun have ren tekst, men også andre komponenter som valgmulighedsliste eller tekstfelter. iOS-alarm har også titler, indhold og knapper, der ligner Android-dialog. Den eneste forskel er, at indhold kan udelades, men en titel skal opbevares.

Android-dialoger har 3 former: 1) Enkle dialogbokse, ligesom en menu: Der er ingen OK og knappen Annuller i dialogen. Du kan trykke på en indstilling i dialogen for at vælge, og derefter forsvinder dialogen. Du kan trykke uden for dialogen eller Tilbage-tasten for at lukke dialogerne. 2) Bekræftelsesdialog, de mest almindelige: Der er knapper, som brugerne skal trykke på for at bekræfte deres handling. 3) Fuldskærmsdialog, kun brugt på telefoner: fuldskærmsdialoger er ikke på fuld skærm på tablets. Android-fuldskærmsdialog er ligesom iOS-modalvisning, som introduceres senere.

tekster

Titlen og indholdsteksten i Android-dialoger justerer venstre; Titlen og beskrivelsesteksten i iOS-alarmeringscenter. Android bruger "Sentence case" til titlerne; iOS bruger "Title Case". Både Android og iOS bruger "Sentence case" til indholdsteksten.

Titlen på Android-dialog og iOS-alarm skal være kort og klar. Undgå spørgsmål med nogle indikationer, som ”Er du sikker på, at du vil slette filen?” Setningen skal være enkel, neutral og direkte, ligesom “Slet filen?”.

Knapper

Om antallet af knapper, Android og iOS kan have 1-2 knapper. iOS-retningslinjer foreslår at undgå 3 eller flere knapper generelt, fordi flere knapper skaber kompleksitet og kan kræve rulle. Hvis du har brug for mere end to valg, kan du overveje at bruge et handlingsark i stedet. Men når iOS spørger brugerne, om de vil opdatere deres iOS-version, viser den tre knapper, Installer nu, senere og detaljer i alarmen.

Når der er to knapper, skal du annullere og hovedhandlingsknappen sætte Android og iOS annulleringsknappen på venstre side og hovedhandlingsknappen på højre side. (Du kan kontrollere denne artikel for at vide, hvorfor de har denne regel). Når kopien på knapperne er længere, kan to knapper sættes lodret. Hovedhandlingsknap vil være øverst på annulleringsknappen.

Kopien på knapperne skal undgå at bruge Ja og Nej, skriveaktion på knapperne ville være mere klar og direkte, som Annuller og Gem, Annuller og Fjern.

iOS bruger rød på knappeteksten til advarsel, hvis handlingen ikke kan genvindes, som sletning. Android bruger ikke specifik farve på knappetekst. Om knappetekst bruger Android UPPERCASE, men iOS bruger Title Case. Knaptekst justeres lige i Android, men den justeres i midten i iOS.

Når konteksten er meget, kan Android-dialoger korrigere titel og sidefod på dialog, men indholdet kan rulles. De rulbare indholdsdialogbokse vises ofte, når der sættes masser af indstillinger i dialogerne. iOS-retningslinjer antyder, at indholdet skal være kort for at undgå rulle i alarmer.

9. Dialogvinduer i fuld skærm VS. Modale udsigter & popovers

Android-fuldskærmsdialogbokse findes kun på små mobile enheder som smarttelefoner, som kan sammenlignes med iOS-modale visninger. iOS-modalvisninger har 4 stilarter, fuldskærm, sideark, formark og andre som split view og popover. Om overgangen til modale visninger på telefoner glider en modal visning op, når du indtaster, og den glider ud, når du forlader.

Popovers bruges kun til tabletter

10. Snackbars & Toasts VS. Advarsler

Ud over dialoger bruger Android også snackbars eller toasts som tipmeddelelser med interferens på lavt niveau. snackbars eller ristet brød, da feedback normalt vises i cirka 3 sekunder, efter at brugerne har taget en handling og derefter glider eller falmer ud automatisk.

Snackbars kan have en handlingsknap, der lader brugeren gentage eller udføre anden handling. Toasts bruges hovedsageligt til visning af systemmeddelelser. Du kan ikke lægge ikoner på snackbars eller toasts.

iOS-retningslinjer har ikke den slags komponenter. Nogle gange kan vi finde nogle apps, der bruger alarmer som feedback, men alarmer vil afbryde brugerne og kan have større interferens. De lignende komponenter i iOS ville være den lille pop-up, der dukker op, når du justerer lydstyrken og forsvinder efter få sekunder. Nogle apps tilpasser pop op-vinduet, der kun vises i sekunder som Android-skåler som feedback.

Nogle apps tilpasser muligvis deres advarsler, så de vises i sekunder som Android-skål.

11. Lister VS. Borde

Lister, den mest almindelige og basale komponent, findes i hver app (du kan finde dem i mindst Indstillinger for apps). I Android består lister af en kontinuerlig kolonne med rækker. I iOS kalder vi Lister som tabletter, der består af mange celler, alias rækker.

Android-listestil har en-linjeliste, to-linjeliste (består af en primær tekst og en sekundær tekst) og flere linjelister (består af en primær tekst og 2 eller flere sekundær tekst). Ikoner, miniaturebilleder og listekontroller, som afkrydsningsfelter, radioknapper og switch-knapper, kan tilføjes til lister. Normalt sættes hovedhandlinger i venstre side af listen, og sekundære handlinger placeres i højre side af listen.

iOS-tabeller ligner Android-lister, men der er stadig nogle punkter, du skal være opmærksom på:

1) Når Android-rækken har en primær titel og en sekundær tekst på telefonen, placeres de lodret. Den sekundære tekst kan være beskrivelse eller værdi. I iOS har den udover to-linjes typografi også en-linjestil. Den primære tekst, etiket, sættes på venstre side af cellen, og værdien sættes på højre side af cellen. På tabletten er Android-række sommetider ligesom iOS på grund af større plads, hvilket sætter en primær titel og en sekundær tekst vandret som en enkelt linje.

2) iOS-række har bedre brugervenlighed end Android. Hvis der er en børneskærm, viser iOS en pilindikator på en celle i forældreskærmen, så brugerne kan vide, at cellen er trykbar og vil føre til en anden skærm. Men i Android kan vi ikke vide, om listerne kun er til visning af oplysninger eller indgangen til en anden skærm. De har alle det samme udseende.

3) iOS-tabeller har 2 former: Almindelig og grupperet. En almindelig tabel har en hel hvid skærm med skillelinjer. Selvom kun få celler har indhold, har rasteområdet stadig dele. Grupperede tabeller har en grå baggrund. Den første grupperede tabel har en vis plads med en navigationslinje og den anden grupperede tabel nedenfor. Android har kun en stil og brug kun en skillelinje til at adskille to forskellige lister.

12. Underoverskrifter VS. Gruppede tabeloverskrifter og sektionsoverskrifter

Android-underoverskrifter og iOS-overskrifter bruges til at adskille og gruppere lister eller gitterlister med forskellige indhold. iOS har 2 forskellige stilarter til at adskille lister: 1) Grupperede tabeller, der bruges til at gruppere helt forskellige oplysninger; 2) Sektionsoverskrifter kan ses i almindelige tabeller, der bruges til at sortere det lignende dataformat, f.eks. Fotos med forskellige tagede datoer eller kontakter med forskellige navne.

Android-underoverskrifter bruger sætningssag. iOS-grupperede tabeloverskrifter bruger “UPPERCASE”, og almindelige tabeloverskrifter bruger “Titelfil”.

Når du ruller, forbliver Android-underoverskrifter bundet til toppen af ​​skærmen, indtil de skubbes fra skærmen af ​​de næste underoverskrifter, hvis opførsel er ligesom iOS-sektionsoverskrifter. Grupperede tabeloverskrifter har ikke denne form for opførsel.

13. Listekontroller

Listekontroller er også vigtige komponenter til apps. Listekontroller, som flere sektioner, enkelt valg, afbrydere, omarrangere gribere, efterladte og udvide / kollaps skifter, vil blive introduceret i dette kapitel.

13–1.Multipleval: Afkrydsningsfelter VS. Afkrydsningsfelt med cirkel

Android bruger afkrydsningsfelter til flere valg. En boks med et kryds repræsenterer status for det valgte emne; et felt uden kryds betyder, at emnet ikke er valgt. Afkrydsningsfelter, som kan findes i webstedet eller desktop-OS, bruges normalt komponenter til flere valg, men iOS har ikke denne komponent. I iOS bruges en cirkel med et kryds til flere valg, men dens form kan få brugerne til at forveksle det med en radioknap.

Android-afkrydsningsfelter kan sættes på venstre eller højre side, men iOS sætter normalt flere valgkontrol på højre side.

Det er værd at bemærke, at Android undertiden bruger afkrydsningsfelter som switches til aktivering / deaktivering af funktioner, men iOS bruger switch-knapper til at gøre det snarere end dets cirkel kontrol

13–2. Enkeltvalg: Radioknapper / flueben VS. markeringerne

Android har radioknapper, som også findes på websider eller desktop OS som en enkelt valgkontrol. En radioknap har en cirkel med en prik inde, hvis emnet er valgt. Radioknapper bruges til lister over to eller flere gensidigt eksklusive genstande.

iOS har ingen radioknapper, men det har i stedet kontrolmærker som valg af kontrolvalg.

Android plejede at placere radioknapper på højre side af lister, men nu kan du finde radioknapper sættes gradvist på venstre side. iOS sætter afkrydsningsfelt på højre side, men markeringer kan sættes på venstre side, hvis højre side har andre elementer, som f.eks. en næste sideindikator.

Selvom Retningslinjer for materialedesign ikke introducerer kontrolmærker, der vises fra 2016 gradvist, men du kan finde eksemplet i menuen i Google Kalender.

Android-enkeltvalg: Radioknapper & kontrolmærker. Men den venstre er et dårligt eksempel som en simpel dialog, den skal IKKE have en CENCEL-knap i henhold til Googles retningslinjer. Eller det kan være en bekræftelsesdialog ved at tilføje en OK-knap, men det vil føre til flere trin.

13-3. Skifter

En switch er et skifte mellem to gensidigt eksklusiv status, til og fra. Tidligere havde Android ikke switches og brugte afkrydsningsfelter til aktivering / deaktivering af nogle funktioner, men nu bruger Android switches mere og mere. iOS bruger altid switches til at aktivere / deaktivere funktioner. Kontakter sættes på højre side af lister både i Android og iOS.

Android-indstillinger til og fra: Gmail bruger afkrydsningsfelter, men Fotos bruger afbryderknapper

13-4. Genbestillings / Gripper

Android bruger et ikon, der består af 4 parallelle horisontale linjer som en ombestillingskontrol, for at undgå at forvirre folk det med hamburgerikon, der består af 3 linjer, der bruges til at udvide og kollapse navigationsskuffen. Optagerikon vises normalt i redigeringstilstand.

iOS-griberikon blev vist tidligere end Android. Du kan også se det i redigeringstilstand. Men iOS-griber består kun af 3 linjer, fordi iOS ikke bruger en skuffe som standardnavigation som Android.

13-5. Efterladte (Stryg handlinger)

Når du har skubbet til venstre eller højre, kan du finde nogle skjulte handlinger bag en liste. Det er meget almindeligt at finde i iOS. I fortiden kunne du normalt finde en sleteaktion, når du stryger, nu er der flere handlinger ud over at slette. I en mail-app kan du finde arkiv, flag og mere efter at have skubbet til venstre; markér læst eller ulæst ved at skubbe til højre.

Efter Android 5.0 vises svejsehandlinger, såkaldte Leave-Behinds, i retningslinjerne. Det er værd at bemærke, at Leave-Behinds ikke bør bruges i en skærm har faner på grund af gestikonflikt, og det er grunden til, at Android ikke havde denne komponent før.

Efter at have svejset en liste i afstand og derefter stoppet, kan du se 1-3 handlinger bagpå, og derefter trykke på en af ​​den for at tage handling. Men hvis du stryger for længere afstand, udføres standardhandlingen. Android har kun én handling bag og tage handlingen ved at stryge lige.

Billedkilde: Google Material Guideline & Facebook Design

13-6. Expand / Collapse

Eksponering / Skjul kontrol kan hjælpe hierarkiet fladere, fordi brugere ikke behøver at gå ind i det næste skærmbillede for at se informationen, oplysningerne vises på samme skærm. Denne kontrol kan ofte findes i FAQ-lister. Når der er tappet et spørgsmål, vises svaret. Der kræves færre trin, hvis du prøver at gennemse disse QA'er.

Som afhængighed af at sætte udvidelse / kollaps på lister, kan du også placere denne kontrol i overskrifter, så brugerne kan sammenklappe gruppen, de ikke bruger ofte.

Billedkilde: Google Materiel Design Guideline

Udvidelse / kollaps kan ikke findes i iOS Human Interface Guidelines, og det findes sjældent i iOS-apps. De lignende kontroller kan være noget, der dukkede op på Explore-skærmen i App Store, i iOS 8. Men det er mere som en sti snarere end at udvide / kollaps kontrol, fordi du ikke kan se andre elementer grupperet i forskellige overskrifter på den samme skærm.

iOS 8 App Store
Giv 10 klapper, hvis du har læst denne artikel.
Giv 20 klapper, hvis du synes, det er nyttigt.
Giv 50 klapper, hvis du synes det er fantastisk!
Tak skal du have :)

Fortsæt til Android VS. iOS: Sammenlign 20 UI-komponenter og -mønstre (Del 2)

Reference