Re: [EGD-discu] AFNOR compte rendu de la réunion du 21/09/2017

[ Thread Index | Date Index | More ergodis.org/discussions Archives ]


Bonsoir,

merci d’avoir assuré lors de la réunion et de nous avoir rédigé un CR, qui 
appelle une série de commentaires :

Le 22/09/17 22:54 Jean-Christophe Groult a écrit :
> […]
> La séance commence par un retour général de D.Chêne. En premiers les outils
> techniques de l’AFNOR fonctionnent plutôt mal : des mails ne sont jamais
> distribués ou seulement à certains, des pièces jointes se perdent, les
> convocations n’arrivent pas…

Ça il faudrait le signaler au Ministère ou plus haut, car il ne faudrait pas que les
infrastructures d’une association impactent la définition du clavier d’ordinateur 
officiel de la France. 

Vu que Microsoft et les autres membres de l’AFNOR ne cotisent pas assez (si l’on 
retient cette explication plutôt que de se lamenter une nouvelle fois de la mauvaise 
gestion au sein de la structure), il faut que le gouvernement mette la main à la poche,
et c’est justement le moment de doter tant que le budget 2018 n’est pas encore voté 
par l’Assemblée nationale.

> D.Chêne remet également en cause la méthodologie de la commission : les profils
> d’utilisateurs ciblés ne sont pas clairs

Justement, on pert d’utilisateurs qui ne veillent pas à bien écrire (avec EFI et tout 
ce qu’il faut) ou qui travaillent en mode brouillon en vue d’une correction ultérieure 
au sein de l’industrie graphique, donc en-dehors du champ du clavier bureautique. 

> et surtout il n’y a aucune méthode prévue pour l’évaluation de la disposition AZERTY.

Pour l’évaluation pratique ? Il était question d’un logiciel de l’université d’Aalto…

> Il signale également que les travaux du Dr Neuville, en particulier sa thèse où
> il proposait une réforme de l’azerty, n’ont pas du tout été pris en compte.

Cette thèse est-elle accessible ? Je ne connais que le résumé du rapport de mission, 
publié sous la forme de son célèbre livre sur Le Clavier bureautique et informatique.
Là il propose notamment de mettre du système dans la disposition des caractères 
informatiques, et prône la touche de composition, par exemple pour saisir les 
fractions précomposées, celles-là même que le GT veut maintenant abandonner !

> 
> Ses remarques ne concernent pas bépo car les critères retenus pour sa création
> sont clairs et satisfaisants, et une longue période d’évaluation et de retour
> d’utilisateurs a été faite. (D.Chêne utilise bépo donc il connait bien).

Super.

> 
> Le président de la commission rappelle que la qualité du résultat n’est pas
> négociable, quitte à repousser la date de publication.

Ça donne de l’espoir de voir que la position que M. Magnabosco représentait 
dans le webinaire de juillet ait de puissants soutiens au sein du GT. Visiblement, 
on ne répétera jamais assez que la bonne qualité de la norme de clavier ne doit 
devenir victime d’aucun mauvais compromis, et que la norme ne doit pas être 
bâclée. L’Afnor veillera donc à tenir ses promesses.

> Le travail du groupe de travail est donc prolongé et il n’est pas envisageable
> que la norme soit publiée avant la fin de l’année.

Pas de souci.

> Magnabosco signale la possibilité de publier en tant que norme expérimentale.
> Cela permet de publier plus rapidement, sans consultation publique, dans le but
> de permettre d’évaluer la norme « en vrai ». Par contre une norme expérimentale
> a une durée de vie de 1 à 3 ans. Après il faut publier la vraie norme.

J’essaie de comprendre pourquoi M. Magnabosco signale ça maintenant. Après tout 
ce qui a été dit et promis, ça arrive comme un cheveu dans la soupe. Rappelons 
que pour la première consultation publique, des choses étaient prévues pour 
justement « évaluier la norme ‹ en vrai › ». Le Canada est passé par la case « norme 
expérimentale » et ça n’a rien arrangé. Une fois sortie la NF-X, elle aura tendance 
à s’imposer comme l’azerty historique, en fonction de la lourdeur et du poids du 
“vrai” mis en place pour la “tester”. À mon avis ce n’est qu’une tentative de sauver 
la linéarité du processus, à laquelle l’Afnor est habituée et à laquelle elle hésite à 
déroger sous peine de se sentir déshonorée… 

Ils ont pu lire, pourtant, dans un tweet qu’une tâche mal définie nécessite un 
processus non-linéaire :

https://twitter.com/dispoclavier/status/907372029644603392
dispoclavier‏ @dispoclavier 11 sept.
@PhM_Norma @tgrouas Le #clavierfrançais est une tâche plutôt mal définie, 
donc le processus de développement a avantage à être non-linéaire.
https://twitter.com/interacting/status/906803187646164992
How Is Design Thinking Useful for Tackling Ill-Defined or Unknown Problems?
#designthinking #ux
https://www.interaction-design.org/literature/topics/design-thinking?utm_source=twitter&utm_medium=sm

Une NF-X pourquoi pas, mais pas sans enquêtes publiques préalables. Après, 
ça peut être utile au cas où l’on n’aurait pas vu quelque chose. Corriger une 
norme expérimentale paraît plus faisable que de réviser une norme de clavier 
publiée comme finale.

> 
> == DÉPOUILLEMENT ==
> Les précédentes réunions de dépouillement de juillet (qui ne concernait que les
> commentaires hors-sujet) ont réuni 80 participants.
> 
> Il reste à peu près 600 commentaires « pertinents ». Toutefois Denis Chêne
> trouve ce chiffre sous-estimé, car beaucoup de participant ont confondu le
> champs de commentaire avec celui de proposition. Il pense qu’il faut vérifier
> tous les commentaires. De plus je (=LeBret) signale que je n’ai pas reçu les
> pièces jointes mentionnés dans plusieurs commentaires. D.Chêne aussi. Il
> semble que personne n’ai reçu ces pièces jointes. Elles devraient nous être
> envoyé prochainement.

Il y en a une en tout cas qui est en ligne, ou plutôt sa version mise à jour :
http://dispoclavier.com/pourAFNOR.html

Donc vous n’avez pas reçu les pièces jointes, et les commentaires non plus
possiblement ?

> Sur les 600 commentaires évoqués par Magnabosco 53 concernent exclusivement Bépo
> Mais certains sont communs à Bépo et Azerty. Notamment quand cela concerne le
> jeu de caractères.
> 
> == AZERTY ==
> Tonalité majoritaire: rester proche de l’AZERTY original
> Il faut aussi noter qu’il y a des demandes contradictoires.
> 
> === Chiffres et verrouillage majuscules ===
> Plusieurs commentaires demandent les chiffres en accès direct. Je rappelle que
> bépo ne l’a pas fait car les chiffres sont beaucoup moins utilisés qu’on ne le
> croit même pour les développeurs. Exemple du developper Dvorak qui a mis les
> chiffre en shift.

Le bépo ne l’a pas fait à cause du tiret, si j’ai bonne mémoire des échanges ML.
Il n’y a pas LES développeurs, il y a une hétérogénéité, certains segments ont 
l’utilité des chiffres en direct. Le developer-Dvorak pour sa part n’est pas vraiment 
une référence pour la France puisqu’il est limité à deux niveaux et une bascule.
Nous on a quatre niveaux minimum, et deux bascules (sans compter NumLk et 
ScrollLk), sauf peut-être sous macOS (qui ne manquera sans doute pas d’en ajouter
une). 

Pour les symboles, l’essentiel se joue au niveau 3, et ils sont tous rapprochés 
de la rangée de repos. Perso par exemple j’ai le croisillon en direct sur [3] et en 
AltGr sur [Q], et j’ai besoin de me forcer pour le taper en haut plutôt que sur la 
rangée de repos, donc je m’en sers très peu sur [3].

> M.Nancel qui, dans les réunions précédentes, était favorable aux chiffres en
> directe, a fait des simulations et rapporte qu’effectivement les chiffres en
> direct dégradent fortement l’ergonomie et les performance.

Sur l’azerty ça relève de l’évidence à moins d’opter pour le modèle Canadien, 
qui est on le sait peu ergonomique… Sur l’azerty on a besoin du direct pour 
les lettres accentuées, donc… difficile d’y vouloir mettre les chiffres par défaut.

> 
> La méthode pour obtenir les majuscules des lettres accentuées a également donné
> pas mal de commentaire, en autres sur son incohérence avec les autres lettres.
> Cela va être revu.

Il ne faut surtout pas hésiter à multiplier les enquêtes publiques. Chacune fera 
avancer le projet.

> 
> === Signes mathématiques === (57 commentaires)
> Les commentaires demandent le regroupement des signes mathématiques
> 
> Quelques caractères sont contestés car inutiles : les fractions précomposées, la
> racine carré, le signe infini. Les 2 derniers sont conservés, mais les 3
> fractions précomposées sont abandonnées (¼ ½ ½)

Bien sûr si c’était pour les mettre sur des touches… Mais les « abandonner » 
purement et simplement, ce serait vraiment bête, excusez du peu.

Vivement la prochaine enquête publique.

> Le signe moins typographique est réclamé et sera incorporé..

On peut se demander — au moins, je me demande s’il faut finir par manifester 
dans la rue pour chaque caractère à ajouter. Cette histoire de signe moins relève 
de l’avarice ou de l’incompétence, il aurait suffi de prendre le jeu de caractères 
partiel multilingue latin conçu pour la norme de clavier internationale ISO/IEC 9995-3, 
puis de le compléter, les gens qui ont fait ça n’étaient pas bêtes ! Sur le signe moins 
on aurait eu zéro discussion.

Le contenu de la suite et fin du CR me semble plutôt encourageant.

Que l’on n’hésite jamais à se téléphoner si des fois une après-midi s’avère 
insuffisante pour traiter tous les points. Vu l’ampleur de la tâche, la bonne 
méthode semble de discuter en amont par mail et par téléphone ou visio AVANT 
de se réunir physiquement. Ou qu’est-ce qui y fait obstacle ?

Bon courage pour la suite,

Marcel

> 
> === Déplacement de qq caractères ===
> Il y a des demandes pour déplacer quelques caractères comme @ Æ Œ et aussi pour
> le regroupement/déplacemnent des caractères par paire dont <>
> 
> === Diacritiques === (47)
> Globalement les commentaires vont dans 2 sens : il y a en de trop, et leurs
> places ne sont pas bonne. Il y a aussi des demandes pour utiliser la double
> frappe des diacritiques comme dans bépo :)
> Il est également envisagé de créer une nouvelle touche morte « latin étendue »
> et de supprimer 1 ou 2 diacritiques avec peu de combinaisons. (le détail a été
> donné mais je ne me souviens pas)
> En bref cela va être revu.
> 
> === Typographie ===
> Classiquement certains s’y perdent entre les nombreux guillemets et les nombreux
> tirets. Solution: essayer de guider par la position sur le clavier et insister
> sur une gravure distinctive.
> Les lettres en exposants sont aussi demandées et donc incorporées.
> 
> == BÉPO ==
> Malheureusement il était déjà près de 17h quand on a enfin atteint ce point.
> Donc tout n’a pas était traité :( J’ai demandé la liste exacte de ces
> commentaires pour pouvoir y répondre.
> 
> Premier point, la position des touches suivante :
> — F pas assez accessible et K trop accessible. Réponse: ce n’est pas ce que
> montre les cartes d’accessibilité. D.Chêne suggère que les personnes ont
> cherché visuellement le F (sous la main), mais confirme que la position est
> accessible
> — W pas assez accessible. Le grand classique pour l’anglais. Réponse: la positon
> médiocre du W est compensé sur la très bonne accessibilité des lettres les plus
> fréquentes en anglais. Sur un texte réelle, le bépo est plus performant que
> l’azerty et même le qwerty
> — XCV pour les raccourcis claviers. Réponse: oui on a fait le choix d’une
> rupture, car où s’arrête les raccourcis claviers standards ? Z = undo, A =
> sélectionner tout… Cela pose problème surtout aux personnes qui veulent
> sélectionner à la souris (main droite) et faire le raccourci clavier à main
> gauche. Ergodis recommande d’utiliser le clavier au maximum, y compris pour la
> sélection.
> — WASD problème des joueurs. Le bépo n’est pas destiné au jeu. Le mieux est de
> changer le pilote pour un QWERTY le temps de la partie, car pour les jeux on
> tape souvent en aveugle et donc c’est plus la position de la touche que la
> lettre qui compte. 
> 
> Il y aussi les 2 points ci-dessous, mais on n’a pas pu les abordés :( on fera ça
> par mail.
> — fines insécables et espace insécable
> — ß
> 
> == la suite ==
> une réunion téléphonique dans la semaine du 31 octobre
> une réunion physique mi-novembre
> 
> Voilà. Je suis à peu près sûr d’en oublier, je complèterais si ça me revient.
> A+
> LeBret
> 
>



>




--
Pour ne plus recevoir les messages de cette liste de discussion, envoyez un courriel avec pour destinataire discussions-REQUEST@xxxxxxxxxxx et pour sujet "unsubscribe".


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/