Logo da.androidermagazine.com
Logo da.androidermagazine.com

Android q's bagbevæg bryder en grundlæggende app-interaktion: indstikskuffen

Anonim

Android Qs nye bevægelsesnavigationssystem er en klar opgradering af hvad Google prøvede med Android 9 Pie. Multitasking er lettere, og hver af kernebevægelserne er lettere at bruge med mere flyt. Men en kerne del af navigationsparadigmet, der stadig er i luften, er den nye bagbevægelse.

Vi har set flere telefonproducenter skabe deres egne rygebygninger, men ikke på den måde, som Google standardiserer med Android Q: stryg ind fra kanten af ​​skærmen, enten til venstre eller højre, når som helst for at udføre den samme handling tidligere håndteret med tilbage-knappen. Denne forskel fra resten af ​​bagbevægelserne på andre Android-telefoner er ekstremt vigtig, fordi den forstyrrer et af de mest grundlæggende navigationssystemer i appen, der bruges i dag: indstikskuffen.

Indstikskuffen har været en grundlæggende appgrænsefladekomponent i et årti.

Den skjulte indstikskuffe har været en grundlæggende navigationsmekanisme for apper i næsten et årti, og den er udbredt ud over Android til næsten enhver anden platform på en eller anden måde. Apps, der ikke bruger en slide-in skuffe er få og langt imellem, og mange (inklusive nogle af Googles egne) er afhængige af det som deres primære system til at bevæge sig gennem dele af appen. Selv dem, der overflader de mest anvendte funktioner til en nederste navigationslinje, bruger stadig skyderen i skuffen som dumpingplads til yderligere indstillinger.

(Den eneste kategori af apps, der ikke regelmæssigt bruger en slide-in skuffe, er spil, der har deres egen kamp med kantbaserede bevægelser.)

Ved hjælp af Android Q med bevægelsesnavigation mister hver enkelt app sin slide-in skuffe, indtil udvikleren opdaterer.

Når du bruger Android Q med bevægelsesnavigation aktiveret, mister hver enkelt af disse apps sin slide-in skuffe. Du kan simpelthen ikke stryge ind fra kanten, på noget sted eller på nogen måde for at afsløre det. Den eneste måde at vise skuffen på vil være at trykke på hvilken som helst knap der er knyttet til den - typisk en hamburger-menu-knap i øverste hjørne, som bliver stadig sværere at nå på store (og høje) telefoner. Det er en massiv smerte, der i det mindste kræver en ændring i muskelhukommelse og reducerer dramatisk hastigheden, hvormed du kan navigere i apps.

Google ved, at bagbevægelsen vil skabe hovedpine for alle, der er kommet til at stole på indskydningsskuffen (blandt andet tætkanter og swipes), og gør det meget klart for udviklere, at de er nødt til at planlægge for dette lave om:

Hvis brugeren stryger ind fra kanten af ​​skærmen, fortolker systemet denne gestus som en Back navigation, medmindre en app specifikt tilsidesætter denne gestus for dele af skærmen. For at gøre din app kompatibel med gestusnavigation, skal du udvide app-indholdet fra kant til kant og håndtere modstridende bevægelser korrekt.

Android-udviklerdokumentation fastlægger processen, hvormed udviklere kan definere områder af deres apps, der er ekskluderet fra bagbevægelsen, og i stedet for at udføre andre handlinger - hvad enten det er for at trække i en dias i skuffen, eller blot have garanteret berøringsinput alle de vej til kanten for noget andet samspil. Som et eksempel har Google allerede opdateret Play Store-appen for fuldstændigt at fjerne bagbevægelsen på hele venstre side og kun lade den være til indstikskuffen.

Områder med udelukkelse af gestus vil være forskellige for hver app - hvis de overhovedet har dem.

Det er alt sammen fint og godt, men det kræver, at udviklere faktisk gør, hvad Google beder om. Og selvom vi tager det som et givet (som vi naturligvis ikke kan), og hver app med en indstikskuffe på magisk vis har et eksklusionsområde natten over, er der stadig store brugbarhedshindringer. Bevægelsesudelukkelsesområder fungerer kun, hvis du kan stole på, at de er der - ved ikke at vide, hvor dette område er, hvilken side det er på, hvor stort det er, og hvis det er forskelligt for hver app på din telefon introducerer et nyt sæt problemer helt. Det bliver en meget, meget frustrerende overgang.

Desværre for os har udviklere ikke så meget incitament til at oprette disse ekskluderingsområder. De nye bevægelser er obligatoriske at medtage på nye telefoner, der forsendes med Android Q, men de behøver ikke at være standard eller det eksklusive navigationsvalg. Det er en temmelig sikker satsning, at de fleste virksomheder, der allerede laver deres egne bevægelsesnavigationssystemer, eller holder sig med tre-knapsnavigation, fortsætter med at gøre det med Android Q - og for dette store flertal af telefoner derude vil udviklere ikke høre nogen klager.

Dette er en af ​​de situationer, hvor vi rent faktisk kan tage den langsomme udrulning af Android-opdateringer som en positiv ting, fordi udviklere som helhed ikke vil have deres apps ajour med hensyn til de nye Android Q-back-gestus i nogen tid fremover. Og for alle, der opdaterer deres ikke-Pixel-telefon til Android Q, giver det endnu mere vægt på beslutningen mellem at aktivere de nye bevægelser og holde sig til de andre tilgængelige system (er) - Android Q-bevægelser kan være store og intuitive, men er det værd at miste indstikskuffer i de fleste apps, du bruger hver dag? Jeg tror ikke, nogen ville sige, at de er det.

Android Q: Alt hvad du har brug for at vide!