create new tag
, view all tags

Proposal: drop Classic Skin from the standard release

  • I doubt very much whether anyone is actually using Classic skin these days, so why do we persist in releasing it?
  • Visually it is totally blown away by PatternSkin, and adds very little over the default fallback templates
  • The maintenance has been patchy - it is very slow to get updates to the skin, unless you are prepared to DIY
    • Effort required to support it could be better spent on Pattern skin
  • It is rather quirky in places
    • It was grown as TWiki grew, rather than designed up front, so it mixes several design metaphors e.g. TMPL:P versus TMPL:INCLUDE versus template files, mixins versus inheritance
  • It isn't huge, but it still occupies space in the release package and documentation
On the other hand....
  1. Someone out there may just be using Classic skin, or a skin based on it
    • However it can still be downloaded from Plugins web, even if it is dropped from the release
  2. Having two skins in the release forces developers to consider multi-skin issues
  3. Having two skins in the release guarantees that there are at least 2 skins for end users to choose between

-- CrawfordCurrie - 03 Jan 2007

I support this proposal.

What we could do is announce that the skin will be removed from the default release package and continue as stand alone skin and only maintained if someone takes ownership.

If there are people that really want this skin, such an announcement should create a reaction and we can redo the dec Now is the right time. The only action we would actually do is write 3 lines in the release note in the deprecation warning section. That leaves no risk and we get the market reaction if the decision is wrong. We can write in the note that people should react if they disagree.

A decision to do this would need to be taken at a release meeting. We have one the 8th of January.

The reason I support the proposal is that defacto - no one really maintains this old ugly skin and I am sure the number of bugs and usability issues is high if someone really takes the time to test it. PatternSkin is a beautiful skin and if we are to offer two skins then an alternative modern beautiful skin such as Nat would be a better investment in time.

-- KennethLavrsen - 03 Jan 2007

Agreed, but there is value, as CC said, in forcing developers to consider multi-skin issues. At this point, sometimes even the fallback skin is not being properly updated when changes are integrated into PatternSkin. Note also that the ClassicSkin is faster than PatternSkin.

-- ThomasWeigert - 03 Jan 2007

It might be old and ugly to you, but with lynx it is stunningly beautiful, and pattern skin is as ugly as hell, to the point of illegibilityforsomeimportantwords.

I like the speed of editing in lynx with a full powered local character based text editor, and the lack of necessity to fire up a gui if it exists where I am at the moment. I love having the ability to request ?skin=classic on the fly at just about any basic twiki I visit, without reconfiguring or making a big song and dance about my special needs and their justification.

-- SueBlake - 07 Jan 2007

Sue, if you were to use a non-existing skin, such as ?skin=sueskin, would that look much worse than ClassicSkin? A point CC made above is that the default skin is almost the same as the ClassicSkin....

-- ThomasWeigert - 07 Jan 2007

Good input Sue that did move my negative feeling about classic towards the more positive (still think it is ugly though wink )

Maybe a future alternative skin should be a very simple skin that address mobile devices (PDAs, mobile phones) and also work well with Lynx?!

-- KennethLavrsen - 07 Jan 2007

OK, I've attached a combined screenshot, using the pictured "search field" to label each variant with asterisks. Seehowincreciblyuglypatternskinis, and here you're not even seeing the stack of (left bar) junk to wade through at the bottom of the page, but thankfully it's at the bottom not the top! Arguably pattern skin should be fixed to be usable (even if a bit tedious) in lynx and maintained so, but realistically I don't hold my breath for each incarnation to be made lynx-compatible promptly.

Yes the default for a skin that doesn't exist is not bad, so if there were no classic skin, then ?skin=classic would give pretty much the desired results even if I didn't know it was missing. I wonder if this skin is going to be maintained though, is it the same problem like remembering to maintain classic? Even in classic skin I sometimes encounter missing spaces between words, which can change the meaning of a command or make screen readers speak nonsense.

I also use a handheld device, and I can tell you that the viewing expectations for handheld and lynx viewing are worlds apart. What lynx users want, and what blind people using screen readers need, are not the same, though they are somewhat compatible. It's tempting to overlook that just because two people's needs are very different to yours (e.g. lynx, PDA), that doesn't mean they must be at all similar to each other.

I'm lucky I know about ?skin=classic, but I didn't know that there was a default skin or that ?skin=somethingsilly would bring it up. I don't expect users to have to memorise and type too much to get what they need, or to keep telling blind users and lynx lovers to change the hacks they use. If it follows the POLA, that's fine.

So yes, I'm not really against the proposal now, but make sure it's done right. It's not an act that will reduce the burden of accommodating us, but one that will increase the responsibility to do so. Can you handle that? That's the question to answer before the decision is made.

-- SueBlake - 07 Jan 2007

So maybe we should understand what really the difference is between the default skin and the ClassicSkin in terms of appearance. Sue, the default skin has to be maintained as it is the fall back if some skin template is not found.

-- ThomasWeigert - 07 Jan 2007

Differences not just in terms of appearance. Functional differences are important too if they exist, e.g. the absence of "Login or Register" which only Classic has right now, maybe both skins should have had the same update at that time.

The default skin has to be retained; it should also be maintained. I can see that that might be easier to maintain it if classic didn't exist. To borrow from CC's thoughts: Effort required to support it could be better spent on the default skin.

-- SueBlake - 08 Jan 2007

Right. That's what I was thinking also... We need to understand what the critical elements are that need to be offered by the default skin (in other words, we need to migrate those features from the ClassicSkin to the default skin). If we can do so that would be a win in terms of easier maintenance. Maybe you could help identifying the critical features for your use case.

-- ThomasWeigert - 08 Jan 2007

Some factoids:

  • TWiki has a set of screens, each one corresponding to the different functions of the tool; view, edit, oops, more etc.
  • TWiki has a set of default templates, one for each screen. These default templates are what are used when a skin has not been provided that personalises that particular screen.
  • I derived the current default templates from the old Classic skin, by radically simplifying it in a 1 hour hacking flurry, and Sven has been pushing that further to make them even simpler.
  • The default templates need to follow the wiki principle of "the simplest thing that can possibly work". As such they must be able to work anywhere, including mobile devices.
  • They are not pretty, but they are maintained as part of the core.
Skins should layer over the default templates to prettify them. The CssZenGardenSkin, which is hopefully forthcoming from Sven, is an example of a skin that uses the structure of the basic templates and applies some nice shiny gold paint.

Unfortunately Classic and pattern were grown before this strategy was in place, so they have hairy, complex structures.

Sven has been working on a strategy for structuring the default templates to make it easy to derive from them. I think he is using a mixin approach, though we really need to hear from Sven on that.

While the default templates will work on a mobile device or simple browser, I think it would be much better if a new skin (MobileSkin?) were based on the default templates.

in any event, the question is whether we should keep the existing Classic skin or not, and that depends on active users of that skin registering their opinions here.

-- CrawfordCurrie - 08 Jan 2007

I expect to release the CssZenGardenSkin during Feburary 2007, after the twiki 4.1 release, and after I return to Sydney (Guess who's effectly on holiday?).

I expect to do a little more work on the default templates this week, cleanups mostly, and (thankyou Sue) adding missing functionalities like login.

The concept behind the refactorings is documented on the WikiRing Blog , but the short version is that even now, my personal Blog is running a development version, and its still only a 115 line twiki.zengarden.tmpl file.

I Support dropping Classic for 4.1 - the only functional difference is that I removed the checkpoint save & quiet save etc for 'simplicity'

-- SvenDowideit - 08 Jan 2007

Sven, I am not sure whether it is a good idea to remove things like the checkpoint save from the default skin. After all, that is a core supported item, not a skin-specific item. For the default skin to be the basic of all other skins to be built on top, it should start out with having all the core supported features of the UI in it. A customization can drop items from the actions if desired.

There will never be an agreement on what is "simple" and what is not. E.g., why is "login" simpler than "check point"? I don't use it on my personal machine, but I do use check point periodically.

-- ThomasWeigert - 08 Jan 2007

Yeah, its not easy to determine if (as you say) default should be ALL features, and custom skins should be subtractive, or the default should be minima, and custom skins get to be additve.

The Login example is a furfy, as its coded only to appear if you have user Logins selected in configure, and in those cases there has to be a login to do anything.

Currently adding or removing functions from a template you over-ride is not actually plausible (without duplication) - This is something i'm working on at the moment.

a horrible example of this, is simpleheader and standardheader - not only is it simpleheader that is used by default, but the 2 definitions are often almost the same. To make matters worse, there is no symetrical simplefooter and standardfooter, forcing the 2 header definitions to be artificially similar.

-- SvenDowideit - 08 Jan 2007

Yes, I have taken a stab at that long time ago, and it was quite a pain. I am looking forward to seeing your final result. It is quite amazing that you could derive your demo skin with just a hundred lines of additional template code...

Not sure what you mean by overriding not being able to remove or add functions. Building on the current PatternSkin I can easily change the actionbar, for example, by replacing the definitions in viewtopicactionbuttons.pattern.tmpl or override topicaction.

-- ThomasWeigert - 08 Jan 2007

On removing the ClassicSkin: I am all for it with constraint indicated below; shortly before the 4.0 release I actually suggested to remove the ClassicSkin (that was added in a rush before the 4.0 release) but we had some vocal voices against it. I forsaw that almost identical default templates and ClassicSkin just create maintenance overhead. The logical solution is to deprecate the ClassicSkin in 4.1 but leave it in the release, and to remove it in 4.2.

Constraint: The default templates need to be:

  • simple - no sidebar
  • work on clients that do no grok css
  • have all important elements of the PatternSkin (checkpoint save etc)
  • should work well on PDAs (PatternSkin is unusable on PDAs)
  • should work well on text based browsers such as Lynx

I am looking forward to Sven's redesign of the default templates, Sven needs to get feedback from us so that we get a system that is easy to use and fullfills the needs of the stakeholders. Sven, to get more exposure I suggest you share your insight here on twiki.org where you get more exposure.

Lets coodinate the efforts in SimplifySkinCreation based on default templates.

-- PeterThoeny - 08 Jan 2007

MMM, deprecate / remove - on reflection, both may be un-necessary smile

The only reason i felt ok with commiting the changes to 4.1, was because the default templates are quite un-used frown and while doing so, i found out why.

now however, its possible to create a classic skin based on the default templates - its almost an empty skin, but might be worth it just to show people another simple modificaltion (and to provide another test case for default..)

CDot and I envisiaged the default templates to be a building block - It just happens to also be a functional skin - maybe Classic has a place?

(wrt pda - there is another templates change I've been thinking about, but I've not quite gotten to the writing words stage - the templatepath should contain some kind of ClientCapability, or something, so that a different skin is used for PDAs, or screen scrapers 'magically'.

-- SvenDowideit - 08 Jan 2007

As described here it seems to me like classic skin is duplicate effort with the default fall back templates. As I understand if we remove classic skin and one tries to use it, TWiki should use the default fall back template which are very similar to the classic skin, so every one should be happy.
I also noticed that TWiki feels much faster when using simpler skin or default template as opposed to the pattern skin.
As a Symbian developer and smartphone user I would gladly welcome and try to participate in the development of a mobile skin or lite skin. Ideally we would need a mechanism using the user agent to determine the best skin for the client device. Of course users should be able to override that mechanism and still use pattern skin on their smartphone if they want to.

-- StephaneLenclud - 08 Jan 2007

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng LynxAndSkins.png r1 manage 71.5 K 2007-01-07 - 23:14 SueBlake Lynx using pattern and default and classic skins
Edit | Attach | Watch | Print version | History: r20 < r19 < r18 < r17 < r16 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r20 - 2007-01-09 - CrawfordCurrie
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.