[Home]EasySubmission

MeatballWiki | RecentChanges | Random Page | Indices | Categories
This is is one of the ideas to MakeWikiMoreAccessible. This particular page collects ideas that make adding new content easy for new users.

1. Facilitate adding content to a page aka. adding comments
1.1. Existing Implementations
1.2. Edit pages as you view them
1.3. Add content at the end of a page
1.4. Threading
1.5. Add content at the front of a page
1.6. "Insert comment here" button
1.7. Special list tag
1.8. Edit link at the top
1.9. Editing long pages adds bloat
2. Facilitate creation of new pages
2.1. Existing Implementations
2.2. Page creation wizard
2.3. Create homepage wizard
2.4. Wizards are bloat
3. Templates
4. About Meatball

Contributors: HansDonner?, SunirShah, AlexSchroeder, CliffordAdams, JerryMuelver, Wiki:YonatSharon, EricScheid, MatthewSimpson, BayleShanks, SteveHowell

1. Facilitate adding content to a page aka. adding comments

Can wikis be combined with WebLogs? See WikiLog.

One of the differences that it is psychologically easy to add a comment to a weblog, but hard to edit a page in a wiki. Offering easy submissions makes it easy for new users, while maintaining wiki editing powers for advanced users.

1.1. Existing Implementations

WhyClublet has a reply button which presents an edit box for EasySubmission. ZWiki just has an edit box on every page. PeterMasiar? has created a Comment module for TWiki [1] [ http://twiki.med.yale.edu/twiki2/bin/view/Sandbox/TestTalk].

When using [comment pages with OddMuse], all non-comment pages have a link in the footer to the corresponding comment page. On the comment page, the existing comments are shown, and a textarea allows you to write a new comment, and sign your name. When saving, the comment, the username, and the current time is appended to the bottom of the comment page as a minor edit.

[Example available on Alex's homepage]

1.2. Edit pages as you view them

Perhaps this is all just a technical limitation of browser-based Wikis. Ideally, you could just edit a page as you view it. A stand-alone WikiBrowser could do this.

If you use EmacsWiki:SimpleWikiEditMode, then Emacs will display the raw text of the page in a buffer, where you can read and edit the page. This requires wikis that support an extended RawMode.

A similar solution can be implemented using JavaScript. WhyClublet allows you to edit a page by double-clicking anywhere on it, which is another possible solution. Since this violates user interface expectations of browser users, this might be less ideal.

1.3. Add content at the end of a page

When adding content at the end, people "add a comment". See CommentPage. A potential refinement is a reply button at the top, and the well-known edit button at the bottom. "Reply" is obvious, for newbies. "Edit" requires more thought, for oldbies. This might encourage "Me too!" style comments, however. Perhaps that is not a bad thing, of course. At least it gives you some feedback if you are running a weblog.

WhyClublet has the Reply button, which appends to the page a horizontal rule, your text, followed by your signature (i.e. pseudo-structured along the lines of AddressedAndSignedMessage). This behaviour greatly encourages discussion, which would be very suitable to a WikiLog.

1.4. Threading

Perhaps users expect some sort of threading -- i.e. all comments that got added can be identified by some heading, and you can comment on each one of them, and your comment will be inserted at the appropriate position, with visual indication of threading (indentation, for example). The reply button mentioned above is not suitable for this; it encourages weblog style comments without limiting users to it. It's a shortcut, nothing else.

Threaded discussions could be made more wiki-like by allowing rearrangement of the thread tree. For instance, a sub-thread about a more specific topic could be broken off into a different page, or two separate sub-threads on the same topic could be merged.

See also ThreadingForWiki.

A couple of wikis incorporate the concept of a page hierarchy. These are normally represented as a bread-crumb at the top of the page. They include the facility to re-assign hierarchy. I'm sure there would be some lessons to be learned from those wikis.

Idea: Now, if every comment was it's own page (or more properly, node), then they could be arranged and rearranged as needed. All you'd need at the end is to cook in the capability for a master page to append all child nodes into one whole client-page.

1.5. Add content at the front of a page

If the content is added at the front, then it changes the semantics - instead of being a comment, it is a new entry in a weblog. A new topic, a new posting. Perhaps such a thing is only required for the front page.

1.6. "Insert comment here" button

Assume a new tag that creates a button that allows you to add some content right there, where the button is. Then you could have this button at the top or at the bottom, or after every posting.

Clicking on the button could either take them to a blank edit form, or pop up an edit form so that the original context was still available. The inserted comment might be displayed as an indented paragraph.

Of course you can still click the regular page edit button, and you can also delete or change any "insert comment here" tags (or comments) you or others wrote.

It seems that this solution would be the most flexible one.

1.7. Special list tag

Another idea might be to create a new tag for a special list (like the bullet list) but when this list is rendered a "reply-to" button is added to the entries of the list. When pressed, the reply-to button gives a blank edit form. After its posting, the content is added to the list with a higher indentation level. This could allow threading. The list is still editable as a normal list. Though implementing this in a satisfying way might be hard. (One needs to parse the list to find the right insertion point...)

1.8. Edit link at the top

The following feature is unrelated to where exactly the content is added:

Creating an edit button on the top link bar would make it more obvious to the newbie. Plus, it would make it easier for the wiki veteran. Often I see something at the top of a page that I need to edit/author... then I have to scroll all the way down to the bottom of the page to find the edit link. Then, seeing that the page is long -- I am dissuaded from contributing where I was initially motivated to contribute... after all, I should read the whole page, right? Not necessarily so. It would be good to help the reader switch into edit mode as soon as they are motivated to. The edit link at the top would decrease the scrolling needed to do this.

Some people enjoy the convenience. Whether this encourages more short pages since authors know that readers will not read the entire page, nobody knows.

1.9. Editing long pages adds bloat

If a page that is long is likely not worth contributing to. Adding to it, say to counter some argument, may seem important, but really it doesn't matter. If you can't make enough sense of it that are you dissuaded from adding to it, no reader will be able to make enough sense of it to comprehend your addition. This does not suggest that your contribution has no value; the opposite is true. I am suggesting that the page has no value. Naturally the only way out is judicious refactoring.

2. Facilitate creation of new pages

Another thing to consider is a "Create A New Page" button. The current procedure of editing a page, adding a link, saving, then clicking that link, editing, and saving just seems too much like work. The "advanced" technique of editing the URL is difficult to explain clearly.

Perhaps easing creating new OrphanedPages should be discouraged.

2.1. Existing Implementations

Commenting and page creation has been nicely combined in Wiki:ChiqChaq. There is a textarea at the bottom of every page for easy submission. Above this text area, a textbox contains the current page title. If you change the title in this textbox, the text in the textarea is added to a new page.

[AlexSchroeder's homepage] links DatePages for the two last days in the goto-bar. The date pages act as entries in an OnlineDiary. Having the two links always available makes creating new date page easy for the author.

2.2. Page creation wizard

Idea: Two screens before the edit page -- when one clicks on the "create page" link, the first page would have a short description of WikiNames (with examples), and some general text about good page names. A single entry box for entering the name would follow the text.

The next screen would verify that the entered name is valid and does not previously exist (with explanations for these cases). It would then show a title search for each of the sub-words of the new page name. (For instance, if the user entered "WikiSuggestion?", it would search for "Wiki" and "Suggestion" in the titles.) The user would be asked to look at the list to see if someone has already created a similar name.

If the user still wants to create the page, they would click on a link to go to the editing page, possibly with extra help text (like a reminder to save the text).

2.3. Create homepage wizard

Another possibility would be to adapt the "create page" link for a special "add your name" or "create your homepage" link. It would be largely the same, although it would have some special cases (like text about adding your middle initial/name if someone already has your first+last name).

2.4. Wizards are bloat

This seems bent on discouraging the creation of new pages by making it seem too complicated. We already have the means to accomplish the creation of a new page, with the added assurance that the page will not be created as an orphan. It seems we need only to teach people how to use the available tools.

Most people have no problem following the instructions in something like the now-defunct AllMyFaqs?' How to Join. I'm not sure someone who would have trouble figuring out well-explained basics would be a productive member of a wiki community. Elitist, I know, but but there are standards for joining any community.

3. Templates

Observed on a MoinMoin wiki yesterday was the concept of page templates. [See it in action with this as-yet-uncreated page].

Looks very simple, looks very user friendly.

4. About Meatball

Current consensus seems to be that MeatballWiki doesn't need any of that.

RichardDrake (editor of WhyClublet) and I have completely different philosophies to wikis (and life). Richard always prefers a more threaded, weblog style. I prefer to reduce threads to their simplest forms (sometimes shorter threads) once all the viewpoints have been sorted out. I really care about how the site will be read in five years, but Richard is more interested in making sure the present is really exciting. I think the reply button implies that you aren't responsible for maintaining the rest of the site. I don't want to make it easier for people to add chatty threads that someone like myself will have to come along and clean up. For a more chatty wiki, this may be reasonable. But is MeatballWiki just another coffee club? -- SunirShah

I believe every community needs some chatty communication, and that communication does not need to be refactored, it is a mean for producing the real outcome - the document. So there is little lost when after long time that communication is not easily readable. The striving to refactor everything is a mistake for me. But then there should be a clear distinction between the temporarily chat and the main document. I believe a threaded discussion forum attached to every wiki page would be an optimal solution there. -- ZbigniewLukasiak

Using the exclusion principle, this means that we do not want WikiLog features. We don't want to encourage ThreadMode. We want to encourage the cleaning up of pages. A community solution is good enough.

PeterMasiar? said elsewhere, "Thread are good for discussion, then refactor it, but my users do not want to refactor, but they will comment. Commenting is an wiki enabler for my users," to which SunirShah replied, "Right, it depends on your target audience. You can just have everyone write in document mode, which is fine for MeatballWiki where we are experts." Of course, not everyone here is an expert, but we're here to teach.

"Insert comment here" button

In the context of the UniversityWiki project, we are discussing ways of encouraging participation. One of our group related, that editing the whole page was a psychological barrier for him. As a possible solution we came up with supplying every paragraph with an "Edit" button, which would load the page again with the specific paragraph replaced by an edit box and a few controls and hints. [Today I browse through meatball and stumble over this page. Life is funny.] What do you think about that idea? -- DavidSchmitt

Seems like many buttons on a page. -- AlexSchroeder

One per heading? Together with a Comment section, that would also address the FearOfEditingTheWholePage?, wouldn't it? -- David

Personally, I chose to implement CommentPages. That seemed to offer the best deal: Add content that seems "less important" (decrease fear) and looks like traditional posts including username and time-stamp (reduce novelty). -- AlexSchroeder

Yes, comment pages are nice and easy. Meanwhile I've done a HTML spike at [2] for chapter editing. It's really dumb, the only working link is "Persönliches" -> "Ändern" [3], no saving. Sorry that it is german, but I copied original from DseWiki:DavidSchmitt. How do you like it? -- DavidSchmitt

On adding a comment after a page: It's worth noting that using add-a-comment rather than edit-the-page has one clear benefit: you cannot possibly overwrite someone else's comment by accident. MeatBall allows one to recover from collisions, but that's not terribly friendly to a first-time user. You can always add a comment even if you haven't refreshed the page for 1000 years. (It just won't necessarily be relevant anymore.) Definitely useful for an EasySubmission scheme.

It's also germane for adding this feature to a Wiki that always-add-a-comment coexists with edit-the-page collision-recovery. Here's a sample:

The desire of poor User 1 is probably to ignore comments he hasn't seen - there is certainly no edit conflict. So we simply append User 2's comment to User 1's new page. This always works.

This would help keep a Wiki theoretically responsive even with many people commenting on some pages with great frequency, and allow the core backbone of editors to submit changes without needing to repeatedly copy new comments before a submit succeeds (or the worse sin of just steamrollering them).

Any conflict-resolution requires a little knowledge on the part of users to understand what is happening. Adding a comment doesn't need conflict resolution. The more technical aspect of the problem are discussed on EditConflict.

I note that SocialText has a nice email feature. Each SocialText "workspace" has an email address. If your are a registered user of that workspace, and you email to that workspace, the subject of that email is used as the name of a new Wiki page. If subsequent emails are received with the same subject (as well as Re: and Fwd:) they will be appended to the top of that Wiki page. If you have as the first line of your email 'append: bottom' it will append your email to the bottom of that wiki page.

Section 1.7 above (special tag for a discussion postings), seems like a good idea. It introduces some familiar discussion board structure for the newbies, without losing wiki flexibility. Did anyone try implementing something like this? I see [community wiki has a special 'new' tag] for special rendering of discussion postings, but it would be interesting to see 'reply' links/buttons in a wiki discussion. Imagine being able to click 'reply' next to this message. Could work quite well I think -- HarryWood

TwikiClone had something like this at one point, but I would have no idea where to find it. -- Sunir

CategoryWikiTechnology CategoryWebLog CategoryUncommonWikiTechnology

Discussion

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