SimpleWeb.fr

Souvenez-vous il y a quelques temps je vous avait parlé de Moblin, un système d’exploitation pour Netbooks sur lequel intel travaillait (Quelle interface pour le système d’exploitation de demain ?). Aujourd’hui ce projet n’existe plus car il a été fusionné avec le projet de système d’exploitation Maemo de Nokia pour être renommé en MeeGo. Vou suivez ? Bon bref, ce que vous devez retenir est que MeeGo ambitionne d’être une plateforme de développement multi-terminaux mobiles, donc qui va pouvoir équiper aussi bien les netbooks, que les smartphones, que les téléphones standards, que les TV, que les ordinateurs de bord de véhicules…

Se pose donc le problème de l’uniformisation de l’interface mais également de l’expérience utilisateur. Une première version pour netbooks a été publiée le mois dernier auprès de la communauté : MeeGo v1.0 Core Software Platform & Netbook User Experience project release. Cette première version reprend les fondamentaux de l’interface de Moblin avec sa barre de tâches en position haute (ils ont rajouté un peu de couleurs) :

L'interface de MeeGo pour netbooks

Nous avons également vu dernièrement la version pour smartphones faire son apparition : MeeGo for netbooks and smartphones gets Chrome and Fennec. Même si certaines règles semblent communes (le fond sombre pour les icônes du haut d’écran, le flux d’activité…) nous commençons à voir de sérieuses divergences dans l’interface :

L'interface de MeeGo pour smartphones

Ces divergences sont tout à fait normales car elles sont la conséquence de la prise en compte des contraintes de ces deux types de terminaux. Et ce n’est qu’un début car il va très certainement falloir également tenir compte des spécificités des smartphones eux-mêmes (d’un modèle à l’autre) :

Vue paysage pour la version smartphones de MeeGo

Et finalement cette semaine ont été publiée les premières images de la version touchbook : Pre-alpha MeeGo for tablets demo.

Comme vous pouvez le constater sur la vidéo précédente, l’expérience utilisateur a été complètement repensée pour une manipulation au doigt (donc moins de précision et de clics) où l’on fait défiler les contenus par types de droite à gauche :

La page d'accueil de MeeGo pour touchbooks

Cette page d’accueil me semble tout à fait intéressante mais tranche complètement avec les principes posés pour les autres versions. Il y a également une vue plus traditionnelle avec des icônes sur un bureau et une barre d’applications pour basculer de l’une à l’autre :

Les icônes de MeeGo pour touchbooks

Nous sommes ici bien plus proche de l’iOS que du MeeGo pour netbooks. En soit ce n’est pas un drame mais cela illustre bien la difficulté de concevoir une interface suffisamment malléable pour convenir à différents types de terminaux.

Si je ne me trompe pas, l’objectif de MeeGo est avant tout de fournir une plateforme technique stable, mais pas nécessairement une interface unifiée pour l’ensemble des terminaux visés. Certains éléments communs pourraient être conservés (jeux de couleurs, picto et typo, barre d’état…) mais le pari de proposer une interface unique me semble intenable (Microsoft s’y est cassé les dents avec Windows). Attendons de voir s’ils se lancent dans la publication de design guidelines (qui pourraient être très intéressantes)…

MàJ (01/07/2010) : De nouvelles captures d’écrans viennent d’être publiées pour illustrer l’interface de la version smartphones de Meego  : MeeGo Handset Project Day 1 is Here.

Pas de gros changement par rapport à la précédente version mais un réel effort d’épuration de l’interface et une identité visuelle bien marquée (qui diverge toujours des autres versions). (via The Next Web Mobile)

Saviez-vous que le format PDF a été créé en 1993 par Adobe ? Autant dire que ce format de fichiers est aussi vieux que le web (presque). Toujours est-il que les fichiers PDF font partie du quotidien des internautes mais qu’ils ne sont pas sans poser de problèmes. Le principal étant de provoquer l’ouverture d’une nouvelle fenêtre ou de lancer le téléchargement du fichier alors que l’utilisateur croit avoir cliqué sur un “simple” lien.

Idéalement il faudrait que chacun des liens pointant vers un fichier PDF soit clairement identifiable et précise le poids du fichier. C’est ce que je m’efforce généralement de faire en le précisant dans le lien mais il y a différentes possibilités :

• Ceci est un exemple de fichier (PDF, 55 Ko)
• Ceci est un exemple de fichier (fichier PDF, 55 Ko)
• Ceci est un exemple de fichier (PDF, 55 Ko)
• Ceci est un exemple de fichier [PDF, 55 Ko]

C’est en tombant sur un article récemment publié (How should you display links to PDF files?) que j’ai eu envie de relancer ce vieux débat. Un débat ? Oui tout à fait, celui qui concerne les système de formatage automatique des liens en fonction du format des fichiers. Car le problème est que vous ne pouvez pas vous reposer sur la bonne volonté des rédacteurs qui n’auront pas toujours la conscience de préciser le format ainsi que le poids.

Il y a bien les recommandations d’Adobe en la matière (Use of Adobe icons and web logos) mais elles ne disent pas comment mettre ça en oeuvre de façon automatisée sur un existant avec une multitude liens dans une multitude de pages :

Il existe des solutions pour faire cela avec les feuilles de style (Showing Hyperlink Cues with CSS) mais cela ne règle pas le problème de l’affichage du poids du fichier et vous pousse à reformater l’ensemble des liens (créant ainsi de la pollution visuelle) :

Idéalement il faudrait limiter ce formatage supplémentaire (ajout d’un picto et du poids) aux liens pointant vers des fichiers et l’intégrer directement à l’outil de gestion de contenu qui se chargerait de rajouter un picto ainsi que de calculer et afficher le poids du document. Savez-vous si ce type de solution existe ?

Sinon il ne vous reste plus qu’à le faire à la main…

Je termine une série d’articles sur la conception de formulaires avec deux sujets encore non-traités : Les formulaires pour terminaux mobiles et les formulaires narratifs.

Tout ce que vous avez besoin de savoir sur les formulaires mobiles est ici : Forms On Mobile Devices: Modern Solutions. Cet article est en fait un résumé d’une série de billets publiés par Luke Wroblewski sur son blog (Web Form Innovations on Mobile Devices et Better Mobile Form Design). J’ai eu la chance d’entendre ce fameux Luke en conférence lors du MIX et je peux vous assurer que son discours est parfaitement au point.

Dans son article il recommande ainsi d’exploiter au maximum les spécificités des interfaces des terminaux mobiles pour faciliter le travail de saisi dans les formulaires avec :

• La fonction de zoom
  
• L’adaptation du clavier virtuel en fonction du format du champ
  
• L’affichage temporaire du dernier caractère saisi dans un champ de mot de passe
• Les menus contextuels pour la saisie de valeurs numériques
• Les menus spéciaux pour la saisie de données complexes (comme la date ou la taille en pieds / pouces)
  
• L’adaptation de la mise en page en fonction de l’orientation de l’écran
• L’utilisation d’éléments d’interfaces natifs qui sont livrés avec le système d’exploitation
  
• L’utilisation des composants hardware comme le micro, le GPS ou le compas.

Cet article est une véritable perle pour qui veut se lancer dans le développement de sites web adaptés au smartphones. Vous remarquerez que je ne fais pas référence aux applications mobiles ni aux sites web mobiles mais au cas bien particulier des sites web destinés aux smartphones (iPhone, Android, Blackberry, Palm, Windows Phone…). Il y a beaucoup de paramètres à prendre en compte dans ce contexte particulier car les différences de rendus peuvent être spectaculaires (comme en témoigne la dernière capture d’écran).

Si vous connaissez un article sur les meilleures pratiques de conception de formulaires pour sites web mobiles (à destination des feature phones) je suis preneur…

Changeons de sujet maintenant pour rebondir sur un autre article de Luke W qui traite des formulaires narratifs : Mad Libs Style Form Increases Conversion 25-40%. Pour faire court, les formulaires narratifs utilisent une mise en page complètement différente des formulaires traditionnels et privilégie une approche plus narrative : “Je suis … et je recherche … pour faire … à partir de …“. À découvrir par exemple chez Effduffer.

Dans les faits, ce type de formulaires transformerait mieux que les formulaires traditionnels, les équipes de Vast ont ainsi constaté une amélioration de 25% à 40% de leur taux de transformation sur le formulaire de contact :

Des résultats surprenant pour une approche très originale. Assurément une piste à creuser…

Avec la vague du tout social, chaque site (ou presque) propose une couche sociale, donc des comptes pour les utilisateur. Il en résulte l’omniprésence des formulaires d’identification que l’on retrouve un peu partout. Oui mais voilà, l’espace se fait rare et il ne reste plus beaucoup de place pour ce type de formulaire. Qu’à cela ne tienne, il existe différentes astuces pour palier à cette contrainte.

Le site Design Reviver nous propose ainsi une très belle collection de formulaires d’identification : 100 Outstanding Login Forms. De cette collection je retiens trois tendances :

• Les sites qui affichent le formulaire directement sur la page d’accueil ;
• Les sites qui affichent un lien ouvrant un panneau flottant avec le formulaire ;
• Les sites qui affichent un lien menant vers une page spécialement prévu à cet effet.

Afficher les deux champs d’identifiant et de mot de passe sur la page d’accueil est la solution idéale, mais ça prend de la place là où vous en avez désespérément besoin. Utiliser un lien ouvrant un panneau est une très bonne solution de replie, mais cela pénalise les utilisateurs qui ont désactivé le javascript sur leur navigateur. Utiliser une page spécifique est encore mieux car cela ne pénalise personne et peut être combiné avec le formulaire de création de compte et les éléments de réassurance / incitation qui vont avec.

Des formulaires présentés, je retiens celui de Wordpress (simple et efficace) :

Le formulaire d'identification de Wordpress

Dans le même style mais avec un peu plus de… style il y a celui de Tumblr (minimaliste mais cordial) :

Le formulaire d'identification de Tumblr

Signalons aussi celui de Facebook (très faible encombrement) :

Le formulaire d'identification de Facebook

Notez au passage qu’avec des intitulés en français c’est tout de suite plus laborieux comme chez Ning :

Le formulaire d'identification de Ning

Enfin mon préféré est celui de RedBrick Health avec un mélange de compacité et de sophistication :

Le formulaire d'identification de RedBrick

Je serais bien incapable de vous sortir une règle d’or sur l’emplacement des intitulés de champs car il existe plusieures possibilités :

• Au-dessus des champs ;
• À gauche des champs aligné à gauche ;
• À gauche des champs aligné à droite ;
• Dans le champ.

Ces quatre solutions fonctionnent bien, c’est juste une question de place disponible.

Par contre je peux vous recommander les bonnes pratiques suivantes :

• Localiser le formulaire ou le lien vers le formulaire en haut à droite de la page (là où se trouvera le nom de l’utilisateur une fois identifié) ;
• Afficher un lien vers l’oubli de mot de passe ET d’identifiant ;
• Prévoir un lien vers la création de compte ;
• Proposer de retenir le mot de passe pour une durée fixe (2 semaines semble une convention) ;
• Utiliser un cadenas pour symboliser la connexion sécurisée.

Voilà, si vous en avez d’autres, n’hésitez pas.

Le pied de page st un emplacement de votre site web, c’est le dernier élément visualisé lorsque l’on parcoure la page de haut en bas et c’est aussi le filet de sauvetage pour les utilisateurs perdus qui ne savent plus où cliquer (cf. Soignez vos extrémités  - menu et pied de page et Un plan du site dans votre pied de page).

Bref, le footer est un élément essentiel de la construction de votre site à ne négliger sous aucun prétexte. Je vous propose donc de découvrir deux articles qui en parlent. Tout d’abord 10 Techniques for a Fantastic Footer où l’auteur énumère ses règles de construction pour un pied de page : Inclure un plan du site, un retour en haut de page ainsi que des liens vers les plateformes sociales. De ce point de vue là le site Sushi & Robots est un bel exemple :

Le pied de page du site Sushi & Robots

Il préconise également de le truffer de liens pour faciliter le rebond sur une page intérieure, comme sur le site RailsTrip (vous noterez au passage l’histogramme du nombre de billets publiés par jour) :

Le pied de page du site RailsTrip

Il est également précisé que l’on peut y mettre du contenu (encore une fois pour les visiteurs perdus qui n’ont pas trouvé ce qu’ils cherchaient en parcourant rapidement la page de haut en bas) comme sur WPBeginner :

Le pied de page de WPBeginner

Autre article très bine documenté : Informative And Usable Footers In Web Design. Les conseils prodigués y sont à peut près les mêmes, ils citent en prime le très bel exemple d’Apple qui fournit à la fois un fil d’Ariane et un plan du site :

Le pied de page du site d'Apple

Si vous cherchez d’autres sources d’inspiration, je vous recommanderais également cet article avec des exemples plus “exotiques” : 25 Creative Website Footers. Bon… je sais ce qu’il me reste à faire…

Les fils d’Ariane (”breadcrumbs” en anglais) sont des éléments de navigation permettant aux internautes de se repérer dans l’arborescence d’un site et de remonter facilement d’un ou plusieurs niveaux. Même s’ils ne sont pas toujours bien vus par les internautes lambda, ils ne prennent pas beaucoup de place et sont utiles pour le référencement. Inutile de vous refaire l’article, sinon il y a Breadcrumb Navigation, Breadcrumb Navigation Increasingly Useful et Breadcrumbs In Web Design: Examples And Best Practices.

Donc en théorie c’est une bonne pratique de conception, sauf que dans certains cas, notamment pour les sites avec une arborescence très profonde, les fils d’Ariane ne tiennent pas sur une seule ligne car les intitulés sont trop longs. La seule solution est alors de faire un affreux retour à la ligne. À moins que vous ne puissiez cacher les niveaux intermédiaires et ne les déplier qu’au survol de la souris. C’est ce que propose ce site : CompareNetworks jQuery’d Bread Crumb.

Fil d'Ariane animé grâce à javascript

Plusieurs configuration sont possibles en fonction de la place dont vous disposez : tout cacher, ne pas plier le premier et/ou l’avant dernier niveau… Il y a en prime une petite animation au survol de la souris pour déplier le niveau (il faut pour cela utiliser la librairie javascript jQuery, cf. Getting Started with jQuery).

Le résultat est propre, mais terriblement perturbant (surtout avec cette animation). Le mieux serait encore de réduire la taille des intitulés de navigation ou de simplifier l’arborescence (exemple dans les pieds de page du site d’Apple). Sinon il y a toujours la solution par défaut de faire un retour à la ligne…

(via Escargot)

Voilà plus de 10 ans que je conçois des sites web et plus de 10 ans que les formulaires sont une source de discussions sans fin pour savoir comment les optimiser (j’avais même publier un tutoriel en 2004). Alors que je pensais avoir trouvé LE formulaire parfait (j’hésite encore entre Remember The Milk et Ballpark), voici que l’Apple Store nous propose un formulaire d’achat qui risque bien de faire date : The Apple Store’s Checkout Form Redesign.

L’idée de génie est de proposer un formulaire où les intitulés sont directement dans les champs :

Le nouveau formulaire de l'Apple Store

Cette solution permet de gagner beaucoup de place et d’afficher toutes les étapes du processus d’achat en une seule page (grâce à un principe d’accordéon). Le principe n’est pas nouveau mais c’est la première fois que je le vois mis en application sur un formulaire entier et sur une boutique en ligne à très forte fréquentation.

Il y a d’autres exemples de ce type de mise en page, notamment chez FoodSpotting :

Le formulaire de création de compte de FoodSpotting

Une solution particulièrement efficace mais qui n’est pas forcément meilleure que d’afficher les intitulés à gauche (ou au dessus) des champs, comme ici un très bel exemple chez LaunchMind :

Le formulaire de création de compte chez LaunchMind

Bref, ça m’embête de vous dire ça, mais il n’y a toujours pas de solution “ultime”, tout reste une question de contexte, d’ambiance, de place disponible et d’intégration dans votre charte graphique. Plus d’exemples ici : Interface Design Inspiration | 30 Impressive Ways to Design Sign-Up Page/Form.

Vous connaissiez déjà les champ texte associés à un menu déroulant pour filtrer la recherche comme sur le site du Guardian :

L'interface de recherche du Guardian

Vous connaissiez déjà les intitulés-filtre de champ texte en forme de menu déroulant comme sur LinkedIn :

L'interface de recherche de LinkedIn

Vous connaissiez déjà les filtres de recherche inclus dans le champ texte comme sur Kontain :

L'interface de recherche de Kontain

Mais connaissiez-vous les champs texte intégrant un filtre déroulant ? Cette interface de recherche est ainsi disponible sur Giraffe Restaurants (une chaine de restos anglais) : Search-dropdown Hybrid Box. Soit vous saisissez directement le nom de votre ville dans le champs :

L'interface de recherche de Giraffe Restaurants

Soit vous cliquez sur la petite flèche pour faire apparaitre la liste des villes déjà sélectionnée :

La liste des ville sélectionnées pour la recherche du site Giraffe Restaurants

Un clic sur le nom d’une ville et les résultats sont affichés :

Les résultats de recherche sur le site Giraffe Restaurants

L’idée est intéressante mais la mise en œuvre est polluée par des traitements graphiques trop lourds. Dommage car cet écran est pourtant entièrement dédié à la recherche. J’ai souvenir d’autres exemples plus sobres… mais impossible de remettre la main dessus. Si votre mémoire est meilleures que la mienne, partagez vos exemples.

Dans son dernier billet, Raphaël de Robiano, consultant en ergonomie, a effectué un test utilisateur sur un site Web. Il soulève un détail intéressant en ce qui concerne les formulaires de recherche. Je cite :

Ce test a été l’occasion d’identifier un problème sur un des formulaires de recherche du site que j’aimerais partager avec vous.

Le champ de recherche était accompagné sur la droite d’un petit bouton permettant de valider les caractères introduits et de déclencher le processus de recherche. Ce bouton représentait un petit triangle pointant vers la droite.

Or certains participants au test ont pensé qu’en cliquant dans ce champ, ils obtiendraient une liste déroulante reprenant l’ensemble des produits de la compagnie. Et, en effet, il y a une certaine similarité entre le bouton déclenchant la recherche et celui des listes déroulantes classiques (la balise SELECT  pour les familiers du HTML).

D’autres participants ont bien identifié cet élément comme un formulaire de recherche, mais se sont fait la remarque qu’un bouton « search », « go » ou « ok » serait plus approprié.

Comme quoi, la présence d’un petit élément graphique, peut parfois avoir un effet significatif dans l’interprétation de l’interface d’un site.

Voulant approfondir et échanger avec vous sur le sujet, j’ai regardé ce qu’il en était des formulaires de recherche sur d’autres sites sélectionnés au hasard : Twitter, Amazon, Facebook , Linkedin, Skype , Orange et Cyberpresse.ca

Le formulaire de recherche de Twitter :

Le formulaire de recherche de Amazon :

Le formulaire de recherche de Facebook :

Le formulaire de recherche de Linkedin :

Le formulaire de recherche de Skype :

Le formulaire de recherche du site de Orange :

Le formulaire de recherche du site Cyberpresse.ca (Google ) :

Je remarque que la mention ” Rechercher ” est celle qui est le plus utilisée. Il arrive aussi qu’on l’accompagne des mots ” OK ” ou ” GO” . À mon avis,  je crois que la mention “Rechercher”inscrite directement dans le champ de recherche avec l’ajout  icône ( loupe ) à droite est un choix intéressant.

À titre d’information, je partage avec vous un un article dont je me suis rappelée après la lecture du billet de Raphaël de Robiano. L’article en question traitait les observations de Jakob Nielsen. Je cite le passage intéressant sur le sujet :

3- Le moteur doit ressembler à un moteur !

Le moteur de recherche doit être facilement repérable par l’internaute. Mieux vaut donc éviter les libellés “amusants” ou originaux pour le bouton de recherche: “chercher” ou “rechercher” convient mieux que “trouver”, “OK”, “allons-y !” ou autres… éventuellement, “OK” ou “go !” est acceptable, à condition que le mot “recherche” (ou : “rechercher dans monsite.com”) figure avant le champ de saisie, comme suit:

la recherche sur amazon.fr

De plus, il est préférable que le bouton de recherche soit facilement identifiable comme tel: un bouton standard de formulaire, même si son esthétique est moyennement appréciée des designers, présente l’avantage d’être immédiatement reconnu. Si vous choisissez d’utiliser une image, arrangez-vous pour qu’elle ait bien l’air d’un bouton: forme allongée aux extrémités arrondies, et/ou dessin ombré suggérant le relief.

|
a priori, aucun problème d’identification pour ces boutons

Qu’en pensez-vous.

Comment concevez-vous vos formulaires de recherche ? Quelles mentions avez-vous tendance à ajouter ? :  ” Rechercher ” , ” OK “, “GO” , une loupe, une flèche, ect.  ? Intégrez-vous tout simplement le mot ” Rechercher” dans le champ de recherche ? Vous arrive-t-il de choisir un autre terme que ” Rechercher ” ?

Avec l’avènement des médias sociaux et des contenus générés par les utilisateurs, certaines plateformes sociales ou portails sont devenus si denses que l’on ne sait plus trop ce qu’ils sont ou à quoi ils servent. Voilà pourquoi il y a généralement des pages “About” (ou “À propos” quand l’interface est en français).

Le problème est que ces fameuses pages “About” ne renseigne pas réellement sur le site, sa mission, son histoire et les fonctionnalités qu’il propose. Illustration avec le site Idealist :

La page d'accueil d'Idealist

En regardant la page d’accueil il est impossible de comprendre ou deviner l’activité de ce site. Par contre, la section “About” propose une page “First Time Users” tout à fait remarquable :

La page "First Time User" du site Idealist

Toutes les informations utiles sont sur cette page :

• Une explication courte de ce qu’est le site, de son fondateur, avec un accès vers l’historique ;
• Une liste des grande fonctionnalités proposées avec des liens directs vers les sous-fonctionnalités ;
• Une visite guidée en vidéo pour ceux qui veulent prendre plus de temps.

Rien à redire, c’est du grand art : les phrases sont courtes et précises, sans possibilité de mauvaise interprétation. La mise en page est très sobre avec un cadre pour renforcer l’attention. La liste à puces est bien aérée pour faciliter la lecture à l’écran.

Un exemple à suivre.