Optimaal design

[rogierslag]

Wat ik nu aan het maken ben is een intranetpagina. Ik heb het design zo opgezet dat de hoofdmenubalk (bestaat dat woord?) aan de linkerkant staat. Als je op een menuitem klikt schuiven de onderstaande menu-items door en wordt er een soort submenu getoond. Dit is te zien in respectievelijk ingeklapt.jpg en uitgeklapt.jpg . (let ook niet op de lettergroottes want ik heb hier alleen Paint en geen behoefte mijn conceptjes ontzettend netjes te maken ).

In het design (oke, ik bedoel eerder de plaatsing van dingen want het is nou zwart en wit ) wordt rekening gehouden met 800*600 gebruikers die IE6 gebruiken. Hiervoor is het interne venster altijd maximaal 771*419 waardoor er nooit gescrolled hoeft te worden.

Nou vroeg/vraag ik me twee dingen af

1. Is een hoofdmenu links handiger dan boven? Dit vooral: wat is het meest intuiëf? Ik vind zelf links met het naar benedenschuiven het meest logisch, maar misschien is een balk boven met een subbalk (ala T.net FP) handiger?
2. Voor het dynamisch naar onder schuiven kan ik moeilijk gaan doen met AJAX, maar ik denk dat dat niet echt nodig is. Het moet wel een webapplicatie worden die aanvoelt als bijvoorbeeld Gmail of iets dergelijks. Ik denk dat met een beetje javascript en een hidden-frame wat PHP input regelt dit ook te doen moet zijn, maar misschien is het gebruik van AJAX hier toch beter? Dit in verband met de informatie die steeds op de achtergrond moet worden opgehaald.

[3DDude]

waarom maak je niet 2 voorbeelden / kleine conceptjes van hoe het er dan uit zal gaan zien.
En leg je deze dan voor aan je collega's die gebruik willen gaan maken van de intranet-site

[whoami]

Hmm, dit is niet echt software-design & architectuur. Dit gaat eerder over webdesign.

PRG->WEB

[rogierslag]

3DDude schreef op woensdag 05 december 2007 @ 22:32:
waarom maak je niet 2 voorbeelden / kleine conceptjes van hoe het er dan uit zal gaan zien.
En leg je deze dan voor aan je collega's die gebruik willen gaan maken van de intranet-site

Degenen die er gebruik van moeten maken hebben zelf geen enkel idee wat het handigst is. Zijn van die typisch ik-heb-een-trucje-geleerd gebruikers. vandaar. Maar aangezien ik de oplossing later weer kan verkopen (dat mocht) wil ik wél die userface zodanig hebben dat iedereen er goed en snel mee kan werken

[RM-rf]

Is het nodig om de Menu's uit te klappen?
heb je het nodig om die ruimte te sparen, bv omdat je in de overblijvende ruimte kennelijk andere inhoud wilt tonen?

Als het niet nodig is, de ruimte eigenlijk er sowieso is; is er volgens mij ook geen grond menu's uit te laten klappen.

[_Apache_]

Vergeet de volgende punten niet;

- Houd rekening met je doelgroep, hoe cliche het ook klinkt, elke groep is weer anders, elke groep bekijkt zijn interface weer vanuit een andere hoek.
- Houd rekening met gewenste functionaliteit, maak een interface waarin het mogelijk is. Denk hierbij aan ruimte, verborgen knopjes etc.
- Geen enkele interface is perfect, dat is een utopie. Maar er zijn wel interfaces heel goed .
- Vergeet de toekomst niet. Is 800*600 echt een eis? 1024 lijkt me reeeler namelijk, maar dat is natuurlijk compleet afhankelijk van de hardware en wensen van de doelgroep.

[rogierslag]

RM-rf schreef op woensdag 05 december 2007 @ 22:49:
Is het nodig om de Menu's uit te klappen?
heb je het nodig om die ruimte te sparen, bv omdat je in de overblijvende ruimte kennelijk andere inhoud wilt tonen?

Yep, onder elk hoofdonderdeel komen een stuk of 8 subonderdelen en dat wordt anders een prachtige chaos

_Apache_ schreef op woensdag 05 december 2007 @ 22:50:
Vergeet de volgende punten niet;

- Houd rekening met je doelgroep, hoe cliche het ook klinkt, elke groep is weer anders, elke groep bekijkt zijn interface weer vanuit een andere hoek.

Daarom wil ik gewoon rekening houden met ´s werelds grootste groep morons

- Vergeet de toekomst niet. Is 800*600 echt een eis? 1024 lijkt me reeeler namelijk, maar dat is natuurlijk compleet afhankelijk van de hardware en wensen van de doelgroep.

Ik maak meerdere stylesheets, maar de 800*600 is het lastigst, omdat deze erg streng en beperkend is met de ruimte. Erg handig is dat vanwege de kosten en geringe meerwaarde (management) er enkel 15" monitortjes staan. En dat voor mensen die de hele dag Office gebruiken. Ik zal toch eens voorzichting lobbyen voor 19" want die 15" is echt klote

[Voutloos]

rogierslag schreef op donderdag 06 december 2007 @ 02:00:
[...]
Yep, onder elk hoofdonderdeel komen een stuk of 8 subonderdelen en dat wordt anders een prachtige chaos

Volgens mij bedoelt RM-rf niet dat je alles uitgeklapt moet laten zien, maar dat je ook submenu's kan laten zien zonder de overige hoofditems opzij te schuiven. Ik heb iig een hekel aan dat soort verpringende elementen.

[Jiffy]

Voutloos schreef op donderdag 06 december 2007 @ 08:14:
[...]
Volgens mij bedoelt RM-rf niet dat je alles uitgeklapt moet laten zien, maar dat je ook submenu's kan laten zien zonder de overige hoofditems opzij te schuiven. Ik heb iig een hekel aan dat soort verpringende elementen.

Eensch. Verspringende menu's vind ik persoonlijk ook afschrikwekkend. Het lijkt me dat dit voor 'gebruikers-die-een-truukje-hebben-geleerd' nog veel meer zal gelden.

[RM-rf]

rogierslag schreef op donderdag 06 december 2007 @ 02:00:
[...]


Yep, onder elk hoofdonderdeel komen een stuk of 8 subonderdelen en dat wordt anders een prachtige chaos

Chaos? al bij 5x8 = 40 linkjes op een pagina?
mwah, dat is eerder een kwestie van goed ontwerp, functionaliteit en overzichtelijkheid, ook zoiets kun je er gewoon prima overzichtelijk uit laten zien ...
met kleurgebruik of grafische elementen een schone 'scheiding' aanbrengen

Ik vind rubriek-namen als 'Overig' en 'Algemeen' eerder een hoog 'Magic Meat' niveau hebben (die term wordt in usability gebruikt voor een navigatiestructuur die veel 'verborgen' houd en overlaat aan de gebruikers om dat zélf op eigen houtje uit te vinden, gebaseerd op een verhaal over een slager die bij het vlees op zn toonbank niet de naam wil schrijven van welk dier het afkomt: dat moeten zn klanten maar proeven).

als het toch gewoon gaat om een statische pagina die als 'doorverwijsportal functioneert zie ik daadwerkelijk niet de meerwaarde in van het moeten hoveren over hoofdrubrieken om subrubrieken te zien en ik vermoed dat het voor gebruikers, zeker als die gebruikers niet zo 'ontdekkerig' en 'computer-flexibel' zijn, enkel zal storen en een barriere voor het gebruik vormt.

Tevens vind ik het onzin om te doen alsof een effectieve beeldscherm-grootte van 700x450 pixels te 'weinig' zou zijn voor 5 hoofdgroepen en 8 onderlinkjes...
Aangenomen dat je 30 a 35 pixels voor de hoogte van zulke buttons heb, hou je nog genoeg ruimte voor margins over.

Uit de beschrijving komt mij (nofi) een beetje de indruk van iemand die het te graag 'mooi' wil doen en de nieuwste technieken wil toepasen (Ajax noemen, terwijl dat hier volgens mij nergens nut of zin heeft en niet eens van toepassing is, mogelijk gebruik je de term ook abusievelijk als je het hebt over dynamische HTML-elementen in een pagina zonder asynchrone requests)..
Op zo'n moment is er een goede raad: K.I.S.S. (wat een verpopularisering is van een principe dat door een nederlandse programmeur en informaticus gesteld is ooit: "Eenvoud is een voorwaarde voor Betrouwbaarheid")

[ Voor 16% gewijzigd door RM-rf op 06-12-2007 09:50 ]

[rogierslag]

Het zal er niet onoverzichtelijk op worden (hoewel ik me ontzettend heb voorgenomen duidelijker te zijn in interface dan Fidura, want dat is een hel!), maar het feit is eerder dat men zich niet steeds de blubber zoekt voor een linkje. Het ideale geval is dat men klikt op een hoofdcategorie, waarna ze een subcategorie kunnen kiezen

		Deze cel en onderstaande cellen herbergen de inhoud
Hoofdmenu1	Submenu1.1, afhankelijk van gekozen hoofdmenu
Hoofdmenu2	Submenu1.2, afhankelijk van gekozen hoofdmenu
Hoofdmenu3	Submenu1.3, afhankelijk van gekozen hoofdmenu
Hoofdmenu4	Submenu1.4, afhankelijk van gekozen hoofdmenu

offtopic:
Ik heb nogal de tabellayout verneukt, maar je snapt het idee wel hoop ik

Submenu1.* hoort bij hoofdmenu1, submenu2.* bij hoofdmenu2 etc. Dit moet een beetje dynamisch gebeuren zoals bijvoorbeeld in Gmail. Niet met een hover, maar daadwerkelijk met een klik, meer zoals in een desktop programma.

Verder moeten calls tussentijds opgeslagen worden, moeten er databases worden geraadpleegd zonder complete refresh en moeten er via een auto background refresh ook pushmessages kunnen worden verstuurd. Dan lijkt me AJAX ook weer niet ontzettend overdreven. Er worden namelijk weldegelijk asynchrone request gebruikt (als het zonder AJAX kan lijkt me het juist beter, ontwikkeld makkelijker voor meerdere browsers. Alleen wil ik niet het 1*1px frame gebruiken om serverdata in een javascriptje te mikken.)

Hoofdmenu namen zijn ook nog fictief, die wil ik nog wel iets duidelijker maken. Algemeen en Overig slaat namelijk op helemaal niks.

Tenslotte wil ik het graag mooi doen. Ik ben nou een student en het kan toch zeker een goed zakcentje opbrengen om zo´n complete omgeving aan verschillende bedrijven te verkopen. Nieuwe technieken zijn geen vereiste, het liefst gebruik ik bewezen technieken zoals PHP, CSS en HTML aangezien ik daar goed bekend mee ben. Maar ik leg het hier juist voor omdat jullie nou eenmaal meer ervaring hebben met deze dingen (no slijmopmerking intended )

[rogierslag]

subtiele rotschop

[rogierslag]

Hopelijk mag ik nog een keer iets posten.

Ik heb nou het volgende menu geproduceerd: http://voorbeeld.abenslag.nl/menu/menuvoorbeeld.html

Voor mijn gevoel is dit netjes opgelost. Het is allemaal redelijk overzichtelijk en werkt eigenlijk hetzelfde als het Start menu in Windows (wat vrijwel iedereen snapt).

Alleen twijfel ik nog over de indeling van het menu. Achten jullie dit voldoende functioneel?

[djiwie]

Welke onderdelen worden het meest gebruikt? Die zou ik bij elkaar groeperen. Verder vind ik de indeling van 'Dossierbeheer' en 'Relatiebeheer' onder het kopje 'Informatie beheer' (dat moet trouwens aan elkaar geschreven worden) niet logisch.

Maar ik ben geen gebruiker. Het werkt toch echt het beste om je toekomstige gebruikers je ontwerp te laten zien, ze een aantal taken uit te laten voeren (zoals: voer een gesprek in voor een relatie die niet in het systeem staat) en laat ze vervolgens maar klagen waarom ze zo veel moeten klikken, waarom het niet bij elkaar gegroepeerd staat, etc. Zij moeten er tenslotte dagelijks mee werken!

Ga je trouwens nog aparte icoontjes gebruiken voor de onderdelen? Dat maakt het gemakkelijker om snel het juiste onderdeel te vinden bij het scannen

[Blue-eagle]

De raakvlakken mogen iets groter (padding van 2px meer zou voldoende zijn), aparte icoontjes voor herkenning is handig, en ik zou ervoor zorgen dat zodra je met de muis uit een submenu beweegt, het submenu nog een halve seconde zichtbaar blijft. Vooral mensen die niet goed met de muis om kunnen gaan willen horizontaal nog weleens te ver doorschieten en kunnen zichzelf niet op tijd corrigeren.

Daarbij vind ik het grafisch gezien niet mooi dat de icoontjes strak tegen de rand aan staan - dat zie je in veelgebruikte omgevingen als Windows ook nauwelijks terug. Maar dat zou opgelost kunnen zijn door het raakvlak te vergroten (padding).

Verder zou ik kijken of je niet iets anders kan verzinnen voor het groeperen van de knoppen, nu laat je een lege rij staan om bijvoorbeeld "beheer" en "vergrendelen" van elkaar te scheiden. Die zou ik in de hoogte wat smaller maken en verduidelijken in de stijl van de applicatie.

[rogierslag]

Alweer een flinke tijd terug dat ik hier voor het laatst heb gepost.

Ik heb het oude gebeuren volledig op de schop gegooid en hierdoor ziet het er nu, voor mijn gevoel, een stuk frisser uit.

Helaas is Internet Explorer 6 nog steeds de klootzak met de onmogelijkheid van transparantie in een png, wat vooral opvalt in een hover. Vanwege het uiterlijk van de icoontjes is een 256 kleuren gif niet echt van toepassing. De icoontjes moet ik nog even fatsoenlijk ontwerpen, ik heb er nou ééntje staan als voorbeeld dat je de stijl een beetje vat.

Ook is de padding waarde nou groter en blijft het menu staan bij een mouseout. Alleen een mouseclick buiten het menu reset de beginpositie. Ik moet alleen nog even sleutelen aan de naamgeving van de onderdelen, dat die meer voor zichzelf spreken. Eventuele tips zijn welkom. Tenslotte vindt de doelgroep de huidige soort/alfabetische ordening handig. Hier wil ik dus niet teveel aan veranderen.

Graag wil ik even van jullie horen

1. Hoe bevalt het huidige menu (in vergelijking met het vorige)
2. Hoe is de reactiesnelheid**

** => Ik heb nou de server expliciet dingen laten cachen op de client, want IE wil ook nog eens alle icoontjes ophalen, ook al hebben ze dezelfde E-tag . Dit is bij het laden geen probleem, maar als bij een hover er een 0.3 seconde vertraging inzit is dat niet netjes.

En als laatste de URL http://intranet.abenslag.nl/zoalsiktwil/menu.html

P.S. Ik heb hier geen IE7 dus eventuele renderfoutjes zijn ook welkom!

[simon]

Wat een hoop zeg, het is nu nogal veel zonder contrast

[rogierslag]

verklaar je nader, want met een zo'n reply kan ik ook niet echt veel helaas. Wat is er contrastloos, waarom ed

[simon]

Ok, je hebt eeen enorme rit aan opties, grijze achtergrond, en elke optie staat vrij recht onder elkaar, het contrast tussen elke knop is minimaal, je moet er voor zorgen dat er contrast is tussen de ene knop en de andere, dat er een soort van 'textuur' in beeld is. Nu is 't een blok, dat vooral als tekst over komt, dus zorg voor onderscheidt (contrast) tussen je knoppen.

Ik zou zeggen, probeer gewoon heel veel, kijk heel veel... de reactiesnelheid is wel erg vlot, dat is mooi. Het is rustiger dan 't vorige, maar je moet denk ik meer feeling voor design ontwikkelen, erg moeilijk uit te leggen, is meer een grafisch iets, maar ruimtelijk en qua kleur/contrast is 't een wat compact menu.. Het straalt geen rust uit.

[Muthas]

Overigens kan zoiets ook met vrijwel volledig met CSS, op een IE hover JS hack na. Dat werkt veel sneller. Kijk even op A List Apart. Dit voorbeeld is dan wel horizontaal, verticaal kan ook gewoon.

Huidige design is wel oké, vooral als je overal nog een hip klein icoontje toevoegd.

Edit: Wat zit iedereen te zeuren over contrastloos gebeuren? Is toch lekker rustig zo. Hoeveelheid tekst valt imo wel mee.

[ Voor 15% gewijzigd door Muthas op 11-01-2008 21:00 ]

[simon]

Oh nee ik zeur.. helemaal.. ik mag dat toch gewoon vinden? Ik vind 't contrastloos en veel tekst.. Mja, misschien ben ik gewoon een grafisch georienteerd persoon..

[dB90]

Ben zelf ook een grafisch georiënteerd persoon en vind het menu er strak, zakelijk en duidelijk uitzien. Het gaat geloof ik om een intranet webapp en de gebruikersgroep kent office en windows dus ik denk dat dit er goed op aansluit! De mening van de doelgroep is in deze het allerbelangrijkst! Way to go

[Bozozo]

Ik vind het een mooi menu, maar het sluit niet goed. In FF2 moet ik ergens op focussen om de uitgeklapte dropdowns in te klappen.

Google even op Sons of Suckerfish dropdowns, daarmee presteer je hetzelfde met een postzegeltje javascript en zonder CSS hacks.

[djiwie]

In IE7 wordt het menuitem met een icoontje niet helemaal goed gerenderd, het verspringt iets naar links als je het uitklapt.
Probeer trouwens om in de grootste groep items nog een scheiding aan te brengen, de meeste mensen kunnen tot 5 items nog in één blik overzien, daarna wordt het te veel.
En het menu sluit inderdaad niet, maar ik weet niet of dit by design is.

[rogierslag]

het niet automatisch inklappen is inderdaad by design. De bedoeling was dat het gedrag van het intranet het gedrag van het Windows Start-menu zou evenaren, en dat klapt ook niet in totdat e de focus ergens anders legt. Verder is er natuurlijk zo geklikt en is dit toch handiger voor de anti-muisvaardige mensen die niet de vaardigheid hebben om een pixel of honderd naar rechts te gaan, maar meteen over het hele scherm heencrossen

Iets meer rust wilde ik erin brengen door overal netjes een mooi icoontje bij te ontwerpen.

Herontwerpen voor minder javascript en geen CSS hacks ga ik denk ik toch niet doen. In principe werkt het allemaa prima, het is alleen voor IE wat veel renderwerk gevraagd waardoor er fouten insluipen. Met het intranet heb je namelijk alsnog volledige controle over de "applicatie" en ik was stiekem van plan in plaats van IE om Opera te implementeren voor het gebruik. Dat rendert namelijk alles prachtig.

Javascript en CSS worden via een 100Mbit netwerk naar de gebruiker gestuurd en dan voor 10 dagen gecached op de client. Het is dus niet echt van belang dat de Javascript vrij groot is. Ik ga ook nog wel de minify-tool eens uit de kast halen om de JS en CSS te verkleinen, naast de al aanwezige Gzip compressie.

Tenslotte vraag ik me af of het echt noodzakelijk is dat men na ongeveer 5 items een "rustmoment" inbouwt. Ik heb er nog nooit van gehoord en eerlijk gezegd ken ik genoeg mensen met 3 Start menu tabbladen waar ze, zodra ze weten waar het staat, keurig mee kunnen werken.

[simon]

mja je hebt 'het werkt' en 'het kan opzich beter', dat men niet klaagt wil niet zeggen dat het niet met heel weinig werk beter kan.

[djiwie]

rogierslag schreef op zaterdag 12 januari 2008 @ 12:05:
Tenslotte vraag ik me af of het echt noodzakelijk is dat men na ongeveer 5 items een "rustmoment" inbouwt. Ik heb er nog nooit van gehoord en eerlijk gezegd ken ik genoeg mensen met 3 Start menu tabbladen waar ze, zodra ze weten waar het staat, keurig mee kunnen werken.

Kijk bijvoorbeeld hier eens, onder "Beperkingen in het werkgeheugen (working memory, WM)":

Algemeen wordt er vanuit gegaan dat stimuli uit onze sensoren in eerste instantie in een relatief onbewerkte vorm in ons werkgeheugen terechtkomen. Het werkgeheugen is een korte-termijn geheugen waarvan de inhoud bestaat uit huidig geactiveerde kennis en perceptuele input. (...) Het WM is hiertoe maar voor korte tijd in staat en heeft een beperkte capaciteit. Het laatste wordt aangeduid als 'Miller's law': 7±2 (George Miller, 1956). Hiermee wordt gerefereerd aan het aantal items dat tegelijkertijd actief kan zijn binnen het werkgeheugen, dat 7 plus of min 1 of 2 is. Overigens is dit later door de cognitieve psycholoog Nelson Cowan [1] weerlegd: Hij heeft aangetoond dat het kortetermijngeheugen doorgaans niet verder komt dan 4. Is het meer, dan is vrijwel altijd sprake van 'chunking'.
(...)
Bijvoorbeeld het aantal options in een listbox waar je de gebruiker uit laat kiezen. Houd dat onder de zeven. Er kunnen wel meer keuzes staan, maar in dit geval zal een bepaalde organisatie de gebruiker ondersteunen; bijvoorbeeld een alfabetisch of hierarchisch geordende lijst.

Met een scheidingsbalkje groepeer je de boel tot hapklare brokken voor je gebruiker. Als gebruiker houd je dan het overzicht, omdat je alle items in je working memory kunt verwerken.