Remplacer Fcke par un pétard mouillé

L’éditeur WYSIWYG Fcke est bien connu des internautes quand ils doivent saisir du contenu riche dans certaines applications web.

L'interface de l'éditeur Fcke

Le Wysiwyg permet de mettre en forme texte et image sans connaissance technique, et Fcke s’est imposé auprès de nombreux développeurs comme un choix fiable, gratuit (open source) et performant.
Mais le web change et les exigences des développeurs aussi. Les créateurs de Fcke planchent donc depuis deux ans sur un nouvelle mouture entièrement réécrite. Elle vient de sortir et force est de reconnaître qu’elle brille de mille feux !
Voici donc venir CKE !

L'interface de CKE

Plus « flashy » , non ?
Ces boutons ronds, ces ombres portées…très moderne. Et entièrement configurable avec ça ! Les nouveautés sont alléchantes:

• Des options permettant de tout paramétrer : quels boutons, quelle couleur, quelle taille…
• Une architecture de plugin permettant d’alléger ou d’étendre les fonctionnalités
• Des performances accrues à l’affichage et à l’enregistrement
• Une validation XTHML irréprochable
• Une accessibilité améliorée

Pour l’utilisateur final, tous ces changements sont vains.

Le comportement de l’éditeur n’a pas changé ! Mettre en page avec CKE est aussi peu intuitif qu’avec Fcke. J’ai fait immédiatement un essai de ce que j’ai vu faire des dizaines de fois par des utilisateurs : j’ai essayé de déplacer l’image à coté du titre :

J'ai déplacé l'image à l'aide de la souris e haut à gauche.

Voici le code généré :

<p>
<img align="left" height="168" hspace="10" src="http://a.cksource.com/c/1/inc/img/demo-little-red.jpg" width="120" />
</p>
<h1 id="firstHeading">
Little Red Riding Hood</h1>
<p>

Le titre h1 est dans le paragraphe p, l’accessibilité est déjà mise à mal. La validation W3C ne passera pas, en définitive, le flux des informations de la page est brisée.

Ce n’est pas ce que voulait faire l’utilisateur, il n’y connait rien en HTML. Rappelons que c’est tout de même le but du Wysiwyg.

Or, aujourd’hui tous les éditeurs Wysiwyg demandent des connaissances en HTML et en CSS pour faire des mises en forme un peu élaborées. Si j’avais voulu mettre mon image à droite, j’aurais dû changer son alignement. Un concept purement hérité des CSS.

Pire, de nombreuses options demandent carrément de rentrer des données numériques :

option d'images

Qui peut prétendre que je suis face à un éditeur qui ne demande aucune connaissance technique ? Nous sommes en 2009 et ces éditeurs sont moins intuitifs que les premiers traitements de texte informatique visuels :

Word en 1984

J’attendais bien plus de deux ans de travail par l’équipe de CKE. Je vois que l’adoption des nouveaux paradigmes Wysiwyg va se faire longuement attendre et que nos utilisateurs vont encore avoir à se battre avec des comportements erratiques ou à revoir leurs ambitions esthétiques à la baisse.

Un sujet à creuser, j’y reviendrait, avec le défrichage des tentatives pour remédier à cette immense lacune du web !

Moins de 8% des gens savent ce qu’est un navigateur

Vidéo à l’appui, micro trottoir réalisé par Google :

Un navigateur (browser), « c’est Google » ont répondu en majorité les gens. et quand on leur a demandé la différence entre Google et un navigateur, c’est le règne de la confusion la plus totale !

Une preuve de plus s’il en fallait que l’utilité importe plus que l’outil ! Les utilisateur veulent aller sur internet trouver une information, ils lancent l’application qui leur apportera cette solution. Son nom ? Peu importe. Mais il est sûr que le terme Internet Explorer est plus efficace que Mozilla Firefox. Les gens cliquent sur « Internet ». Et ils vont chez Google.

Ne leur parlez pas d’autre chose, amenez les à découvrir une manière plus efficace et plus simple  de l’utiliser, mais ne promouvez pas la supériorité technique ou la sécurité. Ils ne peuvent que vous croire sur parole, tandis que facile, ça ils peuvent le constater en quelques minutes.

Un service utile, un emploi facile, c’est la clé pour un produit numérique !

MVC, un paradigme (!) de designers pour programmeurs

Les programmeurs connaissent bien le paradigme  » Modèle Vue Contrôleur »  qui permet de séparer la présentation de l’interface d’une application en trois composant, chacun ayant un rôle particulier :

Le Modèle qui contient les données, indépendamment de toute présentation,
La Vue qui affiche les données d’après les instructions du Contrôleur,
Le Contrôleur qui va chercher les données à afficher en fonction de ce que fait l’utilisateur sur l’interface.

Wikipedia nous en donne le schéma suivant :

Modèle Vue Contrôleur

Chez les designers, notre paradigme suit une logique similaire, pour des raisons à peine différentes : en séparant forme et contenu, on facilite la maintenance des sites, et on en automatise une partie. Le contenu serait donc le Modèle et la forme la Vue. Le Contrôleur, pour un designer, sera alors le comportement de l’interface.

Par exemple, sur une page de contact, le contenu affiché dans la vue est un formulaire :

formulaire avant envoi

Si un utilisateur le rempli et l’envoie, on peut afficher un message de remerciement pour garantir que le message est bien envoyé. On change donc la Vue, en allant chercher un nouveau Modèle, que le Contrôleur aura chargé lorsque l’utilisateur aura appuyé sur le bouton « envoyer » du formulaire :

message de confirmation

Difficile de dire qui des programmeurs ou des designers ont inventé le principe . MVC est clairement attribué au créateur du langage smalltalk en 79, mais les graphistes utilisent des grilles de composition préformatées depuis l’invention de l’imprimerie.

Il y a dans le design d’interaction un dialogue constant entre ses racines graphique et son origine informatique. Je ne me lasse pas de découvrir les apports de l’un et de l’autre.

Interface adaptatives

Le projet SUPPLE de l’Université de Washington propose une application d’interface qui s’adapte à l’utilisateur selon l’usage qu’il en fait :  selon ses capacités motrices, l’agencement des composants évolue pour une présentation personnalisée.

Les déficients moteurs n’ont par exemple pas tous les mêmes difficultés selon qu’ils utilisent une souris ou un trackball (boule directionnelle) ou exclusivement le clavier. Ainsi, certains auront plus de facilité à manipuler peu de boutons pour peu de mouvements, tandis que d’autres auront plutôt besoin d’avoir une vue d’ensemble plus générale de l’ensemble des fonctions.

En analysant l’usage quotidien, le logiciel va proposer une disposition basée sur les capacités et les préférences de chacun :

C’est une innovation à rapprocher de celle qui a fait débat l’an dernier, réalisée par le MIT . Cette dernière proposait une version différente d’un site internet basée sur le nombre de clics sur certaines sections des pages, qui permettait de dresser un profil cognitif. Bien que jugée intéressante, cette approche a été critiquée car elle ôte trop de contrôle à l’utilisateur.

Nous arrivons à un stade où on commence à bien connaitre et mesurer les utilisateurs. Les interfaces dites « intelligentes » commencent à être répandues, l’exemple le plus courant étant les recommandations d’articles des sites e-commerce, ou simplement la sélection de la dernière police utilisée dans Word !

Des pistes émergent pour pousser les interfaces au paradigme suivant : les interfaces émotionnelles. Les ordinateurs vont vouloir savoir si vous êtes contents…qui sait si nous n’auront pas à résoudre des bugs de chantage affectif !

Présenter sa documentation

Je viens de découvrir un excellent site communautaire animé par un architecte de l’information : The wall of deliverables .

Bourrés d’exemples visuellement parlant, il démontre l’importance d’une présentation compréhensible par toute l’équipe de création d’un site, du développeur au designer, sans oublier le commanditaire et son équipe.

Je me souviens que dans mes débuts, je livrais de véritables essais paginés avec l’ensemble des processus, conclusions et recommandation sur un ton très sérieux. Évidemment personne ne le lisait et je devais tout ré-expliquer verbalement, et répondre à des myriades de coups de fils sur tel ou tel détail, alors que bon sang, c’était dans la documentation !

Des schémas clairs et annotés sont un bien meilleur moyen de s’assurer que le développeur va les garder sur son bureau comme référence :

Sur ce sujet le livre « Communicating Design » de Dan Brown m’a bien aidé. Il est touffu, et en anglais très technique (et pire : y a pas d’images ou presque !), mais je pioche dedans quand je suis à court d’idées :