Cette page décrit les idées principales qui ont guidé la conception et l’implémentation de PmWiki.
Son auteur, P Michaud? ne proclame pas que tout ce qui suit soit une idée originale, c’est juste ce qui a dirigé le développement de PmWiki. Vous êtes le bienvenu pour critiquer ce qui suit. Le texte audiences explique aussi plus le raisonnement qui est derrière les idées qui suivent.
- 1. Préférence accordée aux rédacteurs plutôt qu’aux lecteurs
- Le coeur de PmWiki est un système de publication collaborative pour des documents contenant des “hyperliens”. Il est déjà difficile de trouver des gens qui participent à l’écriture (y compris pour Pm); la maîtrise du code HTML et des problèmes de liens sont des obstacles à une contribution active pour les auteurs. Ainsi, le but de PmWiki est de faciliter l’édition pour les auteurs, même si cela implique certaines limites aux documents rédigés.
- 2. Ne pas essayer de remplacer le HTML
- PmWiki n’est pas une alternative qui permet de faire tout ce qui est possible avec le HTML. Il y a de bonnes raisons à ce que les gens n’utilisent pas leur navigateur pour éditer du HTML—c’est seulement parce que ce n’est pas très efficace. Si vous avez besoin d’écrire beaucoup d’HTML “funky” dans une page web, alors vous ne devriez pas utiliser PmWiki pour la créer. Ce que PmWiki essaye de faire est de rendre faciliter l’édition les liens entre PmWiki et d’autres pages web “non-wiki”, d’inclure des pages PmWiki à l’intérieur de pages web complexes et de permettre aux autres pages du web de facilement se lier avec PmWiki.
Ce principe découle du précédent sur la préférence accordée aux rédacteurs — toute nouvelle fonctionnalité requiert des marqueurs/balises supplémentaires pour la supporter. Continuant ainsi, le source du document deviendrait affreuse et nous finirions tous avec un niveau bien meilleur que juste celui d’écrire du HTML.
Une autre raison pour éviter l’HTML complexe est que du code mal formé peut empêcher complètement l’affichage des pages, et un code HTML complexe peut être un risque au niveau de la sécurité—d’autant plus si les pages peuvent être créées anonymement. Voir
http://www.cert.org/advisories/CA-2000-02.html pour plus d’informations.
- 3. Eviter les fonctionnalités gratuites (ou l’usine à gaz)
- En général les fonctions de PmWiki sont implémentées en réponse à des besoins bien spécifiques, plutôt qu’en des choses identifiées comme “pouvant être utiles”. Dans n’importe quel système utilitaire, il est difficile de changer une fonction mal conçue une fois que les gens ont structurés sur sa base beaucoup de choses. (Besoin d’un exemple ? Regardez MS-DOS ou Windows). Une façon d’éviter une mauvaise conception est de résister à la tentation d’implémenter quelque chose jusqu’à ce que vous ayez une idée claire de comment elle sera utilisée.
- 4. Permettre à PmWiki d’être utilisé comme support pour une maintenance collaborative de pages web publiques
- Bien que ce n’était pas du tout l’intention originale de PmWiki, il est apparu évident que les principes du Wiki Wiki Web pouvaient être utilisés pour faciliter la collaboration de groupe dans la conception et la maintenance d’un site web public. PmWiki permet de protéger par mot de passe les pages individuellement, et deux changements de configuration rendent facile la protection de pages PmWiki par larges sections. De plus, PmWiki fournit “des feuilles de style journalistiques” (ndt : on fait ce qu’on peut, “style sheets on steroids” dans le texte original): vous pouvez changer rapidement l’entête, le pied de page et d’autres éléments sans être obligé de toucher individuellement au contenu de chaque page. Enfin, cela reste relativement facile d’ajouter des balises personnalisées pour des applications spécialisées.
- 5. Facilité d’installation et de configuration
-
« Listes de diffusion | Index documentation | Notes à propos de la conception »