SimpleWeb.fr

En ce moment il ne se passe pas une journée sans que j’entende parler de l’iPad. Et ça ne risque pas de s’arrêter car de nombreuses machines concurrentes sont en préparation chez Dell, HP, BlackBerry… J’ai déjà eu l’occasion de m’exprimer sur les nombreuses possibilités de ces machines (cf. Quels modèles d’interaction pour les touchbooks ?), mais aujourd’hui je m’interroge sur la pertinence de les assimiler à des ordinateurs.

En effêt, même si les touchbooks embarquent des composants électroniques et sont propulsés par des systèmes d’exploitation dérivés de l’informatique traditionnelle, le contexte d’usage de ces terminaux diverge complètement des usages que l’on peut faire avec un ordinateur. Comprenez par là que vous ne faite pas du tout la même chose assis à une chaise devant votre ordinateur (avec un grand écran, un clavier et une souris) qu’affalé dans votre canapé avec votre touchbook (et vos gros doigts).

Ainsi, Apple communique déjà sur les grands sites web proposant une version adaptée aux contraintes de son touchbook (pas de Flash, largeur d’écran limitée, manque de précision du clic…) avec les iPad ready websites. Autre exemple, YouTube qui propose une interface simplifiée à destination des terminaux nomades : YouTube Leanback offers effortless viewing.

L'interface épurée de YouTube Leanback

Si vous allez sur www.youtube.com/leanback, vous pourrez ainsi profiter d’une version épurée et en plein écran que l’on peut consommer en position détente (”Lean back” = “Allongé“) avec une manipulation au clavier :

Plus récemment nous avons également l’exemple fracassant de Flipboard, une startup qui propose une application de visualisation de vos flux d’activité Facebook / Twitter/ … dans un format beaucoup plus avantageux (de type magazine papier) : Flipboard, New “Social” iPad Magazine will be Powered by Semantic Data.

Twitter comme un magazine sur votre iPad avec Flipboard

Là encore l’idée est de proposer une expérience utilisateur plus immersive et surtout bien plus agréable à manipuler avec une interface tactile :

Dernier exemple avec Cooliris, qui proposait déjà un plug-in de visualisation des images (cf. Le web dans un écrin avec Cooliris) qui vient tout juste de sortir Discover, une application permettant de parcourir Wikipedia dans un format “magazine” : Discover by Cooliris: Wikipedia Never Looked This Good.

Wikipedia comme un magazine sur votre iPad avec Cooliris

Là encore l’idée est de proposer une expérience plus riche et surtout bien mieux mis en scène que des “simples” pages de wiki :

Notez que je ne critique pas Wikipedia (qui vient tout juste de refondre son site) ni la mise en page des articles qui remplissent parfaitement bien leur rôle informatif. Mais force est de constater que l’on peut faire ds choses étonnantes et tout à fait intéressantes en jouant uniquement sur la mise en page.

À la question “Faut-il ré-inventer le web pour les touchbooks“, je répondrais qu’il n’est pas tant question de ré-inventer le web mais plutôt de repenser les interfaces de consultation. Ainsi les sites web de Twitter et Wikipedia sont et restent optimisés pour un ordinateur, mais l’éditeur fournit un navigateur adapté au terminal afin de maximiser l’expérience utilisateur.

Je ne peux que constater l’efficacité du résultat et me réjouir de l’intérêt porté au confort et à l’expérience d’utilisation. De plus, les éditeurs tiennent peut-être là le moyen de rentabiliser leur matière première : Le site web est gratuit (financé par la publicité) et accessible avec n’importe quel terminal, mais la version adapté aux spécificités d’un smartphone ou touchbook est payante (ou financée autrement avec du contenu additionnel).

Savez-vous combien pèse la page d’accueil de Yahoo ? Cette question n’est pas anodine car cette valeur a été pendant longtemps une unité de référence pour la vitesse de chargement des pages d’un site web. En presque 10 ans passés en agence, je ne compte plus le nombre de cahiers des charges et brief où il étai stipulé que le poids des pages du futur site du client ne devait EN AUCUN CAS dépasser la limite de 30 Ko (le poids théorique de la page d’accueil de Yahoo! dans l’inconscient collectif).

Puis il a été question de 60 Ko…

Puis ça a été l’avènement de l’ADSL, les années YouTube et maintenant plus personne ne se soucie du poids des pages. Il faut dire que les foyers français sont équipés en haut-débit à plus de 95% (ADSL + câble + fibre, si mes sources sont exactes), donc plus la peine de se soucier du temps de chargement.

Oui mais voilà : Il fut un temps où la page d’accueil de Yahoo! pesait 30 Ko, mais cette époque est loin derrière nous et je constate une inflation alarmante (euphémisme) dans le poids des pages d’accueil qui dépassent fréquemment le Mo. Ce fameux “poids” correspond à l’espace disque occupé par l’ensemble des fichiers qui composent une page d’accueil (HTML, javascript, css, flash, images…).

Je me suis amusé à comparer les pages d’accueil de certaines boutiques en ligne française, et le résultat n’est pas brillant :

• Cdiscount = 2,8 Mo
• Pixmania = 1,4 Mo
• RueDuCommerce = 1,3 Mo
• Amazon = 845 Ko
• MisterGoodDeal = 840 Ko
• PriceMinister = 570 Ko

Non vous ne rêvez pas, pour avoir le privilège d’admirer la page d’accueil de Cdiscount il vous faudra télécharger près de 220 fichiers pour un total avoisinant les 3 Mo. Hallucinant ? Oui, surtout dans un marché aussi concurrentiel. PriceMinister s’en sort très bien avec une page bien plus légère que les autres dû à une utilisation très limitée des images (contrairement à Cdiscount).

Concernant les sites d’information, c’est encore pire :

• L’Express = 3,5 Mo
• Liberation = 3,4 Mo
• 20Minutes = 2,7 Mo
• LeMonde = 2,2 Mo

Même si les mega-bannières et autres publicités au format vidéo plombent la page, n’est-il pas aberrant de ne pas trouver un site d’information sous la barre des 2 Mo ? Et ce n’est pas forcément mieux de l’autre côté de l’Atlantique :

• LA Times = 2,9 Mo
• WashingtonPost = 1,8 Mo
• Newsweek = 1,8 Mo
• NY Times = 1,55 Mo

Concernant les grands portails, la moyenne est moins élevée :

• Facebook = 2 Mo
• Free = 1,8 Mo
• MSN = 1,2 Mo
• Yahoo = 890 Ko
• Bing = 125 Ko
• Google = 125 Ko

De façon surprenante, les grands portails sont plutôt raisonnables dans leur utilisation de la bande passante. Mention spéciale à Facebook qui dépasse la barre des 2 Mo avec une ribambelle de fichiers javascript. Vous noterez au passage que les deux moteurs de recherche pèsent rigoureusement la même poids (je ne sais pas trop quoi en penser…).

Bref, cette rapide étude concurrentielle nous révèle une vérité bien dérangeante : Les pages d’accueil de sites de news sont plus lourdes que certains plug-ins dont le temps de téléchargement est soit-disant rédhibitoire. Même si nos liaisons ADSL sont très performantes, les tuyaux ont des limites et le nombre de fichiers à télécharger nous éloigne toujours plus de la limite symbolique des 2 secondes pour charger une page d’accueil (le temps d’attente est directement lié à l’expérience utilisateur).

Tout ceci est très dérangeant, surtout à partir du moment où Google annonce qu’il va prendre en compte le temps de chargement des pages dans son algorithme. Oups, c’est justement ceux qui ont le plus besoin d’un bon référencement (commerce en linge, news…) qui vont se faire dégrader. Je ne peux que me réjouir de cette annonce car cette escalade dans le poids des pages d’accueil n’augure rien de bon et surtout rend les éditeurs fainéants.

Pourtant il existe de nombreuses façons d’optimiser le poids des pages en limitant le nombre d’images, en optimisant les fichiers HTML et javascript… J’imagine que l’arrivée à maturation des terminaux de consultation alternatifs (smartphones, touchbooks…) va inciter les éditeurs à se remettre en question.

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)

Après plusieurs années de surenchère graphique (coins arrondis, dégradés, reflets, typographies en image…) il semblerait que nous soyons rentré dans une phase de “retour aux fondamentaux” pour les sites web à forte audience. Illustration avec trois sites récemment rénovés qui ont opté pour une mise en page anguleuse (pour une isolation plus rigoureuse des unités d’information) et des couleurs bien tranchées (pour un meilleur contraste) : Castorama, Voyages SNCF et Crédit Agricole.

Le nouveau site de Castorama

Le nouveau site de Voyages SNCF

Le nouveau site du Crédit Agricole

Dans les trois cas, nous retrouvons les mêmes codes graphiques : boîtes carrés et recours massif aux aplats de couleur. Je ne peux que me réjouir de cette tendance à la simplification visuelle car le repérage et la lisibilité n’en sont que bien meilleurs.

Ce qui m’étonne par contre c’est pourquoi maintenant ? Pourquoi maintenant alors que la bande passante est de plus en plus large (grâce à l’ADSL et aux tarifs très compétitifs des fournisseurs d’accès), alors que nous sommes passés par le pire (”Skip intro“)… Ces choix graphiques auraient dû être adoptés il y a bien longtemps.

Le pite dans cette histoire est que nous commençons seulement à voir le bout du tunnel avec l’arrivée de navigateur qui supportent HTML5 et CSS3, donc peuvent nativement afficher les raffinements graphiques qui nous ont donné tant de mal par le passé (coins arrondis, dégradés, ombres portées, transitions, effets typographiques…). Serions-nous rentré dans une époque du design raisonné ? Peut-être. En tout cas je croise les doigts pour que cette tendance perdure et que nous ne nous perdions plus dans la surenchère visuelle.

La nouvelle est tombée la semaine dernière : Google va lancer cette année une offensive sur la télévision et proposer sa technologie de recherche et sa plateforme de widgets au travers d’une TV Box (à découvrir ici : Introducing Google TV). L’annonce est alléchante et les possibilités très nombreuses car cette TV box exploitera la système d’exploitation Android, bien connu des développeurs. Cela veut dire qu’il va être extrêmement simple de développer des applications pour les TV compatibles avec le système Google TV. Cela veut surtout dire que la tâche des concepteurs va encore se complexifier car il va falloir appréhender un nouveau support (en plus des terminaux mobiles) avec de nouvelles contraintes.

Voilà pourquoi Google a prit les devants et publier un certain nombre de recommandations pour ceux qui souhaitent se lancer dans la conception d’applications : Designing websites for Google TV. L’approche de Google est différente de celle d’Apple (qui a plus l’habitude d’imposer des guidelines très strictes) dans la mesure où ils ne publient qu’une série de bons conseils.

Recommandations générales :

• Ne pas gêner le spectateur dans le visionnage de son programme ;
• Bien prendre en compte le contexte du salon (plus de distractions) ;
• L’affichage est différent des ordinateurs (écrans plus larges et rendu des couleurs différent) ;
• Les modalités d’interaction sont différentes (pas de souris ou de clavier, pas de scroll…).

Concernant la simplicité d’usage :

• Ne conserver que le strict nécessaire à l’écran ;
• Un seul niveau de navigation (donc de hiérarchie d’information) ;
• Une navigation omniprésente et adaptée à la télécommande (quatre flèches directionnelles) ;
• Des items de navigation / action très explicites (pas d’icônes).

Concernant l’affichage et les textes :

• Exploiter le format 16/9 ;
• Respecter les zones de sûreté ;
  
• Ne pas utiliser du blanc pour le fond d’écran car cela peut provoquer des scintillements ;
• Éviter les contrastes trop prononcés ;
• Limiter la taille des paragraphes à 90 mots (et des lignes à 12 mots) ;
• Préférer du texte blanc sur fond noir que l’inverse…

Bref, il y a beaucoup de conseils très intéressants dans cette page que je vous recommande de consulter. Il y a également des recommandations sur l’utilisation du son (notamment pour les retours sonores comme dans les jeux vidéo) et de Flash (qui pourra être exploité). Après les Rich Internet Applications, les Rich Mobile Applications, nous aurons bientôt des Rich TV Applications !

Pour approfondir le sujet, je vous recommande également ces études plus anciennes :

• Designing for television ;
• Text on TV screens ;
• Designing for interactive television (PDF) ;
• Accessibility and usability for interactive television.

J’ai comme l’impression que la conquête de nouveaux supports (smartphones, TV, touchbooks…) va se faire de façon moins douloureuse que celle du web car les concepteurs et éditeurs de contenus et services ont conscience de l’importance de la simplicité et du confort d’usage. D’où ces recommandations très utiles.

(via Read/Write Web)

Il n’a pas fallu très longtemps au Dr Jakob Nielsen et son équipe pour publier une première étude sur l’utilisabiltié de l’iPad : iPad Usability: First Findings From User Testing. Chose rare : L’analyse est complète et elle est gratuite. Ce sont donc deux raisons pour vous précipitiez dessus.

Plusieurs choses sont à retenir de cette étude :

• Les utilisateurs préfèrent les applications aux sites web (même si l’application est payante ?) ;
• Malgré le très bel écran de la machine, les textes sont généralement suffisamment grands pour être lus mais trop petits pour être touchés avec précision (notamment les liens) ;
• Comme tous les éléments de l’interface sont potentiellement  interactifs, les utilisateurs ne savent pas où cliquer ;
• Les conventions d’interface utilisées avec succès sur l’iPhone ne fonctionnent plus réellement sur l’iPad car la surface d’affichage est plus grande (donc les éléments plus éloignés les uns des autres).

En règle générale, c’est la navigation qui semble avoir posée le plus de problèmes aux utilisateurs car aucune des applications testées ne se comportent de la même façon. L’exemple donné est celui d’un clic sur une photo qui peut provoqué 5 réactions différentes (rien, zoom, redirection, affichage d’autres photos, affichage d’options). Je pense que l’absence de survol de la souris empêche les utilisateurs d’anticiper l’action à venir.

Il existe également de nombreuses disparités dans la façon de scroller un texte (de haut en bas, de droite à gauche, à l’intérieur d’un cadre…) ou même de s’orienter dans un site. Illustration avec l’application d’USA Today où il faut cliquer sur le logo pour accéder aux rubriques :

L'application iPad d'USA Today

Beaucoup d’exemples dans cette étude tourne autour des applications de news (normale car elle sont les plus riches en contenus) et certaines fonctionnalités “standards” que l’on trouve sur un site web font cruellement défaut : Le bouton “Back“, la recherche et le retour à la page d’accueil en un clic. Pour plus d’infos là-dessus, je vous recommande les deux articles de Benoît Drouillat : Premiers regards sur les applications iPad de plusieurs journaux en ligne et Les premières applications iPad des médias français.

Rassurez-vous, le bilan semble bien sombre mais les utilisateurs ont tout de même montré beaucoup d’enthousiasme et d’émerveillement devant cette machine qui fascine autant qu’elle déroute. Les conclusions de l’étude convergent vers le besoin de définir des conventions d’affichage et d’interaction (l’équivalent des iPhone Human Interface Guidelines).

L’étude pointe également du doigt les usages pour lesquels l’iPad se révèle (ou se révèlera) particulièrement à l’aise : Le butinage de contenus sans but précis et les environnements immersifs.

Pour avoir testé l’iPad pendant quelques minutes, mes premières impressions ont également été très bonnes mais le système d’exploitation fait rapidement apparaitre les lacunes de la machine : Aucune possibilité de gérer plusieurs comptes utilisateurs (dommage pour une machine familiale), pas de système de fichiers (donc impossible d’éditer un document en local), pas de mode “édition” dans les Google Apps…

Les touchbooks sont assurément une révolution dans notre façon d’appréhender l’outil informatique et de consommer des contenus et services en ligne, et l’iPad en est le plus digne représentant. Pour le moment les usages et pratiques sont en train de se mettre en place (l’iPad n’est ni un ordinateur ni un smartphone) mais tout ceci est très encourageant et surtout stimulant (tant de choses à ré-inventer !).

Il en va de même pour les ebooks dont les interfaces sont encore perfectibles (cf. Kindle 2 Usability Review), et les choses ne risques pas de s’arranger avec l’ouverture du reader d’Amazon aux applications tiers…

Il y a 6 ans (6 ans !) je vous parlais de la standardisation des formulaires à l’aide d’attributs date, number, range et email : Des formulaires standardisés. À l’époque il était question de XForms pour typer les champs de saisie. Aujourd’hui l’objectif est toujours le même, sauf que cette possibilité nous est offerte par HTML 5 et que ça se passe maintenant puisque si vous utilisez un navigateur moderne vous y avez déjà accès.

Le site 456 Berae St nous propose ainsi de faire le point sur les nouveaux attributs : HTML5 input types. Pour faire simple, il vous suffit de spécifier dans votre code source le type de données que vous voulez collecter (une date, un nombre, un email…) et le navigateur se charge d’afficher un champ adapté à la valeur à saisir. Cette technique est déjà employée avec brio sur les smartphones (cf. A propos des formulaires mobiles et narratifs) et l’on commence déjà à voir des choses intéressantes sur les navigateurs de dernières génération (Opera, Safari et Chrome).

Je vous invite donc à tester ces différents types de champs dans la page suivante : HTML5 input types test page. Voici à quoi ressemble un champ search dans Safari (coins arrondis comme dans le Spotlight de Mac OS et croix pour vider le champ comme sur l’iPhone) :

Un champ de recherche avec Safari

Voici à quoi ressemble un champ number avec opera (avec les deux boutons) :

Un champ nombre avec Opera

Le champ range avec Chrome (dommage que la valeur ne s’affiche pas sous la glissière) :

Un champ range avec Chrome

Le champ email avec Opera (incluant un contrôle de surface):

Saisie d'un email avec Opera

Et pour finir le champ date avec Opera :

Saisie d'une date avec Opera

C’est ce dernier exemple qui m’intéresse particulièrement car la saisie d’une date ou d’un horaire est compliquée et qu’il y a beaucoup de différences dans les techniques employées. Standardiser le comportement des champs typés permettrait d’assurer de la cohérence au travers des différents sites et de réduire de façon considérable les erreurs de saisie.

Pour le moment il n’y a que la dernière version d’Opera qui implémente correctement les types mais nous ne devrions pas tarder à voir apparaitre ça sur les autres navigateurs. Deux types de champs pourraient grandement améliorer l’expérience utilisateur : Le champ tel pour saisir un numéro de téléphone (uniquement implémenté sur les smartphones) et le champ price pour saisir un prix (pas prévu pour le moment).

C’est un début encourageant et il reste beaucoup de travail mais nous sommes visiblement sur la bonne voix avec d’autres standardisation (notamment les pseudo-classes valid, invalid et required avec CSS3). C’est avec ce type d’améliorations que les navigateurs modernes vont pouvoir faire la différence vis à vis des vieux navigateurs qui sont plus lents, moins bien sécurisés et qui ne simplifieront pas la saisie des formulaires. Mais vous aviez déjà abandonné Internet Explorer depuis longtemps, non ?

Le site Webcredible nous propose ce mois-ci un très bon article résumant 10 comportements-types constatés lors de sessions de test : 10 unexpected online user behaviours to look out for. Ces comportements sont bien connus mais c’est toujours une bonne chose de les résumer pour ne pas les oublier dans vos travaux quotidiens de conception :

• Aveuglement dû aux bannières. Depuis plus de 10 ans que le web existe et que les utilisateurs se font matraquer les yeux de bannières qui bougent et qui flashent, ces derniers ont développés un mécanisme inconscient de protection contre ces agressions visuelles. Surnommé ”banner blindness“, ce phénomène se traduit ainsi : La partie inconsciente du cerveau des utilisateurs leur masque les éléments assimilés à de la pollution visuelle (tout ce qui bouge en haut de page) pour diminuer la charge cognitive. Conséquence : Les éléments de la page avec un traitement graphique trop lourd (animation, beaucoup de couleur dans un petit espace…) sont tout simplement ignorés, et les utilisateurs n’en ont pas forcément conscience.
• Vision tunnel.  Plus vous demandez à un utilisateur d’effectuer une tâche complexe et plus il va concentrer son attention et réduire son champ de vision. Conséquence : Les éléments en périphérie de page ne sont pas vus.
• Esquive de la page d’accueil. Après quelques années de pratique, les utilisateurs savent qu’ils ne trouveront pas ce qu’ils cherchent sur la page d’accueil car le contenu utile ou les fonctionnalités sont dans les pages intérieures. Conséquence : Ils cherchent à quitter au plus vite cette page d’accueil pour explorer les pages intérieures.
• Manque de patiente. Personne n’aime être assis devant un écran et être dans une situation d’échec. Conséquence : Si les utilisateurs de votre site ne trouvent pas rapidement ce qu’ils cherchent, ils vont avoir tendance à le chercher ailleurs sans persévérer.
• Recours excessif au défilement (ou au clic). Contrairement à ce que vous pouvez penser, cliquer ou scroller n’est pas un problème pour els utilisateurs, pire : Ils en abusent. J’ai déjà à de nombreuses reprises pu observer des utilisateurs en panique qui se mettent à faire défiler la page dans tous les sens ou à cliquer n’importe où dans l’espoir de se sortir d’une situation de détresse. Conséquence : S’ils ne trouvent pas ce qu’ils cherchent, les utilisateurs s’énervent et passent en mode “panique”.
• Survol des contenus avec déficit d’attention. En arrivant sur une page qu’ils ne connaissent pas, les utilisateurs commencent par la parcourir de façon chaotique sans réellement s’attarder sur un élément précis. Conséquence : Ils survolent la page et interprètent les bribes d’informations que leurs yeux ont réussis à accrocher.
• La force de l’habitude. Internet est encore un média jeune et intimidant pour bon nombre d’utilisateurs qui progressent à tâtons. Une fois qu’ils se sentent à l’aise dans une tâche (consulter son compte en banque, publier des photos…) ils n’apprécient pas du tout devoir recommencer. Conséquence : Les changements trop importants sur un site peuvent générer beaucoup de frustrations.

Voilà l’essentiel des comportements-types que l’on peut retrouver sur la majorité des internautes. Une fois que vous les avez en tête, il suffit de les intégrer comme des contraintes dans vos travaux de conception :

• Pas trop de trucs qui bougent à l’écran (vous ne pouvez attirer l’attention qu’une seule fois) ;
• Rapprocher visuellement ou géographiquement les éléments qui ont un rapport entre eux ;
• Evitez une trop forte densité de l’information en injectant du blanc et des zones de respiration (quitte à allonger vos pages en hauteur) ;
• Optimiser votre système de navigation (en testant différents cas d’usage de flux de navigation) ;
• Procéder petites évolutions régulières plutôt que par versions majeures (un site web n’est pas une application informatique).

Si vous avez relevé d’autres comportements-types ou avez d’autres conseils génériques, n’hésitez pas à les déposer en commentaire.

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…

Suite à la publication d’un tutoriel il y a quelques années (Des tableaux plus simples, oui je sais il y a un problème d’encodage) je me rend compte qu’il y a bien longtemps que je n’ai pas abordé le sujet des tableaux. C’est bien dommage car il ne se passe pas un jour sans que je croise un tableau de données en ligne.

Même si aujourd’hui la conception de tableaux de données ne pose plus trop de problème, la complexité de certains tableaux pousse les concepteurs à utiliser des astuces pour gagner de la place et faire rentrer dedans toujours plus de données et de fonctionnalités. Je vous propose donc de découvrir ces trois articles qui listent des cas très intéressants : Ultimate guide to table UI patterns, Ultimate guide to table UI patterns (même titre) et 15 Tips for Designing Terrific Tables. Je vous propose donc ma sélection d’exemples.

Chez BlinkCampaign nous avons une alternance des couleurs des rangées et des données affichées sur deux lignes :

Le tableau à double rangée de données de BlinkCampaign

Chez PulseApp nous avons des sections en guise de séparateurs :

Les sections du tableau de PulseApp

Chez BuildItWith.me nous avons des filtres dignes d’une application Apple :

Les options de filtre chez buildItWith.me

Chez Dropbox nous avons un menu déroulant d’actions contextuelles :

Le menu déroulant d'actions contextuelles de Dropbox

Enfin chez Mint nous avons de l’édition en ligne des lignes avec la possibilité de dérouler un panneau pour les données complémentaires :

L'édition en ligne étendue de Mint

Tout ceci est très inspiré et nous prouve qu’il est possible de construire des interfaces applicatives très performantes à partir de “simples” tableaux.