I really liked VoidSkin's "view this page as Skin1, Skin2, ..." demo, and was disapponted to see that it called an external script.

Q: why can't any and all server side skins, that need nothing special from the browser client, be dynamically selectable? E.g. why can't I have a menu, or a set of buttons, that change the skin I am using? (As opposed to having to go and edit my config.)

s/me/my-users-who-barely-like-twiki-at-all/

It might require cookies. Is that so bad?

-- AndyGlew - 24 Jun 2003

See SessionPlugin . Regarding

> It might require cookies. Is that so bad?

My opinion is an emphatic yes.

Cookies add extra processing time onto systems and inherently make reads non-cacheable. This is despite any pragma, or cache-control headers that may be put in place - so many sites get it wrong that many cache systems will at best cache 2-3 copies of the page unique to end users (cookie match) - which is little better than having a browser cache. Often many caches (commercial and free) will simply see a cookie header however and mark the content uncacheable. (Except for the client browser...)

The upshot is for the benefit of a small number of users who like skinning the whole are slowed down and things are made worse. Caches can do fancy things with delta encoding and page matching, but as far as I'm aware the only major vendor that did this no longer sells their product in that market space.

I personally think that the user interface should be tailored to the people using it. Essentially sites should define a small number of default skins. The very default should just have an edit button for control (and maybe attach/navigation). This way the bar is kept low. If people want to login, they should be able to do so. For example this:

• http://twiki.org/cgi-bin/viewauth/Codev

"Logs you in" to Twiki. True their authentication details aren't kept between sessions, but they can customise things if they really want to. That said, I personally think this approach is very much the wrong approach. A better approach IMO would be to allow alternative interfaces stored in the URL. People then bookmark the front page. This results in the site being "skinnable", but stays cacheable. This makes more sense if you allow webs to be merged and just treat some styles of topics as templates which can either be editted or used for rendering.

For example:

• http://twiki.org/cgi-bin/view/Codev/DynamicallyChangeableSkins would use the default skin
• http://twiki.org/cgi-bin/view/Codev/PatternSkin/DynamicallyChangeableSkins would import the templates from the PatternSkin web, and use those for rendering instead.
• http://twiki.org/cgi-bin/view/Codev/TigerSkin/DynamicallyChangeableSkins would import the templates from the TigerSkin web, and use those for rendering instead.
• This idea is based on some of the discussion in LogicallyNestedWebs and thinking about how user edittable templates fits in

This would allow users to bookmark different views of a twiki web, and hence have view customisations. This would go a long way to achieving the goal you're talking about above. Furthermore if you allow users to define subwebs of their own personal page, they can then upload their own personal templates - which other people can user as well:

• http://twiki.org/cgi-bin/view/Codev/Users.MichaelSparks.MySkin/DynamicallyChangeableSkins would import the templates from the TigerSkin web, and use those for rendering instead.

Clearly all this could be made ClickyPointy (I term it that way because I like ClickyPointy) rather than TappetyTappety. In fact you can even do this with the above:

• Someone logs in
• A cookie gets stored on their machine which doesn't normally get sent by the browser, but is accessible to pages in the browser. (IYSWIM)
• When the client downloads the page some javascript on the page runs, detects from the cookie stored in the browser which skin is required, and forces a browser reload to grab the new page.
• From that point on the user browses using their defined skin.

That also protects the privacy of end users. Given step 1 doesn't even require a username and password - it's just an impetus for sending/setting a cookie, the user doesn't have to register to have this information stored.

My tuppence worth. Personally I feel skins at the end user level rather than site level are overkill. Despite installing many TWiki's in many places with many users I've not yet seen more than less than 1% of users both changing their skin, even though they know how to. That said I've always changed the templates to change the user interface to something "friendlier" along with a local much shorter "welcome" page which might be the reason why.

All that said and done though, I think a case could be made for a larger TWiki distribution that assumes a higher base level system (cookies raise the requirements somewhat) if someone was willing to act as a maintainer for it for the forseeable future. If you're willing to do that, I'm all for it

The base level requirements sometimes seem silly, but they do mean that making static versions for download as tarballs, or snapshotting to PDAs or accessing on strange mobile phone browsers is not just possible, but relatively painless in comparison to some other styles of community site.

-- MichaelSparks - 24 Jun 2003

here i agree with you cookies do make web pages & twiki's un-cacheable, and is a waste of time for skinning. But there are data and process reasons why they can be a good and important thing (like a bug tracking system with user specific queries and settings) and in that context, user settable skins are no extra loss. and for me, this non-cachable-ness is the reason why the twiki is useful in the enterprise. it allows the rendering of non-trivial information streams.

rather than http://twiki.org/cgi-bin/view/Codev/PatternSkin/WebHome you can already do http://twiki.org/cgi-bin/view/Codev/WebHome?skin=PatternSkin and then render the links on that page with the skin variable set. (that last part does not work yet)

-- SvenDowideit - 24 Jun 2003

There could be a solution: Embed the skin (here tiger) into the "path" part of the URL, as in:

   http://mysite.com/twiki/bin/tiger/view/Web/TopicName

And modify TWiki to just re-use blindly the left part of the URL (before view) in all its requests (i.e, do not take it from lib/TWiki.cfg anymore). It will also help with TWiki hosting. Thus once you choosed a skin (via its URL) you will stay with it, and it will be cacheable.

Moreover, it will allow nice interaction with the web server administration (setting redirects, excluding search engines: you want them to only search one skin)

Of course tiger would be a link (symblink on unix?) to bin/, or could be an Alias provided by the server on windows.

It is close to Michael idea, but I think it can be implemented with very few changes to TWiki code, and povides a better support for web server configuration directives

-- ColasNahaboo - 24 Jun 2003

While I prefer twiki/bin/view/Codev/tiger/Etc over twiki/bin/view/Codev/Etc?skin=pattern as a matter of principle -- slashes are easier to read through than question marks -- I sure hope something like this is not done without making ShorterURLs first.

-- MattWilkie - 24 Jun 2003

http://mysite.com/twiki/bin/tiger/view/Web/TopicName
Of course tiger would be a link (symlink on unix?) to bin/, or could be an Alias

Wow, horrible! (Sorry ) But, sorry, just no. Please. Please Peter, no. Please !

In this scenario you:

• Mix data with code - for every skin you install you have to add another symlink into a binaries directory.
• Force the server into following symlinks in the bin dir (I do this, some wouldn't due to security concerns...)

This just makes me go eeeeewwwww! Reasons:

• Breaks data and code separation principles. (Means that site sharing content must also share symlinks in code directory)
• Liable to break on upgrade. (I upgrade up untarring a release, running my installer and copying my webs over (symlinking the webs directory actually) and bouncing the server. Assuming that works I then port my patches. The actual upgrade takes about 20 minutes, porting patches takes quite a bit longer at the moment )
• You're putting data in the binaries directory!
• What happens if someone goes silly and does:
  =http://mysite.com/twiki/bin/tiger/tiger/burning/bright/view/Web/TopicName=
  And has 3 skins in that web's directory called burning, bright and tiger ?
• You're puting data in the binaries directory ??!

(ShorterURLs is a misnomer really - much of the URL for a TWiki page has meaning. view=action Codev=namespace/collection of topics, DynamicallyChangeableSkins=contentious argument, the exception being cgi-bin, or twiki/bin - which does have meaning to the server. Longer comment put in ShorterURLs... )

-- MichaelSparks - 24 Jun 2003

I'm getting a little pulldown menu that allows the user to try out a slew of different skins on the current page. Considering putting it on my site's standard skin.

Colas: I would have expected you to complain about putting the skin in the URL. Doesn't that go against making URLs unique and invariant?

By the way: another advantage of putting the skin in the URL: it would make it easier to do frame based skins, since the skin for sub-frames could be specified in the BASE clause.

-- AndyGlew - 25 Jun 2003

Just for the record: a similar idea was already discussed in SetSkinViaUrlPath.

Ad code/data separation: Handling upgrades to templates comes closer to patching code than anything else, see PluginsWebOrTWikiWebForPluginPackages. Given this, I don't see a big problem with a skin package slapping a thin wrapper script/link into /your/twiki/bin. This will be the least cumbersome part of skin maintenance.

Ad keeping ?skin=foo parameter: wouldn't it be better to serve as RelativeURLs in the first place? This could be easily implemented in WoutMertens' NeedFunctionForScriptUrls proposal.

Ad URL "function": /twiki/, /cgi-bin/ and the like serve no purpose other than making admin life (a small bit) easier. At least the view script is worth being rewritten or (script-)aliased IMHO.

2¢ by PeterKlausner - 02 Jul 2003

> I don't see a big problem with a skin package slapping a thin wrapper script/link into /your/twiki/bin.

A skin is data. A template is data. Pure and simple - they're things that have meaning to the code, but aren't code. They might have code like qualities (and using the conditional rendering combined with includes are probably turing complete), but they are data. (Much like perl source code is data to the perl compiler)

Putting extra "files" into the bin directory simply for skinning is a really nasty way of doing this. Really nasty. One more time: REALLY nasty.

-- MichaelSparks - 02 Jul 2003

IANAOOG (I am not an OO Guru (tm) ) but I smell featuritis. Why dynamically selectable? Only small percent of users ever bothers to set custom skin. Even smaller percent will want to do this dynamically. IMHO so much more important things to fix in Twiki. What a waste of time and efforts! All IMHO, of course.

-- PeterMasiar - 03 Jul 2003

Dynamicly changing skins is useful for the "I don't know what I want. I just want to see what everything looks like, without mucking about" stage. After a site's design has been settled on it probably wouldn't be used very much -- but it would go a long way to easing the pain for new administrators (and users if they are the kind that actually do change preferences).

So, for me, it wouldn't be necessary that all of twiki support dynamic skins so long as their is one place to quickly pick and choose and experiment. It could be a single javascript powered "selector" page for example.

-- MattWilkie - 03 Jul 2003

You do not need to add any code - any user can check within current Twiki how the same page will look in another skin - just add parameter ?skin=[skinname]. See http://twiki.med.yale.edu/ycmi/bin/view/Sandbox/SkinTest for one example. No coding, no hassle (skin needs to be installed, of course). So again, I am missing somethin: why we need this feature?

-- PeterMasiar - 04 Jul 2003

{slaps-forehead} Right. I was thinking, mistakenly, that dynamic skins would be a way of checking them out without going through all the hassle of installing them.

-- MattWilkie - 04 Jul 2003

The difference I took the request to mean is that rather than being a one shot ?skin=name type thing, it's a more persistant change. Putting skins into webs would make them completely dynamically changeable, and increase TWiki's orthoganality. (eg switch twiki into print skin mode.) I'm not convinced that it's a necessary feature, but the only way to really figure that out is to actually explore the ideas.

-- MichaelSparks - 04 Jul 2003