Hamburger-menyen ble innledningsvis introdusert som et middel til å skjule sekundære navigasjonsartikler i et forsøk på å opprettholde en renere og mer fokusert web- eller applikasjonsdesign.
Android var en av de tidlige adopterne av denne designkomponenten, går så langt som å inkludere den i deres populære Material Design retningslinjer . Siden da har den funnet sin vei inn i flertallet av Android-apper, samt en del av iOS-appene. Det har til og med blitt en stift på et stort antall stasjonære applikasjoner og nettsteder.
Disse forekomstene er designet med varierende grad av suksess. Noen tilbyr legitime løsninger på navigasjonsoverløp, mens andre velger hamburgermenyer av estetiske årsaker på bekostning av brukeropplevelse. Det er blitt en vanlig og akseptert del av moderne produkt og webdesign.
Når det gjelder skrivebordsprogrammer, bør hamburgeren ikke ha noe sted. Sjelden er et design som mangler i skjermrom som en navigasjonsoverflate er nødvendig. Google er en av de viktigste skyldige, tilsynelatende inkludert denne komponenten, bare for å gi konsistens på tvers av sine produkter og mellom desktop og mobile enheter. I virkeligheten er det en ubrukelig og ubeleilig brukervennlighetspraksis, spesielt når det også inkluderer primære navigasjonsartikler.
Tilsvarende gjelder samme logikk for tradisjonelle nettsteder som porteføljer, destinasjonssider og bedriftsnettsteder. På en stasjonær datamaskin er det ingen unnskyldning for å helt skjule primære eller sekundære navigasjonsartikler.
Hamburger-menyen er bare et estetisk hensyn, og ofte en lat løsning
Det er så mye skjermrom å spille med i designfasen, selv når du vurderer små bærbare datamaskiner og nettbrett. Selv de mest komplekse og omfattende navigasjonsmenyene kan vises direkte, gitt litt nøye vurdering. Det finnes ingen faste retningslinjer som på mobilapper, slik at designere kan bli kreative med posisjonering, størrelsesorden og brukervennlige løsninger som svever dropdowns og tiered strukturer.
Hamburger-menyen er ganske enkelt et estetisk hensyn, og ofte en lat løsning uegnet for forhold og enhet. Det gjør det vanskelig å bytte mellom sider, og er helt forvirrende til selv de mest datastyrte individer.
Siden skjermstørrelsene reduserer ned til tablett- og mobilenhetsoppløsninger, begynner hamburgermenyen å løse problemet med plassbegrensninger. Det gir en rask og enkel løsning på mangel på skjerm fast eiendom, og en som er konsistent på mobilnettsteder og Android-apper. IOS tilbyr i hovedsak den samme løsningen, men i form av et overfylt-ikon, som vanligvis heter "More". Den er mer tilgjengelig, gitt posisjonering ved foten av skjermen, innen rekkevidde av hånden din.
Men i en innstilling der designtankere og reklamer utvikler og vurderer nye alternativer til de viktigste komponentene i design, er hamburgermenyen virkelig den optimale løsningen?
Hva hamburgermenyen mangler når det gjelder brukeropplevelse, er kravet om å bli åpnet hver gang en gjenstand innenfor den må åpnes. Når navigasjonsskuffer er inkludert, strekker dette seg til to kraner, hver gang en bruker ønsker å navigere til en annen skjerm. Noen av disse elementene kan klassifiseres som sekundære, mindre viktige elementer som nås langt mindre ofte. Andre, selv i Googles egne apper, er absolutt primære handlinger.
Hvis hamburgermenyen skal forsvinne for godt, må en egnet og forbedret løsning presenteres
Fra påminnelser i Google Keep, for å se senere på YouTube, gir hamburger-menyen ofte overlapping til viktige navigasjonselementer. Som en designkomponent er det et kompromiss. Var hver app å utarbeide sin egen navigasjonsstruktur basert på sine egne unike behov, brukere og layout, ville en mer optimal løsning bli nådd. Men i et økosystem som iOS eller Android er konsistens avgjørende for å gi en enkel løsning for utviklere, og sikre at brukerne kan forstå funksjonaliteten til en app, uavhengig av hvem den er designet av.
Hvis hamburgermenyen skal forsvinne for godt, må en egnet og forbedret løsning presenteres. Det må være en som kan brukes på hver app konsekvent på tvers av et økosystem, med mulighet for en rekke ulike behov og kompleksiteter.
Den første potensielle løsningen er å skifte app tittelen til venstre, åpner plass til opptil fire ikoner gruppert øverst til høyre på tittellinjen. Dette dekker et flertall av hamburger meny bruk-saker, som ofte bare inneholder mellom to og fire elementer. For tilfeller med flere navigasjonsartikler, kan et ellipsis-overløpssymbol bli introdusert. Dette beveger seg bort fra en-size-fits-all-tilnærmingen, istedenfor å gi en rask tilgangsløsning for alle apper, samtidig som de catering for de mer komplekse sakene med større enn fire elementer.
Den andre løsningen er å introdusere nydesignede ikonfeltbjelker. Når materialretningslinjer for tiden oppfordrer designere til å bruke tekstetikettfaner, kan disse enkelt byttes til ikoner. Dette ville åpne nok plass til å fjerne sekundærnavigasjonsmenyen for de fleste apper, og oppfordre designere og utviklere til å forenkle antall primære skjermer i appen deres. På samme måte, med å øke iOS-eiendomsmegling og en revurdere av avstandspraksis i kategorienlinjen, kunne appene passe flere elementer mens de inkluderte sekundære elementer i hver som sekundære faner.
I begge tilfeller gjør det bort med uforsiktig hamburger-menyen. I stedet vil designere og utviklere bli tvunget til å kondensere antall navigasjonsartikler til mer strukturerte og forståelige faner.
Det er altfor enkelt å skyve elementer inn i denne skjulte menyen på bekostning av sluttbrukeren. Det er ofte unødvendig, og ikonet slipper en stor del av tittellinjen i Android-apper.
Over tid vil systemer som Material Design trolig tenke enklere løsninger for å bevege seg forbi hamburgermenyen. Det er på det tidspunktet hvor brukere vil bli presentert med enklere å bruke mobile produkter med enklere, mer tilgjengelige navigasjonsstrukturer.