[pmwiki-users] Feature request: Action lists in skins

Joachim Durchholz jo at durchholz.org
Fri Apr 8 12:55:41 CDT 2005


Patrick R. Michaud wrote:

> On Fri, Apr 08, 2005 at 11:36:44AM +0200, Joachim Durchholz wrote:
> 
>>Bronwyn Boltwood wrote:
>>
>>>I wanted to improve the behaviour of the interface as well as its look,
>>>and that means my work is in the place where function and form meet.
>>>I'm not satisfied to just paint on pretty colours.
> 
> I'm of the opinion that function and form have to meet *somewhere*,

Agreed.

> and the best place for that to happen is generally in the skin and 
> not in PHP code.  But that's just my opinion.

It must happen in PHP, at least partly. After all, the visibility of 
each action link should be controllable from PHP, to facilitate making 
action links invisible depending on who logged in.

Now I've seen the slice&dice concept. It made my head hurt: the regex 
was inscrutable, and I was imagining the skin author who tried to 
determine whether his all-new way of writing action links would be 
recognized by the slice&dice function. (If he was aware of that function 
in the first place...)
I also see all sorts of bugs creeping in whenever PmWiki changes its 
idea about how action links are displayed. That slice&dice thing 
essentially needs to parse a large subset of HTML, and I don't think 
that regexes can do that. Not to mention unexpected interactions with 
substitutions that come before or after it.

My experience with computer systems says that parsing things after the 
fact is almost always inferior to constructing them from pieces. (Which 
is why I constantly babble about the variation within the action links, 
and which parts of it need to be placed in PHP arrays and how to best 
divide the information up - I'm well aware that this is a rather 
indirect way of doing things, but I don't know of a better one. 
Slice&dice is easier on the skin designer but it carries a serious 
unreliability risk.)

>>>That would be because the recipe creator can't be completely certain
>>>what you want to do with it.  No matter what he chooses, somebody will
>>>dislike it.
>>
>>It's not as clear whether the admin wants to actually see the new action 
>>in the action list. He may prefer to type the ?action=... string on the 
>>URL bar manually. (The only reason I can imagine is that it's something 
>>that end users aren't supposed to see. If that's the only reason (are 
>>there others?), that can be handled using a permission-based approach: 
>>show exactly those actions that are available under the current 
>>permissions.)
> 
> No, it's not the only reason, and a permission-based approach isn't 
> sufficient (or correct).  
> 
> One of the basics of good human interface design is to make only the most 
> common actions visible, and provide a way for the human to discover
> the other actions that may be available.  Otherwise a new user of the
> system can be too overwhelmed by all of the available options.
> This means that the set of "available actions" (as determined by 
> permission) is not necessarily the same as the set of actions 
> we want to make visible.

Agreed, but currently PmWiki makes no attempt at making the 
invisible-but-available actions discoverable. Not in the UI itself, at 
least (and I have been finding that quite annoying - I don't want to dig 
through documentation just to discover yet another action, I'd really 
prefer to have an "expert mode" or "explorative mode" that shows me all 
actions available to me, useful or not).

> In fact, in some environments the two concepts are completely
> orthogonal.  Here's the matrix:
> 
>     Action available + visible:  This is done for the most common
>        actions, so that a new user can quickly locate common operations.
> 
>     Action available + invisible:  These are actions for which a
>        user has permission to perform, but aren't displayed because
>        they interfere with the skin aesthetics (too many actions), 
>        aren't something we want to advertise (?action=attr), or are
>        just too advanced to force upon new users (?action=refcount).
 >
>     Action unavailable + invisible:  These are actions for which
>        the user doesn't have authorization, so we want to hide the
>        action or not bother the user with the additional information.
> 
>     Action unavailable + visible:  The user may not have permission
>        to perform the action, but we want to let them know that the
>        option exists so that the user can start to inquire about
>        obtaining permission.  For example, we might want to prominently
>        display "Edit Page" even if a user isn't authorized, so they 
>        know that page editing is available and can start taking steps
>        to obtain permission.
> 
> So, it's entirely reasonable (and desirable) to have actions that 
> visible but inaccessible, or actions that are accessible but invisible.

Agreed.

But then the site admin should decide which action goes to what 
category. Not the skin author (though it's well conceivable that the 
skin author gives recommendations).

>>> As for the skin authors, well, they have no way of knowing what
>>> recipes you have installed and want a UI for.
>> 
>> Which is why I'd like to relieve skin authors from decisions about 
>> action lists.
> 
> 
> 1.  Fair enough, but this doesn't automatically mean the primary 
>     control of action display should therefore pass to recipe authors.  
>     Control needs to rest with wiki administrators, and we have to
>     make it easy for wiki administrators to find and use that control.

Agreed.

Actually I see four influences at work here:
1) Skin writers need to influence how actions look. Since actions may 
have different states (current, available, unavailable, maybe others), 
they might want to specify different looks for each state.
2) Action writers set up the actions and may want to recommend some of 
their side effects (such as opening in a new window by default - 
anything else?).
3) PmWiki translators want to have a comprehensive action list so that 
they can translate it.
4) Site administrators want to have a final say in the selection of 
actions, in their side effects, their visibility and availability for 
the various user groups.

Did I get that right?

That PukkaFloat skin is an interesting test case. PukkaFloat classifies 
actions as "important" and "secondary" (my terminology), by displaying 
the important ones promimently and the secondary ones in a 
not-so-prominent position. I think that this is an excellent design idea.
However, again, this mixes skin-design and administrative tasks. The 
administrator may disagree about the relative importance of actions. 
With the current system, he'll have to modify the skin. (I have been 
thinking about ways to make even this advanced way of using the action 
list configurable, but I have withheld the idea for fear of letting the 
discussion get sidetracked even more.)

> 2.  Skin authors already have the ability to relieve themselves of
>     action decisions, via some the mechanisms we've already discussed
>     in this thread (e.g., the use of ActionList wiki pages).
>     Whether a particular skin author chooses to do so is, well,
>     up to the skin author -- we cannot force it upon them except
>     by convention, guidelines, or "market pressure".

Agreed - nothing prevents skin authors from hardcoding actions.

I wanted to continue to write something like "however, this isn't a 
problem if the actions are the standard ones like 'read' and 'edit'". 
Then I reconsidered: it *is* a problem. There is no such thing as a 
standard action. If a site is mostly-read-only, editing allowed just for 
a select few who know the proper password, then not a single action 
should be displayed, hence no actions should be hardcoded.
The slice&dice approach would properly take care of that. I'd prefer it 
if I saw a chance that it could work silently and effortlessly. It's 
just that I have too many instances of slice&dice either not work at 
all, or become cruft within a matter of weeks.

Regards,
Jo



More information about the pmwiki-users mailing list