Style par défaut des pages de Wikini
L'objectif de cette page est de discuter de l'aspect esthétique de Wikini par défaut afin de le rendre plus attractif. Bien évidemment tout le monde peut prendre part aux discussions et apporter ainsi sa touche à Wikini.
Notez bien que l'on ne parle ici que de l'aspect par défaut, celui qu'on obtient lorsqu'on vient d'installer Wikini.
Aller voir les maquettes sous forme de dessin à la page
MaquettesStyleWikiniParDefaut? et sous forme de page web à la page
MaquetteHtmlStyleWikiniParDefaut?.
Motivation
La motivation vient principalement de la comparaison avec d'autres outils du même type (
Wordpress et
DotClear par exemple) et de la lecture récente d'un livre de design web "Le zen des CSS", co-écrit par le créateur de
CSS Zen Garden lui-même... En outre, ayant eu récemment à choisir un moteur de blog, je suis intimement convaincu que les 2 principaux critères de sélection sont la simplicité d'utilisation et l'esthétique.
Plan de bataille
Il m'apparaît maintenant assez clairement qu'il faut d'abord s'attaquer au graphisme du style par défaut de Wikini et ses possibilités de modifications avant de s'attaquer au codage Html/CSS comme discuté dans les pages
LaurentLunatiSkin et
JmPhilippePropositionsCSS.
Plus exactement :
- 1. on définit un style par défaut, ce qui nécessite de se mettre d'accord sur l'organisation de la page (tel lien va avec tel autre), c'est la page MaquettesStyleWikiniParDefaut? qui conduit au découpage des ImagesDuStyleWikiniParDefaut?
- 2. on définit ce qui doit pouvoir bouger facilement dans le style (tel bloc doit pouvoir être placé en haut, à droite etc., être écrit dans la largeur ou verticalement...), c'est la page DiscussionStructureXHtmlWikini? qui conduit à une PropositionDeStructureXHtmlWikini?
- 3. on code le (X)Html qui fait ce qu'on a dit qu'il faut permettre de faire, ce qui nécessite de revoir la StructurationDesThemesWikini
- 4. on code le CSS qui colle le style par défaut du 1. sur le Html du 3.
- 5. on réalise une démonstration grandeur nature pour laquelle il faudra peut-être toucher au Php du moteur (cf. MaquetteHtmlStyleWikiniParDefaut? et RoadmapNouveauStyleWikini)
- 6. c'est pas fini : on documente !!!
Eventuellement on fait 1 ou 2 styles supplémentaires pour prouver que le XHtml codé permet bien de bouger ce qu'on a dit en 2. Ce serait même presque obligatoire d'en faire un sans images pour les sites qui s'adressent à des visiteurs principalement en bas débit.
Il faudrait aussi prévoir une série de tests d'accéssibilité sur le plan sémantique (avec
http://webxact.watchfire.com/, http://www.cynthiasays.com/ et
http://wave.webaim.org/) et sur le plan visuel notamment pour le daltonisme (
recommandations du w3c et
http://colorfilter.wickline.org/ pour des simulations).
Critique du style par défaut
Aspect global
L'impression immédiate que laisse Wikini est pour moi la densité : texte écrit petit, s'étirant sur toute la largeur, lignes très proches les unes des autres, absence de marges importante sur les bords, pas de graphisme, pas de menu latéral pour diviser la largeur de page, titres avec lettres serrées les unes contre les autres, beaucoup de soulignés... Bref surtout du texte et pas de fil directeur évident.
Sur l'aspect global les conseils émis dans le livre cité plus haut sont les suivants :
- préférer des marges généreuses, notamment sur les côtés, pour que la page se différencie facilement du contenu des autres fenêtres
- préférer un menu de navigation latéral qui est plus attendu par les internautes qu'un menu en haut ou en bas de page
- favoriser la lisibilité : espacement vertical des lignes généreux, longueur de ligne "raisonnable", taille de caractères ne nécessitant pas une loupe ! (et modifiable par le navigateur)
- jouer sur les polices, les couleurs et les espacements de caractères pour représenter graphiquement la hiérarchie des informations (titres, sous-titres, texte, lien, etc.)
- éviter les contrastes de couleur forts (jaune sur bleu, vert sur rouge, etc.) qui sont ressentis comme agressifs
- éviter d'employer une palette de couleur trop étendue, sauf effet particulier recherché (mais il faut alors bien maîtriser le sujet)
Codage Html/CSS
Pour les navigateurs en mode texte - donc pour l'accessibilité, il vaut mieux placer la section contenant le texte de la page (bloc
div) en début de code Html. Cela évite de parcourir la liste des liens potentiellement longue pour y arriver et surtout à chaque page à lire !
Pour faciliter un peu le travail des graphistes web, il vaut mieux passer
WikiNiEnHTMLStrict afin de forcer
InternetExplorer 6.0 en mode plus proche des standards. Ainsi il ne reste que les IE 5.5 et 5.0 de réellement extravagants par rapport aux standards (malheureusement pas par rapport à la part de marché, encore que...).
Discussions
Je (
GreGoire?) recommande de faire plusieurs feuilles de style:
- Une pour les couleurs, les tailles de caractères, les polices...
- Une autre pour la mise en page,
- Enfin, une spécifique pour l'impression.
Oui je n'en ai pas parlé dans la section du dessus
Codage Html - CSS, mais j'aurais certainement dû. En fait la discussion sur ce sujet est déjà ouverte sur la page
RendreModulairesLesFeuillesDeStyle et... ne fait pas (pas encore ?) l'unanimité. Pour ma part cela devient de plus en plus inévitable d'organiser la structure des styles car :
- il faut pouvoir gérer à terme des thèmes facilement installables mais surtout facilement sélectionnables
- ceux qui développent des thèmes ne peuvent pas prévoir un habillage pour chaque extension possible imaginable
- inversement ceux qui développent des extensions ne peuvent pas prévoir un habillage pour chaque thème possible imaginable
- quid de l'internationnalisation si des thèmes font appels à des textes placés dans des images ?
De ce fait il est très souhaitable que Wikini adopte une structure de fichiers souple et ouverte pour les thèmes. D'ailleurs j'ai ajouté un couplet en rapport avec ces réflexions à la page
RendreModulairesLesFeuillesDeStyle sans plus de succès... Sauras-tu être plus convainquant que moi ? --
JmPhilippe
Que peut-on faire ?
Aller voir les maquettes à la page
MaquettesStyleWikiniParDefaut?.
Mise en page
Je propose que Wikini adopte une mise en page classique dans le web actuel d'une zone de contenu de largeur fixe, centrée dans la fenêtre du
navigateur et avec une marge à droite et à gauche minimale généreuse. Les menus seraient placés dans une colonne de la zone de contenu, à droite ou à gauche (il semble que ce soit plus courant de la trouver à gauche toutefois). La zone de copyright resterait en bas de page.
Esthétisme
Pour le choix des couleurs, le bleu est vraisemblablement la couleur sans risques quelle que soit la nationnalité du lecteur.
Pour le graphisme, sans entrer dans le débat du logo Wikini (voir
DiscussionLogoPourWikini), on peut ajouter quelques images pour agrémenter le texte. Par exemple le titre du Wiki pourrait être placé dans une image (un rectangle aux coins arrondis avec effet de lumière et d'ombre), la zone de contenu pourrait avoir une ombre, les puces des listes pourraient être remplacés par des icônes (notamment dans le menu).
Ergonomie
Dans cette section une liste de fonctionnalités rattachées à l'espace de la page où tout un chacun pourrait proposer une amélioration graphique/pratique/fonctionnelle, puis un vote pour une exploration de la faisabilité de cette nouveauté.
- bandeau de fonctionnalité fixe en bas de page — éventuellement footer fixe — (à la CraoWiki, mini bandeau superbe auquel il ne manque que la description lors du survol de l'icone) -- Xf75013?
- Personnellement j'aime beaucoup cette petite barre. -- JmPhilippe
- ce qui me fait penser qu'il faudrait une bulle d'aide sur tous les liens dans l'idéal. -- JmPhilippe
Problèmes posés par Wikini
Texte des liens sans espace
NB: ce problème est discuté sous un autre angle dans la page
TitreAlternatifPourChaquePage dans laquelle on trouvera une référence au problème posé ici pour la mise en page.
De nombreux liens de la page mais en dehors de la zone de texte sont composés d'un assemblage de lettres sans espace (
PagePrincipale,
DerniersChangements,
DerniersCommentaires,
ParametresUtilisateur par exemple). Ceci pose un problème de mise en page car on peut se trouver avec un mot de 50 lettres totalement insécable puisque sans espace. Comment alors prévoir suffisamment de place dans le design ?
Certes on peut facilement remplacer les liens en question par un texte (
DerniersCommentaires devient Derniers commentaires) de sorte que le seul problème qui subsiste est celui du nom des pages créées par les utilisateurs. Notamment celui du titre de la page.
Description du site
Il n'y a pas de texte décrivant le site. Si le nom du site est un peu compact, voire sans rapport direct avec le contenu, comment savoir de quoi il s'agit ? Il faudrait donc pouvoir définir ce texte descriptif dans les paramètres de Wikini afin de l'afficher près du nom du site.
Texte de copyright
Sauf erreur de ma part, il doit manquer dans le pied de page une zone où revendiquer les droits de copie du texte du wiki.
Marquage erroné des paragraphes
Le tag
P n'est pas utilisé et des tags
BR sont utilisés (à tord) à la place. Outre l'aspect sémantique des choses, que certains peuvent voir comme un problème de puristes, ceci a l'inconvénient de ne pas pouvoir régler normalement l'espacement des paragraphes dans les CSS. En effet, dans la logique Html, c'est la marge verticale des paragraphes qui doit servir à aérer le texte entre les paragraphes. Cependant, dans le Wikini actuel, il faudrait jouer sur la hauteur du BR, ce que je n'ai jamais pratiqué...
- Oui, en fait cela est un véritable problème technique lié à la façon dont WikiNi transforme le "code" des pages en (X)HTML: pour l'instant, de manière simplifiée on peut dire qu'il procède de manière linéaire: il lit le texte du début à la fin en remplaçant chaque "balise" par sa correspondance en (X)HTML. Le problème est que pour utiliser des balises paragraphe (P), il faudrait pouvoir déterminer quand les ouvrir et les fermer, et faire attention à ne pas inclure dans un paragraphe des éléments interdits (listes, titres (?), tableaux => actions etc.) puisqu'un paragraphe ne peut contenir, sauf erreur de ma part, que des boites de type en-ligne selon la spécification XHTML 1.0... Ceci me paraîtrait actuellement impossible, ou du moins très difficile sans une certaine perte de performance pour le rendu des pages... -- LordFarquaad
- Ce ne serait pas surtout parce qu'il fait des analyses par expression régulière ? Parce qu'en gros, dès que tu attaques un texte sans rien devant qui t'obliges à mettre un élément bloc (comme les titres ou les listes), tu dois ouvrir un P. Et dès que tu rencontres un retour à la ligne ou un signe de début d'élément bloc, alors il faut le fermer, non ? Là où effectivement ça se complique, c'est quand il y a des actions. Il faut qu'elles sachent qu'un P est en cours pour éventuellement le fermer si elles en ont besoin (et du coup signaler qu'il est fermé). D'ailleurs c'est le même problème si tu insères du code Html brut. En fait, il me semble finalement que le plus simple pour n'en rater aucun serait d'écrire tout le Html sans les P et de les ajouter a posteriori entre les éléments bloc lorsqu'il y a du texte. Comment ils font les autres, on a déjà regardé ? --JmPhilippe
Absence de logo
Certes wikini.net n'a pas (encore ?) de logo. Ce n'est pas une raison pour considérer que les sites basés sur Wikini n'en ont pas non plus ! Donc il faudrait ajouter un tag
IMG dans l'entête pour placer un éventuel logo.
Problèmes de conception courants
Couleur du texte et du fond
J'ai eu plusieurs remarques sur mes wikinis, parce que la couleur blanche du fond de la page, n'etais pas confortable pour la lecture, (sur mes pages j'ai donc mis un fond gris moche, en attendant une solution plus esthetique) --
Err404?
- C'est un problème à part entière : ceux qui ont une bonne vue trouvent que blanc sur noir, c'est trop contrasté, alors que ceux qui ont une mauvaise vue trouveront que noir sur gris ou gris sur blanc n'est pas facile à lire... --JmPhilippe
Marges en pixels, en em ou en %
Mieux vaut faire des marges en % pour que celles-ci s'adaptent à la taille de la fenêtre de navigation. Ceci est nettement préférable car sinon celui qui navigue en 640*480 aura l'impression que c'est trop compressé, alors que celui qui navigue en 1280*1024 ou même plus gardera son impression que c'est trop large... --
LordFarquaad
Largeur de la zone de texte
Pour la largeur de la zone de texte, en fait il est de notoriété publique qu'il ne faut pas dépasser un certain nombre de mots par ligne (12 à 15 je crois) car sinon c'est plus pénible à lire. L'explication est qu'au-delà, cela oblige les yeux à effectuer des mouvements latéraux trop amples, d'où une lecture moins rapide et donc perçue comme plus difficile. Je sais que cela conduit à allonger les pages verticalement mais si tu fais bien attention, dans les journaux, on écrit en multiples colonnes finalement assez étroites pour cette raison... --
JmPhilippe
- Je suis parfaitement d'accord :-) -- LordFarquaad
- Oui, c'est plus agréable en effet. --SimoN?
Discussions
- En gardant la structure originale (liens en haut et bas, page sur toute la largeur) J'ai développé un graphisme plus "friendly" sur mon wikini. Ce n'est pas qu'une modification de style, vu que j'ai aussi restructuré le footer en images, mais je pense que ca rend l'apect un peu moins "techies". Avec quelques class, on pourrais faire la même chose avec le footer traditionel. Si ca vous semble utile... -- SimoN?
- En effet, quelques class ajoutées au footer permet de le definir dans les css (par exemple le menu du haut contiendrait des boutons css plutot que des liens peu personalisable) --Err404?
- Oui mais ça c'est le travail qui vient après : adapter le code Html/CSS au design et à sa personnalisation. Pour l'heure, effectivement le graphisme de SimoN? est beaucoup plus agréable, mais je pense qu'il gagnerait en légèreté avec des marges à droite et à gauche d'au moins 80 ou 100 pixels. -- JmPhilippe
- Ok pour les marges, j'ai essayé d'avancer dans ce sens et du résultat. Je pense qu'une jolie entête intégrée au futur logo rendra l'aspect moins froid et plus convivial. Le menu horizontal pourrait être mieux mis en évidence, mais le choix des couleurs dépend du logo il me semble. Je ne suis pas spécialement en faveur d'un menu latéral. Un simple menu de tête laisse beaucoups de liberté au sein de la page, et fait perdre moins de "place". (Je gère mon menu avec une page incluse.). Le Css doit encore être clarifié et commenté (et adapté à ce maudit MSIE). -- SimoN?
- Ca a l'air pas mal du tout ce que tu as fait, mais ça ressemble fort à DokuWiki? non ? Il faut voir avec les couleurs finales évidemment, et pour le logo WikiNi ça n'avance plus trop (même plus du tout...). Sinon je vois que tu as enlevé le champ de recherche au bas de la page ? -- LordFarquaad
- Connaissait pas docuwiki, mais c'est vrai que ca doit ressembler à pleins de styles de wikis (a wikipedia notemment, j'ai repris des morceaux de leurs styles pour les polices), j'ai cherché la lisibilité plus que l'identité. Resterais encore a mettre quelques couleurs, et peut être personaliser/adapter les images et les polices à un style wikini (ces icones proviennent de Gnome Art). Le champ de recherche, j'attendais de lui trouver une place... en haut ou en bas? -- SimoN?
- Je ne sais pas ce que tu en penses mais pour moi, c'est mieux, c'est plus fluide ! -- JmPhilippe
- Je pense que quelques class, ne suffiront pas pour changer le header et le footer, en effet un wiki s'il peut se suffire à lui même, il est parfois obligé de se plier à des chartes ou à des environnements graphiques pour son intégration. Si l'on désire conserver légèreté et facilité d'emploi, il me semble beaucoup plus judicieux d'appeler des pages "wiki" pour chaque espace défini dans le WikiNi de base ex. :
- pour la têtière, (qui est souvent graphique et fixe), il est possible de la personnaliser avec un fichier css lié juste à cette page (dans un but d'édition facile) ;
- pour le/les menus un fichier contenant juste les fonctions que l'on désire voir ;
- pour le bas de page un fichier contenant juste les fonctions que l'on désire voir ;
- pour le menu une page éditable ... comme cela existe et fonctionne très bien...
- pour les autres espaces fixes... même chose....
personnellement dans le cadre de mon travail, je veux utiliser WikiNi, mais il devra aller s'habiller avant pour passer l'approbation de la charte, or la structure de base actuelle n'est pas du tout prévue pour cela et le quidam lambda (moi) doit bricoler dans des espaces où je ne devrait pas pour un simple relookage (je ne devrai avoir à toucher qu'aux css en direct). En dehors du risque de faire des bétises, la maintenance est d'autant alourdie en cas d'évolution dans les versions. Ce sont certainement de réels points bloquant pour les décideurs. -- Xf75013?
- Et est-ce que tu penses que le nouveau style par défaut vers lequel on va aura la souplesse nécessaire à l'habillage pour ta charte ? Dans le cas contraire, il faut absolument nous dire pourquoi ! -- JmPhilippe
- Grosso modo, si l'on parle de la stucture de la page, rien ne semble indiquer que l'on soit dans la possibilité de personnalisation. En effet un amalgamme est fait entre le style par défaut du wiki — qui n'est là que pour être changé (personnalisé) — et une structure des pages qui est encore à définir. Car n'étant pas pour les templates (trop lourds) il faut offrir une solution simple à la personnalisation. La solution la plus légère que je vois est une découpe des zones dans le wiki (têtière / menus / bas de page / corps de page / autres fonctionnalités... qui correspondent le plus souvent à une ou plusieurs actions), aient une description css. À charge de la personne qui personnalise de fixer les actions qu'elle veut voir dans ces zones (sous forme de page éditable) et de modifier les css pour personnaliser la place des blocs ainsi que l'habillage graphique. Donc pour parler cru le style graphique, "je m'en fous" c'est mon client (éventuellement sur mes recommandations) qui décide pas WikiMan --Xf75013?
- De ce que je comprends, il te manque des fonctionnalités pour tes chartes graphiques afin d'ajouter des éléments dans certaines sections de la page. Du coup les chartes en question ne seraient pas purement graphiques, sinon, à moins que tes clients soient extrêment perfectionnistes, ça ne gênerait pas trop que telle section apparaisse avant telle autre, ce qui compte pour la charte graphique est que ça ait la même tête visuellement, et non que machin soit là ou non (sachant qu'on peut éliminer des éléments uniquement en CSS). Non ? -- JmPhilippe
- Fonctionnalité non il n'en manque pas, ce qui manque c'est une découpe structurelle. Prenons l'exemple de la têtière d'un site WikiNi, actuellement, pour personnaliser la têtière on touche au header, mais j'aimerai que ce header soit ouvert à l'édition aussi simplement qu'une page. La version à venir si elle saura définir via les css une couleur de fond sur la zone, saura-t-elle que je désire mettre dans la zone "PagePrincipale" ou "ParametresUtilisateur" ou "Éditer cette page" ou "..." ? Les utilisateurs des wikis sont peut-être mûrs pour pouvoir personnaliser leur environnement de travail. Tout comme on peut personnaliser le nom du wiki pour l'affichage de celui-ci dans la têtière, il devrait y avoir ces possibilités pour les menu et pieds de page (voir plus). -- Xf75013?
- Donc en fait ce que tu cherches, c'est de pouvoir remanier l'organisation structurelle. Note que pour l'exemple que tu cites, ce n'est pas forcément nécessaire de remanier la structure XHtml. Avec celle vers laquelle on va, tu pourras en effet très bien déplacer en CSS la section qui contient "PagePrincipale" ou "ParametresUtilisateur", ou le "Éditer cette page" dans l'entête à coup de position: absolute. Par contre il faut lister les éléments qu'on est susceptible de déplacer de la sorte afin de s'assurer que la future structure permettra effectivement de les déplacer (voir DiscussionStructureXHtmlWikini?). -- JmPhilippe
- Une entête personalisable en page wiki c'est très facile a faire: http://simon.cassiopea.org/header.txt et idem pour la feuille de style: http://simon.cassiopea.org/css.css perso pour la personalisation des wikis que j'installe c'est devenu indispensable -- SimoN?
LordFarquaadASuivre