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

[Bronwyn Boltwood]

On 4/8/05, Joachim Durchholz <jo at durchholz.org> wrote:
>Bronwyn Boltwood wrote:
>>On Apr 7, 2005 11:12 AM, Joachim Durchholz <jo at durchholz.org> wrote:

>>>When settin up my wikis, the one thing that I wanted was the standard
>>>set of actions, plus any actions included via recipes.
>>
>>That I can understand.  It would be nice for admins to have a simple
>>way to say they want to see actions x, y, and z, but not a or b.
>>OTOH, that could pose some difficult problems when designing skins.
>
>What kind of problems?

Off the top of my head, when planning the parts of a PmWiki skin that
contain actions, the designer has to consider things like:
-how many links will there be?
-how long is the link text?
-will the browser do something stupid if the viewport is very narrow,
very wide, or if there is too much/too little text in a specific area?
-how will this degrade when it meets unusually buggy or older browsers?
-are there any uncommonly used but useful features that I want to make
available?
-how should these actions be grouped, ordered, or (de)emphasized? 
What actions should be entirely hidden?

The general theory behind interface design is that a good interface
guides users in finding and using the product's capabilities.  To
craft a successful design, the designer must have a thorough
understanding of:
- what the object (PmWiki) is capable of doing
- what the users want to accomplish
- what the users are already familiar with
- how much the users are willing to learn in order to better use the product

Based on the answers to those questions, the designer makes judgement
calls about what capabilities are important or frequently used, and so
must be easy to find and use, versus less important or rarely used
ones, that can safely be de-emphasized.

Clearly there could be so many different answers to these questions
that no one interface for PmWiki can completely meet the needs of all
possible users.  That's why it's important for those users to be
capable of changing it to suit themselves.  We all want to make that
possible, but we're arguing over the best set of tradeoffs.

How much is the designer supposed to plan ahead for the unexpectable? 
When is the customization-crazy site admin (like me ;) responsible for
what happens?  How much does it take to void the warranty?

>One that I can think off-hand is that the action list might become too
>large to look good. I.e. if the skin is designed for a horizontal row of
>actions, and the action texts simply don't fit. (That's a reason why
>wiki admins should have control over the action texts: so that they can
>choose shorter ones.)

That's an excellent example.  Most horizontal list designs either look
ugly or break if the tabs wrap to a second line, but it's not hard to
make that situation come up with a narrow window and wide text. 
Things like min and max-width are handy for dealing with that, but if
the admin has added a bunch of actions that the skin designer didn't
plan for, there could be more problems.

>So I first installed a few skins. Found that some of them had actions in
>them that weren't installed at that point. Cursed - I'd have to remove
>the action to avoid confusing my friend, then re-install them as soon as
>I'd get around to installing those recipes that implemented the action.

Comment tags were your friends? :)
 
>Then I found that I had chosen skins for appearance instead of for
>technical merits. (Some of the skins look very nice but aren't flexible.
>Some use markup that's not interpreted consistently across browsers.)
>Now I had the prospect of doing that action list redesign stuff for each
>skin that I'd try out. And trying out them I wanted, and I don't want to
>bother with actions when I'm trying to evaluate flexibility towards my
>friend's wishes! Curse, curse, curse...

Creating a good web design is hard, just as designing a good interface
for anything is much harder than using one afterwards...

Bronwyn