MétaphoreLivre

MeatballWiki | RecentChanges | Random Page | Indices | Categories

L'hypertexte écrit en utilisant la métaphore du livre a une table des matières, un index, une structure hiérarchique avec des chapitres, des sections, des sous-sections. GnuInfo est un tel médium hypertexte.

La métaphore du livre est un bonne figure structurée pour les choses qui seront éventuellement imprimées comme des manuels. C'est aussi une belle métaphore pour utiliser un petit site web parce que les personnes savent comment naviguer dans un livre : regarder la TableDesMatières, vérifier l'index, aller en avant dans les pages, revenir en arrière.

EmacsWiki avait un script qui vous permettait de télécharger la totalité de la (UseMod) database comme un fichier texinfo, qui peut être ensuite compilé en GnuInfo (ou dans un DVI). Il ne fonctionne plus à cause de BitRot?.

DossierNavigation

A quoi cela ressemble ?

La métaphore du livre en hypertexte est l'un de ces phénomènes de croisement de paradigme. Les personnes ont écrit l'hypertexte dans un format livre parce que c'était pour elles une structure familière. Néanmoins, maintenant que la poussière s'est installée, il est vraiment clair que la métaphore du livre est l'une des meilleures façons de structurer l'hypertexte. Elle présente l'information dans un flux logique et linéaire. Les personnes aiment regarder des choses dans un flux linéaire. En fait, l'une des plus grandes plaintes avec l'hypertexte est que ce n'est pas linéaire.

L'hypertexte ajoute au livre traditionnel le concept de "références actives". Ce qui veut dire, qu'au lieu d'énoncer "Les oeufs permettent de faire de bon gâteaux. (voir Chapitre 12. Gateau.)" vous pouvez maintenant dire "<a href="gateau.html">Les oeufs permettent de faire de bons gâteaux.</a>". Pourtant c'est pire parce que cela n'explique pas au lecteur où va le lien. Il est même mieux de dire "Les oeufs permettent de faire de bon gâteaux. (Voir <a href="gateau.html">Chapitre 12. Gâteau</a>.)" -- SunirShah

Ce format "Voir ref" suggère que quelques noms de pages devraient ressembler à des titres de chapitres plutôt que des phrases que vous pourriez utiliser dans un texte normal. -- DaveHarris

Si vous voulez connaître ce que quelqu'un a pensé à quoi, cela ressemble en RéalitéVirtuelle? à lisez le [WebBook project] de 1996. Truc bizarre.

: Merci pour le lien, je pensais que l'idée du WebBook? était élégante. J'ai particulièrement apprécié cette partie où ils ont pris toutes les pages dans le livre et les ont affichées sur un écran. Je me demande si quelque chose de similaire pourrait être réalisé à l'intérieur du TouchGraphWikiBrowser. Aussi, je suis d'accord avec les types du WebBook? qu'il est bien de voir des animations des pages que vous avez feuilletées pendant que vous feuilletez l'ouvrage. Ceci aide à garder un sens du lieu (dans les vrais livres au moins). Ceci dit, je ne pense pas qu'un sens du lieu soit nécessaire simplement pour empêcher un sentiment de confusion, mais je pense vraiment que cela aide les personnes à connecter les idées. Il est plus facile d'avoir peu de choses en face de vous et de feuilleter en avant et en arrière que d'essayer de vraiment tenir tout ensemble à l'esprit en une seule fois. -- BayleShanks

Limites de tailles ?

Par conséquent, le bénéfice est l'ergonomie accrue pour les consommateurs finaux. C'est plus facile de les lire. Ceci nous dit quelque chose à propos des consommateurs finaux, pas à propos du contenu. Simplement parce qu'il est facile de consommer ne veut pas dire que la forme est plus pertinente. Est-t'il imaginable que les 14 000 pages WikiWiki soient présentées en un livre ? Même si on les imprimait, les 14 000 pages ne seront pas imprimées dans un livre. Elles seront éparpillées sur plus de 30 livres de 500 pages ou moins. Les 30 livres seront ensuite disponibles dans une bibliothèque. Chaque livre se concentrera sur une thématique ou une sous-thématique particulière. La MétaphoreLivre est seulement utile pour les choses taillées pour le livre.

Il y a quelque support pour cela dans l'AntiMacInterface :

: Par exemple, nous sommes aussi coupables parce que tout le monde utilise la vieille métaphore usée du livre : quand nous avons récemment conçu l'interface utilisateur de 300 MB pour la documentation en ligne de Sun, nous avons utilisé une métaphore du livre pour unifier les icônes, le vocabulaire et la structure hiérarchique de la navigation de l'utilisateur. Notre excuse était que l'interface afficherait l'information originalement écrite comme des manuels imprimés distincts et que ç'aurait été désordonné d'utiliser un modèle hyperespace de format-libre pour représenter ce texte. Il n'y a pas de doute, néanmoins, que la métaphore du livre nous ait empêchés de présenter des fonctionnalités désirables comme la capacité de réordonner les chapitres selon leurs scores de pertinence après une recherche.

Pour de grandes collections de pages, le graphe connecté continue à être la seule métaphore disponible pour nous. Néanmoins, la MétaphoreLivre peut être utilisée pour structurer un espace local dans un graphe connecté. La page AutresHypermédias? semble être un bon exemple. Elle structure l'espace de la page dans un modèle façonné en étoile. Les pages Hypermédia se grappent autour. Ce n'est pas un livre à ce stade. Mais si on lui donnait une introduction propre et une discussion propre, ce le pourrait. Voir IndexAvant.

: Si les 14000 pages étaient linéaires dans un format livre, beaucoup du contenu aurait besoin d'être récrit/effacé. Je suspecte que cela l'améliorerait. La forme pseudo-linéaire présente beaucoup de redondance et d'illogisme.

: Une bonne organisation à la façon d'un livre ajoute de la valeur parce qu'elle présente le contenu sur une forme plus compréhensible. Je suspecte que les outils de "Génération Automatique de Table des Matières" n'ajouteraient pas cette valeur. Ceci requiert un éditeur humain. Un outil peut simplement faire le travail du fantassin. Qui est utile, naturellement, et pourrait conduire vers plus de rédacteurs pour faire le travail. Ne confondez simplement pas la forme avec le contenu. -- DaveHarris

Bien vu. La génération automatique de TableDesMatières échouerait quand il y a une redondance de contenu, quand les résumés de pages manquent, quand les sections d'introduction et de discussion manquent. Peut-être que tout ce dont nous avons besoin pour améliorer l'ergonomie d'un wiki, serait un programme pour détecter ces faiblesses ? Ceci voudrait dire que générer une tables des matières n'est pas vraiment nécessaire. Vérifier que toute l'information soit disponible pour générer une tables des matières potentielle, serait cependant agréable :

Un moyen pour mettre en faisceau les pages en rapport et déterminer si l'une des pages pourrait servir de page résumé. Vérifier si la page résumé offre véritablement quelque chose de plus qu'une liste de liens (suggérer que le texte supplémentaire soit une discussion des liens). Trouver des pages avec un contexte similaire et suggérer des fusions.

Est-ce quelque chose pour lequel nous serions prêts à oeuvrer ?

Ceci ne nous dit pas encore si utiliser la MétaphoreLivre pour quelque chose comme la page SécuritéDouce serait pertinent et/ou désirable.

Les éléments de SécuritéDouce sont indépendants les uns des autres, à ce stade ils sont connectés. La page a une belle table des matières. Il n'y a cependant pas d'index mot-clé. Les sous-sections ne se connectent pas de manière linéaire en utilisant des liens avant et après. Les pages liées ne contiennent pas elles-mêmes des sous-sous-sections plus profondes.

Laissez-moi poser une autre question, alors : Devrions-nous utiliser la MétaphoreLivre pour structurer les pages sur un wiki ? Est-ce que cela améliorerait l'ergonomie ?

En se fondant sur une Table Des Matières, ce serait possible de lier toutes les pages avec des liens suivant, précédent et haut, ce serait possible de fournir des chapitres, sections et sous-sections. Je ne sais pas encore si cela produira quelque chose de mieux que MeatBall ou WikiWiki en termes d'ergonomies pour les consommateurs finaux.

: Ce truc en rapport peut se discuter. En d'autres termes, si la même page apparaît dans deux tables des matières différentes, elle aurait besoin de deux ensembles de liens suivant/précédent.

: Personnellement, même au moment de lire un site qui a ces types de liens, je les utilise rarement. J'utilise à la place la navigation peu profonde HubAndSpoke. -- DaveHarris

: Je pense que la PageSectionnée? (SectionedPage) serait une structure utile pour cacher de multiples jeux de liens type suivant/précédent. -- BayleShanks

La MétaphoreLivre est le meilleur moyen pour construire un livre parce qu'un livre est essentiellement linéaire. Avoir des liens dans un livre (une table des matières entrée/index entrée --> numéro page) est pratique pour naviguer le flux. Cependant, l'hypermédia peut être plus fluide. Tout spécialement quand ce n'est pas du contenu statique, comme un wiki. Et comme vous le savez, il est difficile de maintenir une table des matières pour un wiki (ala PointsDeDéparts). -- SunirShah

Sur l'EmacsWiki ça a été facile, parce que PointsDeDéparts est la même chose que DossierDossiers. Tant que la page dossiers liste quelques-uns de ses enfants dans l'ordre, les enfants peuvent être rangés de cette façon. C'est seulement les enfants appartenant au dossier mais sans lien avec la page dossier (ceux étant "adoptés dans un générateur de table des matières automatique) qui ne peuvent pas être ordonnés.

Lutter pour maintenir ces listes de pages à la main est bien parce que cela facilite la navigation pour les autres utilisateurs. Chercher les rétroliens est lent, alors que lire un menu sur la page dossiers est rapide. Le menu sur la page dossiers peut aussi offrir quelques mots supplémentaires à propos de la page étant liée.

Le fait d'avoir un générateur automatique de table des matières pourrait motiver quelques utilisateurs pour ajouter véritablement la méta-information requise : ajouter une étiquette dossier aux nouvelles pages, et ajouter un lier vers la nouvelle page à partir du dossier. Si leurs nouvelles pages ne la produisent pas à l'intérieur de la TDM, elles se verront listées comme "non incluses"...

Génération Automatique de Table des Matières

Quelqu'un intéressé pour écrire un script qui scanne à travers un HyperTexte et essaye d'écrire une Table-Des-Matières comme si c'était un livre ?

Quelques personnes semblent travailler là-dessus.

TableDesMatières utilise un idéateur manuellement créé (Fév 2001):

: ce que j'ai fait est de créer deux "états" qui utilisent un fichier outline pour ensuite générer une "table des matières" et une "VueLivre?" qui dispose des numéros de sections assignés.

StrikiWiki essaye de structurer les pages (Fév 2001) :

: L'idée fondamentale était d'ajouter une fonctionnalité de gabarit. Chaque page avec un format associé dedans. Ce format décrit quelles sont les sections de la page. Un format est simplement une autre page. Parce qu'un format est basiquement une liste de sections, tout le monde peut produire un nouveau format.

Ce n'est pas ce à quoi je pensais cependant. J'aimerais une table des matières générée automatiquement pour tout le wiki . Je pense que ce serait possible de créer automatiquement la TDM en utilisant quelques heuristiques ou autre.

Voilà comment fonctionne EmacsWiki. Notez que EmacsWiki a été créé longtemps après l'invention d'utiliser les Categories comme un outil, aussi pour EmacsWiki, les PointsDeDéparts et les DossierDossiers sont les mêmes. En outre, les pages categories du EmacsWiki ont généralement une petite introduction, et elles listent beaucoup des pages (certainement pas toutes) dans cette catégorie (dossier) dans une liste simple non numérotée.

Lire la page database
Retirer les pages effacées
Retirer les redirections
La page principale a des liens vers beaucoup de pages Category. Toutes celles-ci sont transformées en chapitres.
Pour toutes ces pages, trouvez leurs enfants. Un enfant est une page qui est pointée à partir du parent, et qui lie en arrière vers le parent. L'ordre des pages est le même que l'ordre des liens dans la page parent.
Puis allez à travers toutes les pages orphelines et utilisez le premier lien démarrant par "Category" (NDT ou Dossier) en tant que parent, si ce n'est pas une page orpheline. Ajoutez la page à la fin de ses frères.
Retirer toutes les pages qui sont encore orphelines. Ce sont des pages qui sont trop loin pour être retirées de n'importe quelle page Category. Avec un peut de catégorisation, redirection et effacement, cette liste d'orphelines peut être réduite drastiquemement.

Voilà une suggestion plus ancienne :

Construire un graphe connecté de toutes les pages.
Chiffrer les PagesLesPlusLiées (MostLinkedPages) pour toutes les pages.
Produire un nombre fixe des PagesLesPlusLiées des chapitres. Séparer toutes les pages restantes à l'intérieur de grappes autour des chapitres en chiffrant les chemins les plus courts vers les pages chapitres.
A l'intérieur de ces grappes (faisceaux), utiliser les PagesLesPlusLiées pour déterminer un nombre fixé de sections.
Répéter la mise en faisceau par un chiffrement des chemins les plus courts vers les pages sections.
A l'intérieur de ces sections, utiliser les PagesLesPlusLiées pour déterminer un nombre fixe de sous-sections.
Répéter la mise en faiscau en chiffrant les chemins les plus courts vers les pages de sous-sections.
Trier les pages à l'intérieur de ces grappes (faisceaux) selon l'apparence à l'intérieur de la page sous-section.
Trier les sous-sections pour ordonnancer l'apparition à l'intérieur de la page section.
Trier les sections pour ordonner l'apparition avec la page chapitre.
Trier les pages chapitres selon l'ordre d'appparition dans les PointsDeDéparts (l'unique influence humaine dans tout cela).

Pour essayer de trouver des faisceaux de pages, regardez la liste SchémaIndexation. La page "MarcheAuHasard" semble particulièrement intéressante.

Feuilleton

Bien, peut-être WikiExport?. J'ai travaillé sur la manière de tirer les pages wiki à l'intérieur de composants IFRAME, même inter-serveurs. Cela a seulement aiguisé mon appétit. Maintenant j'aimerais effectuer une recherche (la recherche de catégories fonctionne bien), sélectioner la liste des hits, la copier à l'intérieur de la boîte magique, et cliquer sur un lien et obtenir toutes les pages sélectionnées wiki concaténées dans un gros fichier unique HTML (petits problèmes avec les traductions de liens) quelque chose comme l'option "Print Book" dans Amaya. J'ai fabriqué un script Perl pour faire cela avec un répertoire de fichiers HTML pour tirer les fichiers ensemble dans un fichier qui puisse être ouvert dans Word pour l'impression, mais je ne peux pas voir la manière wiki de faire ça. Peut-être devrais-je me concentrer sur le rêve de jour et moins sur la programmation, parce que je suis clairement bien meilleur sur ce premier point que sur le dernier point. -- JerryMuelver

A propos de la maintenance manuelle des pages Dossiers

Maintenir manuellement la liste des pages contenues dans la page principale des Dossiers requiert de la discipline de ne pas rater l'une des sous-pages. Par conséquent, combinez la liste manuellement créée et annotée des pages avec une liste de pages qui est liée en arrière vers l'index des dossiers ou Catégories mais ne sont pas listées dans la partie manuelle. Cette "liste de pages non listées" peut alors être utilisée pour classer des ajouts dans la partie manuelle et les annoter. Pour améliorer les incentives à produire un classement manuel, la liste peut être réduite à "Actuellement X pages non annotées dans ce dossier" avec un lien vers la liste.

LangueFrançaise PageTranslation BookMetaphor