Depuis sont lancement en début d’année dernière, l’iPad n’a beaucoup souffert de la concurrence (il représente aujourd’hui plus de 90% du marché des touchbooks). Une position dominante bien pratique pour imposer la “touche Apple” aux interfaces et à leur fonctionnement (cf. iOS Human Interface Guidelines). Oui, mais la situation est en train de changer, car la concurrence est maintenant en ordre de marche pour inonder le marché avec des concurrents (clones ?) de l’iPad.

Qui dit “concurrence”, dit “diversité”, et donc “disparités”. Les futurs concurrents de l’iPad seront ainsi propulsés par différents systèmes d’exploitation qui vont compliquer la tâche des concepteurs d’interfaces tactiles. La raison en est toute simple : les utilisateurs ne lisent pas les instructions sur un ordinateur, ils les liront encore moins sur un touchbook.

Heureusement certains se sont portés volontaires pour essayer de rationaliser tout ça et de définir un référentiel de gestuels. Luke Wroblewski, grand gourou de l’utilisabilité, a ainsi publié l’année dernière son Touch Gesture Refence Guide où sont listés les principales interactions tactiles avec un ou deux doigts :

Dans le même ordre d’idée, Open Exhibits a également proposé une bibliothèque encore plus large d’interactions tactiles pour interfaces mulittouch (la Open Source Gesture Library) :

Vous pensiez être tiré d’affaire ? Détrompez-vous, car Apple vient déposer une série de brevets pour des interactions tactiles encore plus complexes : Complex Gestures On and Over Your Next iPad.

Les interactions décrites dans le brevet vont beaucoup plus loin, car elles prennent en compte l’intégralité des deux mains (paumes, tranches…) mais également les figures sans contact (“hover sensitive device“). Les schémas sont suffisamment explicites pour vous rendre compte du degré de sophistication…

Je suis d’un côté fortement impressionné par tant d’innovation (ces nouveaux brevets pourraient peut-être intégrer la troisième ou la quatrième génération d’iPad), mais plutôt inquiet d’un autre côté, car l’intuitivité des touchbooks risque d’en prendre un coup ! Ces nouvelles gestuelles posent également de nombreux problèmes :

• Les utilisateurs parviendront-ils à mémoriser et reproduire ces figures ?
• Comment peut-on tenir le touchbook s’il faut réaliser des figures à deux mains ?
• La détection de gestuelles à proximité de la dalle tactile ne va-t-elle pas parasiter le fonctionnement de l’appareil ?

Et le pire dans tout ça c’est que nous n’en sommes qu’au début : la prochaine console portable PSP va ainsi intégrer une surface tactile au dos de la machine, cette innovation devrait très bientôt être récupérée par d’autres constructeurs….

Les wireframes sont un sujet sans fin dans la profession. Vous pouvez leur donner différents noms (storyboard, maquette fonctionnelle, zoning…), LA grande question de savoir quel est l’outil le plus approprié revient régulièrement (un peu comme le salaire des cadres ou le prix de l’immobilier). C’est un peu notre sujet “marronnier” à nous !

Bref, tout ça pour dire que ça fait longtemps que je ne me suis pas exprimé sur le sujet. Je pense ne pas me tromper en disant que la profession semble avoir unanimement adopté l’idée de faire de prototypage rapide. Le débat porte plutôt sur le niveau de détail, à savoir : quel est le bon niveau de détail d’un prototype ? J’ai complètement abandonné l’idée d’apporter une réponse à cette question existentielle, aussi je vous conseille plutôt la lecture de ces différents articles pour vous faire une idée :

• Wireframes are dead, long live rapid prototyping
• Sketches and Wireframes and Prototypes! Oh My! Creating Your Own Magical Wizard Experience
• Design Better And Faster With Rapid Prototyping
• Ultimate Guide to Website Wireframing

Il existe ainsi différentes écoles correspondant à différentes techniques et catégorie d’outils :

• L’utilisation du papier / crayons pour faire du sketching (je recommande l’utilisation d’un masque comme celui proposé par UI Stencils ainsi que d’un bloc note qui vous aidera à tracer des traits droits comme le Dot Grid Book) ;
• L’utilisation de bibliothèque de composants avec un outil de présentation comme PowerPoint ou Keynote (j’ai récemment découvert les Wireframe Tollkits de KeynoteKungFu) ;
• L’utilisation d’outils de prototypage rapide comme Balsamiq ;
• L’utilisation de solutions beaucoup plus puissantes comme Axure RP.

Pendant 10 ans j’ai utilisé ma propre bibliothèque de composants sur PowerPoint mais je pense avoir définitivement tourné la page sur cette méthode (trop laborieux et pas forcément adapté à un processus de création collaboratif). Après plusieurs tentatives j’ai également abandonné Axure qui est un outil très puissant, mais beaucoup trop lourd (à n’utiliser que pour les équipes de plus de 10 personnes et les projets de plus d’1 an).

J’ai récemment trouvé un bon compromis avec l’utilisation conjointe du papier et d’un outil de prototypage rapide. L’idée est d’utiliser le papier/crayon directement en réunion pour poser les grandes lignes des interfaces et interagir en séance, puis de formaliser ça dans un outil de prototypage apportant un peu plus de structure et permettant de pérenniser le travail (les feuilles de papier ne sont définitivement pas assez stables).

Concernant les outils de prototypage rapide, il existe plus d’une dizaine de solutions que nous pouvons classer en deux catégories :

• Les outils en ligne comme Mockingbird ou MockFlow qui sont très légers et parfaits pour faire de la collaboration (mais du coup un peu “légers”) ;
• Des outils à installer mais qui intègre une couche de collaboration (les deux produits les plus avancés sont FlairBuilder et Balsamiq).

Là où ces deux dernières solutions font la différence, c’est dans leur capacité à gérer les templates, à savoir les différentes couches qui composent votre interface et qui ne changent pas forcément à tous les écrans. FlairBuilder propose ainsi un principe de Master Pages assez intuitif :

Balsamiq va un peu plus loin avec le principe de Symbol qui sont à la fois plus souple et plus puissant (vous pouvez vous servir des symbols pour créer des composants réutilisables ou des masters). Cerise sur le gâteau, les symbols peuvent être instanciés et  contextualisés :

Au final j’ai donc une légère préférence pour Balsamiq qui est à la fois plus simple à prendre en main, mais également plus puissant. Le produit évolue vite et propose en plus un environnement collaboratif (MyBalsamiq). La question à laquelle je ne trouve pas de réponse est la suivante : puisque les maquettes créées sont en XML (plus précisément en BBML), pourquoi ne peuvent-elles pas être récupérées dans des outils de création graphique ? Dans mes rêves les plus fous, je verrais bien Adobe racheter Balsmaiq et l’intégrer à la Creative Suite… Dans tous les cas de figure, Balsamiq est une valeur sûre.

Impossible pour moi de conclure cet article sans mentionner deux formidables blogs qui listent des exemples de wireframes : Mockups To Go et Wireframe Showcase.

La lecture à l’écran est un débat récurent dans le monde de l’utilisabilité. Je n’ai pas l’intention de relancer ce débat ni d’y apporter une contribution significative. Par contre, je rapprocherais les problématiques liées à la lisibilité des contenus web à la montée en puissance des terminaux alternatifs : Vers des sites adaptés aux netbooks ? et De la difficulté de concevoir une interface multi-terminaux.

Le problème que nous essayons de résoudre ici est celui de la lisibilité, ou plutôt de l’adaptation de l’interface au différents contextes de lecture. Il est ainsi difficilement envisageable de concevoir une interface qui convienne à la fois aux utilisateurs d’ordinateurs traditionnels (avec des écrans toujours plus grands), de smartphones, de touchbooks… Il existe pourtant une solution toute simple pour pallier à ces situations : les feuilles de style.

Les CSS sont ainsi parfaitement adaptées à gérer cette problématique. Il serait ainsi tout à fait pertinent de fournir 4 feuilles de styles différentes :

• pour la mise en page du site en mode “web” (donc avec un affichage standard) ;
• pour pouvoir imprimer la page sans tous les éléments parasites (en supprimant les menus et colonnes) ;
• pour pouvoir lire le contenu à l’écran (en proposant uniquement le texte avec une plus grosse police de caractères) ;
• pour pouvoir consulter la page sur un smartphone.

Concernant la version imprimable, il existe quantité d’écrits sur le sujet donc je ne m’attarde pas (CSS Design: Going to Print et How To Create A Simple Print CSS For Your Site). De même pour ce qui concerne la version pour smartphones, il existe des plug-ins et des outils pour faire basculer l’affichage en mode “mobile” (j’utilise par exemple l’extension WPtouch pour WordPress).

Le mode “lecture à l’écran” me semble par contre tout à fiat intéressant à étudier. Il existe déjà des initiatives intéressantes en ce sens (comme le Skimmer du NY Times) mais elles restent marginales. Au mieux, ce que nous proposent les éditeurs pour améliorer le confort de lecture à l’écran est d’augmenter la taille de la police de caractère. Personnellement, je préfère de loin cliquer sur le bouton “Imprimer” et de lire la page d’aperçu avant impression.

Il ne serait pourtant pas très compliqué de proposer un bouton pour basculer en mode “Lecture“. Cette fonction existe ainsi sur le navigateur Safari :

L’avantage des feuilles de styles est de pouvoir exploiter un code HTML unique tout en proposant des expériences de lecture adaptées au contexte. Je suis en train de travailler sur une refonte de ce blog et je vous fournirais des explications détaillées sur les multiples feuilles de styles mises en place dès que ça sera prêt.