[pmwiki-users] Supporting different modes in default pmwiki

[Bronwyn Boltwood]

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