Share
Of je nu intern werkt, contractt of voor een bureau, bedrijven hebben apps nodig om verschillende redenen. Gevestigde bedrijven in het bijzonder moeten zorgen voor hun bestaande klanten en de apparaten die zij gebruiken. Vaak betekent dat een nieuwe app voor zowel Android als iPhones.
In een ideale wereld zouden we maanden bezig zijn met het ontwerpen van twee apps. Maar in werkelijkheid laten veel projecten niet zoveel tijd toe. Voor alle apps waaraan ik heb gewerkt, was de deadline strak genoeg om een app te ontwerpen, laat staan om het project volledig in tweeën te delen.
Vaak ontwerp je een app, waarbij aanpassingen worden gemaakt voordat je deze aan twee ontwikkelteams overhandigt. Als u op deze manier een app ontwerpt, is het belangrijk om het verschil tussen de twee platforms in een vroeg stadium te begrijpen, en de snelle manieren waarop u ervoor kunt zorgen dat de ervaring voor elke gebruiker hetzelfde is..
Waarschijnlijk heb je een persoonlijke voorkeur voor één systeem. Ik heb altijd iPhones gebruikt, dus ik heb een meer natuurlijk begrip van de UI-patronen op iOS. Het eerste dat u moet doen is grip krijgen op het andere platform en de beste manier om dit te doen is een ander apparaat kopen, een Android in mijn geval. Het kan zelfs een goed idee zijn om dit als uw primaire apparaat voor de duur van het project te gebruiken, om echt een indruk van het platform te krijgen.
Als u in huis werkt, moet u ervoor zorgen dat ze u een testapparaat aanschaffen. Als er problemen zijn, communiceer met het management over de waarde die het begrijpen van het alternatieve platform zal toevoegen aan uw ontwerpwerk (de kosten zijn duur voor twee apparaten uit uw eigen zak, maar voor een bedrijf is dit een lage uitgave in vergelijking met de uitgaven voor de ontwerp en ontwikkeling van een nieuwe app). Als u freelance werkt, zou u het moeten afrekenen tegen uw belastingaanslag.
Omdat we tegelijkertijd voor beide platforms ontwerpen, terwijl we ons bezighouden met de echte wereld waarin de tijd beperkt is, moet je de realiteit accepteren dat prioriteit wordt gegeven aan één platform vanaf het begin. Maak deze beslissing niet op basis van uw persoonlijke voorkeur, maar op basis van de markt voor uw app. Gebruiken meer mensen in uw markt Android-telefoons? Is het een betaalde app? Wat is de doelgroep? Door deze vragen te stellen, kunt u bepalen welke de voorkeur heeft.
Lees meer over UI-richtlijnen voor Android en iOS. In het verleden stond Apple bekend als strenger met hun richtlijnen. Om een app in de app store te krijgen, is er een goedkeuringsproces dat ongeveer twee weken in beslag neemt. Er is geen goedkeuringsproces voor de Play Store. Vanwege de lagere toegangsdrempel voor Android is de kwaliteit van het ontwerp traditioneel slechter geworden. Google wil dit veranderen met hun Material Design-richtlijnen.
De esthetiek van het Materieel Ontwerp is zeer bekend bij webontwerpersEr zijn veel goede en gratis UI-kits die u kunt gebruiken voor uw projecten (u vindt enkele vermeld aan het einde van dit artikel). Het gebruik van deze componenten zal uw app natuurlijk een native gevoel geven. Maar zelfs als u de UI-kits hebt, kan het lastig zijn om te weten waar u moet verschillen en waar u hetzelfde moet blijven tussen platforms, dus daar wil ik u helpen.
Volg deze eenvoudige stappen en uw app is op de goede weg om zowel op Android- als op iOS-apparaten te passen.
Sinds iOS7 is Apple overgestapt naar een vlakkere ontwerpstijl en zijn de skeuomorfische schaduwen, texturen en effecten weggevallen die de beginjaren van de iPhone bepaalden. Android, dat in het begin meer systematisch van stijl was, is iets anders gegaan. De nieuwe Material Design-richtlijnen van Google creëren subtielere verwijzingen naar de echte wereld, met een gelaagde "papieren" benadering die meer hiërarchie biedt.
Android-telefoons hebben een terugknop, die kan worden gebruikt om terug te keren naar de vorige schermen in de app.
Kom terugiPhones hebben deze knop niet, dus er moet een manier zijn om terug te gaan naar het vorige scherm. Dit wordt meestal gedaan door een 'achterste' chevron in de linkerbovenhoek van het scherm, maar er moet rekening worden gehouden tijdens de verschillende reizen in uw app.
Er zijn algemene elementen (zoals een statusbalk en koptekst) die op alle pagina's van uw ontwerp worden weergegeven. U moet de hoogte of stijl van deze balken helemaal niet veranderen als u wilt dat de app native is, dus ik zou aanraden om ze eenmalig te definiëren in uw eerste paginaontwerp voor elk platform. Daarna kunt u een plaatshouder (of de status en de bovenste balk van uw primaire besturingssysteem) gebruiken op elk van uw modellen, maar geeft u aan ontwikkelaars aan dat dit hetzelfde moet zijn over de hele linie.
Er zijn kleine verschillen tussen de navigatiebalken op elk platform. Op Android blijft de tekst uitgelijnd, terwijl deze voor iOS gecentreerd is. Op iOS vervangen veel bedrijven de titel van de hoofdpagina door hun bedrijfslogo, maar dit is geen goede praktijk op Android. De statusbalk (met uw netwerk-, batterij- en tijdinformatie) is een native component en u hoeft het ontwerp niet te overwegen. Zorg er wel voor dat je mockups presenteert om de juiste te gebruiken om verwarring of afleiding te voorkomen.
Misschien is het grootste verschil tussen iOS- en Android-platforms navigatie. Het primaire navigatiepatroon op Android is een lademenu. Android-gebruikers gaan hier natuurlijk naar toe voor menu-items, en het heeft de neiging om alomtegenwoordig te zijn tijdens de hele ervaring. De richtlijnen van Apple zijn meer in het voordeel van een tabbalk, die zich onderaan het scherm bevindt, en die gemakkelijke toegang tot de hoogste niveaus van de app biedt. Wanneer u de architectuur op het hoogste niveau van uw app bepaalt, kunt u twee afzonderlijke menu's plannen voor de twee platforms.
Het is misschien belangrijker om te denken aan de architectuur van de app dan aan de lay-out van de menu's - een punt dat ik in een ander artikel over een aantal van deze kwesties heb gemaakt. Als uw structuur gezond is, volgt de navigatie.
Zoals je hier ziet, zijn er twee navigatiepatronen: een lademenu voor Android en een tabbalk voor iOS. Het is soms eenvoudiger om de navigatielaag eenvoudig te verbergen terwijl u aan individuele weergaven werkt.
Kaarten worden het primaire UI-patroon in digitaal ontwerpen. Ze zijn veelzijdig en stellen gebruikers in staat snelle hapjes van inhoud te consumeren op een manier die geschikt is voor mobiel gedrag. Visueel passen kaarten goed in het materiaalontwerp van Android (geïnspireerd op papier). Het gebruik van slagschaduwen en redelijke goten tussen kaarten zorgt voor een natuurlijk uiterlijk en natuurlijk gevoel.
Op iOS heeft het gebruik van kaarten meer zorg en aandacht nodig. Zelfs grote apps zoals Facebook en Pinterest gebruiken kaarten op een manier die enigszins afwijkt van de iOS-richtlijnen. iOS-richtlijnen suggereren het gebruik van diepte in transparanten en overlays, maar de basisweergave is meestal vlakker. Instagram gebruikt een volledig platte ontwerpstijl, hoewel elke post kan worden beschouwd als een kaart vanuit een architectonisch oogpunt. Het is de moeite waard om te kijken hoe Instagram hetzelfde componentgevoel krijgt binnen een iOS-stijl. Als je met kaarten gaat op iOS wees dan heel voorzichtig met elk gebruik van schaduw, en probeer ze zo subtiel mogelijk te houden.
Kaarten voor Android en iOS, sommige dimensies lenen een beetje de moeiteDe lettertypefamilie van het systeem op iOS is Helvetica Neue. Op Android is het Roboto. Hoewel de stijl van de lettertypen merkbaar anders is, lijken de metrieken van de lettertypen sterk op elkaar. Als u tijd spaart, bent u veilig genoeg om met slechts één programma te werken, maar communiceert u met ontwikkelaars om het juiste lettertype voor het systeem te implementeren. Bij het werken met belangrijke lay-outs en extremen in lettergroottes is het raadzaam om op zijn minst uw lay-out uit te testen met beide lettertypen.
Als u een extra stap wilt zetten, moet u meer aandacht schenken aan de typografische en opmaakconventies op elk platform, opnieuw verwijzend naar de bovenstaande richtlijnen. Een paar generalisaties:
Dit is een heel eenvoudig voorbeeld, om te benadrukken hoe zelfs op eenvoudige manieren de typografie je meteen kan vertellen of je te maken hebt met een Android- of een iOS-app.
iOS (44px @ 1x) en Android (48dp - 48px bij een verhouding van 1: 1) hebben enigszins verschillende richtlijnen voor aanraakdoelen. Material Design-richtlijnen suggereren ook dat alle elementen moeten worden uitgelijnd op een 8dp vierkant basislijnraster.
Bij het laatste project waaraan ik werkte, vonden we het veiliger om deze Android-richtlijnen te volgen omdat (a) het grotere 48px-aanraakdoel veilig is voor beide platforms, en (b) de lay-out voor Materiaalontwerp meer gedefinieerd en actueel is. Hoe dan ook, je zult een raster nodig hebben om mee te werken, maar met het feit dat Android strenger gedefinieerd is, bleek 8dp goed te werken. Dit betekent dat u uw document moet instellen met stappen van 8 dpi in zowel horizontale als verticale vlakken om een betegelde rasterlay-out te maken.
Er zijn verschillende knopstijlen gedefinieerd in Materiaalontwerp:
Vergeleken met materiaalontwerp hebben iOS-apps een typisch plat uiterlijk, zonder gebruik te maken van diepte- of slagschaduwen. De primaire knoppen hebben een opvulkleur, terwijl de secundaire knoppen worden omgekeerd met een streek van dezelfde kleur. Deze metafoor kan enigszins beperkt worden, vooral in vergelijking met tabs en andere te volgen elementen. Om deze zeer vlakke stijl goed te krijgen, is het belangrijk om duidelijke en consistente metaforen te hebben voor wat kleuren betekenen in uw app.
iOS heeft ook een platte tekststijlknop, maar deelt niet de hoofdstijlstijl van Android en is lichter in lettertype.
Met actievellen kunnen gebruikers kiezen uit een groot aantal acties uit één gebruikersinterface-item. Als ik bijvoorbeeld een afbeelding aanraak (of lang druk), wil ik deze mogelijk delen, uploaden, kopiëren of verwijderen.
iOS en Android gaan hier op enigszins verschillende manieren mee om. Ten eerste zijn er vergelijkbare actievellen die vanaf de onderkant van het scherm worden weergegeven als een overlay op de huidige weergave.
Met actievellen, overlays en waarschuwingen gebruiken iOS en Android verschillende details om de diepte in lagen aan te geven:
Bestaande alleen op Android, dit is een snelle methode om een selectie te maken. Houd er echter rekening mee dat er geen native iOS-equivalent bestaat. In het onderstaande voorbeeld drukt de gebruiker in stap 1 op "profiel" en krijgt op die locatie een eenvoudig menu om een van de beschikbare profielen te kiezen. Deze menu's worden ook vaak gebruikt vanuit de overlay-knop in de actiebalk, aangegeven door drie verticale stippen.
Voor bepaalde ingangen zoals datum en tijd, komt Android nu met ingebouwde dialogen. Deze zien eruit als alarmpop-ups, maar met UI is dit specifiek bedoeld om dit type gegevens in te voeren. Een voorbeeld wordt getoond van een kalenderinvoer. Android heeft een geoptimaliseerde overlay voor het invoeren van een datum. iOS gaat hier heel anders mee om, het verschijnt als een wiel dat omhoog komt als een onderste blad. Wees voorzichtig met het plannen van deze en communiceer vroegtijdig met de ontwikkelaars over de invoercomponenten.
Gesegmenteerde besturingselementen worden gebruikt om te schakelen tussen verschillende inhoud binnen één weergave. Hun gebruik is vrijwel hetzelfde, maar ze zijn visueel erg onderscheidend op elk platform, dus het is belangrijk om de juiste stijl te gebruiken. Op iOS zijn er drie tabbladen, die op dezelfde manier zijn gestileerd als de eerder besproken lijnknoppen. Op Android worden ze aangeduid met een eenvoudige onderstreping en krijgen ze veel meer witruimte om hun interactie aan te duiden.
Het is belangrijk om de stijl hiervan goed te krijgen, omdat ze belangrijke acties kunnen controleren, zoals aanmelden, voorwaarden accepteren of zelfs betalingen bevestigen. We willen dat ze zich betrouwbaar en inheems voelen.
De Android-meldingen gebruiken de platte knopstijlen die eerder werden getoond, waarvan de dimensies te vinden zijn in de richtlijnen voor materiaalontwerp. De acties zitten rechtsonder van de melding. De "knoppen" zijn eigenlijk volledig op tekst gebaseerd. Ze gebruiken alle hoofdletters om ze meer structuur te geven en ze dragen de primaire actiekleur van je app.
Op iOS worden de acties gescheiden door verdelers. Ze zitten meestal in een zin of titel, omdat ze hun structuur uit de afzonderlijke blokken halen. Ze zijn gecentreerd in het veld en opnieuw zullen ze je actieve kleur erven.
Het pictogramontwerp is vrij het specialistische gebied in UI-ontwerp. Of u nu gratis pictogrammen gebruikt, een pictogramontwerper opdracht geeft of de pictogrammen zelf ontwerpt, er is een eigen stijl die eigen is aan elk platform. iOS-gepopulariseerde lijnpictogrammen, met zeer dunne streken. De pictogrammen van het Android-systeem hebben dikkere lijnen of zijn volledig solide pictogrammen. In het verleden gebruikten Android-pictogrammen perspectief of een driedimensionale draai, maar nu specificeren hun richtlijnen tweedimensionale pictogrammen die recht worden bekeken. Hier is een snel voorbeeld met verschillende pictogrammen voor vergelijking, of gebruik de directe links naar pictogramrichtlijnen voor Android of iOS
Ongelukkig 13. Er zijn een paar UI-details die door de kloven kunnen glippen. Veelvoorkomende problemen zoals waarschuwingen en het laden van pictogrammen worden vaak overgelaten aan ontwikkelaars. Je hebt mogelijk schurkenstaten en vreemde waarschuwingen meegemaakt die niet overeenkwamen met de rest van de app. Er zijn meestal native oplossingen voor, maar deze kunnen worden afgestemd op de stijl van uw app. Dit is zeker een gebied waar samenwerking met ontwikkelaars de beste manier is om te beslissen op welke manier jij moet werken.
Keuzerondjes, selectievakjes, velden en schakelaars zijn functionele componenten die een native-gevoel moeten krijgen. Net als bij waarschuwingen en dialogen, zijn deze bedieningselementen en ingangen een gebied van vertrouwen en vertrouwdheid voor de gebruiker. Gebruik de native componenten zo veel mogelijk voor deze, zodat mensen (a) weten hoe ze te gebruiken, en (b) uw app vertrouwen met hun gevoelige gegevens of betalingsdetails.
In het onderstaande voorbeeld zien we equivalenten voor schakel- en keuzerondjes voor Android en iOS. Nogmaals, de verschillen zijn klein genoeg om met één ontwerp vooruit te gaan en later voor de ander te verfijnen, maar de subtiele verschillen zijn essentieel voor een native look. Gebruik uw UI-kit zo veel mogelijk voor deze componenten en communiceer opnieuw met ontwikkelaars in het begin van het proces.
Android (links) en iOS (rechts)Het is geen onmogelijke taak om met één ontwerp een native feel voor uw app op zowel iOS als Android te creëren. Probeer deze tweaks vanaf het begin bij te houden, houd componenten in de gaten die zich niet synchroon voelen op één platform en werk altijd zo dicht als je kunt met ontwikkelaars.
Dit artikel geeft je hopelijk snel antwoorden over waar je het ontwerp voor twee apps kunt afwisselen, maar je hebt ook een aantal hulpmiddelen en sjablonen nodig om je ontwerp goed uit te voeren. Er zijn veel algemeen beschikbare bronnen die je als uitgangspunt kunt gebruiken, hier zijn enkele van de beste:
Als u meer wilt weten, vindt u veel informatie die ik heb verstrekt in de platformrichtlijnen. Ze zijn behoorlijk uitgebreid, dus ik heb zojuist de onderdelen eruit gehaald die belangrijk zijn om te vergelijken. Maar als u meer specifieke vragen heeft, is dit de beste plaats om te beginnen:
Deze UI-kits zullen u helpen bij het opnieuw creëren van basale systeemeigen besturingselementen en overeenkomende formaten. Je kunt de stukken eruit halen die je nodig hebt en vervolgens schakelen tussen de stukjes voor de Android- en iPhone-uitvoer van je ontwerpen.
Zelfs als u eigen pictogrammen maakt of in gebruik neemt, zijn ze handig om als plaatsaanduiding te gebruiken terwijl u werkt. Pictogramontwerp kan een taak op zich zijn en u wilt niet dat pictogrammen u vertragen terwijl u een algemeen gevoel voor uw app krijgt. Ik vond onlangs de onderstaande links op icons8 er redelijk goed uitzien, of flaticon.com is geweldig voor meer algemene pictogrammen.
Het is altijd handig om apparaatmodellen te hebben voor het presenteren van uw app. Deze komen in vele categorieën. Misschien wil je een basismodel voor de context, een vereenvoudigd plat apparaat om je app te laten schijnen of een lifestyle-mockup om een use-case te presenteren. Hier zijn een paar middelen die ik nuttig heb gevonden, er zijn er veel meer. Als het op Android-apparaten aankomt, wees voorzichtig met wat u kiest. Ik zou neigen naar de Nexus-reeks, aangezien dit de telefoons van Google zijn en geen voorkeur hebben voor andere fabrikanten.
Accentsconagua