Het nieuwe bewegingsnavigatiesysteem van Android Q is een duidelijke upgrade van wat Google probeerde met Android 9 Pie. Multitasking is eenvoudiger en elk van de kerngebaren is gemakkelijker te gebruiken met meer vloeiendheid. Maar een kernonderdeel van het navigatieparadigma dat nog steeds in de lucht hangt, is het nieuwe ruggebaar.
We hebben verschillende telefoonfabrikanten hun eigen rugbewegingen zien maken, maar niet op de manier waarop Google standaardiseert met Android Q: veeg op elk gewenst moment vanaf de rand van het scherm naar links of rechts om dezelfde actie uit te voeren eerder behandeld door de terug-knop. Dit verschil met de rest van de back-gebaren op andere Android-telefoons is uiterst belangrijk omdat het interfereert met een van de meest fundamentele in-app-navigatiesystemen die tegenwoordig worden gebruikt: de schuiflade.
De schuiflade is al tien jaar een fundamentele app-interfacecomponent.
De verborgen schuiflade is al bijna tien jaar een fundamenteel app-navigatiemechanisme en wordt op een of andere manier buiten Android doorgegeven aan zowat elk ander platform. Er zijn maar weinig apps die geen schuiflade gebruiken, en vele (waaronder enkele van Google) vertrouwen erop als hun primaire systeem voor het doorlopen van delen van de app. Zelfs degenen die de meestgebruikte functies op een navigatiebalk aan de onderkant plaatsen, gebruiken de schuiflade nog steeds als stortplaats voor verdere opties.
(De enige categorie apps die niet regelmatig een schuiflade gebruikt, zijn games, die hun eigen problemen hebben met op gebaren gebaseerde gebaren.)
Met behulp van Android Q met bewegingsnavigatie verliest elke app zijn schuiflade totdat de ontwikkelaar wordt bijgewerkt.
Wanneer u Android Q gebruikt met bewegingsnavigatie ingeschakeld, verliest elk van die apps zijn schuiflade. Je kunt gewoon niet vanaf de rand naar binnen vegen, op welke plaats of op welke manier dan ook, om het te onthullen. De enige manier om de lade te laten zien, is door op een willekeurige knop te tikken - meestal een hamburgerknop in de bovenhoek, die steeds moeilijker te bereiken is op grote (en lange) telefoons. Dat is een enorme pijn die op zijn minst een verandering in spiergeheugen vereist en de snelheid waarmee je door apps kunt navigeren drastisch vermindert.
Google weet dat het ruggebaar hoofdpijn zal veroorzaken voor iedereen die op de schuiflade gaat vertrouwen (naast andere tikken en vegen) en maakt ontwikkelaars heel duidelijk dat ze dit moeten plannen verandering:
Als de gebruiker vanaf de rand van het scherm naar binnen veegt, interpreteert het systeem dat gebaar als een navigatie terug, tenzij een app dat gebaar voor bepaalde delen van het scherm overschrijft. Om uw app compatibel te maken met gebarennavigatie, wilt u de app-inhoud van rand tot rand uitbreiden en conflicterende gebaren op de juiste manier verwerken.
Android-ontwikkelaarsdocumentatie legt het proces uit waarmee ontwikkelaars delen van hun apps kunnen definiëren die zijn uitgesloten van het achtergebaar, en in plaats daarvan andere acties zullen uitvoeren - of dat nu is om een schuiflade in te trekken of gewoon gegarandeerde aanraakinvoer weg naar de rand voor een andere interactie. Google heeft bijvoorbeeld de Play Store-app al geüpdatet om het teruggebaar aan de linkerkant volledig te verwijderen en alleen voor de schuiflade over te laten.
Gebaaruitsluitingsgebieden verschillen voor elke app - als ze die al hebben.
Dat is allemaal goed en wel, maar het vereist dat ontwikkelaars daadwerkelijk doen wat Google vraagt. En zelfs als we dat als een gegeven beschouwen (wat we uiteraard niet kunnen), en elke app met een schuiflade magisch 's nachts een uitsluitingsgebied heeft, zijn er nog steeds grote hindernissen voor de bruikbaarheid. Gebaaruitsluitingsgebieden werken alleen als u erop kunt rekenen dat ze er zijn - niet wetende waar dat gebied is, aan welke kant het is, hoe groot het is en dat het voor elke app op uw telefoon anders is, introduceert een nieuwe reeks problemen allemaal samen. Het wordt een zeer, zeer frustrerende overgang.
Helaas voor ons hebben ontwikkelaars niet zoveel motivatie om deze uitsluitingsgebieden te maken. De nieuwe gebaren zijn verplicht op te nemen op nieuwe telefoons die worden geleverd met Android Q, maar ze hoeven niet de standaard noch de exclusieve navigatiekeuze te zijn. Het is een vrij veilige gok dat de meeste bedrijven die al hun eigen bewegingsnavigatiesystemen maken of zich houden aan navigatie met drie knoppen, dit zullen blijven doen met Android Q - en voor de overgrote meerderheid van de telefoons daar, zullen ontwikkelaars geen klachten horen.
Dit is een van die situaties waarin we de langzame uitrol van Android-updates als positief kunnen beschouwen, omdat ontwikkelaars als geheel hun apps nog lang niet up-to-date zullen hebben met overwegingen voor de nieuwe Android Q-backgebaren. En in het geval van iedereen die zijn niet-Pixel-telefoon bijwerkt naar Android Q, geeft het nog meer gewicht aan de beslissing tussen het inschakelen van de nieuwe gebaren en het vasthouden aan de andere beschikbare systemen - de Android Q-gebaren kunnen geweldig en intuïtief zijn, maar zijn ze de moeite waard om schuifladen te verliezen in de meeste apps die je elke dag gebruikt? Ik denk niet dat iemand zou zeggen dat ze dat zijn.
Android Q: Alles wat u moet weten!
