Tags:
skin_consolidation1Add my vote for this tag create new tag
view all tags

Refactoring Proposal: Create framework for reusing as many basic skin elements as possible.

Motivation

In the latest iteration of PatternSkin (included in TWikiRelease04x00x02), ArthurClemens has made great strides in breaking out skin templates into smaller components. Being as these templates are really basic page elements (e.g. top bar, tool bar, side bar, etc) that are relevent to almost any skin, it occurs to me that this is one area where we could make some real progress to ConsolidateFunctionalityFromSkins. Towards this end, I'd like to propose to skin authors to set up some process whereby they could start to consolidate as many of their tmpl files as possible into a shared base of standard templates. Some of the benefits I see of this effort include:

  • Improved compatibility between skins.
  • Less duplication of template elements between skins.
  • Improved foundation for creating new skins.

Description

I see a couple facets of this effort:

  1. Skin authors would review their template definitions to identify as many elements as possible that they feel could be moved to a shared base.
  2. Skin authors would work together to combine templates that have overlapping functionality and standardize css class names.
  3. We would develop documentation about each base template component to help aspiring skin authors to understand the purpose of each component and how it works.

-- LynnwoodBrown - 21 Apr 2006

Impact and Available Solutions

Note: Patch is attached as https://twiki.org/p/pub/Codev/ConsolidateSkinTemplates/twiki-foo-bar-patch.diff. The patch is against the TWikiAlphaRelease of 15 Feb 2004.

Documentation

If necessary, developer documentation of new features and changed APIs introduced by this proposal.

Examples

Example uses of new features and changed APIs introduced by proposal.

Implementation

Any comments on how the refactoring is implemented or could be improved


Discussion

I know this is a pretty major request of skin authors, particularly ArthurClemens and MichaelDaum, who already have considerable investment in developing their respective skins. I just throught that if we could define a process whereby template elements are "nominated" to be added to a core set, then this would facilitate working together over time as you continue to develop and refine your respective skins.

-- LynnwoodBrown - 21 Apr 2006

Simplifying the basis on which our complex skins ar built is a great idea, but putting a Peter hat on for a moment, what do users actually need?

Application platform wikis like TWiki and Tiki that hover on the edge of being CMSes tend to have complex, full-featured interfaces.

MediaWiki seems to manage pretty well with a single moderately complex skin, themeable with parameters and CSS. They have focused their efforts on wikipedia as a single target market, so have concentrated on making this one skin as effective for that application as possible.

At the low end, c2 wiki has a really really basic skin. Other important wikis, such as meatball, have similar characteristics.

I see TWiki being used in all three domains. So, I see requirements for three types of skin:

  • Type 0 skins are extremely lightweight, simple, general purpose skin tuned for performance before function.
    • C2 and Meatball both use type 0 skins.
    • Type 0 skins will generally be used by public wikis, where a conversational form is the prime requirement.
  • Type 1 skins tune for a specific application or application.
    • Generally more sophisticated than Type 0 skins, and often with a locked-in look and feel.
    • Often interactively themeable, but not particularly flexible.
    • Mediawiki uses a type 1 skin.
    • I think Classic is a type 1 skin.
  • Type 2 skins are tuned for function before performance.
    • Type 2 skins are used in integration platforms, where many different applications are integrated under a single common interface.
    • Everything on your plate at once
    • Tiki and Xwiki both use Type 2 skins.
    • I think Pattern and Nat skins both fall into this class.

This classification is really why I aleady put a lot of effort into simplifying the default templates. I see the need for a Type 0 skin. I am resistant to code changes that marginalise type 0 and type 1 skins (there have already been several!). Consider the analogy to the work Meredith is currently doing on pluggable variables; if a user doesn't need skin features, why should we force them to take them?

So, while I favour modular construction of skins, I see it as critically important that type 0 is the starting point.

-- CrawfordCurrie - 22 Apr 2006

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2006-04-22 - 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-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.