Wikini:LaurentLunatiSkin

templates et habillage

(Recommandation de CharlesNepote : attention de bien séparer la page entre les aspects fonctionnels et techniques.)
(J'ai complètement reformulé nos discussions pour plus de lisibilité. J'espère avoir respecté tous les points de vu. Naturellement on peut toujours rediscuter. -- CharlesNepote)

Expressions des besoins fonctionnels

Pour l'accessibilité je pense qu'il y a besoin de pousser un peu le réflexion sur les placements et le nommage des divers éléments. Par exemple le footer contient essentiellement des éléments en rapport avec la page vue, la logique m'a incité à douter de la zone ciblé par la recherche (la page ou tout le site?), il a fallu que je teste pour savoir. -- LaurentLunati

Oui, la place de la recherche n'est pas logique. Je pense que sa place a été dictée à l'origine par le désir de n'avoir qu'une seule ligne dans le menu de navigation (en haut). Ce qui est idiot. Ta remarque est juste, en d'autres termes il ne faut pas vassaliser le contenu à la présentation.

Rappel de la structure actuelle

Structurellement WikiNi les pages de WikiNi sont actuellement ainsi formées :

nom du wiki (doit-il être un lien vers la page principale ?)
nom de la page
menu de navigation intégrant les contenus suivants séparés par des "::" :
- lien vers la page principale (obligatoire)
- menu de navigation
- identification [contenant "ParametresUtilisateur :: Vous êtes CharlesNepote (Déconnexion)"]
corps
zone de commentaires
menu relatif à la page (mélangeant actions et informations sur la page ; champ de recherche)
signature

Proposition de nouvelle structure et de besoins fonctionnels

Après quelques discussions, nous proposons une nouvelle structuration des contenus :

menu d'accessibilité : menu permettant une meilleure accessibilité aux parties de la page et/ou du site (ce menu peut être rendu invisible pour les personnes n'en ayant pas besoin)
nom du wiki
nom de la page
menu de navigation (au contenu libre, ouvant contenir éventuellement un champ de recherche)
identification [contenant " ParametresUtilisateur :: Vous êtes CharlesNepote (Déconnexion)"]
corps
zone de commentaires
menu des actions relatives à la page : Éditer cette page, Supprimer, Éditer les permissions, historique, références
menu des informations relatives à la page : propriétaire, date de la dernière modif (on peut envisager d'autres informations)
signature

(notez : 1. la disparition du lien obligatoire vers la page principale dans le menu de navigation, 2. la sortie de l'identification du menu de navigation, 3. la disparition du formulaire de recherche du précédent menu relatif à la page, 4. de la sission en deux sous-menus du précédent menu relatif à la page. 5. L'ajout du menu d'accessibilité)
Question en suspend : la recherche doit-elle être un bloc à part ?

En termes fonctionnels, nos besoins sont les suivants :

Chaque élément structurel fait l'objet d'un bloc de style propre.
Plusieurs éléments structurels peuvent être réunis en tant que deux sous-blocs dans un bloc commun (par exemple : il devient possible de réaliser un menu regroupant menu de navigation et identification).
Les éléments suivants ont un contenu complètement configurable (si possible en ligne) :
- menu d'accessibilité
- nom du wiki
- menu de navigation
- signature
Seul le bloc "corps" est indispensable au sein d'une page, tous les autres blocs sont optionnels (1).
L'ordre d'apparition des blocs doit être configurable ; si possible en ligne par l'administrateur.
Il n'est pas possible de rendre le site inutilisable à la suite d'une manipulation hasardeuse en ligne.

(1) Il existe des cas, certes marginaux, où un administrateur peut désirer ne pas faire apparaître ces contenus : le nom peut être dans le corps de chaque page et il est donné dans la balise <title> ; idem pour le nom de la page ; les actions sur la page peuvent être entrées à la main dans l'URL ; le menu n'est pas nécessaire ; (cf. l'exemple de http://www.meridon.com/ où on voit que le nom de la page et les actions sur la page n'apparaissent pas). Il n'y a donc qu'un et un seul contenu indispensable : le corps de la page, tous les autres étant optionnels.
-- LaurentLunati et CharlesNepote

Pistes de solutions

Tous cela laisse supposer que l'on veux utiliser un système de template pour WikiNi, il me semble avoir vu une discussion sur les template et que le résultat était de ne pas les utiliser.... Dans tous les cas, je trouve le système de template tout à fait valable, reste à trouver le bon moteur ou à en faire un ( pas très complexe à faire, j'ai déjà essayé). --GarfieldFr
- Les systèmes de template sont une solution mais ce n'est pas la seule. La solution utilisée actuellement n'est peut-être pas incompatible avec les propositions auxquelles nous réfléchissons. A propos des systèmes de template, nous avions conclu à leur rejet pour des raisons de complexité de mise en oeuvre et de performance : nous souhaitions que des développeurs ne connaissant pas WikiNi puissent être rapidement opérationnels. Deux ans plus tard, la quasi totalité des outils de gestion de contenu utilise un tel système et WikiNi a montré qu'il était facile à personnaliser (fonctionnellement) ; on peut donc peut-être réévaluer ce rejet. -- CharlesNepote
  - Complexité de mise en oeuvre? Je pense que ca dépend fortement du moteur utilisé, il est vrai que Smarty par exemple n'est pas simple, surtout avec l'utilisation du cache mais il existe d'autre moteur plus simple et permettant de créer facilement des templates. Par contre, il peut être interressant de passer uniquement par des CSS à condition d'enrichir un peu le HTML généré. Je pense qu'il est un peu pauvre pour pouvoir générer des pages comme sur www.csszengarden.com et qu'il faut probablement revoir un peu les balises de bloc pour rendre l'interface plus facile à modifier via des CSS, WikiNi serait alors le seul (?) wiki à ne pas utiliser un système de template et la question des performances serait suprimée, reste à trouver un pro des CSS. Autre avantage des CSS, si le fichier est détruit le site est toujours visible et il est tout a fait possible d'écrire le CSS dans une page WikiNi permettant ainsi la modification "online" de l'aspect du site !--GarfieldFr

Je n'ai pas changé d'opinion sur les templates, au bout d'un moment, par "amélioration" successive on se retrouve avec un veritable language (cf spip ou templeet), je rappelle que php, lui même, était au départ une extension html que l'on peut considérer comme un template. Donc mon avis sur la question : des templates pour développer Wikini : non. -- DavidDelon
PS : voici un exemple de ce que l'on peut trouve dans http://www.templeet.org [fr] :

Je suis assez d'accord avec ce point de vue, le template ne devrait pas dériver vers ce type de chose. Reste qu'il est nécessaire de pouvoir choisir l'ordre d'apparition des élément dans la page, et de jouer sur les imbrications de div. Cela pour plusieurs raisons, tout d'abord, d'un site à l'autre, les éléments importants ne seront pas forcement les même, les objectifs de ces sites non plus. Si par exemple je souhaite consulter mon site en grande partie avec un pda , la logique d'apparition des divers éléments sera guidé par cette contrainte, et dans ce cas la css est inefficace. De plus pour tirer pleinement partie des feuilles de style, il faut aussi pouvoir modifier un peu les jeux d'imbrications, css zengarden est un bel exemple mais il faut aussi penser que le html à été spécialement conçu à cet effet, chaque paragraphe ayant été codé avec un id propre, donc impossible à réaliser avec un wiki. J'avais fait un petit exemple basé sur les listes pour montrer qu'il est possible de faire beaucoup à partir des css mais que cela demande parfois quelques petits "aménagements". www.orogram.com/Documents/listes.html --LL

Pour ma part, ce n'est pas tant l'ordre d'apparition qui me semble important mais l'apparition en elle-même. Concernant l'ordre d'apparition, une méthode intéressante consiste à déterminer l'ordre de manière à ce qu'un aveugle ou PDA ait le plus grand confort possible : généralement : le titre du site, le titre de la page, un menu de navigation interne à la page, le contenu puis les menus et signatures (pour peu qu'on veuille faire apparaître tous ces éléments). La CSS fait le reste. Concernant l'apparition en elle-même, je pense que tous les éléments doivent être optionnels sauf le contenu. -- CharlesNepote
- L'ordre d'apparition est aussi très important, d'une part pour les css qui il ne faut pas l'oublier fonctionnent beaucoup sur le principe d'héritage de valeur, d'autre part pour le type d'utilisation faite du site. Par exemple si notre aveugle ou utilisateur est avant tout un lecteur, et que l'objectif est la consultation pure on placera les menu d'édition en fin de page car l'acte d'éditer découlera de la lecture du contenu. Si par contre c'est quelqu'un qui utilise le site pour partager des informations vite notées, alors l'important est l'accès à la fonction d'édition qui devra alors être placer en tête de contenu. Cela est valable aussi pour un site qui souhaite pouvoir harmoniser l'aspect et l'ergonomie de ses page quelque soit le type d'appareil utilisé et la version du navigateur (99% des cas). Les css sont une avancée majeure, mais elle ne permettent pas tout... --LL

Je suis sensible à ces arguments. Pour autant la solution du template dans le source de Wikini me semble lourde. La solution de MacroWikini proposée par CharlesNepote ne conviendrait-elle pas ? -- DavidDelon

Oui c'est effectivement une solution envisageable, l'idéal serait de pouvoir intégrer des div autour de ces variables, mais on entre là dans un niveau de complexité peut être trop important et on risque surtout des erreurs. La solution est sans doute dans l'association des MacroWikini à un enrichissement du code pour augmenter le nombre de possibilités d'habillage. le source de csszengarden nos donne quelque pistes, comme :

<div id="pageHeader">

<h1><span>xxxxxx</span></h1>
<h2><span>xxxxxx</span></h2>
</div>
- <div id="quickSummary">
  - <p class="p1"><span>xxxxx</span></p>
  - <p class="p2"><span>xxxxx</span></p>
    - </div>

les inclusions systématique de span dans les balises permettent d'avoir à minima deux niveaux par éléments, ce qui facilite grandement l'habillage (notamment les blocs encadrés) en appliquant le principe à l'ensemble des balises on arrive à quelque chose d'assez agréable à skinner je pense --LL

Solution technique pour ordonner les contenus

L'ensemble de fichiers nécessaire à une skin doit donc comprendre :

un (ou +) fichier décrivant l'ordre d'apparition des éléments
une ou plusieurs feuille de style
un dossier stockant les éléments associés (images, mp3....)

Le (les) fichier décrivant l'ordre d'apparition, sert aussi à placer les classes et id
-- LaurentLunati

Il existe d'autres solutions, comme la possibilité d'éditer directement dans une page wiki l'ordre d'apparition des éléments et la feuille de style (une page pour chacun) : cette solution pose les mêmes problèmes que j'ai mentionnés ci-dessous. Elle rencontre également un autre problème : si l'ordre d'apparition des éléments est effectué dans une page wiki, alors il faut prévoir un mécanisme qui empêche l'administrateur de supprimer l'élément "corps" qui lui est justement nécessaire pour configurer la présence et l'ordre des éléments. -- CharlesNepote

Une solution simple consiste peut-être a avoir une page pour les élément avant corps, et une pour les éléments après.... ainsi quoi qu'on fasse le principale est préservé. De plus le corps est une partie qui n'exige pas de travail autre que sur les css, puisque par définition le contenu n'existe pas encore :) ( je mets volontairement de coté les pages "fixes", comme éditer) --LL
- L'idée à l'avantage d'être simple à gérer mais elle complique un peu le travail du concepteur, obligé de jongler entre deux pages... Une deuxième solution consiste, dans le programme, à positionner un marqueur lorsque le corps a été affiché (genre $body = "true") ; si ce marqueur n'est pas positionné on affiche automatiquement le contenu en fin de page. -- CharlesNepote

Question de la modularisation du menu sous la forme d'une page Wiki

C'est quelque chose que l'on voit fréquement sur des wikinis personnalisés (nous l'utilisons nous-même en intranet). Je suis partant pour une telle modularisation mais elle pose des problèmes fonctionnels sur lesquels il faut réfléchir.

Comment gérer cette modularisation ? Je vois plusieurs pistes :
1. mettre les données dans une page du wiki
2. mettre les données dans un fichier à plat (par exemple le fichier de configuration)

Je traiterai seulement du cas 1 qui est le plus intéressant mais aussi le plus problématique.

1. Modularisation à travers une page du wiki.
Cette page est-elle créée à l'installation ? A priori oui, je ne vois pas bien d'autres solutions sans compliquer l'installation.
Quels droits d'accès possède cette page à l'installation ?

Si tout le monde peut la modifier, alors n'importe qui peut effacer le menu ce qui risque de dérouter l'administrateur débutant. Au minimum, il faut informer l'administrateur sur l'importance de cette page, le laissant libre de protéger ou non cette page et l'informant également des possibilités de retour en arrière en cas de vandalisme ou d'erreur de modification.
Pire, si la page est installée de manière classique, elle ne possède pas de propriétaire : elle est donc susceptible d'être supprimée. Je pense qu'il faut au minimum informer l'administrateur fonctionnel qu'il doit s'approprier la page. Note : cette solution complique un peu l'installation ; peut-être serait-il plus simple de forcer l'administrateur à s'enregistrer au moment de l'installation et de lui donner par défaut la propriété de toutes les pages installées (note : forcer l'administrateur à s'enregistrer au moment de l'installation ouvre par la suite d'intéressantes possibilités d'administration : page d'administration en lecture seule pour l'admin, configuration fonctionnelle à partir d'une page du wiki, etc.).
Le nom de cette page doit-il être "codé en dur" ou l'administrateur peut-il choisir une autre page comme menu ? Je pense que le nom de cette page doit pouvoir être configuré dans le fichier de configuration.

-- CharlesNepote

Pour moi dès qu'il y a possibilité de personnalisation, il y a forcement un administrateur identifié, cela explique aussi les éléments obligatoires autre que le corps. L'administrateur est alors libre de choisir si d'autre que lui voient ou non ces éléments, mais techniquement il souhaitera les avoir à sa disposition pour administrer le site...enfin il me semble:)
Si à ces notion de modification de l'apparence par le propriétaire d'une page on ajoute la notion de sous pages... on arrive à des chose intéressantes.
Pour le menu je pense qu'il y à deux chose différentes, le menu défini par l'administrateur, et des éléments importé de pages wiki dans ce même menu ou non. donc la réponse est sans doute les deux, une page fixe réservé à l'administrateur donc non modifiable par n'importe qui et la possibilité d'importer des parties de page pour laisser sur certain menus ou blocs d'infos la main aux utilisateurs --LL

Exemple de solution avec PhpWiki

Par exemple, ce vers quoi je tente d'aller avec PhpWiki et son système de template ressemble à quelque chose dans ce genre :

gabarit d'une page type:

<?= Template('top') ?>
<?= $CONTENT ?>
<?= Template('bottom') ?>

Le template top contient par exemple:

<?= Button('remove') ?>
<?= Button("PageHistory?", _("PageHistory?")) ?>
<?= Button("diff") ?>
<?= Button("PageInfo?", _("PageInfo?")) ?>

L'objectif est d'avoir une base d'éléments autour desquels je peux construire mes propre hiérarchies de div, à la rigueur la façon dont je nomme mes class et id n'a que peu d'importance, une skin complète correspondant à un couple dossier template, +css, il suffit juste d'avoir une liste des éléments disponibles, la liste des templates minimum à créer et les relations d'interdépendances.

Cela va dans le sens d'un simple à personnaliser (aspect) permet d'élargir facilement le nombre de "peaux" disponibles.
je ne suis pas entièrement satisfait du système de PhpWiki qui reste à mon goût encore trop complexe, difficile à appréhender sans y passer du temps.
LL

Pourquoi "encore trop complexe, difficile à appréhender sans y passer du temps" ? Qu'est-ce qui le rendrait plus simple à ton goût sans perdre de son efficacité. Je propose que dans notre réflexion on ne réfléchisse par à la technique pour réaliser le système d'habillage mais uniquement le système fonctionnel permettant de le réaliser. -- CharlesNepote

Le problème de PhpWiki est que l'on trouve beaucoup de php autour des balises insérant le contenu, pour tester le type de page, si l'utilisateur est logué ou non....enfin plein de chose qui n'ont rien à faire là. --LL

Propositions concrètes pour WikiNi

Sans aller trop vite, car la réflexion est loin d'être terminée, on peut néanmoins proposer des solutions concrètes à mettre en oeuvre dès maintenant.

1. Transformer le nom du wiki en lien

Avantages :

il s'agit maintenant d'un usage très largement répandu sur internet
permet de rendre facultatif le lien vers la PagePrincipale dans le menu de navigation

Inconvénients :

fait double emploi avec le lien vers la PagePrincipale lorsque les deux sont présents
ajoute un chouia de code HTML + CSS

Mais comment gérer un image concomitante ou "à la place de" ?

Solution

Dans /actions/header.php :

<h1 class="wiki_name">
<a href="<?php echo $this->config["base_url"], $this->config["root_page"] ?>"><?php echo $this->config["wakka_name"] ?></a>
</h1>

Code CSS de la feuille de style par défaut :

.wiki_name { float: left; margin: 0px 15px 0px 10px; font-size: 150%; }
.wiki_name a { text-decoration: none; color: black; }

2. Sortir l'identification du menu de navigation

Actuellement nous avons :
<div class="header"> <?php echo $this->ComposeLinkToPage?($this->config["root_page"]); ?> :: <?php echo $this->config["navigation_links"] ? $this->Format($this->config["navigation_links"])." :: \n" : '' ?> Vous êtes <?php echo $this->Format($this->GetUserName?()); if ($user = $this->GetUser?()) echo ' (<a href="'.$this->config["base_url"] ."ParametresUtilisateur&action=logout\">Déconnexion</a>)\n"; ?> </div>

Je propose :
<div id="site_nav"> <?php echo $this->config["navigation_links"] ? $this->Format($this->config["navigation_links"])."\n" : '' ?> </div> <div id="authent"> Vous êtes <?php echo $this->Format($this->GetUserName?()); if ($user = $this->GetUser?()) echo ' (<a href="'.$this->config["base_url"] ."ParametresUtilisateur&action=logout\">Déconnexion</a>)\n"; ?> </div>
Notez :

le changement des classes pour des id
le nom de la classe "header" n'a pas de sens puisqu'il d'agit d'une notion physique ; je l'ai changé en "site_nav", notion fonctionnelle
la disparition du lien "en dur" vers la page principale : cette dernière doit être optionnelle ; il est possible d'avoir ce lien à partir du titre du site
les doubles deux points séparant la PagePrincipale des autres liens "::" a disparu

En poussant encore un peu, on peut envisager :
<?php echo $this->config["navigation_links"] ? "<div id=\"site_nav\">".$this->Format($this->config["navigation_links"])."</div>\n" : '' ?> <div id="authent"> Vous êtes <?php echo $this->Format($this->GetUserName?()); if ($user = $this->GetUser?()) echo ' (<a href="'.$this->config["base_url"] ."ParametresUtilisateur&action=logout\">Déconnexion</a>)\n"; ?> </div>
Notez :

la div n'est pas affichée si le menu n'existe pas

Et je me demande s'il ne faudrait pas intégrer ParametresUtilisateur dans le bloc "authent" ?...
-- CharlesNepote