[spip-dev] des trucs qui font mal aux yeux (tm)

Dev
1

tests d'interface en 2.1 :

- j'aime pas la disparition du calcul de hauteur du textarea : la
manette ne remplace pas le fait qu'avant ça s'adaptait tout seul. Mais
les crayons font mieux que ça de toutes façons, en n'attendant pas le
chargement du textarea pour en déduire la hauteur nécessaire, et en la
faisant dépendre 1) du contenu 2) de la fenetre : on pourrait imaginer
reprogrammer ça d'une manière plus smart.

- les lettres sont bcp plus grosses à l'édition qu'en affichage (avec
la prévisu de la barre typo c'est flagrant) : du coup perte de repères
visuels

- le blanc (padding?) dans le textarea est trop large, ça semble "flotter"

- et j'aime bcp le chocolat, y compris les menus verticalisés

-- Fil

2

tests d'interface en 2.1 :

- j'aime pas la disparition du calcul de hauteur du textarea : la
manette ne remplace pas le fait qu'avant ça s'adaptait tout seul. Mais
les crayons font mieux que ça de toutes façons, en n'attendant pas le
chargement du textarea pour en déduire la hauteur nécessaire, et en la
faisant dépendre 1) du contenu 2) de la fenetre : on pourrait imaginer
reprogrammer ça d'une manière plus smart.

Pareil. C'est vraiment une fonctionnalité qu'elle était bien pratique. On peut imaginer comme Fil il dit, on peut aussi faire un poil moins haut que dans la version précédente (parce qu'on se calait vraiment très près des bords).

Sinon, je verrais bien un bouton «Plein écran» comme le plugin «Édition plein écran», mais dans la barre des raccourcis (parce que le double-clic qui provoque le plein écran, pour les petites corrections c'est relou), et qui conserverait la barre et la prévisualisation.

- les lettres sont bcp plus grosses à l'édition qu'en affichage (avec
la prévisu de la barre typo c'est flagrant) : du coup perte de repères
visuels

Perso, je dirais que c'est le contraire: c'est le texte de la prévisu qui est beaucoup trop petit.

En mode prévisu, je compte 100 caractères par ligne. Et tout de même 80 caractères en mode édition. La colonne de texte d'un livre, c'est entre 60 et 80 caractères. Au-delà, la lecture est rendue beaucoup plus difficile (l'œil se perd quand il passe d'une ligne à l'autre).

Par ailleurs, les caractères tout petits, ça n'est plus trop la mode. (Y'a des effets de mode aussi: y'a quelques années, tous les journaux en ligne affichaient leurs articles en corps 10, maintenant c'est pas moins de 12). Et pour le coup: si on n'a pas des yeux de compétition, ça peut devenir difficile.

En revanche, si on rend plus cohérent, on aura une difficulté: l'édition et la prévisualisation risquent d'être quasiment identifiques; d'où difficulté à comprendre pourquoi on ne peut rien faire dans la prévisualisation (que certains risquent de confondre avec un éditeur Wysiwyg, par ailleurs). On pourrait choisir deux polices différentes.

- le blanc (padding?) dans le textarea est trop large, ça semble "flotter"

Le but, c'est d'aérer en mettant des blancs tournants. Les blancs tournants améliorent la lisibilité du texte (si, il y a des études disponibles en ligne, mais j'ai la flemme de les retrouver).

Après, le coup de la scrollbar décollée sous Firefox, ça n'est pas un bug, mais une caractéristique: c'est comme ça que Firefox a décidé que ça devait se comporter.

3

pour le coup (et à mon sens, cela va sans dire), je n'utiliserais pas cet argument là pour cet élément précis : à savoir un 'cadre de travail' (textarea) et non un 'rendu de visualisation' (affichage de page).

perso, un
   padding:10px 5px;
sur
   .formulaire_spip textarea

améliore sensiblement.

4

je parle bien du mode édition
   ?exec=articles_edit&id_article=147
et non visualisation
   ?exec=articles&id_article=147

5

tests d'interface en 2.1 :

- j'aime pas la disparition du calcul de hauteur du textarea : la
manette ne remplace pas le fait qu'avant ça s'adaptait tout seul. Mais
les crayons font mieux que ça de toutes façons, en n'attendant pas le
chargement du textarea pour en déduire la hauteur nécessaire, et en la
faisant dépendre 1) du contenu 2) de la fenetre : on pourrait imaginer
reprogrammer ça d'une manière plus smart.

Pareil. C'est vraiment une fonctionnalité qu'elle était bien pratique. On peut imaginer comme Fil il dit, on peut aussi faire un poil moins haut que dans la version précédente (parce qu'on se calait vraiment très près des bords).

Sinon, je verrais bien un bouton «Plein écran» comme le plugin «Édition plein écran», mais dans la barre des raccourcis (parce que le double-clic qui provoque le plein écran, pour les petites corrections c'est relou), et qui conserverait la barre et la prévisualisation.

- les lettres sont bcp plus grosses à l'édition qu'en affichage (avec
la prévisu de la barre typo c'est flagrant) : du coup perte de repères
visuels

Perso, je dirais que c'est le contraire: c'est le texte de la prévisu qui est beaucoup trop petit.

Faisons un compromis : avec 1.05em sur le textarea et sur le markitup
ça semblerait pas mal, non ?

En mode prévisu, je compte 100 caractères par ligne. Et tout de même 80 caractères en mode édition. La colonne de texte d'un livre, c'est entre 60 et 80 caractères. Au-delà, la lecture est rendue beaucoup plus difficile (l'œil se perd quand il passe d'une ligne à l'autre).

Par ailleurs, les caractères tout petits, ça n'est plus trop la mode. (Y'a des effets de mode aussi: y'a quelques années, tous les journaux en ligne affichaient leurs articles en corps 10, maintenant c'est pas moins de 12). Et pour le coup: si on n'a pas des yeux de compétition, ça peut devenir difficile.

Puisque tu en reparles, moi j'ai du mal avec les listes (d'articles et
autres) qui sont repassées en arial 12px au lieu du verdana 12px (en
2.0). Le texte semble plus petit, les lettres sont beaucoup plus
collées et mes yeux d'hypermethrope fatiguent très vite à parcourir
ces listes du regard pour y trouver ce que je cherche.
J'y connais rien, bla bla etc, mais je trouve qu'un verdana 11.5px est
plus lisible pour une même hauteur de ligne.

Cédric

6

OK, j'ai fait les modifs si vous voulez tester:

- le padding des textarea est réduit à droite et à gauche: padding: 10px 5px
- le texte du textarea et de la prévisualisation est identique: 1.05em
- dans les listes, la deuxième colonne (celle de l'intitulé principal) passe dans une nouvelle classe: «verdana12», qui est du verdana à 12px.

J'ai mis 12px, parce que je ne suis pas certain que mettre un font-size à 11.5px soit recommandé. (Et on a déjà un verdana à 11px par ailleurs.)

Arnaud

7

Martin Arnaud a écrit :

OK, j'ai fait les modifs si vous voulez tester:

- le padding des textarea est réduit à droite et à gauche: padding: 10px 5px
- le texte du textarea et de la prévisualisation est identique: 1.05em
- dans les listes, la deuxième colonne (celle de l'intitulé principal) passe dans une nouvelle classe: «verdana12», qui est du verdana à 12px.

J'ai mis 12px, parce que je ne suis pas certain que mettre un font-size à 11.5px soit recommandé. (Et on a déjà un verdana à 11px par ailleurs.)

Arnaud
  

Adiou,

Incidemment j'ai rencontré pas mal de soucis d'affichage avec Verdana
récemment (notamment liés aux changements de taille de fonte et de
graisse trop brutaux et hétérogènes suivant le modèle de navigateur), et
décidé de mettre celle-ci au rencart pour les designs d'interfaces.
Je lui ai préféré "Trebuchet MS" qui, même si elle est plus typée, est
vachement plus étroite, progressive, et "classe", pour tout dire...
...peut-être l'essayer aiderait-il à obtenir des interfaces plus
"distinguées"...

@+
Philippe

8

Bonjour,

Trebuchet MS est bien, mais n'est pas sur tous les ordis qui soient... Il me semble qu'elle est plus présente sur les Macs que sur les PC...
Changer pour la Trebuchet MS serait déplacé le problème ailleurs...

Euh... Petite question subsidiaire : êtes vous sûr de ne pas avoir une police altérée?...

9

hop ! jouons :
   http://www.typetester.org/

10

Teddy Payet a écrit :

Bonjour,

Trebuchet MS est bien, mais n'est pas sur tous les ordis qui soient...
Il me semble qu'elle est plus présente sur les Macs que sur les PC...
Changer pour la Trebuchet MS serait déplacé le problème ailleurs...

Euh... Petite question subsidiaire : êtes vous sûr de ne pas avoir une
police altérée?...

Re,

Non c'est une police Micro$oft que j'ai sur deux machines de test XP et
Vista en natif système ; je n'ai pas de ma mais je pense qu'elle ne
devrait être présente sur MacOs que dès lors que MS Office y est installé.
Quoiqu'il en soit la police des css est la première reconnue comme
installée sur la machine par le brouteur et rien n'empêche d'affiner le
choix...
Arial et Helvetica ne sont pas non plus exemptes de défauts sur
certaines configurations et souvent le boulot du carrossier c'est
d'obtenir le "moins-pire dans un maximum de cas", non ?
Incidemment je passe l'essentiel de mon temps sous Debian et si je
m'arrêtais à celà "font-family:sans-serif;" me serait largement suffisant !

Philippe

11

hop ! jouons :
http://www.codestyle.org/css/font-family/sampler-CombinedResultsFull.shtml

12

OK, j'ai fait les modifs si vous voulez tester:

oui c'est mieux pour ce qui concerne la zone d'édition ; pour les
listes je n'avais pas spécialement de grief

-- Fil

13

Fri, 26 Feb 2010 16:18:18 +0100, Arnaud:

- le texte du textarea et de la prévisualisation est identique: 1.05em
- dans les listes, la deuxième colonne (celle de l'intitulé
principal) passe dans une nouvelle classe: «verdana12», qui est du
verdana à 12px.

Détail mais pas tant que ça : je pense que ça serait pertinent de
mettre un nom de classe HTML (ou plusieurs différents, suivant les
éléments) qui désigne la fonction des éléments, pas leur apparence
supposée. Sinon pour les styles perso on va vite se retrouver avec des :
.verdana12 { font-size:14px; font-family: serif; }

En gros si on a abandonné les <font face="verdana" size="12"> c'est
dommage de refaire la même avec des <span class="verdana12">...

Mes 2 pesos. :slight_smile:

14

Hi

Juste pour dire qu'en arabe et en farsi, les titres des grandes icones de l'espace prive sont a peine visibles, il faudrait peut-etre qu'elles soient en bold.

George

Martin Arnaud wrote:

15

S'lt

- j'aime pas la disparition du calcul de hauteur du textarea : la
manette ne remplace pas le fait qu'avant ça s'adaptait tout seul. Mais
les crayons font mieux que ça de toutes façons, en n'attendant pas le
chargement du textarea pour en déduire la hauteur nécessaire, et en la
faisant dépendre 1) du contenu 2) de la fenêtre : on pourrait imaginer
reprogrammer ça d'une manière plus smart.

Pareil. C'est vraiment une fonctionnalité qu'elle était bien pratique. On peut imaginer comme Fil il dit, on peut aussi faire un poil moins haut que dans la version précédente (parce qu'on se calait vraiment très près des bords).

Pour ma part je préfère cette nouvelle version, l'ancienne ne
s'adaptait pas correctement, scroll obligatoire pour aller sauver son
texte et un textarea bien trop long le plus souvent des cas.
Je préfère avoir un textarea par défaut que je puisse agrandir quand
je le souhaite. Confort des plus appréciable.
Le problème est qu'il faut savoir qu'il existe une "manette" pour
agrandir la zone de texte. Il me semble très difficille de le deviner
par sois même.

km

16

Mais Fil parlait d'un truc adapté à l'ouverture. La manette de redimensionnement on n'y touche pas, mais la zone de texte devrait s'adapter au contenu existant. Si le champ est vide, le textarea est petit, et s'il existait déjà un texte, alors on s'adapte à sa longueur (avec une hauteur maximale quand même parce que faut pas exagérer).

17

On peut remettre très facilement un calcul de ce type, uniquement sur l'id #text_area , ça ne me semble pas sorcier. Cependant, pour avoir brassé un peu les 2 situations, je préfère nettement sans modification automatique de la hauteur. Les deux situations ont leur propres avantage : avec, on montre beaucoup plus de texte d'un coup, pour rechercher une ligne à modifier, c'est plus simple. sans, l'accès au bouton enregistrer et aux champs sous le texte est bien moins casse pied.

Je préfère sans, parce que quand j'ai à modifier simplement une ligne, en général j'utilise les crayons, depuis l'espace privé, qui arrivent (ou arrivaient avant jQuery 1.4 ?) à approcher le curseur à peu près où on souhaite ses modifications, pour peu que le double clic est bien fait :slight_smile:

La solution d'arno de mettre un chti bouton "plein écran" doit certainement aussi être possible. Ça solutionnerait peut être ce dilemme !

18

Mais ce que suggère Fil permettrait de limiter les dégâts pour les deux cas:
- on met un calcul d'agrandissement, parce qu'avoir un tout petit pavé quand on travaille sur des longs textes (et qu'on a un grand écran), c'est carrément une régression par rapport à l'existant (et quand je travaille sur un texte de 10 paragraphes, mon soucis est de pouvoir l'éditer dans des conditions optimales, pas d'accéder au bouton Submit sans scroller);
- on se base non seulement sur la hauteur de l'écran (et on pourrait agrandir moins, proportionnellement, que dans les version précédentes, dans lesquelles on est dangereusement proche des bords), mais aussi sur la longueur réelle du texte. Comme ça, les ceusses qui ont des textes courts ne sont pas perturbés par un immense textarea vide.

On peut aussi décider que, dans la prise en compte de la longueur réelle du texte, on ne cherche pas à afficher exactement ce texte (dans la limite de l'écran), mais qu'on se fait un truc un peu proportionnel. Par exemple: on considère que 3 ou 4 paragraphes, en gros, ça n'est pas «beaucoup» et que le minuscule scroll pour accéder à la fin n'est pas rédhibitoire. Dans ce cas, on ne cherche pas à agrandir pour couvrir réellement ces 4 paragraphes. (La difficulté, c'est que même ce qu'on considère comme un texte court dépasse rapidement du petit formulaire standard.)

A*

19

Bonjour,

La question est intéressante au plan ergonomique pour les sites
habituées à gérer des articles volumineux.
Peut-être pas cette fois mais dans l'avenir, disposer d'un choix qui
permette d'éditer le texte d'un article par parties, sans forcément
activer l'édition de toute la saisie, apporterait une forme de solution.
La solution à celà est peut-être dans une nouvelle tag spip que le
rédacteur intégrerait lui-même à son texte, en séparant ses "parties"
{part1}du texte {part2}du texte, ce qui ferait que les reconnaissant
l'interface d'édition de texte en elle-même proposerait "éditer tout"
(affichage champs texte unique) et au regard de chaque partie "éditer le
partie n" (affichage édition de 'partN' à la partie suivante où à la fin
si elle n'existe pas)...

@+

Philippe

20

Je viens d'uploader une version plus intelligente de l'agrandissement du textarea:

- d'abord, l'agrandissement maximum est moins haut que dans la version précédente: c'est la hauteur de la fenêtre moins 200 pixels; ça limite les difficultés positionnement du textarea dans la page (dans la version précédente, il fallait être 'achtement précis pour afficher exactement l'intégralité du textarea dans l'écran);

- ensuite, ça prend en compte le texte qui se trouve déjà à l'intérieur du textarea: histoire de faire un javascript rapide, ça prend le nombre de caractères, et ça calcule la hauteur en faisant: 400 caractères donnent 100 pixels de haut.

De cette façon, quand on a un texte pas très long (genre 3 ou 4 bons paragraphes), le textarea ne s'agrandit pas. En revanche, pour les bavards dans mon genre, on retrouve le confort de la version précédente.

A*