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:
- Skin authors would review their template definitions to identify as many elements as possible that they feel could be moved to a shared base.
- Skin authors would work together to combine templates that have overlapping functionality and standardize css class names.
- 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