The basic idea is to have a way to give readers the option of reading a "simple" or "summary" view of some pages.

Use Case 1: Simple view for newcomers

People who are new to a subject don't need to see the details and arguments that more experienced people do. They just need a light introduction. If they read it and understand the SimpleView, perhaps they'll want to see the more complicated version of the page later.

For example, AlexSchroeder writes summaries on NeuroWiki. NeuroWiki is written for people who are in neurosciences research, or who are about to enter neurosciences research. It's a pretty sophisticated audience. Alex has written a number of pages there that he thinks are great for new people, but that the neuroscientists might find a little too simple. He suspects that, with time, what he's written will be replaced with things the serious researchers might find more interesting. Maybe they'll take out his summary explanation, and replace it with notes on the cutting edge of research in that particular field. Yet, Alex would still like for beginners and laypeople in neuroscience to be able to benefit from his work. Perhaps the idea of SimpleView- a version of pages that are made for beginners- would be able to save his summaries? That way, new people will read the simple views, and experts would be able to ignore them.

This page is part of the MakeWikiMoreAccessible discussion, though it's more about making content accessible to new people, rather than the actual wiki technology itself.

Use Case 2: Time-saving summary

You are an avid reader of CommunityWiki. You come upon a long page with a description of a complicated feature idea. You are interested in the idea, and would be able to understand it at the expert level, but either you are not very interested, and/or you don't have much time. You'd like to just read a summary of the page. Not the in-depth, DocumentMode portion at the top of the page, but just a summary.

Related ideas

The idea of SimpleView has many analogs. It's related to the idea of seperating DocumentMode and ThreadMode text (WikiFeatures😀ocViewThreadViewSplit). HyperCard had beginning and advanced modes for users. ViewPoint had different perspectives on different pages.

You really need MobileContent of some form to do this best - the different audience's for Alex's content might reside in different places.


The notion of two (or more) distinct levels of experience and accordingly several different modes for the interface are something JefRasking? argues against in his book HumaneInterface. In this case, the designer just hasn't thought of a really good interface. The interface should require no knowledge of the user's experience. One example he gives is a configurable menu for an application, where the user can just write the names of commands into his text, and call them when necessary. To come back to your example, it would be just as well to provide a second table of contents with only the intro pages, and make sure that the intro pages only reference one page for "more information". Then the interface allows for newbies to read more as they they progress, without the system having to know whether they are newbies or not. -- AlexSchroeder

I was confused when I first read the page. After I took it apart and understood it, I rewrote it. Now- if you don't like the rewrite, you can change it, or revert it back. But I think this is a little more clearer.

I don't totally understand the response, either. I don't understand the part about writing the names of commands into text, and calling them when needed. But I think I understand what you say about the simpler table of contents. The idea is to have a table of contents for beginners, and a table of contents for advanced people, right?

Tables of contents don't seem to apply very well to wiki. I understand that a lot of wiki have pages that show you everything on them, but I rarely use them. It's like looking at all the keys in the English dictionary- it's not terribly enlightening.

What I would do is have a "lay-neuroscience" wiki. I'd have WikiNodes:WikiNodes on the expert's and the lay person's wiki. I'd write up delegations (WikiNodes:UnderstandingDelegations?) between the two, saying that newbie content goes to the lay-neuroscience wiki, and for more sophisticated exposition, the more research oriented wiki.

That solves several problems:

You could link from one simple page (in the lay-persons wiki) to five complex pages (in the experts wiki). Say, "To see what's going on in this field today, look at the expert's wiki, on pages A, B, and C to learn about X, Y, and Z."

The only objection I think wiki-citizens would have to this is, "But where'd my traffic go?!? Who's going to look at what I write, if I write it off on my own wiki?" That's a whole other conversation that I think is worth persuing, but not on this page.

-- LionKimbro

It seems to me that you really just want to separate wikis -- two separate namespaces and none of the features an imperfect namespace would offer (see WikiNameSpace). Can you explain the benefit of hosting both advanced and simple pages on the same wiki? -- AlexSchroeder

Well, wait- yeah. That's exactly what I want. I want two seperate wiki, just like you said.

So, I'm arguing against SimpleView. I don't want advanced and simple pages on the same wiki.

The only advantage I see with having them on the same wiki is that RecentChanges will keep the group integrated. The beginners and the experts would see each's operations. But while that initially would be a positive, I'd think that the two groups would want to distance themselves later.

I thought you were arguing for SimpleView..? -- LionKimbro

Haha. :D No, BayleShanks wrote the original proposal. My claim was that differentiating between two groups of users (beginners and experts), and presenting them two different interfaces, is bad usability. The hypothesis is that the two interfaces can be unified into a better interface that serves both user groups equally well. The point for wikis is that it should be possible to accomodate both beginners and experts, given the right design choices. One such choice might be that beginners will not be interested in recent changes anyway. -- AlexSchroeder

Ha! I figured you, Alex, were the person who wrote it, because you were the person in the example. But I was wrong.

Regarding beginners and RecentChanges- I can imagine beginners being interested in RecentChanges. If I came across a beginners wiki, and I was learning, I would want to help build the tutorials, pages, and problems to solve. Things like that. Things that help both my understanding, the understanding of others, and my own understanding later when I've forgotten and need to get back into it.

I hope that, one day, there is a linear algebra wiki- A linear algebra wiki for people learning linear algebra. Then I can put my nifty way of visualizing matrix multiplication into it.

-- LionKimbro

I now agree that in the example given above, you would want two different wikis, coupled in the way that CommunityWiki is coupled to MeatballWiki.

When I wrote this page, my concern for that solution that the two communities would grow apart; the same things would have different page names, there wouldn't be a constant flow of experts writing the beginner pages, and most importantly, it would be hard for expert content to be reused in the beginner wiki when it was appropriate. Also, there would be many things for which there would be no "beginner" view written, in which case the beginners should just see the "expert" view.

Now, however, with SisterSites, NearLinks, and the possible future advent of MobileContent transport tools, these don't seem like problems anymore. The only thing I would add right now is that you need a way to follow the NearLink to the expert wiki, and then have the expert wiki remember that you are a beginner and send you back to the beginner wiki when you ask for a page for which a beginner view exists.

I don't see this solution as different from the idea of SimpleView, however. The user sees one wiki structure where each page has two views. This is an implementation of SimpleView.

I'd like to note that "beginner trying to learn the subject" isn't the only use case for the idea, though. See "time-saving summary", above.

Also, I disagree with Raskin that the two interfaces can be unified into a better interface that serves both user groups equally well (but I haven't read the book). It seems to me that the best interface for different groups of users, with different levels of knowledge and different tasks which they want to accomplish, will often be different. Maybe in some cases there will happen to be a happy coincidence, but I wouldn't think this would happen too often.

-- BayleShanks

hmm, this page needs a rewrite, there are 2 differents things here:

By this I mean to 2 different modes to operate the wiki, one for beginers, one for experts. The first one for instance can hide the edit link. This is bad in the opinion of raskin because it discourages habits, you learn the system once when you are a beginner, a second time when you switch to expert mode. Having only one interface allow you to develop habits that lasts. In the case of a wiki, I think the system is simple enough and that it doesn't require a beginner mode. Besides wikis allready place the content in the center of everything by keeping the interface minimal which is the most important. This is obviously in contradiction with the search for EasySubmission, unless EasySubmission is to replace the current interface which might be an interresting goal.

The example given by Bayle underline the possibility to provide 2 different contents around the same subject maybe with the same functionality to work on the content, things that might be addressed by SisterSites, NearLinks...

-- PierreGaston


Wait- hold on a second- nobody's saying that beginners shouldn't be able to edit pages, right?

I don't think we need to automate a bounce-back to the beginner's pages. I think I'd find it a bit jarring. It already is a little jarring to follow a NearLink, but I'm warned ahead of time with a green link. If you have sister sites implemented, and names match up, I don't see why you'd need to automatically bounce-back to the beginner's site.

I think it's enough for beginners to just back-track to the beginners wiki, or to follow a sister sites link. If I'm in expert-research, and expect to continue in expert-research, then I'm doing so beceause I'm comfortable with it, not because I'm trying to find my way back to the beginner's site.


As for summaries, I think you can have summaries on both the beginner and expert wiki. But they're going to read differently. The C summary I get as a programmer is going to be radically different than the "what is C?" summary for lay people. You're not going to tell lay people that C is "an imperative programming language," unless you intend to grant a paragraph telling what an imperative programming language is.

-- LionKimbro




Define external redirect: JefRasking UnderstandingDelegations

EditNearLinks: WikiNodes DocumentMode EasySubmission ViewPoint MakeWikiMoreAccessible MeatballWiki HumaneInterface HyperCard


The same page elsewhere: