Tags:
skin_consolidation1Add my vote for this tag create new tag
, view all tags
On moving common functionalities from the skins to a) the twiki core, or b) a common shared component (a subset of SharedCode). Each skin maker can benefit from the functionalities, and skins are 'cleaner'. All the authors of advanced skins have needed to change and adjunct the functionality in TWiki. Each has done this independently. Replication of the functionality added by one skin into another fragments code, wastes effort and make unavailable that functionality to other potential skin developers. Simply put, functionality does not belong skins and it is in everyone's best interest to factor it out. It is to all TWikiSkins what TigerSkinPlugin is to TigerSkin.

TODO

  1. what functionality is being provided where and why, (done)
  2. where it is duplicated. (done)
  3. which parts of which implementation to use
  4. how to make this functionality available (e.g. does it go in the core, or to Plugins.SharedCode)
  5. how to wire existing skins to use the common skin mechanism
  6. how to minimise the transition effects on users
  7. how to best acknowledge the tremendous contributions each skin developer has made
  8. how to minimise the effort of such consolidation processes in the future

We are currently bouncing between 3 and 5.

I guess the timeframe will be for the DakarRelease? Ideally what comes out of this discussion will be put in the To Do list of Dakar.

Features table



(( Edit this included topic ))

The table: (if TWiki.org has the edittable plugin...)

  • Rows will list functionality (or design points that should be implemented by all skins)
  • Columns will list skins (abbreviating the text)
  • When adding a skin, just add a column in the header
  • Values to of the feature can be:
    • y = Yes, there
    • Y = Yes, and coded in a way that could be / had been retrofitted to standard TWiki or other skins
    • n = Not there, may be added
    • N = Not there, and the author do not want to add it for specific reasons
    • p = Partially implemented (temporarily), or an alternate form
    • P = Partially implemented, but will not be developed further, or an alternate form
    • * = Special case (see footnote after the table)
    • ? = not sure what this mean
Note that these could be nice-colored icons if TWiki.org applied my EditTablePluginExpanseVars.patch on EditTablePluginDev, see: http://koala.ilog.fr/wiki/bin/view/Koala_Skin/ExampleOfEditingTable

This would give:

Feature Tiger See Koala CCat Photon Void Flexible GnuSkin Pattern Simple Caboteria Default
(twiki)
Ambar
abbrev T S K C P V F G Pt I Cab D A
Uses CSS (1=CSS1, 2=CSS2)   2 1 1 n 2 2   2 n 2   1
SavemultiCgiScript n y Y   * n n   n n n n Y
Uses other scripts in bin ?   y   y     y         n
Uses code in a plugin y       y       y       N
Uses code in javascript y       y       n       Y
AccessKeys n y y   n n n   n n n n y
PhotonSearch n y n   y n n   n n n n n
Direct access to printview y y y   n y y y y y n n N
Edit at top and bottom n   y   y n y n y n n n Y
Spell check button on edit     n   n n n n n n n n n
Checkpoint button on edit   y Y   y n n   n   n y n
Direct save on edit y y y n y n n y n n n n Y
User managed layout   *   n n   y   N N n n N
"Create new topic" template   n   n n       y ? n y n
Underscore Wiki links   n   n n       y n y n ?
Parent-child navigation y       n       y y broken y Y
View topic's parent in "More" y       n       y n n y n
ShorterURLs         n           n n n
Option to hide edit features y       n         Y n n n
Support LogicallyNestedWebs Y       n               n

*) SeeSkin uses an INLINESTYLE preference variable which can be used for local or personal css overrides

Feature Tiger See Koala CCat Photon Void Flexible GnuSkin Pattern Simple Caboteria Default
(twiki)
Ambar
# Default view controls         ~30     15 0..12   24 ?
# templates (out of 66)   11                   66  

The "# templates" row indicates how many of the total templates have been skinned. Many skins only do view, some more do edit too, and a few do view, edit, attach and maybe a couple more like rdiff. I don't think any are comprehensive.

Q: What is the "# default view controls" about?


*) The asterisk in the SavemultiCgiScript in PhotonSkin means that I got the savemulti from Colas' KoalaSkin, but I later modified it to add an instant notification system.


Very happy to take suggestions for improving the table.

Here's a candidate list of skins. I know it is contrary to the lets-set-no-deadlines ethos that this project typifies (see the continual pushback and refusal of date-setting in both BeijingRelease and CairoRelease) but I think we need to aim at contacting and having responses from authors of all skins by next week.

%ACTION{who="Main.SkinDevelopersGroup", due="17 May 2003", state="open", notify="Main.MartinCleaver"}% Contact all Skin Authors about filling in the table at TWiki:Codev.ConsolidateFunctionalityFromSkins %ACTION{who="Main.SkinDevelopersGroup", due="25 May 2003", state="open", notify="Main.MartinCleaver"}% Get responses from all Skin Authors

Authors table

Skin Author Response Still using skin Still developing skin Happy to help consolidate (16 May 03) (24 Mar 04)
KoalaSkin ColasNahaboo see below yes yes yes  
PhotonSkin EstebanManchado See below yes yes yes  
SeeSkin MattWilkie see below yes yes yes  
not yet released ArthurClemens see below yes yes yes  
SimpleSkin PeterMasiar see below yes yes yes  
CopyCatSkin MattWilkie see below no yes yes  
CaboteriaSkin TobyCabot see below yes maintenance yes  
AmbarSkin RaviASV see below yes slowly yes  
FlexibleSkin AntonioTerceiro See below yes slowly wink yes  
LkfSkin WalterMundt see below yes some probably  
VoidSkin DaleBrayden see below yes some maybe  
GnuSkin HurdWiki:Main.JoachimNilsson wife expecting baby yes slowly    
TigerSkinPlugin SteveRoe in private email No No No Skin (not plugin?) continued by TorbenGB
TigerSkinPlugin JohnTalintyre in private email yes yes yes (personally, not my company)  
DallasSkin DavidWeller Not developing twiki no no no  
DandruffSkin JeroenVanDongen See below no no no  
MikebSkin MikeBarton See below no no no  
PhantomSkin AlexeyEfimov Didn't reply by 1 June 03        
RoundEdgeSkin PeterThoeny Didn't reply by 1 June 03        

I've emailed to every skin developer to come look at this topic.

Skin authors, please update both the authors table and the feature table (feel free to add both rows and columns) and add any other comments to the bottom of this topic.

-- MartinCleaver



Candidate pieces to be shared

We should make out of this a minimal set of features we agree all should be in all skins, and push authors to incorporate them.

Some of the commonality can be derived by considering what it takes to move between skins. For instance, to provide both KoalaSkin to TigerSkin on my site I have to code Tiger's Left hand menu to contain duplicate items as listed in Koala's Main.WebList. This should not be so, it should be possible to use the Koala's mechanism. We need a definitive list of all such issues. that's the goal of this topic.

TERMINOLOGY

Keep in mind that Twiki uses template for two completely different entities:

  • as in WebTopicEditTemplate as a name of the page which will be copied when ceating new page
  • as in files in template directory named *.tmpl, used to define and assembly skin.

I propose make our terminology little more exact. IMHO we need to distinguish:

  • skin: overall functionality, menu, etc, except of colors, font and styles
  • theme: colors (ie. WEBBGCOLOR is a "theme" of classic skin) or appearance stuff tweaked by stylesheets: link colors etc. All colors in text should come from special markup language and not be hardcoded - if ie. web designer creates a theme with pink page background, your important RED text will be hardly visible. CSS decorations, icons...
  • stencil text (I invented this term) - things in oops*.tmpl where different "skins" want to put different functionality,
  • possibly even separate layer for translations
  • templates: files of used templating system, whether Twiki's own templatins system, or preferably industry standard one, like TemplateToolkit, HTML::Template, or another

YMMV but it helps me to call things which are different by different names.

Having a defined terminology set is a good idea. I understand and agree with the definitions for skin and theme. I don't understand the difference in your definition of skin vs stencil-text; both involve changing functionality, why use two terms? I don't think the definition of template is clear enough. Perhaps add something like "templates are the collection of all the above", but in words that don't sound so abstract and ethereal.

Possibly a case of too finegrained terminology. Stencil text: I was thinking that some skins might want to reorder some functionality, like move Attach from page menu into oopsmore, and it will be nice to have some building blocks shareable between skins, but smaller than whole oops* files. Templates are definitely not a collections of the above - they might be used to build the above.

Sidebar

[...] extracting the side bar from this skin [Plugins.DandruffSkin] as well as from tiger and gnu skins and package as a separate plugin. In addition, it should be possible to treat the sidebar variable just like any other one and thus override in web, user topic, or topic, if so wanted.

Having a side bar is really orthogonal to the other look and feel issues that are solved by a skin.

Ideally, the graphical appearance of the side bar is also shaped by templates and thus can be made subject to the influences of a particular skin.

  • Ability to enable/disable and edit sidebars, header and footer within TWiki (as in FlexibleSkin).

About putting the side bar in a separate plugin (ThomasWeigert): please give me ideas where to put the navigation? Because this is so severely lacking in the standard distribution (and in most Wikis for that matter). You see, a skin should not be only about appearances. The way the page is layed out, which features are presented where and when all contribute to the ease of use, usability and acceptance of Twiki. And there is a lot of work to be done on that part.

multi-level webs

  • Ability to accommodate multi-level webs (as in KoalaSkin).

JS Editor

It would be nice to see the Javascript editor functionality found in iejs skin included in this effort.

Bumpy Case (or not)

About the bumpy case (follow-up about Bumpy Case in Codev.WikiWordDiscuss) (ColasNahaboo): The Bumpy Case is some kind of "trademark" of wiki systems and these kind of "Standard" help users be confortable in using a wiki, not being locked in what they perceive as a weird syntax used only by one implementation)

I don't completely agree: how many wiki systems will the average end user see before working with one? How many times will the admin change the Wiki system? I bet the answers are: none, zero. Wikis are not well known or widely used. But when users see one, the second negative thing they will notice is the unearthly syntax, like it's some kind of programming language or secret code (BTW, the first negative thing is the lack of graphics - it does not look like a nice website). If you want Twiki to succeed, to be widely supported, make it look and function as humanly as possible.

One more to add to this: Wikipedia is perhaps the greatest advocate of Wiki. And they don't show WikiWord syntax.


I find Underlined_Words easier to read, and SquashedWords easier to type. And for me, the ease of editing is the main reason of using wiki technology in the first place. So if it comes to a vote, I prefer WikiWords. However I don't prefer it strongly enough to make it a sticking point, I'll go with the majority.

Per Peter, again moved and quoted previous comments to Codev.WikiWordDiscuss, not TWiki.WikiWord since that topic is reserved for discussion of the documentation. Please follow-up there regarding Bumpy Case or Codev.WikiWordDiscuss.

create a new page from existing topic

Today I got reminded about excellent feature - create a new page from existing, which lives in a page with less-than obvious name CloneTopicLinkUnderMore, and with almost zero chances to get into CairoRelease.

One stop Admin Tools page

I created IMHO cool feature (which nobody noticed frown ) AdminTools which integrates all links admin needs in one page, and allows to remove web maintenance issues from WebHome (my users asked it). On my test Twiki I even added logo (I have one per web), and result is pretty cool IMHO. But I cannot use logos from other skins, because I do not know where it is placed. My complain is, we do many arbitrary decisions, but do not document them.

* I noticed. I took one look and appropriated AdminTools into our work wiki. smile

Theme Manager

There is "theming" feature in KoalaSkin to allow people to redefine part of the templates for their site and per web. And they can go overboard with splitting the templates in small parts, since this includes no runtime penalty, due to the offline "compilation".

What would it take to merge the functionality in FlexibleSkin into Colas' implementation of a ThemeManager? I'm thinking that we need one theme manager and I want to make sure we don't lose the good functionality we've got in any of the existing functionality-rich skins.

For me the thing most holding back the Koala "ThemeManager" is the fact that I need server access to update the templates. Ideally they would be topics in the Plugins/TWiki web but it might be sufficient if they were attachments to the KoalaSkin page. Either way end users could change them and could guarantee that the content would not get interfered with during render. In fact, as they are revision controlled it might be better solution anyway.

Non-core Functionality (Features)

It is clear to me that features don't belong in the skins, it is like the flesh and skin on your face, all the functionality should come from the bone structure. It is clear that there are real benefits to be gained by all if we complete this initiative and real costs if we don't.

I agree that it's best if a skin doesn't add functionality, but at present we don't have a good alternative. For starters we'd really need a way for plugins to export functionality; I still think that one place to start would be the ability to add new capability that current goes into bin via a general purpose script that Plugins could extend. Additionally it's not always that easy to segregate skins from additional functionality, no matter how desirable.

Well, the alternative is to use the KoalaSkin method of generating this stuff. With so many skins I have to choose between the look based on the extra functionality embedded in the skin. This takes time and locks me into a solution that might eventually not suit my needs.

Search

Some improvements to the core search and save that everbody can agree on

savemulti, Direct Save, Skip Preview

With all this recent activity, much of it asking for savemulti to be in the twiki core, I would just like to remind people that PeterThoeny already said it would be welcome there. He even went so far as to say it could replace the current save and preview. The only thing needed is testing to insure it doesn't break anything. See SavemultiCgiScript for details.

user managed layouts

Note for the "user managed layouts" row in table above for SeeSkin: Users can specify their own css rules which are embedded in all pages they view, if they wish. The site administrator can specify rules which can't be overridden (requires editing the template and/or css files). Although this ability is there, I wouldn't encourage it's use. Instead I ask why the user feels the need to override something (e.g. it indicates a problem with the design).

About my 'N' in the table for "User managed layout": I think it depends on what we see as user. Like Matt I would discourage the layouting of the Twiki by the end users, except for having some shortcut links on or off. I think this should be a feature mainly for Twiki owners like admins, or you would weaken usability.

Structural (Re)design

CSS

The one request I would have for changes to the TWiki core would be to completely eliminate html text formatting (font, bold, italic, etc.) tags from the generated output and replace throughout with style-class references (e.g. <span class=warning> instead of <font size=larger color=red>).

Use CSS for layout as much as practical (I suppose getting rid of tables is not practical yet).

About tables, I think that is possible [to] not using them for layout purposes. There is a brazilian site about this theme: it "speaks" portuguese, but there are some amazing tableless sites examples. One of them is http://www.meyerweb.com/eric/css/edge .

  • Ability to manage overall look and layout of skin by editing or designating one file or topic (as in CopyCatSkin).

A different template system?

This might be an ideal time to use the TemplateToolkit and relegate TWiki's skin mechanism to a compatibility plugin. If there are large protests over this, consider the appeal of being able to lift skins off other sites. I would especially like comment from our usability crowd as to the attractiveness and viability of this suggestion.

The references to the TemplateToolkit above feel a bit like wishfull thinking, as noted in TemplateToolkit there are many barriers to adding it to TWiki. I would prefer a focus on what improvements (preferably with contributed code) to the existing mechanism are needed.

Usability

About improving usability: I am discussing this also in PatternSkinCodeChanges. At the moment I am writing flow diagrams to give food to concrete and detailed discussions about the order and number of templates. I have just added the flow of attachments. One (small) improvement I see here is to have a separate delete button for an existing attachment. Once deleted, you return to the page you came from. Please read the diagrams and add any comments.

After the flow diagrams are more or less finished, the next step will be to design page functionalities.

What we can do to make sure that good ideas about usability are promoted and easy to use for all skins, and are easy to install for Twiki admins to make sure they can find an easy way to users? I confess I am always little aware about any customizations, because on next upgrade I need either to redo them again, or loose them, unless they are in the core.

Before diving into creating all templates, we should also know what templates to create. Just copying the standard batch of templates will result in the same status quo of usability levels twiki has now.

Variables

Now that templates are discussed, I would love to see a general way to fill templates. I mean, IMHO, variable interpolation with Perl's s/// sucks. If you add another variable to the template, it isn't replaced by nothing, it's not replaced at all (the user sees a weird %SOMETHING%).

I guess to deal with this we'd have to differentiate template variables from normal topic variables. But, would this really help?

Localization

Another cool thing would be able to localize skins, with gettext or something similar.

FlexibleSkin and FreeSkin have a simple localization mechanism (include a single template file which holds alternate language messages).


TWikiSkin

Did you know there ISN'T EVEN A TOPIC for the Default skin? Wow. I'm surprised. Maybe I missed it.

FlexibleSkin and FreeSkin

Most features that other skins have should be able to be implemented in FlexibleSkin Special Topics, except maybe the edit features.

I'd like to pick up on earlier comments by StevenLumos & AntonioTerceiro about using FlexibleSkin to consolidate at the least the layouts of the various skins. I think this is a great idea because it would:

  • Provide a common framework for organizing the layout aspects of all the skins.
  • Would make the structure of the various skins more transparent.
  • Could faciliate faster innovation for the skins by making their modification that much easier.

For this approach to be really workable, it seems that FlexibleSkin would need at least one additional enhancement. That is the ability to quickly reference multiple sets of "special topics" for the various elements of the skin. That way, you could define a set of "special topics" for any particular skin.

BTW, I realize that this approach only addresses the layout aspect of the skins. Functional aspects of the skins (such as multisave) would have to be addressed in some other way.

For PatternSkin, What would be the performance hit if I use the FlexibleSkin approach of dynamically including top bar, left bar and bottom bar?

KoalaSkin

Con: KoalaSkin will be overkill for simple community sites not ready to complex contents. They'll have User, TWiki, Sandbox, Plugins system webs, and on, max 3 other webs. FlexibleSkin or Tiger II - HobbesSkinDev is much better deal for those, IMHO.

Counter Argument: Note that KoalaSkin does not force you into multiweb mode. For instance you can see that it works also with only one level, as is shown for the Koala_Skin web there: http://koala.ilog.fr/wiki/bin/view/Koala_Skin/WebHome. And moving the web around in the "hierarchy" does not break the URLs as they are note hierarchical in the file system, only as shown in the navigation bar.

KoalaSkin may be overkill due to its current implementation as a bash script, implying the installation of cygwin on windows (but maybe you need cygwin anyways for a TWiki install? No, not always, it's just the easiest )

PatternSkin

For myself, I am really impressed by ArthurClemens skin (see http://www.visiblearea.com/patterns from TooUglyForNonTechnicalUsers ) and I would like to see most of his points made mandatory for all skins (including mine :-). (perhaps except the use of underscores to denote links. The Bumpy Case is some kind of "trademark" of wiki systems and these kind of "Standard" help users be confortable in using a wiki, not being locked in what they perceive as a weird syntax used only by one implementation)

It's chock full of small usability details that are just excellent.

SimpleSkin

a group said they would be interested in TWiki IF they could hide all the edit-related menus behind a "menu" option. I note that SimpleSkin does this, seemingly by switching skins when the button is invoked.

My users are pushing me to reduce all items of complexity.

<heresy>It makes sense from point of view of plain user/reader: If s/he decided upfront not to update pages, why bother and get confused with all the links? wink </heresy>


As for the complexity element...I'm atypical in that I prefer a "busy" interface that minimizes the number of clicks required to do any particular thing. I know most users prefer having less to wade through, but for me a simpler interface is simply adding extra steps to get to what I want to do.

Too many control links in viewing with the default skin? That's certainly an interesting metric to help compare skins. This might also be due to the default pages in addition to the skin, but measuring what a skin offers by number of links in a brand new Main page might be useful.

Number of links is certainly a very important metric for newbies. It was exactly why I have Simple and Empty skins work together. In most extreme case Empty skin has 0 links - the only one to switch skin to SimpleSkin is hidden under logo. You will not believe how happy my users were seing no links in header. wink


CaboteriaSkin is a very simple skin, in fact the goal is to hide functionality since I've heard from a few newbies that TWiki's default skin is intimidating because it has too many links. CaboteriaSkin doesn't implement any new functionality but I'd definitely be interested in keeping it up to date with newer versions of TWiki.


The most important "feature" of MikebSkin was large buttons at the top of the page for the most-often used functions: Edit, Attach, Search, etc. The idea being to make those functions obvious to new users. I encourage new skin to consider that aspect.

TigerSkin and HobbesSkin

a revised TigerSkin called HobbesSkin, and the plan is to have it replace the original Tigerskin when I got the beta bugs out.

In email to TorbenGB and MartinCleaver, Steve explained that he is no longer immersed in TWiki work and thus happy for HobbesSkinDev to become TigerSkin, 2nd Ed. (Hobbes Ed).

GnuSkin

Just noticed that GnuSkin has both functionality in the skin in terms of a Plugin and in terms of scripts. These need to be consolidated.

How to go about it

I suggest that we take one of the skin plugins and consolidate all functionality into it. We then rewire all skins to use our new (albeit bloated) plugin and slowly rework that plugin to remove the duplicated functionality and improve its efficiency.

We then ban any new skin from directly adding functionality; such functionality would be directed at the consolidated plugin.

As a first cut I am talking only about functionality held as Perl. Functionality held as javascript should be consolidated but this is less urgent and can be done later.

There is also a wider issue of PluginBinNameClashes; again we need to go through a rationalisation process.

Use Flexible/Free Skin as structural base

In order to consolidate the layout aspect of skins, let's utilize the framework provided by FlexibleSkin and FreeSkin. Flexible uses tables for layout, while Free is wholly css. Other than that the two skins are very nearly identical.

FlexibleSkin implementation approach is based on a skeleton table, and it has less flexibility that it could have (although it is already very flexible when comparing with other skins).

It is really better if we use div elements, and style (place, color, etc) them with CSS just like it is done in Flexible Skin. The FreeSkin is based on this concept (no tables for layout, one topic for CSS definition, one for defining content before %TEXT%, and one for content after %TEXT%.

We can use the FlexibleSkin approach to lay out the page parts. That leaves us to decide what functionalities goes in which parts, but that should be up to the skin maker.

The reasons for doing this include:

  • FlexibleSkin is unique among the working skins in that it provides a general framework which should be able to accomodate the layout aspects of all of the other skins. In a sense, agreeing on the FlexibleSkin framework would constitute a quasi-templating system that is TWiki-based.
  • Translating the layouts from the other skins into this framework should be fairly simple.
  • Having the layout components defined within topics makes working with them much easier.
  • Having a shared framework would simplify the design of a skin installation and upgrade mechanism.

In line with this proposal I would invite a group of folks to pull together to consolidate the best of layout ideas from all the other skins within a FlexibleSkin framework and in the process complete the other skin templates (i.e. edit, preview, attachments, etc.).

In parallel to this effort, we could focus on designing a common framework for consolidating the functional features of the various skins. I don't really have a handle on this so I'll leave it to others. To my admittedly naive thinking on the matter, it seems like simply agreeing on a standardized syntax for using variables and plugins in skins would go a long way towards consolidation.

I don't know - it seems like we're having a lot of great discussion here but not much movement towards actually realizing our goal to ConsolidateFunctionalityFromSkins. It's my hope this approach can get things moving. I realize that discussions along the lines of TemplateToolkit may represent a more robust long-term approach, but it seems like that is a more involved and ambitious step than we are ready to make. Perhaps I'm being impatient but I'll looking for the shortest route to ConsolidateFunctionalityFromSkins and the FlexibleSkin approach seems very doable in the near term.

In other places a couple of people have mentioned that the Flexible/Free skin approach does not give the administrator anything but added complexity over .tmpl files. Please extend/correct this summary if I have it wrong.

The faults are: added processing time because the many INCLUDEs; a single template is spread over multiple pages necessitating many distinct edits when embarking on wholesale site customisation; personalising is harder because it's constrained - all the basic page divisions are all setup for you, you can only fill the predfined boxes, not place them.

On the processing time, the approach taken in KoalaSkin was to use TWiki template include system ( %TMPL:INCLUDE{"filename"} ), and make the expansion of these includes at template generation time. So I would push for not using %INCLUDEs, but some other constructs that can be pre-compiled. It is the shell function expand_template_includes in the KoalaSkin generation script.

Pre-processing sounds good if it doesn't make the system harder to configure. KoalaSkin uses scripts for this rather than Perl. Any chance of moving to Perl and maybe initiating the build of the templates via TWiki itself, e.g. an entry of a TWiki management page? Also we could extend TestenvCgiScript to check if templates have been expanded (using timestamps or generating to a separate area and warning of differences).

Actually, you can make the KoalaSkin template generation be done from TWiki itself, see: KoalaSkin#Enabling_generation_of_templates .Use of bash instead of perl is because, the older I grow, the more I appreciate simplicity... using a language whose documentation fits in a single man page (bash) is really attractive :-). This could of course be rewritten in perl.

The idea of previously generation of static templates is very good. If all those %INCLUDE%'s can be avoided, it will improve the view performance. This generation could be done with other script that will take as arguments the template base name(the "skin" name), the template type (view, etc), the name of the topic containing the CSS definitions, the topic(or the topic*s*, if we use one for defore and another for after %TEXT%) with the div elements, and generate a static template.

The gains are: free version control; anybody can tweak the design in true wiki fashion; you don't need shell access (a boon for hosted sites); personalising is easier because it's focussed - all the basic page divisions are all setup for you, you just have to fill the box, not place it.

Separate layout and appearance

It would be best if we tell what elements we want in one place, and how will them look like in other.

An outline which I think rebalances the flexible/free skin approach:

1) The html template design is held in a single wiki topic, that is each design is a complete page, not just a header or a footer or whathaveyou. There would be a different design for each mode (view, edit, preview, etc.). The current practice of having a master template which defines things used in common across many templates would continue.

2) The compartments (header, footer, menu, etc.) are contained in named div elements. They do not contain any presentational instructions (make this red, that bold, that tiny, the other thing a large shaded box). Most site admins should not need to alter the html templates at all. yes this can really work, at http://www.csszengarden.com/ all the designs share exactly the same html code

3) CSS sheets are designed in wiki topics, like the templates are. These are the things which will be changed most often to personalise the site. They contain instructions which say "put the div called menu on the left side, make it so wide, with a gray border and light blue background".

4) After the site designer (aka overworked administrator) has finished monkeying around with the templates and styles sheets there is make template function which processes the design topics and makes static templates. This cures the performance problem brought on by INCLUDEs.

For the administrator (aka struggling designer) to be able to do their work there needs to be dev mode toggle which means "use the design topics not the static templates". When activated only the current user and the current browser session is affected. This means one can work on a live production site without worry.


Contributors ThomasWeigert ColasNahaboo LynnwoodBrown PeterMasiar MartinCleaver EstebanManchado DaleBrayden JeroenVanDongen GrantBow AntonioTerceiro MattWilkie StevenLumos TomKagan ArthurClemens TorbenGB WalterMundt TobyCabot JohnTalintyre VinodKulkarni MikeBarton RaviASV


Unclassified Ideas

I couldn't fit these ideas/suggestions into the framework of this topic, as I don't really understand what they mean. Perhaps you can? smile -- MattWilkie 19 June 2004


In essense, the following functionalities are different, and can be independently contributed by different people.
  • Views on Topics. They design different views such as default view, edit, publish, print etc. With each view, the contents are decided, and overall functionalities are decided.
    • One small note: 'Edit Table' button appears in default view, but it shouldn't appear in publish view.
    • Spreadsheet, generate PDF, and similar other functionalities are also views.
    • All views should be explicitly named, and can be used with syntax such as =%VIEW('edit')%. The non-standard view providers use syntax that also uses plugin name as part of that view.
    • Views supply default icons, and layouts can override these icons with their own icons.

  • Functionality modules. They are similar to views, but also generate content for the view. And they shouldn't bother how the content is rendered. The functionality names share view name space.

  • Layout designs - provide different layout designs. Within a single Layout design, they support multiple, generally recognized views. If the view is special (say spreadsheet), the view designer should be able to contribute a new layout-topic for that view.
    • Screen is divided into different areas, and each area can be edited.
    • Apart from %VIEW{'edit'}% buttons, they can also reference named text such as =%TEXT{'projects'}% where 'projects' will come from content of page. To enable this, the view algorithm is modified so that, a hash is constructed from specific definitions. INCLUDEs are processed before this phase. This will allow us to let each topic contents decide look and feel of that topic. So I might INCLUDE a project list in a topic, and have it visible in left navigation bar.

The skin designer merely packages these independent designs to give an integrated view.

Template engine doesn't allow variables to be defined in topic contents (but allows them to be referred). So I feel it is just a minor enhancement.

-- VinodKulkarni - 12 Jun 2003


Furthermore, you can't change the variable syntax if you do those substituions by hand. I think fixing this would allow us to change, in the future, the current implementation with TemplateToolkit or whatever.
  • Can you please expand on this, I don't follow your point. [ JohnTalintyre 10 Jun 2003 ]

About Perl direct substitution, we are mixing the purpose and the current implementation this way. I mean, there should be a module or something (perhaps just a function) to do the substitution. Right now, we can't, for example, change the implementation without changing all the scripts that use templates and interpolate variables. And, what is perhaps worse, we can't add new custom variables to templates, because the other scripts using them (the templates) won't interpolate the custom variable and it will appear as is (%VARIABLE%) in the final rendered page. I say so because it has actually happened to me, with the search template and some extension (to colorize the results) made by PhotonSearch.

Now you say it, I had not thought about the difference between template variables and topic variables (I assume you are referring to the variables interpolated by plugins when you say "topic variables", right?). Yes, I think they should have a different syntax, or at least we should have a catch-all substitution in a default plugin.

What I meant by the last paragraph was that we can't change the current template variable syntax until we refactor the by-hand substitutions by a centralized base function. For example, if instead of the current:

$tmplHead =~ s/%SEARCHSTRING%/$search/;
We did something like:
TWiki::substvars($tmplHead, {'SEARCHSTRING' => $search});
Then we could change the current template variable syntax, and probably a lot of code would be cleaner and more maintainable (imagine 10 or so substitutions by hand, and a single function call with 10 values in a hash)

-- EstebanManchado, -- JohnTalintyre


Maybe it's me - maybe I am not patient enough. And maybe our process is failing.

GRIPE: Anyone would think that the 'Core' Team doesn't read this topic; I'd have thought they would at least bother to endorse the ideas, or respond to our calls for other plugins to be installed here on TWikiDotOrg. /GRIPE.


Belongs in another topic:

Example 3: CGI::Application community wanted a wiki for FAQ. I set up Twiki, but they decided to go with a Kwiki, even with less features (currently no edit clash protection, TOC, namespaces=webs, email notifications, COMMENT plugin). I just realized I need to ask why ...:-(


I'm no longer actively using TWiki. Perhaps in the light of Martins 'pressing issues list' it's interesting to share the 'why'. My main driver to move onto something else was the lack of support for structured data (defining datastructures, storing them and retrieving them, querying, etc.). I guess I was trying to use TWiki beyond its architectural limits, and I've a feeling a lot of people are doing that.

Anyway, this [skin consolidation] is a move in the right direction IMO.

-- JeroenVanDongen - 18 May 2003

Hi Jeroen, This is a little off topic, but what have you chosen to use instead? I agree TWiki currently has architectural limits, but I don't know of any other systems that fit my needs any better for this type of thing.

-- GrantBow - 19 May 2003



Refactoring Notes: (since rev1.87)
  • first pass at consolidating the comments on consolidating the skins. -- MattWilkie - 08 Jun 2004
  • second pass, some shape is beginning to coalesce from the mist -- MattWilkie - 09 Jun 2004
  • third pass, more consolidation. Note that the section headings are not well thought out, feel free to conflate/rename/move around -- MattWilkie 10 Jun 2004
  • finally finished consolidating discussion. {whew!} Next step is to start weeding out repititions and redundancies. Feel free to pitch in. smile -- MattWilkie - 19 Jun 2004
  • removed longform contributors list; refactored from beginning to 'features table'
Edit | Attach | Watch | Print version | History: r95 < r94 < r93 < r92 < r91 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r95 - 2008-09-15 - TWikiJanitor
 
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.