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 :

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) :

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

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

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

Et pour finir le champ 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 ?