Remarques interface web d'Opale

#1

Ce post concerne les petits désagréments rencontrés sur l’interface web d’Opale, ceux qui veulent y rajouter leurs remarques sont bienvenus.

  • Le raccourci ctrl-t dans Chrominum ne permet pas de baliser un terme spécifique mais ouvre un nouvel onglet.
  • Je n’ai pas trouvé comment mettre en forme les tableaux (largeur de colonne, ligne d’entête…)
  • Les onglets des items, placés en bas, sont peu accessibles (notamment si l’item en cours est long)
  • La création des nouvelles balises (information, complément…) dans un item ne sont pas évidentes. Si j’ai bien compris, il convient de sélectionner la balise précédente pour voir apparaître un petit pictogramme +…
  • les espaces insécables précédant les ponctuations n’ont pas été implémentés.
    à suivre…
#2

Ctrl+t : c’est un loupé, ce sera corrigé. Les raccourcis ont été homogénéisés entre les chaines libres (avec Dokiel et Optim) et vérifiés par rapport à Chromium.
Pour modifier un tableau (en particulier retrouver la mise en forme) : tu peux utiliser la touche « INSERT » image pour entrer en édition dans le tableau.
Pour les espaces insécables : on regarde, probablement un petit problème de paramétrage sur Opale (ok dans Dokiel).

#3

Merci Christelle !
Cependant pour le tableau, en tout cas dans chromium, Ins permet bien de gérer le nombre de colonnes et de lignes (ajouter, supprimer) par contre je ne vois pas comment faire une ligne d’en-tête ou augmenter la taille des cellules.

Je continue avec un nouveau point qui est peut-être voulu.

  • Lorsque tu transformes une balise texte (qui possède déjà un contenu) en balise citation pluriparagraphe par exemple le contenu se trouve supprimé
#4

je ne vois pas comment faire une ligne d’en-tête ou augmenter la taille des cellules.

image

Tu as dans la barre de menus les trois popups pour les types de colonnes, lignes et cellules. Le champs de saisie juste après à droite te permet de gérer les largeurs d’une ou plusieurs colonnes.

#5

Pas sûr de bien comprendre : c’est un principe d’onglet classique. Qu’est-ce qui te gêne ? Ton écran est très petit ? Tu peux nous montrer une copie d’écran ?

#6

Oui, contrairement à l’éditeur dans le client 4.2, l’objectif est d’épurer au maximum et donc de supprimer toutes les étoiles présentes en permanence qui étaient très critiquées. Résultat : tu clique là où tu veux ajouter quelque-chose et on te propose des points d’insertion autour de cette zone.

A noter que tu dispose aussi de l’approche inverse où on te montre tout ce que tu peux insérer dans l’écran en cliquant sur le bouton vert « + » dans la barre d’outils au dessus de l’éditeur. Le système t’indique alors où là tu peux insérer chaque « élément ».

En effet, les schémas n’étant pas identiques, la transformation n’est pas triviale et définissable par simple configuration dans SCENARIbuilder, mais on peut la coder, TODO…

#7

Je pense que tu est sur MyScenari ? si oui, il y a sûrement un bug de scroll dans la version actuellement en prod qui fait que les onglets ne sont visible qu’en bas du document en cours. Ceci doit être corrigé avec la version de MyScenari qui sort… aujourd’hui !

#8

Effectivement, je suis sur myScenari et c’est un problème de scroll !
J’ai compris grâce à la remarque de Sylvain sur les tableaux, je ne voyais pas le menu car mon tableau était au milieu du grain. Idem pour le + vert (très pratique) qui résout ma remarque concernant l’ajout d’une balise type information et idem pour les onglets inaccessibles.
En un coup de cuillère à pot Sam a résolu la moitié de mes problèmes.
Merci également à Sylvain de s’être penché sur mes angoisses.

01
01.png1366×743 86 KB

#9

Je ne suis pas certain que cela vaille la peine de vous relever la nuit…

#10

Par rapport au fait d’épurer l’interface et de ne propose les options d’ajout d’éléments seulement quand un bloc est sélectionné, avez-vous envisager une solution intermédiaire (entre mettre les boutons tout le temps ou ne les mettre que quand on a cliqué) qui serait de les afficher au survol ?

#11

Ce serait en effet une option, non retenue pour le moment car le coût de calcul de ces possibilités d’insertions n’est pas négligeable, et ces calculs seraient alors massivement et fréquemment lancés.
Outre la question du ratio « utilité / coût écologique » (à la quelle je suis très attachée, même si j’en conviens, on est là sur des questions de principe), je crains que sur des machines modestes ça commence à coincer (lag). Mais je n’ai pas testé… On pourra revoir en fonction des retours utilisateurs, mais c’était un point que j’observais de près pendant l’atelier UX des rencontres, je n’ai pas vu de blocages là dessus.

#12

Il est indispensable de calculer à chaque survol ? On ne peut pas calculer une fois, puis cacher-afficher (comme on le ferait en CSS) avec le survol ?

#13

Oui, des caches sur chaque élément peut aider mais au prix d’une consommation mémoire plus importante (qui est déjà conséquente) et ces caches doivent être invalidés après chaque modification.

Une autre optimisation (et compromis) serait de n’afficher ces boutons qu’après un certain temps de présence de la souris sur un élément, comme dans le cas de l’affichage d’une « bulle d’aide » (tooltip), en général une temporisation de 0,8 secondes. Cela éviterait un écroulement de la réactivité de l’appli au déplacement de la souris après une modification.

#14

Salut à vous,
une petite question qui a sans doute été déjà posée : pourquoi les balises (information, définition…) ne sont pas proposées par ordre alphabétique ? Qu’est-ce qui a présidé au choix de leur classement ?
+

#15

Bonjour Antoine,

De mémoire, cet ordre a été établi en fonction de la fréquence d’utilisation décroissante da la balise d’intentionnalité. Mais cette fréquence est forcément très différente en fonction des contextes métiers, et des utilisateurs. Il y a donc une part d’arbitraire :slight_smile: Ca serait donc assez cohérent, vu les usages très divers d’Opale aujourd’hui, de classer ces balises par ordre alphabétique (hormis la balise « Information » logiquement la plus utilisée). A faire remonter sur la place des évolutions (évolution simple pour le coup ).

Si un jour on introduit une couche de machine learning dans les éditeurs scenari, on pourra obtenir un ordonnancement des balises nettement plus pertinent et contextualisé.

Bonne journée

Antoine

1 J'aime
#16

Hum… si c’est fait par le modélisateur, oui mais… tant qu’on reste en français ! :wink:
Si on veut le trier dynamiquement en fonction de la langue courante tout en gérant des exceptions, ça se complique il me semble…

#17

Exact ! Simple dans la langue naturelle du modèle (le français), mais nettement plus complexe pour gérer cet ordre alphabétique dans les autres langues !

#18

ça doit être prévu dans des fonctions i18n d’ internationalisation dans les bonnes bibliothèques bien codées comme il faut ?


#19

Bonjour Pascal,

En effet, mais la difficulté n’est pas de disposer d’un algo de tri selon la locale mais d’enrichir les mécaniques de Scenari builder pour indiquer explicitement dans quels cas nous souhaitons un tri alphabétique dynamique de cette liste, mais surtout quel sous-ensemble précis de cette liste nous souhaitons garder et quels éléments nous souhaitons forcer un 1ers ou en derniers.

#22

Bonjour à tous,
pour quelle raison, dans l’interface d’édition, lorsque tu cliques sur le bouton vert « + » et que tu sélectionnes par exemple « information » le contenu de l’item remonte automatiquement tout en haut au lieu de rester là où en est l’édition ?
Autre question : la suppression de l’option « fermer tous les onglets » (en bas de l’écran) est-elle motivée ?
Merci
+