[Home]MakeWikiMoreAccessible

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Background

I'm a member of a club that currently has a very poor turnout, web-wise -- no newsgroups or mailing lists, and virtually no webpages even though the club has nearly a thousand members of which a high percentage have web access (or at least email addresses).

I'd like to change that, and I thought that setting up a WikiWikiWeb would be a nice way to ease them into the InformationAge?. The problem is that I suspect that most of the members aren't particularly computer literate and I don't want them to think it is overly complex and be put off at the first page: in short, I need to flatten the learning curve.

I have a few ideas of my own, but I'd really like to hear what you lot think.

My thoughts on the matter

I feel that the moment I manage to get someone to sign RecentVisitors and create a homepage will be the moment that that person realises that it's not that complex after all. Most of my ideas are therefore geared towards this goal.

Obviously the content is going to be vital for easing people into the WikiWay, but there are other issues:

Well, those are my random ideas so far. Simplistic I know, but such is often the way. Comments please! -- GaryBenson

Check the Home Page here http://allmyfaqs.com/cgi-bin/wiki.pl?HomePage for some approaches to eliciting participation. Try the Special Page for First-Timers and Newbies link. JerryMuelver

CategoryMeatballWikiSuggestion


One of the strengths and weaknesses of wikis is that they are a bit daunting, especially because trust is so foreign to people. "What do you mean anyone can edit them? Do you have to log in? Doesn't that mean anyone can destroy them?" One of the reasons Wiki:WhyWikiWorks apparently is that the WikiSyntax is bizarre (although it seems fairly easy to understand to me).

But once you start, they're pretty easy to use. The real learning curve is how to write effectively, especially in a hypermedium. Or even on a wiki. A lot of people try bringing assumptions from other media here, and that works out badly. For instance, frequently I see people pointlessly dating their comments like a message system. Or I see people making a lot of shallow pages to define terms; definitions are usually better explained where the word is used. English is powerful. Not to say I'm very good at writing.

As to some wiki writing idioms, see StyleGuide.


Unfortunately, some wikis have no "difference" facility. In order to facilitate discussion I've taken to using timestamps. Yuk. I should probably go through and clean them out once they've aged enough. -- anon

The Visual Foxpro wiki (FoxWiki:RecentChanges) rather nice approach to pointing out new content. They have a macro #N# which expands to a fading "[NEW]" text. It stores the timestamp of the edit in the document, and shows the [NEW] as red for a day or so, then orange for a few days, and finally removes it from the display. See FoxWiki:SqlVsDbf for a sample (until about December 9, 2000).

Easy diff display is actually a recent feature for many wikis. The C2 wiki had the diffs on the "editcopy" page (two links away from the normal page) until early 2000 (late 1999?). I prefer diffs, but I admire many of the Fox-Wiki adaptations. --CliffordAdams


One feature I've considered in the medium-term (few months) is an easy "submission" form for editing. The basic idea would allow users to simply submit to the site in general, and allow volunteer editors to decide placement, naming, formatting, and other editorial decisions.

For instance, suppose the original author had some ideas about wiki tutorials for new users, but wasn't sure where to put them (or even if the content was appropriate for the local site). With a submission system the user could simply write their content, and rely on more experienced wiki authors to find a good place for it. It would also be a good way to welcome people to the community, by showing that their contributions are welcomed (and not just tolerated).

Another possibility would be a "draft" status of a page, which would flag the page as incomplete and needing more work. Users could create new draft pages easily, but only those people who volunteer as editors would see them. (The drafts would be somewhat like "minor edits"--hidden by default but visible on request.)

There are a lot of good wiki ideas out there. Hopefully I can make a few of them real. --CliffordAdams

If you could fill in the description of "DraftSubmission?" (or whatever) and stick it in the appropriate places, that would be cool.

What more do you need? Maybe a link on the link bar. Or you could so something like Why's reply button, but only to the DraftSubmission? page. I'm not sure about these additions. They would change the flow of the community. People take the path of least resistance, after all.

Keep in mind that when we get PageDeletion, this kind of thing would be almost automagic. Just whack some stuff in somewhere. Except of course that if I write something in the morning and I come back in the evening, I have the unfortunate problem of trying to find it again. -- SunirShah


On the tutorial side, I think the best one would be an interactive tutorial that led people step-by-step through editing a temporary wiki (or maybe just a fake wiki). It would take more than 5 minutes, but it would allow people to thoroughly learn by doing. For instance, a section on wiki linking might have a screen like:

Linking to other sites:

You can easily include links to other sites in your text. Just type the full URL as it appears in your browser's "address" or "URL" line, like http://www.usemod.com/, and the wiki will automatically turn it into a link. Note that common punctuation at the end of a URL will be separated from the link (such as the comma in the previous example). See AdvancedLinkFormatting for more options like displaying custom link text on the resulting page.

A few sample links are provided below. You can edit these links (or add your own) and press Preview to see the results.

[Small 5-10 line text area with a few sample links pre-entered]
[Preview button. (Pressing preview returns to this page)]

Preview Results:

[Shows wiki-rendering of text in box above, updated if user presses preview.]

Related links: [list of related formatting/linking pages]

Previous: WikiNames Next: InterWiki

. . .

Hmmm... This is sounding better and better. I could probably even mostly implement it as a wiki, adding a little extra markup like <samplebox>[text that is initially displayed in the textarea]</samplebox>. Advanced users could follow a special link (or add something to the URL) to edit the help-page, or maybe turn on an "advanced preference" to show edit-links on help pages.

Something like this could be part of UseModWiki 0.92 (early 2001) or 0.94 (later). (Another possiblity is to extend the multi-wiki concept slightly and allow a mini-farm of wikis. One of these could be the help wiki.) --CliffordAdams

Was it Helmut or John who had started a wiki tutorial? Someone know?


I was thinking about having a kind of two stage approach for the tutorial: a FiveMinuteGuide? is probably fifty times more likely to be followed than a HalfHourGuide?. Once they have done their five minutes and made their own homepage, then they will be inclined to follow the AdvancedTutorial? at a later date. IMO anyway! (So I finally got the site running; comments on [GtmWiki:WikiInFiveMinutes] would be appreciated. -- GaryBenson)

This is particularly relevant in the UK (where the club is based) since dialup access is expensive and DSL is nonexistant as such.

The easy submission form could be semi-implemented by having an ImNotSureWhereThisShouldGo? page which people can add bits to. Editors could then cut and paste the text into a new location. Not perfect, I know, but it's a start... -- GaryBenson

see also: Wiki:OneMinuteWiki, Wiki:OneDayWiki, Wiki:OneMonthWiki, Wiki:OneYearWiki


Guiding principle (suggested)

One problem often faced by people when trying to get people to participate is that they don't say how someone is supposed to participate. We've all been told that our input is valuable, but we are rarely told how to make out points heard. Moreover, people need clear mechanisms. Therefore, state step by step the ways people can act, as if they were automatons. Guiding principles, such as this one, are nearly useless because it's too easy to get lost following through. "Ok, but now what?"


I agree wholeheartedly with the above anonymous comment. I've been spending a bit of time going through various wikis' introduction pages to try and collate the important points that people new to the concept will need to understand.

On another note, earlier in this discussion I said something along the lines of `the EditText? button' rather than `the EditText? link'. While SunirShah quickly pointed out the error of my ways, it got me thinking.

Okay, I've been doing dynamic web stuff (mostly on a small scale) for some years, and I'm happy with the idea that links and buttons do the same kind of thing really, but what does the innocent virgin computer user new to the web see? In their eyes, there is clear distinction between

It's semantic I know but perhaps, just perhaps, new wiki users would respond better to an EditText? button than an EditText? link.

-- GaryBenson

That's a good point. I'd still force upon you the necessity to use FORM buttons.

<form action="http:mb.pl?action=edit&id=LinkPattern" method="get">
  <input type="submit" value="Edit this page" />
</form>

Might be superior to the current "Edit text of this page" link.

If one is concerned about link/button consistency, the SampleUndefinedPage? link (the question-mark) would also become an issue. Things are different in wikis (hopefully better), and I think that users may need to adapt slightly.

Unfortunately, one messy reality about current browsers is that they often render forms quite differently. For instance, in UseModWiki, the bottom linkbar on a page is within the search form. This is done because MSIE 5 renders a blank line at the beginning of a form, and it looked truly ugly with a blank line between the "edit this page" line and the search entry field. (I tried other combinations, and settled on the current one.) You can also try enclosing the form in a table with border=0, cellspacing=0, cellpadding=0; that also gets rid of the blank line, at least on IE5 on Mac.

Starting with 0.90, the edit-text line will become: "Edit text of this page | View or edit other revisions", with the second link showing the history of the page (with view/edit/diff links for the older versions). See

Everywhere you want to insert a form button (with a separate action), imagine a blank line above the form. I could just use different values of one single form, but I like having separate URLs for separate actions. --CliffordAdams

Why not add a bit of CSS to turn the form into an inline element?

form { display: inline; }
-- JohnKugelman

I've tried that on my wiki. Not all browsers apply that rule to forms. - tarquin


Other suggestions: EasySubmission, AutomaticHomepage


Near the top of this item, there's the comment "frequently I see people pointlessly dating their comments like a message". I take it this is not in the spirit of Wiki, but why? -- PaulHolbrook

Would there be any point to you dating your question here Paul?


A very small summary of the most useful TextFormattingRules should be present on every edit page. PhpWiki does this. It's helpful for those unfamiliar with the WikiSyntax.

It would be nice if Meatball did it too (hint hint) -- GaryBenson

WakkaWiki? also summarizes a few TextFormattingRules on the edit page. Nice. While editing: Sometimes I open a new window on the full TextFormattingRules. Occasionally I open a new window with the current InterMapTxt. It would be convenient for me if there were links to those on every edit page. -- DavidCary


Discussion

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