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.