• J’ai fait avec Mosquito le site d’Avec-Vous Design (avec qui on travaille régulièrement sur les installations d’écrans interactifs) :
    http://www.avecvousdesign.com/spip
    http://www.avecvousdesign.com/spip/S-21-Fontainebleau

    C’est #SPIP #HTML5 #responsive évidemment.

    À noter :

    – le menu de navigation déclenché par un menu hamburger (en haut à gauche), qu’on privilégie désormais (malheureusement encore beaucoup de clients n’en veulent pas en grand écran) ; ici particularité : le logo de la boîte qui slide vers le haut du menu de navigation en changeant de largeur ;

    – dans le slider de page d’accueil (oui, je sais…), le petites transitions CSS qui provoquent l’apparition du texte, c’est assez mignon comme trouvaille,

    – pas mal de boulot sur les pages du « portfolio » :
    http://www.avecvousdesign.com/spip/TMT-Francois-Xavier
    l’image en plein écran en haut de page évidemment, mais surtout les deux colonnes qui scrollent de manière différenciée (à gauche le texte, à droite les images), de façon à démarrer et terminer en même temps le scroll (généralement : la colonne d’image scrolle moins vite que la colonne de texte). Pas évident à régler… (sur petit écran, présentation différente avec un pavé d’images en bas de page).

    – la présentation des rubriques de portfolio (les carrés qui s’animent, la sélection de sous-rubriques dans la même page…) :
    http://www.avecvousdesign.com/spip/Portfolio

    – sur la page « Actualités », en mode #longform :
    http://www.avecvousdesign.com/spip/Actualites
    La présentation de plusieurs images successives sur la même ligne (ou plusieurs lignes selon la taille de l’écran).

    • C’est joli et très clair, super. :)

      Mais :

      malheureusement encore beaucoup de clients n’en veulent pas en grand écran

      Et ils ont raison !

      Masquer le menu principal dès le départ, c’est une mauvaise pratique ergonomique. Et apparemment les dernières études utilisateurs ont fait re-changé l’ergonomie de nombreux gros acteurs du web (qui, c’est certain, sont assez bien informés vu le retour sur investissement qu’ils cherchent, et qu’ils font tous très attention au moindre changement d’interface) pour revenir à afficher au moins les entrées principales les plus importantes dès le départ SANS hamburger, directement visibles, et cela y compris en mobile tout petit écran. FB, Google, Twitter, Airbnb et plein d’autres sont tous revenus a des menus directement visible pour les entrées principales…

      Donc c’est exactement l’inverse que l’état actuel des connaissances (et des utilisateurs, car les utilisateurs changent évidemment) conseille actuellement :
      1) bien garder le menu principal visible en grand écran (au moins les entrées principales) sans rien avoir à cliquer
      2) le garder aussi en petit écran, au moins pour les 3/4/5 entrées principales

      Quand il y a beaucoup d’entrées (ce qui n’est pas le cas de ton site là) la solution est d’afficher 3 ou 4 choses plus un dernier bouton « more » (que ce soit un hamburger, trois petits points horizontaux ou verticaux, ou un mot « more », « plus »…)

      http://seenthis.net/messages/397625
      +
      http://seenthis.net/messages/258219

      Et au passage, quand on utilise un bouton de menu et qu’il n’est pas dans une barre de menus avec plusieurs entrées (ce qui permet de deviner que tous les éléments de la même barre sont cliquables), les tests utilisateurs montrent apparemment que l’icône hamburger seule est très mal comprise :
      http://seenthis.net/messages/241675

      Et que ce qui compte c’est :
      1) avoir un fond ou des bordures qui permettent de deviner que c’est un bouton cliquable (la bordure augmente beaucoup les clics)
      2) avoir un mot « menu », avec ou sans icône, augmente encore beaucoup plus les clics : l’icône hamburger peut alors décorer en plus le mot, mais c’est juste une déco, l’important étant d’avoir un vrai mot

      | ≡ Menu |

      (et donc @visionscarto n’est pas super de ce point de vue là non plus :D)

    • Hello @arno, dis moi, ton truc de « synchronisation du scroll entre deux colonnes », à tout hasard, l’aurais-tu codé dans une fonction un peu générique ? Est-ce qu’on peut l’appliquer à n’importe quelle paire de colonnes côte à côte ?

      J’utilise Sticky Kit, qui fait un truc similaire mais pas pareil : ça fait devenir « fixed » la colonne la plus petite le temps qu’elle rattrape l’autre, puis ça s’arrête.
      http://leafo.net/sticky-kit

      Mais toi ta méthode c’est de faire un effet de ralentissement du scroll sur la plus petite colonne, je trouve ça plus sobre et plus discret.

      Yorait moyen d’en faire une lib générique, tu penses ?

  • Mobile #Menu AB Tested: #Hamburger Not the Best Choice?
    http://exisweb.net/mobile-menu-abtest

    I did a previous test that seemed to show that a bordered “hamburger” (aka sandwich) icon was used more than other options.

    The menu icon on the right was clicked more than the previous two.

    I then decided to test the hamburger icon against the word “MENU”.

    Ah ! Y’a une suite !

    Hamburger vs Menu: The Final AB Test
    http://exisweb.net/menu-eats-hamburger

    The MENU button was clicked by 20% more unique visitors than the HAMBURGER button (…)

    Hamburger icons may appear to be ubiquitous, but they are not the only option.

    There is an issue that is much more important:

    Android users are almost 3x less likely to click a navigation button than iOS users.

    #webdesign via @tetue

    • Résumé : en tout il a fait trois tests AB.

      Le premier étant celui de l’image de @tetue, où il montre tout d’abord que la bordure autour du bouton augmente beaucoup les clics.

      Ensuite dans le deuxième, il introduit le mot « menu » tout seul, avec et sans bordure.

      Enfin dans le troisième, il teste uniquement entre icône et mot, mais les deux avec bordure (puisqu’on a appris avant qu’il faut vraiment avoir une bordure).

      Le grand gagnant étant : le mot « Menu » seul (avec une bordure) :

      Par contre, il apprend au passage que les utilisateurs d’Android cliquent énormément moins sur les éléments de navigation que les utilisateurs Apple.

    • Abusing Ellipses – Siolon
      http://www.siolon.com/blog/abusing-ellipses

      Recently amongst web developers there been a passionate conversation about the use of “hamburger” iconography for progressive disclosure usually showing navigation (for the record, I hate that name for the icon). Some have done extensive A/B testing to prove it alone doesn’t work well, and others write passionately how they have abandoned the pattern. This along with other examples like using a select menu for smaller viewport navigation highlights a problem with our community: we can all-to-quickly grab onto a fad without asking fundamental questions about whether it works or not.

      The Ellipsis’ Traditional Use in Interfaces

      I want to bring up another pattern that has recently become a big problem also: the humble ellipsis. I started seeing ellipsis iconography show up more and more over the last couple of years in web applications. Now the pattern has existed for a long time in desktop applications, but it has served a different purposes. For example, in the OS X Human Interface Guidelines, we read the following instructions for using ellipsis:

    • Lien avec http://seenthis.net/messages/397625
      qui explique que de nombreux gros acteurs (sites ou applis) ont fait machine arrière et on arrêté l’approche « bouton de menu seul qui ouvre un menu caché ».

      Au lieu de cela, ils sont revenus à un menu directement visible, du type « onglets », avec, lorsque nécessaire, un bouton supplémentaire permettant d’ouvrir des choses en plus : parfois c’est trois points « … », parfois c’est « More » ou « Plus », etc et ça ouvre soit un déroulant, soit une page de menu complète séparée.

      Mais le plus important c’est que les éléments principaux, les plus utilisés, sont toujours visibles du premier coup.