[pmwiki-users] Supporting different modes in default pmwiki

Radu radu at monicsoft.net
Mon Aug 8 19:14:23 CDT 2005


Neil is right; there ARE cognitive factors against views (especially 
automatic view changes), and since I like pmwiki for its leanness, I 
would not see the views recipe (and templates) in the default 
distribution (at least not until they stabilize enough to make sense 
to anyone).

Same thing for all the vars in the default pmwiki. It's great that Pm 
is thinking to move them out to a script. I'd like to see the core 
(pmwiki.php) be just that, the absolute minimum for a wiki, and all 
the jingles'n bells to be imported via the default sample-config.php, 
from where the admins can chuck them as they please.

On the other hand, I agree with Bronwyn that the views would not be 
automatic. The user would CHOOSE to switch to a specific one and 
expect to find the functionality the specific view implies. I've done 
quite a bit of research on this.

Word does have the functionality to change the 'view' through the 
Customize options. Unfortunately they don't have a way to establish 
several 'views': sets of customized options, and switch between them. 
You have to switch toolbars on/off one at a time.

Radu

At 06:43 PM 8/8/2005, Bronwyn Boltwood wrote:
>On 8/8/05, Neil Herber <nospam at eton.ca> wrote:
> > At 2005-08-08  01:38 AM -0400, Bronwyn Boltwood is rumored to have said:
> > Having fairies cleaning up my desk sounds appealing on one level, but this
> > whole idea of modes or roles or views (I favor the last term) seems to be
> > glossing over a very important UI feature, namely: muscle memory. "Users"
> > (what should I call these folks now!!) learn to expect the edit button in
> > the upper right, the history button in the lower left, the sidebar on the
> > far left and so on. Having views that make subtle changes to these
> > arrangements causes disorientation and frustration.
>
>That is a good point.  Views are a tradeoff: people who use the wiki a
>lot in different capacities will probably love them, but people who
>just muddle through will likely be confused.  Only you can accurately
>assess if they are a good idea for your site.
>
>If views are left as a cookbook recipe or optional script (like rss
>and refcount), then they can be disabled entirely.  Another two
>alternatives are to (1) choose a default view, but disable view
>switching, or (2) set it up so that only those users who need or want
>views use them.
>
>To elaborate on #2, say the admin sets the default view for a site,
>and uses some trick to hide view switching from the majority of the
>site's users, while leaving it available to himself or other people
>for whom the benefits outweigh the costs of learning.  Example
>techniques: conditional markup to hide the view switcher that's stored
>in a wikipage, default skin does not support views, but other skins
>available do, edit a view-supporting skin to not support views...
>
>If view switching is made freely available to all, don't forget that,
>except in stealth view, there is a view indicator visible on every
>page, which (a) reminds you what view you're in, and (b) lets you
>switch views.
>
> > In the case of a physical space like my real desk, I do keep the calculator
> > in a drawer until I need it, but I would probably leave it on my desk if it
> > had more surface area.
>
>Screen resolution is also limited.
>
> > In the software world, I find the so-called improvements to programs like
> > Word that make the menus adapt to your usage to be so frustrating that I
> > turn them off and revert to the
> > show-me-everything-I-can-do-and-leave-them-in-the-same-damn-place menus.
>
>I also turn off the "personalized menus" in Word, even though the
>concept sounded like a good one.  I can see, thinking about this and
>modes, that the problem with Word's personalized menus is that it is a
>half-assed implementation.  Word has more capabilities than you would
>ever want to use at once.  What the personalized menus option does is
>to guess what menu items you might want visible during your task, and
>change them around behind your back.  Aside from that being rude,
>there's a fundamental flaw: Word has no clue what your actual task is,
>and there is no way to tell it, or have it save different settings for
>different tasks.  No wonder it's mostly wrong...
>
>Modes don't work like that.
>1. They only change when you tell them to, unless the admin has
>deliberately written code to change that behaviour.  Nothing happens
>behind your back.
>2. A skin designer, or Pm, or both, will have specified a role or task
>that they are targeting, and carefully considered what tools ought to
>be available.
>3. Setups for other tasks and roles are easily available, and you can
>create your own.
>4. You can customize them if you don't like the defaults.
>
> > There is also some value in having facilities that a person might use
> > eventually be visible - it may prompt a curious click.
>
>Hence the big, shiny edit button in reader mode.
>
> > I also don't want to classify myself as a reader/seeker or
> > author/contributor or admin/dictator or have software decide what I am
> > based on my login or current behavior.
>
>You won't be forced to choose one before you can start using the site,
>and it's not as if someone was collecting demographic or market
>segmentation information and selling it to spammers, based on your
>choosing or not choosing a mode.  Also, by default, modes will not
>switch themselves automatically.  Calm down...
>
> > Providing user (eek!!) help in a fairy-controlled environment could be very
> > frustrating: "My menu doesn't have a 'blurt' function on it ..."
>
>"Which item on the bar labelled "Mode", at the top of the wiki page,
>has a bright yellow background?  It's 'reader'?  Please click on
>'author'.  Good.  Now click the menu and you should see 'blurt' on it.
>  You do?  Great, the next step is..."
>
>You can see from the above that I've done tech support before, so I
>understand what you're worried about.  I promise that most techs will
>soon learn what options are capable of causing strange behaviour, and
>confirm their status as required to resolve the call.
>
> > Getting my users (sigh ...) to actually edit a page is like pulling teeth,
> > and telling them that now they will have to select the mode they want to
> > use to access the wiki will be the kiss of death.
>
>But they don't HAVE to.  You might choose to let them do so, but this
>sounds like a crowd that either shouldn't have modes enabled at all or
>have it locked to reader or author.  Anyway, given the rest of the
>thread and this mail, I doubt that modes will be forced upon them...
>:)
>
>And didn't we say somewhere that the user's choice of mode should be
>saved in a cookie?
>
>Bronwyn
>
>_______________________________________________
>pmwiki-users mailing list
>pmwiki-users at pmichaud.com
>http://host.pmichaud.com/mailman/listinfo/pmwiki-users

Cheers,
Radu
(www.monicsoft.net) 





More information about the pmwiki-users mailing list