[pmwiki-users] View modes

[Radu]

At 01:25 AM 8/9/2005, Bronwyn Boltwood wrote:
>While turning certain functions on or off would be great, it also
>might be hairy for skin designers to implement.

Why? All recipes already have switches, and adding them would be tied 
into the view= or action= functionality.

>   How is all this stuff
>going to be inserted?  How will PmWiki and the admin know just where
>it will be shown in the layout?

Providing layout is the job of the skin :) There are two ways I can see:
* make the modules locations fixed and just switch them on/off as 
Gemini already does
* add some extra variables after the view= (or action=) one to set 
location and other module options
... or combinations thereof. It's really up to the skin designer.

>   What about all the stuff added by
>cookbook recipes?

Once we talk about functional skins we are already integrating 
functionality (recipes) into the skins. So the view-based skins will 
integrate existing recipes. Yes, it could get a bit hairy with 
updating/upgrading recipes, but at least it's done in a central 
location (by the skin designer), and the skin users (basic admins) 
will have less of a headache.

>   Will all skins have to be coded to accept all of it
>in order to have views at all?

Naw! Skins which do not support views will continue as they are: eye candy.

However, I've been saying that skins are already a bit of both 
worlds, since several of them provide different feel as well as 
different looks. And admins (at least I :) choose skins for their 
functionality more than for their looks.

Anyway, looks can be changed in view-based skins by providing 
alternative css files.

AFAICT, Pukka's been trying to mix function and looks through css 
only and it proved a bit of a challenge...

>As a base, the standard needs to contain descriptions of the four
>standard views, and detail each view's purpose, required functions,
>and recommended features.

Now you begin to sound like some planner from Microsoft (no offense intended ;)

Standards... *shiver*... are for machines. People need functional 
flexibility, and we're designing interfaces here. Everyone will have 
a different need, and all we can do is provide functionality from 
which we all can pick and choose.

>   The simplest (though not necessarily best)
>path from there is to let skin designers decide how to arrange the
>controls and content, and how much and what kind of customizability
>they will provide.

Exactly :) Except that I think it's also the best path.

>Shortly, once Hans' script is a little more hammered out, we skin
>designers should try making view-supporting skins and see what
>techniques work best for changing the controls and providing ways to
>customize the setup, before casting everything in stone.

Methinks we should never cast things in stone. Quite rigid, that material...

But you're right. I spoke my pieces, I'll put a bit more on the 
Cookbook and test pages, then I'll shutup and try to implement what 
I'm suggesting.

Thanks for your opinions, though.


Cheers,
Radu
(www.monicsoft.net)