Est-il bon de changer automatiquement la langue de saisie du clavier en JavaScript?
Dans certains sites Web et applications Web, l'utilisateur final doit remplir des formulaires. Dans des contextes multilingues, certains développeurs tentent de modifier la langue d'entrée du clavier ou de se connecter au champ qui doit être rempli dans une autre langue, de détecter les frappes de touches en anglais et de le remplacer par les caractères de la langue cible.
Est-ce une bonne pratique dans l'expérience utilisateur? A-t-on fait une étude à ce sujet?
Non, ne faites pas une telle chose automatiquement. Cela va à l'encontre de deux principes d'utilisation très importants: ne surprenez pas l'utilisateur et laissez-le se sentir en contrôle.
Taper dans une langue différente est un problème que les utilisateurs doivent résoudre dans de nombreuses situations. Par conséquent, tous ceux qui doivent taper dans une deuxième langue ont déjà choisi une solution indépendante de l'application qui fonctionne pour lui. Remplacer automatiquement cette solution par votre propre homebrew est mauvais.
Premier problème: L'utilisateur peut ne pas vouloir taper (tout) dans la langue que vous pensez qu'il devrait taper. Exemple: un utilisateur écrit dans sa langue écrite native, non latine, The French Word for book is "livre". Si vous translittérez automatiquement tous les traits de mots clés, le mot français sera également translittéré, ce qui rendra impossible de transmettre les informations comme l'utilisateur le souhaitait.
Deuxième problème: Vous ne savez pas à quelle disposition de clavier l'utilisateur est habitué. Oui, il y a généralement une disposition "standard" par pays, mais ce n'est pas toujours la plus utilisée. Surtout les jeunes utilisateurs d'ordinateurs qui ne se sont jamais assis devant une machine à écrire et ne veulent pas apprendre deux dispositions pour taper leur langue et taper des symboles latins préféreront souvent utiliser une mise en page phonétique plutôt que leur mise en page standard. Mais les dispositions phonétiques ne sont pas toujours standardisées. Surtout pour les lettres qui n'ont pas d'équivalent en anglais, il peut y avoir des combinaisons de touches au lieu d'appuyer sur une seule touche. Et certains utilisateurs ont appris au fil des années à taper leur langue en latin translittéré pour utiliser des combinaisons de touches inhabituelles pour exprimer des lettres. Considérez la lettre cyrillique щ. Je connais les variantes suivantes de l'entrer parmi les locuteurs natifs bulgares: comme sht, scht, w, 6t et ]. Un Russe entrera probablement dans d'autres combinaisons résultant des correspondances de la prononciation russe de la lettre avec sa première langue étrangère, en commençant par shch et schtsch, ainsi que d'autres qui peuvent être devenues courantes pour des raisons obscures. Et si la première langue de script cyrillique de quelqu'un est le russe, il préférera probablement entrer le bulgare en utilisant également une mise en page russe, car une mise en page bulgare sera aussi étrange pour lui que Dvorak pour un utilisateur Qwerty. Donc, choisir une mise en page standard basée sur la langue du champ de saisie est une idée terrible.
Troisième problème Si l'utilisateur a déjà une solution en place, votre solution interagira avec elle de manière imprévue. Par exemple, j'ai eu un moment où j'utilisais un plugin Firefox pour la translittération, lorsque j'ai appuyé sur F2 dans un champ, il a changé ma disposition de clavier en cyrillique personnalisé. Je ne peux pas prédire comment votre solution automatisée se comporterait dans ce cas, mais si elle l'emportait sur la solution existante, ce serait d'abord très désorientant. Si dans ma mise en page personnalisée, le ? impressions de touches _ (le mien l'a fait, car j'avais besoin d'une combinaison de cyrillique phonétique avec des caractères non alphabétiques Qwertz), et le vôtre imprime ?, Je serais très surpris au début, et je soupçonnerais probablement un bogue dans mon module de translittération au lieu d'un site Web détournant la fonctionnalité de translittération. Si je découvre ce qui se passe, je serais très ennuyé de ne pas pouvoir utiliser ma solution personnalisée. Même si l'utilisateur choisit la voie la plus habituelle pour installer une deuxième disposition de clavier sur le système d'exploitation et changer la disposition de clavier pour la fenêtre actuelle avec un raccourci clavier, vous la changerez pour lui au niveau du champ de saisie sera surprenant et désorientant, il pensera qu'il a changé alors qu'il ne l'a pas fait, et ainsi de suite.
Cela étant dit, fournir l'option de changer la mise en page manuellement est une bonne chose. Premièrement, cela évite les deux pires problèmes de la solution automatique: la surprise et la perte de contrôle. Deuxièmement, même si une solution que l'utilisateur a mise en place sera toujours aussi bonne ou supérieure à la vôtre, l'utilisateur n'a peut-être pas de solution en place pour le moment. Peut-être qu'il est assis devant l'ordinateur d'un ami. C'est peut-être sur son ordinateur de travail qu'il n'est pas autorisé à modifier les paramètres système. Peut-être qu'il essaie désespérément de faire fonctionner un ancien système Windows 2000 et ne veut pas s'occuper de détails tels que l'installation d'une disposition de clavier. Peut-être qu'il utilise le plus récent Gnome, ce qui a tendance à casser le raccourci de commutation de la disposition du clavier dans l'autre version. Quelle que soit la raison, vous pouvez le faire de la même manière que Google Translate et proposer un commutateur de disposition de clavier virtuel qui fonctionne indépendamment des dispositions déjà installées sur le système, de préférence avec un schéma de la disposition active qui peut être utilisé au moins comme référence, dans le cas idéal aussi comme clavier virtuel.
Vous pouvez suivre l'approche utilisée dans les écrans de connexion. Par exemple, lorsque vous vous connectez à Windows et que votre VERR MAJ est activé, un petit ballon attire votre attention sur ce fait lorsque vous concentrez le champ. Cela repose sur l'hypothèse que vous ne souhaitez généralement pas que votre CAPSLOCK soit activé lorsque vous saisissez votre mot de passe. De la même manière, lorsque vous vous attendez à ce qu'un champ soit entré dans une certaine langue, mais que vous détectez que le clavier est réglé sur une autre, vous pouvez simplement attirer un peu l'attention sur ce fait (sans interférer avec le remplissage du champ, bien sûr).
Photo prise à partir de: http://www.humanized.com/weblog/images/caps_lock_indication.png
D'un point de vue personnel, j'ai un jour trébuché sur un site Web du gouvernement israélien qui m'obligeait à remplir un formulaire. La plupart des champs nécessitaient des valeurs en hébreu. Leur solution a été de traduire chaque touche anglaise en une touche hébraïque corrélative (en supposant que tous les utilisateurs utilisent la mise en page régulière QWERTY). Je dois admettre que cette expérience automatique m'a ravi, même si @Rumi P a soulevé des points valables à son encontre.