Pour reprendre le problème de la taille des menus :
En supposant qu'un champ de menu occupe un espace de 80 par 20 pixels :
En 1024x768, un menu horizontal occupe 2,6% de l'espace en hauteur, et un menu vertical 7,8% de l'espace en largeur. Certes, on a tendance à préférer sacrifier l'espace en largeur, car en général, ce qu'on souhaite d'une maximisation est une maximisation en hauteur. Cela dit, je doute qu'une simple barre de menu présente en permanence en haut gêne beuacoup de personnes, car quelque soit l'appli, même en plein écran (je pense aussi bien à IE qu'à Galeon, et il y en a d'autres), il reste toujours une barre de menu en haut.
Le problème du menu horizontal, c'est qu'il y a moins de place disponible pour des entrées qu'en vertical. Dans le cas présent (1024x768), on est limité à 12 entrées, contre 38 en vertical. Il faut donc prévoir soit la possibilité de réduire les menus en largeur (et par exemple d'avoir soit un truc du genre info-bulle qui s'affiche quand on passe dessus, soit carrément un redimmensionnement au détriment des autres entrée, toujours quand on passe dessus).
> Accessoirement, on garde une cohérence entre tous les niveaux de menus -- les menus horizontaux classiques se transforment dès le 2nd niveau en niveaux verticaux si on y réfléchit ! -- alors qu'avec un menu vertical de bout en bout, tout reste logique.
Oui, euh, justement, ça a beau être logique, je n'ai jamais trouvé ça pratique, de devoir naviguer dans des menus verticaux (c'est comme sous Gnome/KDE/Windows à partir du menu démarrer, ça, et franchement ...), donc, même si le 2ème niveau de menu se comporte ainsi, ça en supprime déjà un, ce qui à mon avis est un plus.
Quitte, d'ailleurs, tiens, puisqu'on y est, à afficher les sous-menus à l'horizontale également, par-dessus le premier menu. Ça resterait ainsi cohérent dans l'idée, non ? Car il faut bien se dire qu'une fois qu'on a choisi d'ouvrir un sous-menu, on n'a plus besoin des autres entrées, celles-ci ne font que gêner à l'écran.
[^] # Re: Penser les interfaces ...
Posté par Jak . En réponse à la dépêche Un grand pas pour l'interface de KDE ?. Évalué à 3.
En supposant qu'un champ de menu occupe un espace de 80 par 20 pixels :
En 1024x768, un menu horizontal occupe 2,6% de l'espace en hauteur, et un menu vertical 7,8% de l'espace en largeur. Certes, on a tendance à préférer sacrifier l'espace en largeur, car en général, ce qu'on souhaite d'une maximisation est une maximisation en hauteur. Cela dit, je doute qu'une simple barre de menu présente en permanence en haut gêne beuacoup de personnes, car quelque soit l'appli, même en plein écran (je pense aussi bien à IE qu'à Galeon, et il y en a d'autres), il reste toujours une barre de menu en haut.
Le problème du menu horizontal, c'est qu'il y a moins de place disponible pour des entrées qu'en vertical. Dans le cas présent (1024x768), on est limité à 12 entrées, contre 38 en vertical. Il faut donc prévoir soit la possibilité de réduire les menus en largeur (et par exemple d'avoir soit un truc du genre info-bulle qui s'affiche quand on passe dessus, soit carrément un redimmensionnement au détriment des autres entrée, toujours quand on passe dessus).
> Accessoirement, on garde une cohérence entre tous les niveaux de menus -- les menus horizontaux classiques se transforment dès le 2nd niveau en niveaux verticaux si on y réfléchit ! -- alors qu'avec un menu vertical de bout en bout, tout reste logique.
Oui, euh, justement, ça a beau être logique, je n'ai jamais trouvé ça pratique, de devoir naviguer dans des menus verticaux (c'est comme sous Gnome/KDE/Windows à partir du menu démarrer, ça, et franchement ...), donc, même si le 2ème niveau de menu se comporte ainsi, ça en supprime déjà un, ce qui à mon avis est un plus.
Quitte, d'ailleurs, tiens, puisqu'on y est, à afficher les sous-menus à l'horizontale également, par-dessus le premier menu. Ça resterait ainsi cohérent dans l'idée, non ? Car il faut bien se dire qu'une fois qu'on a choisi d'ouvrir un sous-menu, on n'a plus besoin des autres entrées, celles-ci ne font que gêner à l'écran.