[Home]PropositionFacile

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Cette page a démarré sur EasySubmission. C'est une des idées pour RendreWikiPlusAccessible?. Cette page particulière rassemble toutes les idées qui facilitent l'ajout de nouveaux contenus pour les nouveaux utilisateurs.

1. Faciliter l'ajout de contenu vers une page : ajouter des commentaires
1.1. Implémentations Existantes
1.2. Éditer les pages quand vous les voyez
1.3. Ajouter un contenu à la fin d'une page
1.4. Fil de discussion
1.5. Ajouter du contenu au sommet d'une page
1.6. Insérer un bouton "commentez ici"
1.7. Etiquette de liste
1.8. Editer un lien au sommet
1.9. Editer de longues pages reste indigeste
2. Faciliter la création de nouvelles pages
2.1. Implémentations Existantes
2.2. Magicien de création de Page
2.3. Magicien pour créer une page personnelle
2.4. Les magiciens sont trop gras
3. Gabarits
4. A propos de Meatball

1. Faciliter l'ajout de contenu vers une page : ajouter des commentaires

Est-ce que les wikis peuvent être mélangés avec des CarnetWeb (blogs) ? Voir WikiLog (en)

Une des différences est qu'il est psychologiquement facile d'ajouter un commentaire sur un weblog, mais difficile d'éditer une page sur un wiki. Le fait d'offrir des soumissions faciles facilitera la vie des nouveaux utilisateurs, tout en maintenant les pouvoirs d'édition pour les utilisateurs expérimentés.

1.1. Implémentations Existantes

WhyClublet a un bouton de réponse qui présente une boîte d'édition pour la PropositionFacile. ZWiki a simplement une boîte d'édition sur chaque page. PeterMasiar? a créé un module de commentaires pour TWiki [1] [2].

Au moment d'utiliser des pages de commentaires avec OddMuse [3], toutes les pages sans commentaires ont un lien en pied de page vers la page de commentaire correspondante. Sur la page de commentaire, les commentaires existants sont affichés, et une aire de texte vous permet d'écrire un nouveau commentaire, et de signer avec votre nom. Au moment de sauvegarder le commentaire, le nom d'utilisateur et l'heure en cours sont fournis au pied de la page de commentaire comme une édition mineure.

Un exemple est disponible sur la page personnelle d'Alex : [4]

1.2. Éditer les pages quand vous les voyez

Peut-être que c'est simplemnet une limitation technique des wikis fondés sur le navigateur. Dans un monde idéal, vous pourriez simplement éditer une page au moment où vous la voyez. Un WikiBrowser indépendant pourrait faire ceci.

Si vous utilisez EmacsWiki:SimpleWikiEditMode, alors Emacs affichera le texte brut dans une mémoire tampon, où vous pouvez lire et éditer la page. Ceci requiert des wikis qui supportent un RawMode étendu.

Une solution similaire peut être implémentée en utilisant JavaScript. WhyClublet vous permet d'éditer une page en double-cliquant n'importe où sur la page, ce qui est une autre solution possible. Parce que cela viole les attentes de l'interface utilisateur des utilisateurs de navigateurs, ceci pourrait être moins idéal.

1.3. Ajouter un contenu à la fin d'une page

Au moment d'ajouter du contenu à la fin de la page, les personnes "ajoutent un commentaire". Voir PageCommentaire. Un raffinement potentiel est un bouton réponse en haut et le bouton bien connu d'édition en bas de page. Pour de nouveaux utilisateurs, "Répondre" est évident. "Éditer" requiert plus de réflexion, on le réserve aux vieux routards. Ceci pourrait encourager néanmoins les commentaires du style "Moi aussi !" Naturellement, ce n'est peut-être pas une mauvaise chose. Au moins, cela vous donne quelque réaction si vous faites tourner un bloc-notes (blog).

WhyClublet a le bouton Reply qui fournit à la page une règle horizontale, votre texte suivi de votre signature (c'est à dire, pseudo-structuré le long des lignes du MessageAdresséEtSigné? - AddressedAndSignedMessage). Ce comportement encourage vraiment la discussion, ce qui serait très adapté pour un WikiLog.

1.4. Fil de discussion

Peut-être que les utilisateurs s'attendent à une certaine forme de fil de discussion -- par ex. tous les commentaires qui sont ajoutés peuvent être identifiés par un en-tête, et vous pouvez commenter sur chacun d'entre eux, et votre commentaire sera inséré dans la position appropriée, avec une indication visuelle du fil (indentation par exemple). Le bouton "répondre" mentionné ci-dessus n'est pas approprié pour ça ; il encourage un style de commentaires ala weblog sans limiter les utilisateurs à cela. C'est un raccourci, rien d'autre.

Les discussions organisées par fils pourraient être produites plus à la manière wiki en autorisant le réarrangement de l'arbre du fil. Par exemple, un sous-fil à propos d'un sujet plus spécifique pourrait être cassé et placé dans une page différente, ou deux sous-fils séparés sur le même sujet pourraient être fusionnés.

Voir aussi et traduire ThreadingForWiki.

Deux wikis incorporent le concept d'une hiérarchie de page. Celles-ci sont normalement représentées comme des miettes de pains (petits cailloux) en haut de la page. Elles incluent la facilité de transférer la hiérarchie. Je suis sûr ici qu'il y a des leçons à tirer de ces wikis.

Idée: Maintenant, si chaque commentaire était sa propre page (ou plus proprement, un noeud), ils pourraient être alors arrangés ou réarrangés comme demandés. Tout ce dont vous auriez besoin à la fin est de programmer pour donner la capacité à une page maître d'annexer tous les noeuds enfants en une page-client globale.

1.5. Ajouter du contenu au sommet d'une page

Si le contenu est ajouté au sommet, alors cela modifie la sémantique -- au lieu d'être un commentaire, c'est une nouvelle entrée dans un weblog. Un nouveau sujet, un nouveau billet. Peut-être qu'une telle chose n'est seulement exigé que pour la page d'accueil.

1.6. Insérer un bouton "commentez ici"

Supposez un nouveau tag qui crée un bouton vous permettant d'ajouter quelque contenu, là où se trouve le bouton. Alors vous pourriez disposer de ce bouton en haut ou en bas, ou après chaque post.

Cliquer sur le bouton pourrait soit vous mener à un formulaire d'édition vierge, ou faire surgir un formulaire d'édition en pop-up de façon à ce que le contexte orginal soit toujours disponible. Le commentaire inséré pourrait être affiché comme un paragraphe indenté.

Bien sûr, vous pouvez encore cliquer sur le bouton d'édition générique et vous pouvez aussi effacer ou modifier tous les tags "ajouter un commentaire ici" (ou les commentaires) que vous ou les autres ont écrits.

Il semble que cette solution soit la plus flexible. (ndt : voir exemple sur CraoWiki:AjouterDesCommentaires)

1.7. Etiquette de liste

Une autre idée pourrait être de créer un nouveau tag pour une liste spéciale (comme la liste à puces) mais quand cette liste est affichée un bouton "répondre à" est ajouté aux entrées de la liste. Au moment d'appuyer dessus, le bouton "répondre à" vous ouvre un formulaire d'édition vierge. Après le post, le contenu est ajouté à la liste avec un niveau d'indentation supérieur. Ceci pourrait permettre le fil. La liste est encore éditable comme une liste normale. Même si implémenter cela d'une façon satisfaisante pourrait être difficile. (On doit parser la liste pour trouver le bon point d'insertion...).

1.8. Editer un lien au sommet

La fonctionnalité suivante est sans rapport à l'endroit où le contenu est ajouté :

Créer un bouton éditer sur la barre de liens au sommet serait encore plus évident pour le nouveau venu.

En outre, ceci faciliterait aussi la tâche pour les vétérans. Souvent je vois quelque chose en haut de la page qui a besoin d'être modifié/rédigé... puis je dois scroller tout en bas vers le pied de page pour trouver le lien d'édition. Alors, en voyant que la page est longue -- je suis dissuadé de contribuer là où j'étais initialement motivé pour contribuer... après tout, je devrais lire l'ensemble de la page, n'est-ce pas ? Pas nécessairement. Ce serait bien d'aider le lecteur à passer en mode édition dès qu'il se sent motivé. Le lien éditer en haut diminuerait le besoin exigé de scroller pour faire ça.

Quelques personnes apprécient la facilité. Si cela encourage les pages plus courtes parce que les auteurs savent que les lecteurs ne liront pas la totalité de la page, nul ne sait.

1.9. Editer de longues pages reste indigeste

Si une page qui est longue ne vaut probablement la peine d'y contribuer. Y ajouter du contenu, disons pour contrecarrer quelque discussion, cela peut sembler important, mais vraiment cela importe peu. Si vous ne pouvez pas produire suffisamment de sens à cela qui vous dissuade de rajouter, aucun lecteur ne pourra produire suffisamment de sens à cela pour comprendre votre contribution. Ceci ne suggère absolument pas que votre contribution n'a pas de valeur ; l'opposé est vrai. J'insinue que la page n'a pas de valeur. Naturellement le seul moyen de s'en sortir est un remaniement judicieux.

2. Faciliter la création de nouvelles pages

Une autre chose à étudier est un bouton "Créer un Nouvelle Page". La procédure actuelle d'édition d'une page, est d'ajouter un lien, de sauvegarder puis de cliquer ce lien, de l'éditer et de le sauvegarder. Cela semble représenter beaucoup trop de travail. La technique "avancée" d'éditer l'URL est difficile à expliquer clairement.

Peut-être que la facilitation de création de nouvelles PagesOrphelines devrait être découragée.

2.1. Implémentations Existantes

Le commentaire et la création de pages ont été joliment mélangés sur Wiki:ChiqChaq. Il y a une aire de texte en bas de chaque page pour une proposition facile. Au-dessus de cette aire de texte, une boîte texte contient le titre de la page en cours. Si vous modifiez le titre dans cette boîte de texte, le texte dans l'aire de texte est ajouté vers une nouvelle page.

La page personnelle d'AlexSchroeder [5] utilise les liens d'une DatePage pour les deux derniers jours dans la barre de liens. Les pages-dates agissent comme des entrées dans un JournalEnLigne. 

 Avoir les deux liens toujours disponibles facilite la création de nouvelles pages pour les auteurs.

2.2. Magicien de création de Page

Idée : Deux écrans avant la page d'édition -- quand on clique sur le lien "créer page", la première page aurait une description succinte des WikiNoms (avec des exemples) et un peu de texte générique sur les bons noms de pages. Une boîte unique d'entrée pour entrer le nom suivrait le texte.

Le prochain écran vérifierait que le nom saisi est valide et n'existe pas déjà (avec quelques explications si c'était le cas). Il afficherait ensuite une recherche par titre pour chacun des sous-mots de la nouvelle page nom. (Par exemple, si l'utilisateur entrait "WikiSuggestion?", il chercherait pour "Wiki" et "Suggestion" dans le titres.) Serait demandé à l'utilisateur de regarder la liste pour voir si quelqu'un a déjà créé un nom similaire ou approchant.

Si l'utilisateur veut encore créer la page, il cliquerait sur un lien pour aller vers la page en mode édition, probablement avec un texte supplémentaire d'aide (comme un aide-mémoire pour sauvegarder le texte).

2.3. Magicien pour créer une page personnelle

Une autre possibilité serait d'adapter le lien "créer page" pour un lien spécial "ajoutez votre nom" ou "créez votre page personnelle". Ce serait vraiment le même, même s'il y aurait quelques cas spéciaux (comme du texte à propos du fait d'ajouter son initiale/nom du milieu si quelqu'un a déjà pris la combinaison prénom+nom).

2.4. Les magiciens sont trop gras

Ceci semble conçu pour décourager la création de nouvelles pages en faisant qu'il paraisse trop compliqué. Nous avons déjà les moyens d'accomplir la création d'une nouvelle page, avec l'assurance supplémentaire que la page ne sera pas créée comme une orpheline. Il semble que nous ayons besoin d'enseigner aux personnes comment utiliser les outils disponibles.

La plupart des personnes n'ont pas de problème à suivre les instructions dans quelque chose comme [How to Join]. Je ne suis pas sûr que quelqu'un qui aurait des problèmes à comprendre les fondamentaux bien expliqués serait un membre productif d'une communauté wiki. Élitiste, je sais, mais il existe des standards pour rejoindre n'importe quelle communauté.

3. Gabarits

Observé sur un wiki MoinMoin hier le concept de gabarits de pages. Regardez-le fonctionner avec cette page encore non créée : http://diveintoosx.org/CreatingNewPage.html

Semble très simple, très pensé utilisateur.

4. A propos de Meatball

Le consensus en cours semble être que MeatballWiki n'a pas besoin de tout cela.

RichardDrake (éditeur de WhyClublet) et moi-même ont des philosophies complètement différentes envers les wikis (et leurs vies). Richard préfère toujours un style weblog ou "bloc-notes web" plus en mode discussion. Je préfère réduire les fils de discussions à leur plus simple expression (parfois des fils plus courts) u ne fois que tous les points de vue ont été séparés. Je me soucie vraiment de la manière dont le site sera lu dans cinq ans, mais Richard est plus intéressé pour s'assurer que le présent soit réellement excitant. Je pense que le bouton de réponse implique que vous ne soyez pas responsable de la maintenance du reste du site. Je ne veux pas rendre les contributions plus faciles pour les personnes pour qu'elles ajoutent des fils de clavardages que je devrai surveiller et nettoyer. Pour un wiki plus clavardeur, ce peut être pensable. Mais est-ce que MeatballWiki se veut tout simplement se définir comme un coffee club ? -- SunirShah

Je crois que chaque communauté a besoin de communication sous forme de clavardage, et cette communication n'a pas besoin d'être remaniée,
c'est un moyen pour produire le vrai résultat - le document. Ainsi il y a un peu de perte quand après un long moment cette communication n'est pas facilement lisible. Le combat pour tout remanier est une erreur à mon sens. Mais ensuite il devrait y avoir une distinction claire entre la conversation temporaire et le document principal. Je crois qu'une discussion forum sous forme de fils attachés à chaque page wiki serait là une solution optimale. -- ZbigniewLukasiak

En utilisant le principe de l'exclusion, cela veut dire que nous ne voulons vraiment pas de fonctionnalités de type WikiLog. Nous ne voulons pas utiliser le ModeDiscussion. Nous voulons encourager le nettoyage des pages. Une solution de communauté est bien suffisante.

PeterMasiar? a dit ailleurs, "Les fils sont bien pour les discussions, puis remaniez-les, mais mes utilisateurs ne veulent pas remanier mais ils commenteront. Commenter est une permission wiki pour mes utilisateurs" ce à quoi SunirShah a rétorqué, "Oui, cela dépend de votre audience-cible. Vous pouvez simplement faire que quiconque écrive en mode document, ce qui est bien pour MeatballWiki où nous sommes des experts." Bien sûr, tout le monde ici n'est pas un expert, mais nous sommes ici pour enseigner.

Bouton "Insérer Commentaire ici"

Dans le contexte du projet UniversityWiki, nous discutons des moyens d'encourager la participation. Un de nos groupes nous a rapporté qu'éditer l'ensemble de la page était pour lui une barrière psychologique. Comme solution possible, nous en sommes venus à mettre un bouton "Editer" sur chaque paragraphe, un bouton qui charge la page à nouveau avec le paragraphe spécifique remplacé par une boîte d'édition et quelques contrôles et suggestions. [Aujourd'hui, je navigue à travers meatball et tombe par hasard sur cette page. La vie est amusante.] Que pensez-vous de cette idée ? -- DavidSchmitt

Cela ressemble à mettre plein de boutons sur une page. -- AlexSchroeder

Un par en-têtes ? Ensemble avec une section Commentaire, qui résoudrait le problème de la peur d'éditer l'ensemble de la page, n'est ce pas ? (cf PeurDEditerTouteLaPage? - traduire FearOfEditingTheWholePage?)-- David

Personnellement, j'ai choisi d'implémenter les PageCommentaires. Cela m'a semblé offrir le meilleur compromis pour ajouter du contenu qui semble "moins important" (pour diminuer la peur) et qui ressemble à des billets plus traditionnels incluant le nom d'utilisateur et le timbre chronodaté (réduction de l'effet gadget). -- AlexSchroeder

Oui, les pages commentaires sont jolies et faciles. Pendant ce temps, j'ai fait un clou HTML sur [6] pour éditer un chapitre. C'est vraiment bête, le seul lien qui fonctionne est "Persönliches" -> "Ändern" [7], pas de sauvegarde. Désolé mais le seul lien qui fonctionne est en allemand, mais j'ai copié l'original à partir du DseWiki:DavidSchmitt. Qu'en pensez-vous ? -- DavidSchmitt

Sur le fait d'ajouter un commentaire après une page : Cela vaut la peine de noter qu'utiliser un ajoutez-un-commentaire plutôt qu'un bouton éditer-cette-page a un avantage clair : vous ne pouvez pas écraser le commentaire de quelqu'un d'autre par accident. MeatBall permet à quiconque de revenir en arrrière et réparer les collisions, mais ce n'est pas vraiment amical et agréable pour l'utilisateur qui vient pour la première fois. Vous pouvez toujours ajouter un commentaire si vous n'avez pas rafraîchi la page depuis 1000 ans. (Cela ne sera tout simplement plus pertinent). Définitivement utile pour un schéma de PropositionFacile.

C'est aussi allemand d'ajouter cette caractéristique à un wiki toujours-ajouter-un-commentaire qui cohabite avec le recouvrement de conflit de versions sur éditer-la-page. Voilà un exemple :

Le désir du pauvre Utilisateur 1 est probablement d'ignorer les commentaires qu'il n'a pas vus -il n'y a certainement pas de conflits en édition. Par conséquent, nous ajoutons simplement le commentaire de l'Utilisateur 2 à la nouvelle page de l'Utilisateur 1. Ceci fonctionne toujours.

Ceci aiderait à maintenir une wiki théoriquement réactif même quand beaucoup de personnes commentent sur quelques pages avec un haut niveau de fréquence, et ceci permettrait aux éditeurs fondateurs de soumettre les modifications sans avoir besoin de copier de manière répétée les nouveaux commentaires avant qu'une proposition ne réussisse (ou pire de simplement les passer au rouleau compresseur).

Toute résolution de conflit requiert un peu de connaissance de la part des utilisateurs pour comprendre ce qui se passe. Ajouter un commentaire ne nécessite pas une résolution de conflit. L'aspect le plus technique du problème est discuté sur ConflitEdition.

-- ChrisPurcell

Je note que SocialText a une belle fonctionnalité d'e-mail. Chaque "espace de travail" SocialText a une adresse e-mail. Si vous êtes un utilisateur enregistré de cet espace de travail, et si vous envoyez un e-mail vers cet espace de travail, le sujet de cet email est utilisé comme le nom d'une nouvelle page wiki. Si des emails ultérieurs sont reçus avec le même sujet (comme Re : et Fwd :) ils seront ajoutés en haut de cette page wiki. Si vous mettez comme première ligne de votre email 'append: bottom' le contenu de votre email sera ajouté au bas de cette page wiki.

La section 1.7 ci-dessus (balise spéciale pour un billet de discussion) semble être une bonne idée. Elle présentera quelque discussion bien connue sur la structure du forum de discussion pour les nouveaux venus, sans perdre la flexibilité du wiki. Est ce que quelqu'un a essayé d'implémenter quelque chose comme ça ? Je vois que [community wiki a un tag spécial 'new'] pour un affichage spécifique des billets de discssions, mais ce serait intéressant de voir des liens/boutons 'répondre' dans une discussion wiki. Imaginez être capable de cliquer sur 'répondre' juste après ce message. Pourrait tout à fait bien fonctionner selon moi. -- HarryWood

TwikiClone avait quelque chose comme çà à un moment, mais je n'ai plus d'idées où pouvoir le retrouver. -- Sunir

LangueFrançaise PageTranslation EasySubmission [DossierTechnologieWiki] [DossierWeblog] [DossierTechnologieWikiNoncommune]

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: