> dans cet esprit l'admin restreint a déjà un accès
> facilité aux rubriques qu'on lui a attribué, il manque un système
identique
> pour un rédacteur attaché aussi à certaines rubriques.il suffit de débrider la saisie des rubriques associées pour un profil
auteur la table étant déjà la, je l'avais fait simplement en 1.7 à l'époque,
ensuite une boite qui liste ces rubriques et le tour est joué.
Le plugin Autorité permet ça.
-- Fil
Bonjour à tous,
j'y vais de ma petite idée, en passant ...
Pourquoi ne pas permettre au webmestre, pour la partie privée, de décider s'il conserve la "nouvelle" interface ou s'il veut rester dans l'interface "classique" ? Et ce, au moins, jusqu'à ce que la "nouvelle" soit finalisée et satisfasse tout le monde ?
Si je suis très partisan que l'on essaie de toujours progresser, je trouve aussi que cette "nouvelle" interface de l'espace privé est beaucoup moins claire que celle à laquelle nous étions habitués, très très fouillis, avec des appellations "très (trop ?) microsoftiennes" et non intuitives (par ex. qu'est ce que les "propriétés" d'une rubriques ?).
Par ailleurs, je voudrais signaler que l'affichage de la partie privée de la demo en ligne de spip est totalement foireuse, le css n'étant que partiellement interprété (Safari 3.0.3 Mac), ce qui est curieux, car celle que j'ai téléchargée s'affiche bien, elle, en local(rev. 10080).
La page s'affiche normalement sous Firefox Mac, ainsi que sous IE 6 Win ...
A+
* Moulliac tapuscrivait, le 23/08/2007 13:17:
Bonjour à tous,
j'y vais de ma petite idée, en passant ...
Pourquoi ne pas permettre au webmestre, pour la partie privée, de décider s'il conserve la "nouvelle" interface ou s'il veut rester dans l'interface "classique" ? Et ce, au moins, jusqu'à ce que la "nouvelle" soit finalisée et satisfasse tout le monde ?
Déjà fait : http://trac.rezo.net/trac/spip/changeset/10086
RealET a écrit :
* Moulliac tapuscrivait, le 23/08/2007 13:17:
Bonjour à tous,
j'y vais de ma petite idée, en passant ...
Pourquoi ne pas permettre au webmestre, pour la partie privée, de décider s'il conserve la "nouvelle" interface ou s'il veut rester dans l'interface "classique" ? Et ce, au moins, jusqu'à ce que la "nouvelle" soit finalisée et satisfasse tout le monde ?
Déjà fait : http://trac.rezo.net/trac/spip/changeset/10086
avec un petit onglet "tout" ce serait parfait
Stanislas a écrit :
perso pour le côté éditorial (... ils se demandent s'ils doivent écrire dans le champ « chapo », « texte » ou « ps »...) j'ai détourné le descriptif de la rubrique où je rappelle comment doit être rempli les articles de la rubrique... çà c'est pour les utilisateurs qui interviennent peu souvent sur le site.... ou si on détourne une zone (sur-titre par exemple)...
Stanislas
Ca me donne une petite idée. Est-ce qu'un champ supplémentaire "Règles Editoriales" sur les rubriques ne serait pas pertinent ? modifiables uniquement par les administrateurs ou admins restraints de la rubrique. Ce champs, lorsque l'on rédige un article serait visible dans un coin de la page. Si il est vide, on affiche celui de la rubrique parente.
Ah oui, je sais, vous allez me dire qu'on peut faire ça sous forme de plugin et que je n'ai qu'à le coder moi-même et vous aurez raison.
Bon, si j'oublie pas d'ici là, je ferais une proposition dans 3 mois après la thèse.
Joseph
aaah , ça va défourailler !
non je rigole !
Hé bien moi je trouve ça pas mal du tout.
Sur la discussion ergonomique (thread "utilisation des onglets"):
Faut quand même rappeler une évidence de base qui est tellement triviale qu'elle en devient inaperçue !
un écran est dans un format rectangulaire, orienté "paysage" (le plus grand côté à l'horizontal)
D'autant plus rectangulaire que les barres d'outils diverses et les "footer" (barre de tâches par exemple) de l'OS et du butineur renforce cet aspect.
Or je trouve que l'on sous-utilise l'utilisation de cet horizontalité ...
pour deux raisons me semble-t-il:
- on reste marqué par les formats canoniques du papier (belle utilisation de la racine carrée de 2) tels qu'ils ont été manipulés dans l'imprimerie (ou le papier pour la lettre manuscrite, ou les cahiers scolaires), à la verticale;
- on reste un peu coincé par la problématique des différentes résolutions possibles d'un écran, et de la solution générale qui prévaut assez mécaniquement sur le Web, à savoir favoriser l'usage d'un seul ascenseur pour éviter l'utilisation de 2 ascenseurs. Et donc, on fixe la largeur dans la dimension standard statistiquement la plus utilisée, pour éviter dans la plupart des cas l'utilisation de l'ascenseur H, et on privilégie le déroulement vertical.
Mais tout ça ne va pas de soi.
la présentation d'une structure de données me semble devoir être utilement abordée dans son double déploiement H et V.
Et donc l'arrivée des onglets me paraît à tout le moins être un bon sujet de débats et d'évolutions ...
a+
RB
Les utlisateurs de SPIP que je connais se savent pas se servir de la molette de leur mulot ; ne comprennent pas la différence entre « ajouter une image » et « ajouter un document » et s'abstiennent donc ; ne savent pas déplier, ni au survol, ni au clic ; ne comprennent pas comment changer la date d'un article ; se demandent s'ils doivent écrire dans le champ « chapo », « texte » ou « ps » ; me demandent ce que veut dire « racine » et quelle est la différence entre « rubrique » et « article » (alors je vous parle pas des brèves, des sites, ni des mots-clefs) ; ne trouvent pas le bouton « modifier cet article » et ne remarquent pas qu'ils y en a plusieurs, différents, parce qu'ils sont semés deci delà ; sont complètement perdus dans la signalétique des statuts (« il est en ligne, là, mon texte, ou pas ?!? ») ; se demandent ce que « logo » veut dire et sont encore plus intrigués par le « logo pour survol » ; n'ont jamais vu qu'il y avait un champ de recherche dans l'espace privé ; ne savent pas changer le nom de leur site (parce qu'il ne pensent pas que l'icone « configuration » est cliquable) ; etc.
Notez bien que ces utilisateurs-là ne sont pas que des abrutis de clients, mais aussi des amis et amies, militants, artistes, écrivants qui ont des choses à dire, et même geek, c'est dire.
Je confirme
Et ce n'est pas une critique de spip, mais le résultat d'une démocratisation accélérée d'un outil (de plusieurs outils: ordinateur > Web > CMS > Spip) sans que les compétences suivent. Et je ne vous parle pas de la myriade de formation (professionnelle ou non) à la bureautique qui, même payées à prix d'or par une DRH qui souhaiterait mettre à niveau son personnel, sont généralement une pure catastrophe pédagogique !
a+
RB
Je viens de découvrir la nouvelle interface des rubriques et des
articles. C'est proprement catastrophique.
Ben mince alors, moi qui suis la svn au jour le jour, j'avais visiblement un problème de config qui s'était gelée et me polluait mon CSS, parce que je ne voyais pas du tout de quoi vous parliez tous autant que vous êtes. Il a fallu que j'aille avec phpMyAdmin me faire un reset de mon champ prefs pour enfin les voir ces onglets!!
Donc à part l'ergonomie à discuter, sachez qu'il existe un cas (le mien, non reproductible peut-être) où la mise à jour par SVN a foiré la config. J'ai passé un bout de temps à me recopier les configs de mes utilisateurs pour voir ce qu'ils voient et traquer la petite bête.
Ceci mis à part, je ne trouve pas ça trop moche, et mes utilisateurs qui étaient tous unanimement effrayés par l'énormité de la quantité d'information à ingurgiter ("mais OÙÙÙ tu les vois ces mots-clefs ??? J't'assure qu'ils n'y sont pas chez moi!"), qui ne sont pas des abrutis technophobes, étaient vraiment benaise de l'apparition des crayons. Mais du coup plus personne n'attache de documents ni ne crée de nouveaux articles/rubriques :-/ Cette nouvelle présentation va peut-être en raccrocher quelques-uns...
Moi je trouve l'idée d'avoir plusieurs jeux de CSS très bonne, comme ça, on met ça dans la config et qui veut les onglets les prend, qui veut jouer de la molette fait défiler...
Cordialement, Ch. M.
sachez qu'il existe un cas (le
mien, non reproductible peut-être) où la mise à jour par SVN a foiré la
config. J'ai passé un bout de temps à me recopier les configs de mes
utilisateurs pour voir ce qu'ils voient et traquer la petite bête.
Tu n'es pas le seul, ça m'a aussi vautré un site (oui, un seulement, parce que les autres, je ne prends pas le risque de les faire tourner sous svn).
Moi je trouve l'idée d'avoir plusieurs jeux de CSS très bonne,
Certes. Et qui les code et les maintien les multiples jeux de CSS ?
Déjà que pondre une feuille de style pour la dist c'est la mer à boire 
Tu n'es pas le seul, ça m'a aussi vautré un site (oui, un seulement, parce que les autres, je ne prends pas le risque de les faire tourner sous svn).
Oui, je vis dangereusement, svn sur un gros site en production me vaut de fréquentes sueurs froides...
Moi je trouve l'idée d'avoir plusieurs jeux de CSS très bonne,
Certes. Et qui les code et les maintien les multiples jeux de CSS ?
Déjà que pondre une feuille de style pour la dist c'est la mer à boire
Ben je parlais de l'ancienne et de la nouvelle en tout cas, et puis faire un peu comme les plug-ins quoi, des squelettes faciles à installer, pas trop hétérodoxes, sans trop de php brutal en tout cas, et parmi lesquels il soit facile de choisir. On voit bien avec le fil sur l'herbier que c'est un besoin.
Christian
RealET a écrit :
Pourquoi ne pas permettre au webmestre, pour la partie privée, de décider s'il conserve la "nouvelle" interface ou s'il veut rester dans l'interface "classique" ? Et ce, au moins, jusqu'à ce que la "nouvelle" soit finalisée et satisfasse tout le monde ?
Déjà fait : http://trac.rezo.net/trac/spip/changeset/10086
Bon, j'avais bien vu le commit 10086 mais mon ignorance est telle que après avoir passé une demi-heure hier et un peu de temps aussi aujourd'hui à éplucher la page configuration, maintenance ou autre... Je n'ai pas vu comment switcher de l'un à l'autre.
Si quelqu'un pouvait me l'expliquer en clair ça serait sympa.
Par ailleurs sur le fond, perso j'aime bien les onglets, dans l'ensemble c'est mieux rangé. Mais quand on voit que certains utilsateurs ne savent même pas faire des sauts de paragraphe ni ajouter un document... OK pour eux ça ne changera rien. 
mais il ya tous ceux qui cherchent...
Donc l'option de pouvoir switcher en fonction de la maturité des rédacteurs m'intéresse.
Jacques
jack a écrit :
RealET a écrit :
Pourquoi ne pas permettre au webmestre, pour la partie privée, de décider s'il conserve la "nouvelle" interface ou s'il veut rester dans l'interface "classique" ? Et ce, au moins, jusqu'à ce que la "nouvelle" soit finalisée et satisfasse tout le monde ?
Déjà fait : http://trac.rezo.net/trac/spip/changeset/10086
Bon, j'avais bien vu le commit 10086 mais mon ignorance est telle que après avoir passé une demi-heure hier et un peu de temps aussi aujourd'hui à éplucher la page configuration, maintenance ou autre... Je n'ai pas vu comment switcher de l'un à l'autre.
Si quelqu'un pouvait me l'expliquer en clair ça serait sympa.
Configuration > fonctions avancées > tout en bas (faut scroller ...) : choix de l'interface
Mais attention il faut etre en 10089 car il manquait un fichier dans 10086
Bonjour
Je débarque un peu, je viens lancer enfin un svn update.
Et ben, c'est pas si choquant que ça, enfin rien de traumatisant.
Ça bouge et tant mieux, il faut sûrement lisser des effets de bord.
Juste une remarque, qui de prime abord me gêne, le fait qu'un simple
survol d'un onglet charge le nouveau contenu.
En restant bêtement utilisateur informatique, un clic me semble plus
justifié et pertinent.
Tout simplement car j'aime bien que l'ordinateur fasse ce que je
demande explicitement , comme un clic.
Voili
Km
franchement ce diatribe s'apparente plus à un procès stalinien qu'à un
échange constructif dans lequel transparait le respect du travail d'autrui,
l'humilité et l'ouverture d'esprit
Après avoir lu l'intégralité de ce message on comprend bien pourquoi il a pu
sembler pertinent de comiter un premier jet opérationnel pour illustrer
cette proposition d'évolution . Une proposition destinée à faire réagir, un
préambule au dialogue. c'est toujours plus aisé de se représenter une
évolution d'interface en manipulant un prototype.
Au risque de devoir braver les foudres de l'inquisition* et de me faire
agonir d'injures, il faut bien reconnaitre que l'interface actuelle est loin
d'être tellement parfaite, ergonomique et intuitive pour l'utilisateur
- le principe des onglets y est déjà utilisé d'une façon nettement moins
évidente que dans la proposition puisqu'ils ne ressemblent pas visuellement
à des onglets.
- les termes employés ne sont pas nécessairement porteur de sens pour des
non développeurs. Juste un exemple : "édition" quel utilisateur lambda va
immédiatement comprendre qu'il s'agit de modification?
Je ne vais pas lister ici toutes les imperfections de l'interface actuelle,
mais sincèrement amorcer une évolution sur ce sujet est loin d'être superflu
Maintenant si l'interface de l'espace d'administration de spip est un sujet
tabou et intouchable... il faut le dire... sur spip_dev , cela va sans dire
Nat33
"Martin Arnaud" <arno@rezo.net> a écrit dans le message de news:
571CA22D-4AD4-48FC-BF11-9A2E2284D896@rezo.net...
Salut,
Je viens de découvrir la nouvelle interface des rubriques et des
articles. C'est proprement catastrophique.
1. Je viens de chercher "interface", "onglet", "propriétés" dans mon
lecteur de mail: je n'en trouve rigoureusement aucune trace sur la
liste spip-dev.
Alors quoi, ça n'est plus sur spip-dev qu'on discute du développement
de SPIP? Il faut que je mette SPIP à jour pour découvrir une
évolution aussi importante après-coup? Je suis scandalisé.
2. Le principe des onglets...
A. Ça fait des années qu'on s'attreint à limiter les onglets, à
proposer des solutions "one-click", pour accélérer la navigation dans
l'espace privé. Une des évolutions les plus pratiques de la 1.8,
justement, c'était d'atteindre les sous-niveaux de la barre de
navigation principale d'une seul clic. Là, d'un seul coup, on se
retrouve à naviguer d'onglet en onglet en permanence rien que pour
naviguer de rubrique en rubrique ou pour modifier un article, ce qui
est un pur contresens par rapport à cette volonté d'accélérer les
manipulations dans l'espace privé.
B. Le recours aux onglets est caractéristique d'une pensée de
développeur qui trouve cette solution de facilité quand il a une
difficulté ergonomique. C'est une saloperie à la Windows. Tous les
développements de logiciels récents s'astreignent à limiter
l'utilisation des onglets: on ne les trouve plus, dans les logiciels
modernes, que dans les panneaux de "configuration" (et dans les CMS
conçus par des développeurs – en ce moment j'utilise un CRM libre,
Sugar, c'est nickel sauf que les onglets dans tous les sens rendent
l'utilisation carrément pénible).
C. Les onglets imposent une solution structurelle adaptée à la
logique des développeurs. Mais elle est quasiment contraire à la
logique de l'utilisateur. La logique qui consiste à imposer des
onglets "documents" (avec le logo!), "propriétés" et "interactivité"
a un sens assez foireux pour l'utilisateur final.
D. Comme à peu près n'importe qui aujourd'hui, j'ai une molette sur
ma souris. Une page un peu longue, mais bien structurée, n'est pas un
problème, au contraire: d'abord je vois tout ce dont j'ai besoin sur
la page, le récent système de dépliage automatique au survol était
épatant pour déplier sans se prendre la tête, et d'un coup de molette
j'atteignais directement ce dont j'avais besoin. Avec les onglets,
j'ai tout le contraire: je ne vois pas où est quoi, je dois passer à
un autre onglet pour accéder à ce dont j'ai besoin, au lieu de
simplement balancer un coup de molette, et je dois connaître le
contenu les onglets avant de savoir quoi faire.
E. Quand je navigue de sous-rubrique en sous-rubriques, je dois en
permanence recliquer sur l'onglet "sous-rubriques" avant de pouvoir
naviguer. C'est pénible, et l'évidence du contenu d'une rubrique est
perdue: je perds la vision immédiate de la structure de mon site:
j'ai la liste des articles dans un onglet, et la liste des sous-
rubriques dans une autre.
F. Un système d'onglet perd la hiérarchisation de l'information,
qu'on obtient par la chronologie de présentation des blocs, les
tailles des éléments, bref la maquette générale de la page. Pourquoi,
par exemple, passer la gestion du logo, qui est un élément vital,
dans un onglet à la présentation identique à "Interactivité" dont
l'usage est rare?
3. Le principe des onglets entre en conflit, au niveau de la logique
ergonomique, avec le bouton "Modifier cette rubrique". On avait déjà
un peu cette difficulté, mais là, ce problème saute aux yeux
immédiatement.
Je suppose que l'idée est d'aller vers une édition à la «Crayons»: je
double-clique sur le titre et j'édite le titre directement. Ça, OK,
ça serait une évolution plutôt agréable. Mais je ne suis pas certain
que tous les problèmes ergonomiques aient déjà une solution de ce
côté (quid des images et documents insérés dans les articles par
exemple?).
4. Regrouper les boutons en haut de page. Fausse bonne idée à mon
avis. Il y a évidemment un aspect séduisant et pas totalement
désagréable à avoir les boutons d'action au même endroit. Mais ça ne
me semble pas non plus valable.
A. D'abord, parce que la nouvelle interface regroupe des boutons qui
n'ont strictement rien à voir, tirés de la page elle-même et du pavé
"Raccourcis". Il n'y a rigoureusement aucune logique ergonomique
entre "Voir en ligne", "Tous les articles", "Créer une sous-rubrique"
et "Poster un message".
B. L'idée était tout de même de placer les boutons de création à
l'endroit où l'on affichait les éléments concernés. "Créer un nouvel
article" était sous la liste des articles, etc. À l'usage, c'était
une solution extrêmement rapide, puisqu'on n'avait même pas à
identifier les boutons; sans lire ni l'intitulé du bouton ni
identifier son icone, il suffisait de cliquer sur le bouton placé
sous la liste des articles pour créer un nouvel article. Là, il faut
identifier le bouton précis au milieu d'une ligne de boutons qui se
ressemblent.
Dans cette logique, le bouton "Poster un message" montre clairement
les limites d'une telle présentation. Je ne dois pas pouvoir "Poster
un message" si je ne suis pas en train de lire le forum: d'autant que
les forums de SPIP sont hiérarchisés, et que pour répondre à un
message existant, je ne dois surtout pas cliquer sur "Poster un
message", mais sur "Répondre à ce message" dans le pavé correspondant.
C. De nombreux éléments de "création" ne peuvent évidemment pas être
présents dans le pavé de bouton. Du coup, incohérence ergonomique.
Par exemple, j'ai le pavé "Ajouter un document" (au portfolio) qui se
trouve bien en bas de la liste des images du portfolio, parce qu'on
n'a pas vraiment d'autre choix ergonomique, alors que la logique est
la même que celle des boutons d'éléments liés (donc: boutons de la
barre du haut).
5. Un gros souci ergonomique supplémentaire: la structure de la page
est à nouveau complexifiée. On s'en sortait avec la barre de
navigation principale en haut, et ses accès "one-click" aux sous-
parties; plus une colonne centrale, une colonne de gauche et une
colonne de droite. Maintenant on ajoute dans la colonne centrale une
répartition par onglets, une barre d'icones et un "haut de page" hors
onglets.
6. L'affichage de tous les "titres" des éléments du contenu est une
logique de développeur. Pour l'utilisateur, c'est sexy comme un
manuel de réparation de sa voiture, il n'y a plus de hiérarchie de la
présentation (titre, sous-titre, texte et postscriptum au même
niveau), et je me vois imposer des intitulés vides, alors que si
c'est vide c'est bien parce que je le veux bien.
Oups !! Merci de l'info ... J'en suis resté à la 10080 ... et n'avais pas vu ça !
A+
Marc
franchement ce diatribe s'apparente plus à un procès
stalinien qu'à un échange constructif dans lequel
transparait le respect du travail d'autrui, l'humilité et
l'ouverture d'espritAprès avoir lu l'intégralité de ce message on comprend bien
pourquoi il a pu sembler pertinent de comiter un premier jet
opérationnel pour illustrer cette proposition d'évolution.
Une proposition destinée à faire réagir, un préambule au
dialogue. c'est toujours plus aisé de se représenter une
évolution d'interface en manipulant un prototype.
Mais on a pas les plugins justement pour faire ce genre de tests sans
pourrir le SVN avec des aller et retours ?
Olivier G. <spip <at> novactive.com> writes:
> franchement ce diatribe s'apparente plus à un procès
> stalinien qu'à un échange constructif dans lequel
> transparait le respect du travail d'autrui, l'humilité et
> l'ouverture d'esprit
>
> Après avoir lu l'intégralité de ce message on comprend bien
> pourquoi il a pu sembler pertinent de comiter un premier jet
> opérationnel pour illustrer cette proposition d'évolution.
> Une proposition destinée à faire réagir, un préambule au
> dialogue. c'est toujours plus aisé de se représenter une
> évolution d'interface en manipulant un prototype.Mais on a pas les plugins justement pour faire ce genre de tests sans
pourrir le SVN avec des aller et retours ?
oui, si ce n'est que là l'objet c'est pas un plugin additionnel c'est de faire
évoluer l'interface de l'espace privée... c'est pas très logique de gérer ça en
plugin... un plugin est censé apporter une fonctionnalité complémentaire
là, on a un nettoyage du code de l'interface et une refonte de l'ergonomie
générale c'est pas logique de le gérer en surcharge.
enfin je réagissais surtout à la violence de la réaction. Parce que, mine de
rien, si c'était vraiment facile de discuter ouvertement sur le sujet sans se
retrouver collé au mur... certainement que le projet aurait été amené de façon
moins cavalière.
Nat 33
rburton a écrit :
aaah , ça va défourailler !
non je rigole !
Hé bien moi je trouve ça pas mal du tout.
Sur la discussion ergonomique (thread "utilisation des onglets"):
Faut quand même rappeler une évidence de base qui est tellement triviale
qu'elle en devient inaperçue !un écran est dans un format rectangulaire, orienté "paysage" (le plus
grand côté à l'horizontal)
D'autant plus rectangulaire que les barres d'outils diverses et les
"footer" (barre de tâches par exemple) de l'OS et du butineur renforce
cet aspect.Or je trouve que l'on sous-utilise l'utilisation de cet horizontalité ...
pour deux raisons me semble-t-il:
[...]
Bonjour
Personnellement, si l'interface dépasse 1024 de large et que je soit
obligé d'utiliser un ascenseur horizontale, je serai très mécontent.
Alors que verticalement, rien ne me dérange (mais je préfère que
tout l'espace en largeur de la fenêtre soit utilisé).
A bientôt
Grégoire
Grégoire a écrit :
Personnellement, si l'interface dépasse 1024 de large et que je soit
obligé d'utiliser un ascenseur horizontale, je serai très mécontent.Alors que verticalement, rien ne me dérange (mais je préfère que
tout l'espace en largeur de la fenêtre soit utilisé).
Bonsoir,
Certes, mais le choix qui a été fait de privilégier l'ascenseur vertical (la souris commande l'ascenseur vertical) ne va pas nécessairement de soi. Ceci dit, c'est fait, c'est fait.
même en 1024, combien de sites se calent sur 800 en centrant la colonne.
Enfin, professionnellement j'utilise deux écrans 19 pouces en 1280 et en 1600 ... un site calé sur du 1024 (et je dis pas sur du 800), c'est à pleurer.
Reste la soluce du pauvre qui consiste à étendre (via javascript, par exemple) ,la zone de "contenu textuel" en largeur pour occuper tout l'espace H. Sauf que un texte, ça devient difficile à lire si la ligne est trop longue (au-delà d'une centaine de caractères ...)
quant à l'ascenseur horizontal, je trouve qu'on a trop peu exploré ses possibilités...
juste à titre d'exemple mal torché...
Imaginons un site centré "contenu textuel illustré dans le corps du texte", avec de multiples possiblités de navigation pour trouver le doc à lire. Le doc est appelé par ajax et chargé dans la page unique pour consultation.
je travaille sur une page de 2048
de 0 à 1024 je cale mes différents champs/menus de recherche et de navigation, voire un historique de navigation, en essayant de tout faire tenir sur disons 600 de haut
et sur la partie 1024->2048, le texte trouvé s'affiche et utilise intelligemment toute la largeur de la page: place des illustrations, grande marge à gauche ou à droite pour y balancer les notes en bas de page qui apparaissent enfin à hauteur de leur appel. Le tout avec usage de l'ascenseur vertical.
Tu cherches ton texte
tu le trouve
et hop tu bascules sur la partie droite de la page et tu consultes à l'aise.
J'ai pas testé,
mais cela ne me paraît pas contre-productif et anti ergonomique.
a+
Roger Burton
Grégoire a écrit :
> Personnellement, si l'interface dépasse 1024 de large et que je soit
> obligé d'utiliser un ascenseur horizontale, je serai très mécontent.
>
> Alors que verticalement, rien ne me dérange (mais je préfère que
> tout l'espace en largeur de la fenêtre soit utilisé).Bonsoir,
Certes, mais le choix qui a été fait de privilégier l'ascenseur vertical
(la souris commande l'ascenseur vertical) ne va pas nécessairement de
soi. Ceci dit, c'est fait, c'est fait.
même en 1024, combien de sites se calent sur 800 en centrant la colonne.
Enfin, professionnellement j'utilise deux écrans 19 pouces en 1280 et en
1600 ... un site calé sur du 1024 (et je dis pas sur du 800), c'est à
pleurer.
oui mais on peut difficilement faire mieux :
cf . http://www.libstat.com/pages/resolution.htm pour un exemple type
de consultation de site.
48% sont en 1024 de large, 9% en 800px de large, 5% d'indéterminés.
(il y a plus d'utilisateur à 800px de large que d'utilisateurs ayant
une largeur supérieure à 1400px)
Cela veut dire que si tu construis ton interface pour plus de 1024, tu
va perturber au moins 60% de tes utilisateurs (sans parler de ceux
qui, même avec une résolution supérieure, n'ouvrent pas le navigateur
en pleine page)
Donc 900px de large est actuellement à mon avis le meilleur compromis possible.
Reste la soluce du pauvre qui consiste à étendre (via javascript, par
exemple) ,la zone de "contenu textuel" en largeur pour occuper tout
l'espace H.
Arghh : tout sauf ça :
un jour tu es sur un bel écran 20 pouces avec une interface customisée
pour, le soir tu te retrouves sur un portable de 1024x900 (moi), avec
une interface complètement différente. C'est plutôt perturbant, non ?
Sauf que un texte, ça devient difficile à lire si la ligne
est trop longue (au-delà d'une centaine de caractères ...)
D'ou le fait d'avoir une largeur textuelle maximale de 700px
quant à l'ascenseur horizontal, je trouve qu'on a trop peu exploré ses
possibilités...
juste à titre d'exemple mal torché...
C'est pas habituel du tout : autant l'utilisateur est habitué à
utiliser un scroll vertical (car son interface le lui permet touche
espace, ou flèches rapides de saut de page, ou souris, ou flèche, ou
molette), autant le scroll horizontal est bcp plus difficile (flèches
droites/gauche et souris seulement -- maintenant parfois une molette
horizontale)
Imaginons un site centré "contenu textuel illustré dans le corps du
texte", avec de multiples possiblités de navigation pour trouver le doc
à lire. Le doc est appelé par ajax et chargé dans la page unique pour
consultation.je travaille sur une page de 2048
de 0 à 1024 je cale mes différents champs/menus de recherche et de
navigation, voire un historique de navigation, en essayant de tout faire
tenir sur disons 600 de haut
Tu connais beaucoup de sites sur lequel tu peux prévoir la hauteur que
tu vas avoir ?
De plus, je préfère si j'ai un écran haute def, avoir une zone de
saisie pour les textes qui soit la plus haute possible, question de
confort..
et sur la partie 1024->2048, le texte trouvé s'affiche et utilise
intelligemment toute la largeur de la page: place des illustrations,
grande marge à gauche ou à droite pour y balancer les notes en bas de
page qui apparaissent enfin à hauteur de leur appel. Le tout avec usage
de l'ascenseur vertical.Tu cherches ton texte
tu le trouve
et hop tu bascules sur la partie droite de la page et tu consultes à l'aise.J'ai pas testé,
mais cela ne me paraît pas contre-productif et anti ergonomique.
perso je ne partage pas ton avis. Mais si tu trouves des études
d'ergonomes qui prouvent bien le contraire, je suis prêt à revoir ma
copie.
Je note en tout cas qu'avec un écran de 1600px de large (ne soit pas
offusqué) tu commences à rentrer dans la catégorie des utilisateurs
présentant un handicap, c'est un bon argument d'accessibilité ça 
@+
.Gilles