La plateforme .NET prend en charge l’Unicode et s’occupe parfaitement des problèmes de localisation pour les dates, les monnaies, ... Beaucoup pense qu’un tel système est suffisant pour assurer un bon fonctionnement de leurs logiciels sans se poser de question. Erreur. Et l’UX alors ?
Exemple
Prenons un exemple, cela sera plus simple.
Imaginons un logiciel qui permet de classer des documents en posant des mots-clés. Supposons un logiciel de classement de photos permettant de marquer ces dernières. L’utilisateur possède une liste de mots-clés dans laquelle figurent les mots suivants : “Français” et “Élégant” (on a le droit de classer ce qu’on veut après tout !).
L’utilisateur a en effet pris le temps, lors de la création de la liste, de bien taper les mots clés en respectant les accentuées propres à notre langue. Il s’est un peu embêté d’ailleurs, car aucun clavier français à ma connaissance ne permet de taper les majuscules correspondantes aux voyelles accentuées ou au “ç” par exemple alors que, officiellement, ces lettres doivent aussi avoir leur majuscule... Mais notre utilisateur est consciencieux et connait par cœur les ALT+xxx pour obtenir les accentuées majuscules.
Maintenant, il importe de nouvelles photos et lorsqu’il clique sur chacune il dispose d’une boite de propriétés lui permettant de saisir les mots clés qui seront sauvegardés dans celles-ci.
Bien entendu, le logiciel étant bien fait, il peut aussi par drag’n drop déposer les photos sur un mot clé pour faire l’affectation (ou dans l’autre sens, déposer le mot clé sur une sélection de photos). Dans un tel cas le logiciel recopie servilement le mot clé original dans chaque photo, il n’y a donc aucun souci.
Mais voilà que notre utilisateur, rompu à l’usage du clavier, et devant effectuer de nombreuses mises à jour, préfère taper directement les mots clés dans la fenêtre des propriétés plutôt que d’utiliser les manipulations de la souris...
Il sélectionne une photo et saisit “élégant”. Pas de problème.
Il en prend une autre et tape par erreur “elegant”. Aie... le logiciel créé un nouveau mot clé et l’affecte car il ne voit pas que “élégant” et “elegant” sont identiques. J’y reviendrais.
Sa petite sœur, moins à l’aise avec le clavier, classe, elle aussi, ses photos avec le même logiciel, mais elle se moque de savoir que la touche majuscule du clavier est restée enfoncée. Du coup, elle sélectionne une photo et entre le mot clé “FRANCAIS”. Aie... un nouveau mot clé est créé et affecté à la photo.
Dans sa liste de mots clés, notre utilisateur méticuleux se retrouve à la suite de ces opérations avec les mots clés suivants : “Français”, “Élégant”, “elegant”, “FRANCAIS”. Et bien entendu les mots clés qu’il a saisi proprement ne sont affectés à presque aucune photo, sa petite sœur ayant été plus rapide dans son classement !
Une vraie salade. Il décide d’appeler le support technique du logiciel...
Le développeur de base
“Mais, cher utilisateur, notre logiciel fonctionne sous .NET qui est Unicode et gère parfaitement toutes les spécificités de toutes les langues, si vous ne savez pas taper les mots de votre propre langue proprement nous n’y pouvons rien !”
C’est en général ce que répondra un développeur (support niveau 2 au moins, en dessous on vous jette tout simplement) dans ce cas là...
Mauvaise réponse. Car très mauvaise UX. Et oui, la fameuse “expérience utilisateur”... Eviter les frustrations, rendre les choses claires et limpides, et tout ça... ça vous revient ? ...
Et l’UX alors ?
Dans un tel cas il est évident que le logiciel devrait reconnaitre “FRANCAIS” et “Français” et corriger automatiquement, voire proposer un dialogue avertissant l’utilisateur et lui demandant s’il souhaite vraiment créer un nouveau mot clé ou plutôt utiliser celui qui en semble le plus proche...
Pourquoi cela ne marche-t-il pas automatiquement ?
Tout simplement parce que la sophistication du système utilisé par le Framework .NET (et d’autres dans le même cas) ne s’encombre pas de l’usage courant, seule la pratique “officielle”, sérieuse, normalisée et orthodoxe est prise en compte, et ce n’est déjà pas si mal lorsqu’on se souvient du pénible de la situation avec des environnements anciens comme Delphi ou VB sous Win32 qui se moquaient pas mal de la localisation des chaines de caractères ou des dates.
Ainsi, “français accentué” sera traduit par la méthode String.Upper() par “FRANÇAIS ACCENTUÉ”, ce qui est parfaitement exact. Rien à redire.
Mais la plupart des logiciels ne sont pas conçus pour être manipulés par les membres de l’Académie Française disposant de toute une retraite dorée pour travailler sur une seule lettre de l’alphabet avec des sbires s’occupant de transcrire tout cela au rythme ronronnant d’une vieille institution engluée dans les rouages grippés de l’administration à la française...
Hélas, le français moyen, qui ne sait taper du texte qu’avec deux doigts et encore, en phonétique SMS, n’en a que faire de la beauté des symboles diacritiques et il se fiche royalement de nos "code page 1252" et de l'Unicode du Framework .NET.
Lui, c’est simple, ce qu’il veut c’est que la machine “comprenne” ce qu’il lui dit. Et que ce soit la machine qui s’adapte à lui et non pas l’inverse.
L’utilisateur est un idiot inculte pour nous autres geeks, c’est possible, mais d’un autre côté il a bougrement raison !
Une solution avec le Framework
Le Framework .NET n’est pas si rigide que ça... Seul le développeur est en cause, à lui d’avoir conscience des problèmes potentiels qui peuvent se poser dans certains contextes, à lui d’apprendre à se servir de ce qui est à sa disposition.
Car même si un simple “Upper()” ne règle pas la question ici, nul besoin d’inventer des bricolages plus ou moins alambiqués qui, de plus, risquent fort de ne pas marcher dans tous les cas.
Dans notre cas ce que nous souhaitons c’est simplement supprimer les symboles diacritiques dans une chaine. Ensuite il est facile de la passer en Lower() ou en Upper() et de faire des comparaisons pour rendre l’expérience utilisateur simple et agréable. Et lui donner envie de consommer encore plus de logiciels et d’en acheter plein au lieu de pirater en se donnant pour bonne conscience la raison que les produits sont mal fichus...
Voici le code d’une méthode qui fera exactement ce que nous souhaitons, elle utilise des fonctions du Framework .NET qui ne sont pas forcément utilisées tous les jours, raison de plus pour s’y intéresser, car souvent la solution est déjà dans le Framework.
public static String RemoveDiacritics(String text)
{
return string.Concat(
text.Normalize(NormalizationForm.FormD)
.Where(ch => CharUnicodeInfo.GetUnicodeCategory(ch)!=
UnicodeCategory.NonSpacingMark)
).Normalize(NormalizationForm.FormC);
}
Et voici un exemple d’utilisation :
var original = "Français accentué";
var simpleUpper = original.ToUpper();
var noDiacritics = RemoveDiacritics(original);
var upper = noDiacritics.ToUpper();
Console.WriteLine("Original: "+original);
Console.WriteLine("Simple Upper: "+simpleUpper);
Console.WriteLine("W/o diacritics: "+noDiacritics);
Console.WriteLine("Upper: " + upper);
qui donnera la sortie suivante :
Original: Français accentué
Simple Upper: FRANÇAIS ACCENTUÉ
W/o diacritics: Francais accentue
Upper: FRANCAIS ACCENTUE
Conclusion
L’UX est un domaine passionnant, mais à côté des grandes théories, des envolées lyriques et des discours philosophiques il y a la pratique. Et l’UX en pratique cela va se nicher partout, même dans un simple problème de majuscules et de symboles diacritiques...
Stay Tuned !