FredCavazza.net

J’ai déjà posté de nombreux billets faisant l’apologie de la technologie Flash. Aujourd’hui, je vous propose deux articles tout en nuance sur le sujet où il est question de tirer parti du potentiel des interfaces Flash tout en se reposant sur les acquis du HTML :

• An Internet divided, où l’auteur nous explique que le monde (en ligne) ne doit pas se diviser pas en deux (Flash vs. HTML) mais qu’il est temps de penser autrement l’expérience des utilisateurs en ligne en proposant des interfaces hybrides ;
• On-demand apps demand a richer browser, qui nous explique que les applications en ligne avec des interfaces enrichies (RIAs) présentent un énorme potentiel pour améliorer les interactions et la productivité mais ne peuvent pas se substituer entièrement à des interfaces HTML classiques.

Enfin, un peu de consensus dans ce débat de passionnés ! De toute façon il n’existe pas de bonne ou mauvaise solution, juste des interfaces adaptées à une audience et ses besoins.

Il y a deux façons de concevoir une interface : soit vous vous placez du point de vue de l’utilisateur et vous essayez de privilégier la simplicité d’utilisation ; soit vous vous placez du point de vue du système informatique et vous passez en revue TOUS les cas de figure possibles, puis vous créez une interface qui puissent les prendre en charge.

Je vous propose à ce sujet un très bon article paru sur le site de Gerry McGovern : Do you make this obvious web design mistake? L’erreur dont il y est question concerne ces fameux cas de figures, ou plutôt l’ensemble des cas particuliers. Bien évidemment, vous vous devez de les étudier et de les envisager, sans cela votre application n’aurait pas de valeur. Là où ces cas particuliers peuvent représenter une menace, c’est quand ils viennent polluer une interface. N’avez-vous jamais été impliqué dans un projet où l’on vous imposait ici des cases à cocher, là des menus déroulant, bref un certain nombre de détails qui viennent alourdir un écran pour prendre en compte les cas particuliers ? Moi, toujours ! Et à chaque fois je m’efforce d’appliquer la même règle : ne pas compliquer un écran avec des fonctionnalités qui ne concernent qu’une minorité d’utilisateurs. C’est également le cheval de bataille d’ Alan Cooper pour qui 20% des fonctionnalités couvrent 80% des besoins des utilisateurs.

Premier exemple : pensez-vous que Google occuperait la position dominante qu’il occupe s’il avait affiché sur sa page d’accueil l’ensemble des fonctionnalités de recherche avancée ? Non, et pourtant ces fonctionnalités avancées représentent une forte valeur ajoutée… mais dans un autre écran.

Deuxième exemple : lorsque vous remplissez votre déclaration d’impôts, n’avez-vous jamais été effrayé par le nombre de cases qui couvrent les 4 pages de la feuille de déclaration ? Moi oui, surtout que je n’en utilise qu’une ou deux.

Voici ma conclusion : identifier les fonctionnalités qui présentent le plus d’intérêt puis organisez-les sur l’écran principal, regroupez ensuite les fonctionnalités secondaire et celle qui concernent les cas particuliers dans un écran secondaire. Comme cela, vous faites gagnez du temps à la majorité des utilisateurs qui ne se servent que des fonctionnalités principales sans pour autant laisser les autres utilisateurs.

Je vous parlais dans un précédent billet des méthodes de conception agiles (en l’occurence l’XP) et bien voilà, la démonstration vient d’être faite que les techniques de conception orientée utilisateur et de design d’interactions partages certains fondamentaux avec les techniqeus de conception agiles :

• une attention particulière est portée aux utilisateurs finaux et à la façon dont ils vont utiliser l’outil ;
• le cycle de développement est ponctué de boucles itératives ;
• la collaboration avec les équipes de développement est essentielle.

Tout est dit ! Si vous souhaitez en savoir plus sur le rapprochement de ces deux techniques de conception, jettez donc un oeil aux présentations proposées par le site abstractics : Interaction Design Meets Agility - Presentation.

Une fois n’est pas coutume, c’est Microsoft qui nous offre gracieusement les résultats d’une étude sur la meilleure façon de présenter les résultats de recherche : Optimizing Search by Showing Results In Context ( ficher PDF). Dans cette étude, différentes combinaisons de présentations ont été testé auprès d’utilisateurs : résultats sou forme de liste avec ou sans résumé, avec ou sans catégories… La conclusion de l’étude est que la page présentant une liste de résultats groupés selon des catégories avec un petit résumé pour chaque résultat est la plus efficace. Même si cette page est la plus longue, les utilisateurs s’y retrouvent plus facilement et se font une meilleure idée de ce qu’ils sont trouver. (via GUUUI)

C’est le site every breath death defying qui nous propose une copie d’écran d’un nouveau système de navigation qu’est en train de tester Amazon : New Amazon Top-Nav. Le principe est novateur : un onglet All categories qui ressemble à un plan du site qui se déploie lorsque que l’on passe la souris dessus. A priori ils ont eu la bonne idée de n’activer le déploiement du menu que lorsque la souris survol l’onglet au moins 1/2 seconde. Très bien pour éviter de perturber les utilisateurs. Ça ne vous rappelle pas le comportement du bouton Démarrer de Windows ?

Le site GouBlog nous propose ce matin une brève explication sur l’utilisation des boutons : Les boutons, quand les utilisés. En résumé, ça donne : les boutons et ce qui se veut être un bouton, devraient être réservé pour activer des actions dans le but d’accomplir une tâche spécifique ou un enchaînement de tâche. Voilà, tout est dit, les boutons ne devraient servir ni pour la navigation, ni pour autre chose que l’accomplissement de tâche. Si vous ne devez retenir qu’une seule chose : bouton = action.

Partons à la découverte d’un nouvel acronyme : WIMP, qui décrit un concept d’interface utilisateurs, ou plutôt les objets mis en œuvre par cette interface : des fenêtres, des icônes, des menus et une souris (Windows, Icons, Menus and Point Device). Ce type d’interface est notamment utilisé par nos ordinateurs chéris (Windows, Mac, Linux…). Le site UI Designer nous propose une évolution de ce concept en LIMP où les fenêtres sont remplacées par des listes : The Next GUI – Maybe LUI. L’auteur part du principe que nos outils modernes de communication (logiciel de messagerie, lecteurs de fils RSS et même pages web) font une utilisation de plus en plus intensive des listes, au détriment des fenêtres. Avantages : elles prennent moins de place, sont plus rapide à scanner… Inconvénients : il n’existe pas de mécanismes simple et universel pour les trier ou les filtrer. Une réflexion des plus intéressante…

Non, je ne vais pas vous parler de mon adolescence et de mes problèmes d’acné de l’époque, mais bien des boutons utilisés dans les interfaces web. Le site 456 Berea Street vous propose de voir à quoi ressemble les éléments composants les formulaires (boutons, champs…) en fonction du navigateur et de l’OS : Styling form controls. La conclusion de cet article est qu’il est impossible d’avoir une représentation graphique homogène sur l’ensemble des plate-formes. A moins d’utiliser des images, mais ça serait un peu bête, non ?

Le site TiddlyWiki vous propose d’expérimenter un nouveau système de navigation hyperlien : au lieu d’afficher une nouvelle page, chaque clic sur un lien ouvre un bloc qui s’affiche sous le bloc précédent et que l’on peut en plus éditer. Bon je sais, ma définition n’est pas terrible mais il faut le voir pour le croire. Ce système adapté à une encyclopédie en ligne par exemple peut faire un vrai malheur. Enfin, un peu d’innovation ! Comme quoi la nouvelle économie est bien de retour (il faut vraiment que j’arrête de me répéter !)

Voilà en gros le message que nous livre l’article suivant publié sur le site YourTotalSite : User preferences are for sissies. L’auteur adopte en effet un point de vue extrême puisqu’il part du principe que donner aux utilisateurs d’un site ou d’une application en ligne la possibilité de définir leurs préférences relève plus de l’incompétences du concepteur que d’un besoin réel. Son argumentation part du postulat que la somme des instructions est inversement proportionnelle à l’utilisabilité. En gros, plus il y a d’instructions à lire et moins l’interface est intuitive et facile à utiliser. Et cela est également valable pour les préférences : c’est déjà assez déroutant pour un utilisateur d’appréhender et de comprendre le fonctionnement d’une interface, alors s’il faut en plus qu’il définisse des préférences, c’est trop !

L’auteur enfonce le clou et conclu qu’implémenter un système de préférences illustre la paresse du concepteur qui reporte une partie de la charge de travail sur le dos des utilisateurs. Plutôt dur comme jugement… mais au moins ça ouvre de belles discussions. Et vous, vous en pensez quoi ?