-----Message d'origine-----
De : Cedric Bosdonnat [mailto:cedric.bosdonnat.ooo@free.fr]
Envoyé : jeudi 11 août 2011 17:00
À : discuss@fr.libreoffice.org
Objet : Re: [fr-discuss] [IHM] Nouveau design pour le styliste
Bonsoir à tous,
Bonjour Olivier,
On Thu, 2011-08-11 at 06:55 -0700, Olivier R. wrote:
Suite à la demande de Cédric :
http://nabble.documentfoundation.org/Writer-Espace-manquant-da
ns-une-table-des-matieres-tp3147103p3235015.html
Je ne pensais vraiment pas avoir un mockup en moins d'une
semaine, mais
tu l'a fait: chapeau!
cbosdonnat wrote:
* Elaguer les styles existants et les faire plus jolis
Completement d'accord avec vous sur ce point. Je
n'attends qu'un descriptif de ce qu'il
faut faire pour
faire un premier essai et soumettre ca
aux designers
d'IHM ;)
Un dessin valant plus mille discours, j’ai conçu une maquette :
<http://img194.imageshack.us/img194/7776/stylistnew.png>
J'aime bien le rendu global de la chose. J'ai encore quelques trucs a
soigner sur la nouvelle fonctionnalite d'edition des en-tetes /
pied-de-pages de la 3.5 et je regarde ca.
Entre le patch repris par Michael Meeks et ce mockup, je suis
sur qu'on
peut aller loin ;)
Notes :
— les buttons en bas remplacent avantageusement le menu
déroulant (c’est
plus rapide) ;
Pour sur ;)
— chaque case de prévisualisation d’un style occupe ici
exactement la place
de deux styles dans la liste existante (sous Windows) ;
— la prévisualisation des réglages du style (à améliorer)
offre un gain de
temps considérable pour savoir comment le document est conçu.
Oui. Au pire on peut commencer par afficher la previsualisation et la
remplir / reorganiser plus tard.
Personnellement, la prévisualisation ne m'apporte rien car seul le nom du style compte pour moi,
surtout quand il est standardisé au niveau international comme c'est le cas pour une grande
majorité de styles prédéfinis. Si cela ne gêne pas, pourquoi pas, mais cela n'apporte aucune
information complémentaire. On ne code pas un document en fonction de l'aspect mais en fonction de
la structure, l'aspect pouvant être changé par le destinataire s'il préfère une autre
représentation pour lire confortablement.
Par ailleurs, le styliste devrait être affiché par défaut
(utile pour
susciter l’usage des styles) en mode hiérarchique (pour
comprendre les liens
entre les styles).
Ca ne devrait pas etre trop complique a faire ca ;)
+1
En ce qui concerne les styles :
— il y a trop de styles de puces (20 !), quelques-uns
devraient suffire ;
— il y a trop de styles de numérotation (20 !) ;
Ce n'est pas le nombre qui compte, c'est leur structure à repenser. Il faudrait avoir une idée des
intentions de ceux qui ont inventé ce truc pour tenter de bien exploiter.
Un volontaire pour definir quelques styles de puces et numerotations
sympas a utiliser a la place de ceux existants? Meme si ce
n'est pas une
version definitive ca peut servir de base de travail pour discuter ;)
En fait, ne s'agit-il pas de proposer un modèle par défaut bien structuré et d'aspect agréable ? Ce
n'est pas du code...
— 5 ou 6 niveaux de titre (donc d’index et de table des
matières) devraient
suffire, mais j’imagine que ça poserait problème de les
ôter, attendu les
liens qu’ils ont avec la numérotation des chapitres ;
Je ne suis pas sur qu'on puisse les supprimer comme ca... il
les faudra
toujours d'une facon ou d'une autre pour la table des
matieres et/ou la
compatibilite avec d'autres suites bureautiques.
+1
— les styles «Signature», «Destinataire», «Expéditeur» et
«Formule finale»
sont-ils vraiment utiles ?
Je serais partant pour les inclure dans des modeles
uniquement. Ils sont
utilises dans les documents crees par l'assistant lettre il
me semble...
mais il faudrait ne les creer qu'en cas de besoin.
Les styles prédéfinis qui ont une correspondance avec l'équivalent dans la profession doivent être
conservés. En revanche, il faudrait pouvoir *paramétrer l'affichage des styles utiles à chacun des
modèles*, en sélectionnant que les styles utiles aux rédacteurs. Il me semble que c'est une
propriété du style qui devrait être exploitée dans le formulaire pour l'affichage dédié au
rédacteur (remplacer l'affichage des styles utilisés, par celui des styles utiles pour le
rédacteur).
Notamment un courrier bien structuré utilise *obligatoirement* : «Signature», «Destinataire»,
«Expéditeur» et «Formule finale». En revanche, il est possible que dans certains modèles de
courrier le rédacteur n'ait pas à s'en soucier car ils sont seulement exploités dans la maquette et
des paragraphes pouvant être remplis automatiquement ou préremplis. Dans ce cas les styles
devraient pouvoir être masqués dans la liste proposée au rédacteur.
— «Pied de page droit» et «Pied de page gauche» devraient
être des styles hérités de «Pied de page» ;
— «En-tête droit» et «En-tête gauche» devraient être des
styles hérités de «En-tête» ;
+1
Que ce soit par défaut pour donner l'exemple, pourquoi pas, mais ce n'est pas obligatoire. C'est un
détail qui doit être facile à régler à condition que ce ne soit qu'une valeur par défaut. De toute
façon, un rédacteur ne devrait jamais avoir à connaître de ces styles qui ne sont applicables que
dans les modèles. A masquer pour les rédacteurs.
— «En-tête de liste», c’est plutôt un titre, me semble-t-il ;
bah... il est utile celui-la?
Absolument, *c'est un point fort de LibreOffice* d'avoir un tel style prédéfini qu'il fallait créer
dans MS WW, au moins jusqu'à la version 2000. Cet objet doit exister dans un certain nombre de DTD.
En effet, une liste comporte souvent un paragraphe d'ouverture et des articles (items). "En-tête
liste" est le paragraphe qui se termine par ":". Il doit être lié au paragraphe suivant, qui lui
devrait être le style du premier article de la liste, par exemple, "Puce 1 début", suivi de "Puce 1
suivant". La liste se ferme, par exemple par "Puce 1 fin" suivi d'un retour par défaut à "Corps de
texte". Ainsi avec deux raccourcis clavier, un pour coder "En-tête de liste" et l'autre pour "Puce
1 fin", on code toute la liste.
— «Citation» devrait être un style hérité de «Corps de texte».
Oui
Merci pour ton travail, je le garde sous le coude pour un
prochain dev.
Sinon on pourrait prevoir un week-end de hack en france pour s'occuper
de demarrer un/des projets comme ca non? Si ca tient dans un week-end,
je m'en occuperai peut-etre lors de la hack-fest a Munich (si
j'arrive a y aller).
A Lyon, à l'occasion des JDLL ?
Librement.
Jean-Yves ROYER
--
Envoyez un mail à discuss+help@fr.libreoffice.org pour savoir comment vous désinscrire
Les archives de la liste sont disponibles à http://listarchives.libreoffice.org/fr/discuss/
Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être
supprimés
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.