[Discussie] Dynamisch aantal menu items in CMS
Ik zit al een tijdje met deze vraag: hoe maakt je het best je horizontale menu indien je een CMS hebt waarbij er een willekeurig aantal pagina's kan zijn?
Dit lijkt op het eerste zicht een domme vraag, maar is het eigenlijk niet. Ik vraag niet voor PHP of SQL code omdat dat allemaal geen probleem is. Ik vraag puur om het concept.
Een voorbeeld:
Je pagina heeft een vaste breedte (laten we zeggen 1000px). Je hebt een volledig werkend CMS gebouwd waarmee de gebruiker zelf pagina's kan toevoegen, verwijderen, wijzigen, ... De layout van je website heeft een horizontaal menu. Wat doe je wanneer de gebruiker zoveel pagina's heeft aangemaakt, dat ze eigenlijk niet meer op 1 lijn passen in dit menu? Hoe ga je hier mee om?
Enkele voorstellen of een hele discussie, voor mij is het allemaal welkom.
Jens
Vertellen dat dit niet kan :-) en ik neem aan dat dit uiteraard besproken is voor oplevering aan klant. Zogenaamde restricties dus klevend aan ontwerp en layout en dan gebruik maken van submenu items
Maar één mogelijkheid is dat je de gebruiker laat bepalen of een bepaalde pagina in een menu moet ja of nee en of het dan een submenu item moet zijn van een ander menuitem ja of nee. Daarnaast is het ook mogelijk dat je
het menu verschuifbaar kunt maken.
Momenteel is het erg hot bij smallere vensters een uitklapbaar verticaal menu aan te bieden en bij bredere een horizontaal. zie bijvoorbeeld http://osvaldas.info/drop-down-navigation-responsive-and-touch-friendly
- Je kunt het aantal items beperken, bijv. maximaal 6, zodat je zeker weet dat het past.
- Je kunt op de volgende regel verder gaan... dan heb je dus 2 regels met menu-items.
- Je toont maximaal (bijv.) 5 menu-items en als het er meer worden dan heb je een knop "meer...". Als je op die knop drukt komen de overige menu-items tevoorschijn.
@Frank, mooi voorbeeld voor responsive design, maar niet direct een oplossing voor een gewone webbrowser op normale PC resoluties.
@Ozzie, uit die lijst die je net gaf, wat zou jij kiezen?
Ik denk optie 1. Aan 6 of 7 hoofdmenu-items zou je in het algemeen genoeg moeten hebben.
Ozzie PHP op 22/08/2013 21:34:25:
Ik denk optie 1. Aan 6 of 7 hoofdmenu-items zou je in het algemeen genoeg moeten hebben.
En daarna dan met submenu's werken en de verantwoordelijkheid bij de beheerder van de website leggen? Klinkt misschien nog wel het beste, ja.
Je kunt ook te ver gaan in gebruikersvriendelijkheid. Als jou gebruiker ziet dat een extra menu niet mogelijk is, zal hij vanzelf wel zijn website anders gaan indelen. Ik zou het zo afvangen dat mocht hij wel een menu item teveel aanmaken het er gewoon onder komt te staan. Of je maakt support voor dropdown menu's
Jens V op 22/08/2013 21:35:49:
En daarna dan met submenu's werken en de verantwoordelijkheid bij de beheerder van de website leggen? Klinkt misschien nog wel het beste, ja.
Ozzie PHP op 22/08/2013 21:34:25:
Ik denk optie 1. Aan 6 of 7 hoofdmenu-items zou je in het algemeen genoeg moeten hebben.
En daarna dan met submenu's werken en de verantwoordelijkheid bij de beheerder van de website leggen? Klinkt misschien nog wel het beste, ja.
Inderdaad. Uit onderzoek is gebleken dat je in keuzes (menu's, lijstjes) e.d. het beste maximaal 7 keuzes kunt aanbieden. Bied je meer opties dan is het moeilijker voor de bezoeker om een keuze te maken wat er toe kan leiden dat hij/zij uiteindelijk helemaal geen keuze kan maken. Dus ik zou kiezen voor max. 7 hoofdcategoriën met subcategoriën. Succes!
Ozzie PHP op 22/08/2013 23:50:49:
Inderdaad. Uit onderzoek is gebleken dat je in keuzes (menu's, lijstjes) e.d. het beste maximaal 7 keuzes kunt aanbieden. Bied je meer opties dan is het moeilijker voor de bezoeker om een keuze te maken wat er toe kan leiden dat hij/zij uiteindelijk helemaal geen keuze kan maken. Dus ik zou kiezen voor max. 7 hoofdcategoriën met subcategoriën. Succes!
Jens V op 22/08/2013 21:35:49:
En daarna dan met submenu's werken en de verantwoordelijkheid bij de beheerder van de website leggen? Klinkt misschien nog wel het beste, ja.
Ozzie PHP op 22/08/2013 21:34:25:
Ik denk optie 1. Aan 6 of 7 hoofdmenu-items zou je in het algemeen genoeg moeten hebben.
En daarna dan met submenu's werken en de verantwoordelijkheid bij de beheerder van de website leggen? Klinkt misschien nog wel het beste, ja.
Inderdaad. Uit onderzoek is gebleken dat je in keuzes (menu's, lijstjes) e.d. het beste maximaal 7 keuzes kunt aanbieden. Bied je meer opties dan is het moeilijker voor de bezoeker om een keuze te maken wat er toe kan leiden dat hij/zij uiteindelijk helemaal geen keuze kan maken. Dus ik zou kiezen voor max. 7 hoofdcategoriën met subcategoriën. Succes!
of gewoon de eerste zes horizontaal, de zevende erachter met de tekst 'meer...' en de rest als submenuitems van 'meer...' (verticaal dus)
UX-mythe.
Wat véél belangrijk is voor bezoekers, is dat je informatie logisch structureert. De chaos van 25 of 100 keuzen is voor geen enkele bezoeker prettig. Op een menukaart zie je ook graag structuur: voorgerecht, hoofdgerecht, nagerecht... Daarom zou ik toch zeggen: 7 +/- 2
De formule voor het kortetermijngeheugen is om precies te zijn 7 +/- 2 dus 5 t/m 9 keuzen. Volgens sommigen is dat voor een menuontwerp echter helemaal niet relevant en een Wat véél belangrijk is voor bezoekers, is dat je informatie logisch structureert. De chaos van 25 of 100 keuzen is voor geen enkele bezoeker prettig. Op een menukaart zie je ook graag structuur: voorgerecht, hoofdgerecht, nagerecht... Daarom zou ik toch zeggen: 7 +/- 2
Ceasar Feijen op 22/08/2013 21:18:51:
Vertellen dat dit niet kan
Dit zeg je dus nooit tegen een klant, alles kan er moet gewoon vanuit de ontwikkelaar de juiste oplossing aangeboden worden.
Nee verkoop is het slechte wat je kunt doen, vooral met webdesign omdat hier letterlijk bijna alles mogelijk is. Het is aan het bedrijf of persoon hoe je dit probleem aanpakt.
Gewijzigd op 23/08/2013 14:00:59 door Chris PHP
Frank Nietbelangrijk op 23/08/2013 13:31:33:
of gewoon de eerste zes horizontaal, de zevende erachter met de tekst 'meer...' en de rest als submenuitems van 'meer...' (verticaal dus)
Dat zei ik dus in m'n 1e reactie al als een mogelijke optie ;)
Ward van der Put op 23/08/2013 13:46:43:
De formule voor het kortetermijngeheugen is om precies te zijn 7 +/- 2 dus 5 t/m 9 keuzen. Volgens sommigen is dat voor een menuontwerp echter helemaal niet relevant en een UX-mythe.
Tja, er zijn altijd voor-en tegenstanders ergens van. Dat wil niet zeggen dat het daarom niet waar is. Als ik zelf bijv. schoenen ga kopen, dan heb ik liever de keuze uit 5 paar interessante schoenen dan uit 30 paar interessante schoenen. In dat laatste geval is het namelijk veel lastiger de juiste keuze te maken. Volgens mij heeft het niet zozeer met je geheugen te maken, maar met het maken van de juiste keuze. Als je de keuze uit 30 hebt (in plaats van 5) dan is de kans dat je (voor je gevoel) de verkeerde keuze maakt groter. Dit kan tot gevolg hebben dat je helemaal geen keuze maakt en op zoek gaat naar een andere winkel.
The Paradox of Choice: Why More Is Less. Het bekendste experiment was een verkoopproef waarbij klanten de keuze hadden uit 24 soorten jam of maar 6 soorten jam; bij slechts 6 soorten werd er 10 keer méér verkocht!
Maar goed, punt is wel dat een menu geen jam is en een website geen schoenenwinkel.
Die keuzestress is uitgebreid beschreven in Maar goed, punt is wel dat een menu geen jam is en een website geen schoenenwinkel.
Frank Nietbelangrijk op 23/08/2013 13:31:33:
of gewoon de eerste zes horizontaal, de zevende erachter met de tekst 'meer...' en de rest als submenuitems van 'meer...' (verticaal dus)
Zo een knopje met 'meer...' is toch ook niet echt gebruiksvriendelijk?
Jens V op 23/08/2013 15:49:47:
Klopt ja.
Zo een knopje met 'meer...' is toch ook niet echt gebruiksvriendelijk?
Frank Nietbelangrijk op 23/08/2013 13:31:33:
of gewoon de eerste zes horizontaal, de zevende erachter met de tekst 'meer...' en de rest als submenuitems van 'meer...' (verticaal dus)
Zo een knopje met 'meer...' is toch ook niet echt gebruiksvriendelijk?
De grootste zoekmachine, Google doet dit nochtans toch ook? Met hun zwarte menubalk bovenaan.
Waarom wil je deze keuze eigenlijk formaliseren in het ontwerp van een CMS? De gebruiker van het CMS kan dat toch zelf uitvogelen? Immers: als het niet past, dan past het niet.
Mathias B op 23/08/2013 16:12:58:
De grootste zoekmachine, Google doet dit nochtans toch ook? Met hun zwarte menubalk bovenaan.
En dat vind ik persoonlijk niet altijd even gemakkelijk. Ik kan daar alleen in zijn, hoor :-)
Ward van der Put op 23/08/2013 16:30:39:
Waarom wil je deze keuze eigenlijk formaliseren in het ontwerp van een CMS? De gebruiker van het CMS kan dat toch zelf uitvogelen? Immers: als het niet past, dan past het niet.
Klopt, ja. Maar je hebt ook gebruikers die eigenlijk helemaal geen verstand hebben van wat ze aan het doen zijn. En voor die gebruikers is er best een mechanisme dat hen behoedt van domme dingen...
Gewijzigd op 23/08/2013 16:42:30 door Jens V
Jens V op 23/08/2013 16:41:13:
Klopt, ja. Maar je hebt ook gebruikers die eigenlijk helemaal geen verstand hebben van wat ze aan het doen zijn. En voor die gebruikers is er best een mechanisme dat hen behoedt van domme dingen...
Correct, een fool of twee heb je er altijd tussen zitten, maar je kunt het toch niet foolproof maken. Straks verzint een sufferd bijvoorbeeld dat de link Home de tweede keuze moet worden omdat hij dat zelfs "handig" vindt.
Dit soort keuzen zijn voor gebruikers makkelijker te maken als je ze een live preview toont: zó gaat deze instelling er uit zien! Technisch hoef je er verder geen limiet op te zetten. Toon de ingestelde menu's en inderdaad een "meer..." of pictogram als de menubalk overloopt.
Zoals al duidelijk wordt aangeven is het ZEER ONWENSELIJK dat er een gigantische lijst
aan niet categoriseerde menu items komt te staan.
dus in ons moerstaal:
Menu: ZO KORT EN LOGISCH MOGELIJK
dan heb je de gebruikers van de cms: die willen misschien toch meerdere items.
daar heb je dan al een aantal oplossingen voor gekregen.
kan er een slotje op?
Gewijzigd op 23/08/2013 17:44:51 door Frank Nietbelangrijk
Chris NVT op 23/08/2013 14:00:24:
Dit zeg je dus nooit tegen een klant,
Ceasar Feijen op 22/08/2013 21:18:51:
Vertellen dat dit niet kan
Dit zeg je dus nooit tegen een klant,
Er zit nogal een verschil in nee verkopen of in goed onderbouwd zeer stellig nee adviseren als ontwikkelaar. Bij het eerste raak je klanten kwijt, bij het laatste bied je toegevoegde waarde aan de klant...