[spip-dev] lenteur de ecrire/ et gadgets

Bon, expérience faite, ce sont bien les gadgets de l'interface qui font
ramer l'espace privé (en tous cas sur Safari) :

- le menu "tout le site" (suggestion : il pourrait n'être chargé qu'en .js
  externe, et uniquement en cas de survol)

- les onmouseout/onmouseover dans les listes (remplacer par des feuilles de
  style normales, même si ça interdit de changer de taille à la volée ?)

- les petits bidules javascript de la barre d'icônes verdatres (agenda,
  messagerie, etc). Là aussi, si c'était un .js externe...?

- la barre secondaire qui se déplie/replie. (mais c'est pas sûr). Là il faut
  peut-être jouer du <noscript> ?

Je ne dis pas que l'optimisation du biniou va être facile :slight_smile: mais elle est
nécessaire...

-- Fil

Bon, expérience faite, ce sont bien les gadgets de l'interface qui font
ramer l'espace privé (en tous cas sur Safari) :

Fil,

tu parles vraiment de "ramer" ? Je ne suis pas un grand contributeur de
contenu mais ce que j'ai vu ne m'a pas réellement choqué. On n'est tout de
même pas dans le domaine du transactionnel avec un client a bout du fil et
un écran pour saisir la commande, voir les reliquats...

Mon rédacteur ne m'a jamsi fait cette remarque. Il en est pourtant à plus
d'un millier d'articles et il bosse plusieurs heures par jour dessus.

Pour moi, même si cela fait gadget, cela permet aussi de montrer ce que peut
faire SPIP... et ça en bouche un coin à pas mal !

Peut-être vais-je dire une hérésie mais, comme on a la possibilité d'avoir
un écran large ou étroit, des couleurs pâles ou "moins" pâles, peut-être
faudrait-il une interface "j't'en fous plein la vue" et une interface
"néo-stalinienne" (j'exagère dans les 2 sens !).

JMB

Peut-être vais-je dire une hérésie mais, comme on a la possibilité d'avoir
un écran large ou étroit, des couleurs pâles ou "moins" pâles, peut-être
faudrait-il une interface "j't'en fous plein la vue" et une interface
"néo-stalinienne" (j'exagère dans les 2 sens !).

Heu... Indépendamment du débat rapide / pas rapide, faut quand même
éviter de multiplier les interfaces différentes (on a déjà complète /
simplifiée, couleurs, texte / icones / icones + texte, et maintenant
texte handicapés...). Après niveau cohérence et aussi maintenabilité,
c'est la galère.

Amicalement

Antoine.

Bon, je viens d'uploader une modif pour les survols des listes. Sous Konqueror/Linux, il me semble que c'est beaucoup plus "fluide". Sous tous les autres logiciels, je ne parviens vraiment pas à constater une quelconque différence (vu que c'est immédiat). Au passage, ça introduit parfois un petit bug d'affichage inélégant sous Konqueror. Tant pis.

Là, côté optimisation, je commence à caler.

-> Les éléments déportés dans des .js externes, ça va tourner à la galère intégrale rapidement: il faut balancer des document.write avec du PHP à l'intérieur, c'est cradingue, ça signifie qu'on charge _encore_ plus de fichiers externes dans chaque page, et on va avoir de gros problèmes de mises à jour des fichiers en cache du brouteur (certains éléments survolés changent en fonction du contexte, et la plupart évolue avec les modifications sur le site; et forcer le reload de trucs en .js, ça va tourner à la foire d'empoigne).

-> Le seul soft sur lequel je parviens à constater une accélération sensible, c'est Konqueror. Depuis les récentes optimisations, déjà, j'obtiens un comportement extrêmement plus fluide (sous Linux).

-> Par "ramer", c'est à quel point? Bicoz le fait de ne plus passer par 3 pages successives pour obtenir une information, au quotidien, perso, ça me semble justifier que l'interface donne une impression de moins bonne fluidité. Sur mon antique Mac (7500 avec un processeur G4 à un peu moins de 400Mhz, manquant cruellement de RAM, avec une carte graphique dépassée), sous Mozilla 1.3, la nouvelle interface me fait gagner énormément de temps alors que les survols sont un poil lent - tout est lent, sur ce vieux clou).

-> Sous MacOSX, qu'est-ce que ça donne avec Mozilla? Parce sous Linux, j'obtiens tout de même une impression de fluidité incomparable entre Mozilla et Konqueror.

-> Au fait, essayer de désactiver Javascript. Dans ce cas, l'interface reprend grosso merdo les principes de fonctionnement de la version 1.7, avec au passage nettement moins d'images et beaucoup plus de CSS "simples". C'est un moyen (certes un peu farfelu) pour voir si on préfère avoir un affichage plus "fluide" ou profiter des nouvelles fonctionnalités de navigation.

ARNO*

A propos, pas un problème de fluidité mais de fonctionnalité et
d'ergonomie. Les informations tronquées de façon un peu arbitraire,
c'est extrêmement pénible.

Exemple : j'ai un article signé "Antoine" et "Robert", mais la liste
n'affiche qu'"Antoine" par défaut (parce qu'avec "Robert" en plus ce
serait trop long). Résultat, si je cherche rapidement les articles de
Robert, ou que je parcours juste la liste pour connaître la liste des
auteurs, impossible de savoir que cet article est cosigné "Robert" (sauf
à passer la souris dessus ce qui est totalement tordu : si ça m'affiche
le "premier" auteur, pourquoi pas les autres ??).

a+

OK, je viens d'uploader la modif.

L'idée initiale était d'obtenir, autant que possible, des listes bien régulières (chaque «ligne» étant en gros de hauteur constante). Mais effectivement, pour l'affichage de l'information, le résultat est trompeur.

A*

-> Les éléments déportés dans des .js externes, ça va tourner à la galère
intégrale rapidement: il faut balancer des document.write avec du PHP à
l'intérieur, c'est cradingue, ça signifie qu'on charge _encore_ plus de
fichiers externes dans chaque page, et on va avoir de gros problèmes de
mises à jour des fichiers en cache du brouteur (certains éléments survolés
changent en fonction du contexte, et la plupart évolue avec les
modifications sur le site; et forcer le reload de trucs en .js, ça va
tourner à la foire d'empoigne).

Oui ; je ne dis pas que c'est facile. Mais sur spip.net le menu de
navigation "rapide" ajoute tout de même... 50 ko à chaque page de l'espace
privé. 50 ko, même compressé, même sur une liaison rapide, ça fait une
différence nettement perceptible.

-> Par "ramer", c'est à quel point? Bicoz le fait de ne plus passer par 3
pages successives pour obtenir une information

Bien sûr : mais ça, c'est ce qu'on gagne avec les sous-menus présents sous
chaque icône. Pas avec la totalité des gadgets.

-> Sous MacOSX, qu'est-ce que ça donne avec Mozilla? Parce sous Linux,
j'obtiens tout de même une impression de fluidité incomparable entre
Mozilla et Konqueror.

Avec Firefox, c'est un peu mieux qu'avec Safari. Mais c'est de toutes
façons, à chaque clic, environ 4 ou 5 secondes avant d'avoir la page. En
désactivant les gadgets on tombe à environ 2 s.

C'est un moyen (certes un peu farfelu) pour voir si on préfère avoir un
affichage plus "fluide" ou profiter des nouvelles fonctionnalités de
navigation.

C'est un peu binaire comme choix :slight_smile:

-- Fil

Pour être précis : la page www.spip.net/ecrire/ fait 99177 octets ; quand
j'en supprime tous les gadgets, elle passe à 35402 octets.

Mais faut pas déprimer : le menu déroulant et les autres gadgets, c'est chic
et pratique... il faut juste trouver comment les rendre plus légers, de
manière à retrouver une navigation fluide.

-- Fil

OK, ça c'est carrément imparable :-))

Bon, en attendant de trouver une meilleure solution, je mets ce menu en veilleuse. Il reste la page de "Navigation rapide", moins spectaculaire, mais très efficace.

A la place, je déplace (et complète) les boutons "Créer un nouvel article" (etc.) à cet endroit. D'ailleurs, en bas du menu "Navigation rapide", ils étaient un peu paumés, et potentiellement inaccessibles sur des petits écrans. Ils changent en fonction du contexte. C'est une étape pour se débarasser des pavés de "Raccourcis".

ARNO*

"ARNO*" <arno@scarabee.com> wrote in message
news:opsadqaxvzwsybly@club-internet.fr...

>privé. 50 ko, même compressé, même sur une liaison rapide, ça fait une
>différence nettement perceptible.

OK, ça c'est carrément imparable :-))

Sauf à le mettre en fichier externe qui ne change pas trop souvent (genre,
s'il doit changer on l'appelle avec une nouvelle clé pour forcer le reload -
en fait la clé serait la date de mise à jour des infos de rubriques, ça
tombe bien on la connaît). J'ai fait des essais, mais le javascript et moi
ça fait vraiment deux, et je n'ai pas réussi à mettre le menu dans des
document.write() externes - probablement à cause des guillemets qu'il y a
dans tous les sens...

Bon, en attendant de trouver une meilleure solution, je mets ce menu en
veilleuse. Il reste la page de "Navigation rapide", moins spectaculaire,
mais très efficace.

En fait cette barre est sans doute trop chargée : a-ton besoin de tous les
gadgets ? On peut repenser :
        - interface complète/simplifiée => si l'interface complète était
                simple, ce serait mieux que ce choix là.
        - écran large/étroit => avec la nouvelle interface, j'ai
                l'impression qu'on n'a plus besoin de l'écran large
        - suivre la vie du site => à mettre dans le sous-menu "Edition" ?
        - Agenda, messagerie et infos personnelles -> pour moi, c'est
          totalement inutile, et ça pourrait en tous cas être regroupé
        - Navigation rapide et "tout le site" : léger double emploi ; le
          brouteur, même s'il est sympa, est complètement inutilisé,
          d'ailleurs, comme le prouve l'absence de signalement du méchant
          bug actuel :slight_smile:

A la place, je déplace (et complète) les boutons "Créer un nouvel article"
(etc.) à cet endroit. D'ailleurs, en bas du menu "Navigation rapide", ils
étaient un peu paumés, et potentiellement inaccessibles sur des petits
écrans. Ils changent en fonction du contexte. C'est une étape pour se
débarasser des pavés de "Raccourcis".

Bof, je ne trouve pas ça terrible. Je voudrais aussi qu'on revienne en
arrière sur l'affichage des numéros d'objets partout dans l'interface :
c'est laid, et ça renforce l'aspect "informatique" de SPIP, au détriment de
l'aspect "contenu".

-- Fil

désolé de me répéter mais concernant le bloc ajout de document dans
l'édition d'un article vous voulez vraiment pas le mettre en haut de la page
en permance, de cette façon on ne serait pas obligé de scroller à rallonge
jusqu'en en bas de page pour en rajouter d'autre quand on en a déjà quelques
uns.
Il faudrait bien sûr que le dernier doc ajouté viennent alors se placer
juste en dessous de bloc ajouter du plus récent au plus ancien donc

a+

Je voudrais aussi qu'on revienne en arrière sur l'affichage des
numéros d'objets partout dans l'interface :
c'est laid, et ça renforce l'aspect "informatique" de SPIP, au
détriment de l'aspect "contenu".

Serait-il dans ce cas envisageable d'ajouter un moyen de trouver plus simplement l'id d'un autre élément depuis une zone de saisie, à la manière de ma galerie mais pour les autres éléments que les docs ?

Un autre moyen de rendre cela plus simple et intuitif serait de pouvoir donner un nom technique à tout élément pour pouvoir le réutiliser dans les liens internes.

Exemple, je créé l'article « SPIP est une merveille ! » et je lui donne comme nom technique « SpipMerveille » (qui peut éventuellement être proposé automatiquement par SPIP d'ailleurs) ce qui me permet dans un autre article d'avoir le texte suivant :

« voir aussi [cet autre article->SpipMerveille] sur SPIP »

Le problème est alors certes de gérer les doublons et modifications de noms techniques, mais mon code de référencement des liens internes est toujours disponible ... :wink:

-Nicolas

En fait cette barre est sans doute trop chargée : a-ton besoin de tous les
gadgets ?

- Si on appelle ça des "gadgets", évidemment on est plutôt partis pour les sucrer :-))
Le but est bien de penser ces éléments de telle façon qu'ils soient réellement des éléments d'information/navigation qui améliorent l'ergonomie et accélèrent la navigation interne.

L'exemple le plus évident pour moi, c'est la liste des articles en cours de rédaction dans le popup "Navigation rapide": perso ça me fait gagner un temps fou.

- Pour l'instant, il n'y a pas eu de travail réel sur le contenu des pages elles-mêmes. Or, l'idée est bien que certaines pages seront largement réorganisées. En l'état actuel, on a de nombreux doublons fonctionnels entre la barre colorée (les "gadgets") et le contenu des pages (par exemple les raccourcis). Ce qui renforce, certainement, l'impression de gadget superfétatoire.

On peut repenser :
        - interface complète/simplifiée => si l'interface complète était
                simple, ce serait mieux que ce choix là.

On est toujours confronté à cette difficulté.

A chaque nouveau progrès de l'interface, c'est-à-dire lorsqu'on trouve une nouvelle solution pour hiérarchiser visuellement les informations, on se dit qu'on est pas loin de pouvoir sucrer l'interface simplifiée. Et d'un autre côté, on n'est pas certains que ce soit réellement faisable.

        - écran large/étroit => avec la nouvelle interface, j'ai
                l'impression qu'on n'a plus besoin de l'écran large

Je considère le problème de manière exactement inverse :-))

L'idéal, au niveau du confort pour hiérarchiser et découper clairement l'information dans l'interface, c'est l'écran large. Le problème, c'est qu'on doit (veut?) conserver la compatibilité de manière simple avec l'écran étroit. Ce faisant, on a du mal à réaliser une interface large réellement "large" (et non pas simplement l'interface écran étroit élargie sur 3 colonnes).

Voir par exemple les pages où l'écran large bénéficie d'une programmation plus "manuelle": calendrier mensuel plus lisibile, agenda journalier avec affichage du jour suivant à droite, navigation dans les statistiques, brouteur sur 4 colonnes. Même de manière limitée (quasi anecdotique), on bénéficie d'un confort bien plus grand pour présenter une information structurée.

        - suivre la vie du site => à mettre dans le sous-menu "Edition" ?

Non, c'est vraiment un élément complètement différent. De plus, problème classique: comment présenter une information importante pour la vie du site, mais utilisée rarement?

        - Agenda, messagerie et infos personnelles -> pour moi, c'est
          totalement inutile, et ça pourrait en tous cas être regroupé

Non. C'est pas fini. Il faut bien trouver l'articulation entre ces éléments pour qu'ils soient accessibles de manière cohérente. Déjà, si tu utilises ces fonctionnalités, les informations présentées deviennent plus nettement différenciées.

Bof, je ne trouve pas ça terrible. Je voudrais aussi qu'on revienne en
arrière sur l'affichage des numéros d'objets partout dans l'interface :
c'est laid, et ça renforce l'aspect "informatique" de SPIP, au détriment de
l'aspect "contenu".

En attendant mieux, AHMA. Dans l'utilisation de SPIP pour publier des articles très nettement séparés, avec peu de liens internes, le besoin d'accéder vite et facilement aux numéros des articles est très limité. Mais dans la réalisation d'un site beaucoup plus wébique, avec de nombreux liens internes, la présence des numéros d'articles uniquement dans les articles eux-mêmes est très pénalisant (même en ouvrant une fenêtre supplémentaire pour avoir sous la main accès aux articles, parce qu'il faut bien ouvrir chaque article pour connaître son numéro).

Dès que j'ai le temps, je vais faire des essais pour pouvoir récupérer les numéros des articles selon une autre méthode, moins envahissante.

ARNO*