Tags:
create new tag
, view all tags
We have been working on a new skin for TWiki to meet the requests of users to have a somewhat slicker interface than the "classic" TWiki.

This skin is now called TigerSkin - and has (finally) been properly packaged!

drkwskinexample.gif
Example of our new skin

The main requirements expressed by our users and web design experts were:

  • Make the UI fit in visually to other bank intranet sites

  • Provide graphical clues to help first time users understand the concepts of topics and webs

  • Expose the Big Features of TWiki (edit and attach) and hide more advanced concepts (revs, diffs...)

  • Provide a web/topic menu that can handle 100s of topics & webs while staying compatible with today's TWiki mechanics (ie a flat tree with just two levels of abstraction)

  • Give users the ability to personalize their menus (and styles) - a way to offer a relevant view to each user from a large number of topics

We started by using the current skins capability (and can instantly switch back to the classic skin for those who prefer it) - but learned that there are a few minor improvements to the current TWiki that could really increase the potential of skins:-

REQUEST 1 - REVISIONS

The view script has "hardwired" the split character as "|" and the anchor as "a href..." . By making these TWiki.cfg parameters, the REVISIONS can be displayed vertically by substituting BR for | and they can take any "a class=xxx href..." thus allowing them to be stuck into a rollover menu.

REQUEST 2 - Template Organisation

It is a big chore to create and synchronize changes across all 51 templates. However in the most part the skin template can sit before and after the classic template. We added the following to Store::ReadTemplate() to circumvent this chore...

# "read the template file
    if( -e $tmplFile ) {
        my $txt = &readFile( $tmplFile );
        
        # Modify views for DrKW style
        if ( -e "$tmplDir/drkwtop.tmpl" && $tmplFile !~ m|/view.| ) {
            my $top = &readFile( "$tmplDir/drkwtop.tmpl" );
            my $bottom = &readFile( "$tmplDir/drkwbottom.tmpl" );
            $txt =~ s|<TD[^>]*>.*?wikiHome.gif.*?</TD>||smio;
            $txt =~ s|%WEBBGCOLOR%|#e3f0e3|go;
            $txt =~ s|<BASE.*>(.*)|$1|;
            $txt =~ s+<TITLE>+<LINK href="/twiki/pub/skins/drkwleftnav/twiki.css" rel=stylesheet type=TEXT/CSS>\n<TITLE>+smio;
            $txt =~ s+\s*(<TABLE[^>]*>.*?</TABLE>)(.*)(<TABLE[^>]*>.*?</TABLE>\s*(%WEBCOPYRIGHT%)?\s*(</FORM>)?)\s*</BODY>+$top$1$2$3$bottom</BODY>+smio;

        }
        return $txt;
    }
    return "";

We would like to see the current templates structured so that the header and footer can be easily parsed and stripped out but leaving template specific parameters alone...this would not affect the performance of the classic skin significantly.

errr...that's it smile

-- SteveRoe - 20 Apr 2001

Looks quite nice. Wish I had that much time to spend on TWiki. wink

So you'd prefer the Topic content to be rendered seperately from the Topic's view interface, as it were.

How is things like subtopics likely to effect your development?

-- NicholasLee - 22 Apr 2001

Currently the menu is independent from the web/topic structure - the menu items are literally a new topic (TWikiDRKWLeftMenu on our site) that we just update manually. The UI design already supports two levels of hierarchy. The next step in our work is to parameterize the menu - that is to parse the site/web preferences and to show whatever has been placed in the WEBTOPICLIST. Just as with the current WEBTOPICLIST, the "display name" on our menu does not have to be the actual topic name - so we can create (artificial) collections of webs for ease of navigation.

So, while I have not been following the debate on subtopics in depth, I expect that there would/could be some kind of reflection of the tree in the WebPreferences that evolves the classic skin "navbar" to help users navigate around the new structure? [Or would there be a tree of WebPreferences pages - that overrides/modifies the root each time you step in a level?] Anyhow, the visual menu design can easily adapt to whatever is added for subtopics.

From our skin perspective, we will probably add a 3rd level of hierarchy to the menu - this should be even more flexible in terms of content hiding and coupled with the notion that the display name need not be the web or topic name should provide a full solution for any reasonable site. With my UI design hat one, I am a little wary of deep tree structures for navbars (and there is the question of how to represent the layers without running out of real estate).

-- SteveRoe - 23 Apr 2001

At the moment I'm working on subtopics as a way of abstracting certain specific content relationships. ie. Attachments. Topics contained within Webs contained within a Wiki.

Look for an interface like

@siblings =  $topic->parent->children()
.

Rather than say a generalised method for organising information.

-- NicholasLee - 23 Apr 2001

Some more on generalising templates. At present most templates have a nearly identical header and footer, each being a table.

The templates could instead look something like:

%HEADER{action="(edit)" description="Change topic"}%

   stuff specific to template

%FOOTER:START%
      button1 (html)
      %SEP%
      link1 (html)
%FOOTER:END%

The data for these new variables could be contained in a special template e.g. headerfooter.html. Which would itself be skinable. Only cost here is one extra template load per view. Advantage is easier template maintenance and much easier skin generation (where a skin doesn't just affect the view template).

-- JohnTalintyre - 23 Apr 2001

Of course the question then arises if we go down John's course, we reinvent the wheel. Template Toolkit or something similar might be a path to consider.

-- NicholasLee - 23 Apr 2001

In what way is this reinventing the wheel? also, the code for the above is pretty simple.

-- JohnTalintyre - 30 Apr 2001

I've found http://www.template-toolkit.org/ which looks very interesting. Looks like it could be used in TWiki, but would its areas of overlap could be confusing. Is this the best Perl template processing package around?

-- JohnTalintyre - 22 May 2001

Depends what you mean by best.

There is a whole pile of template systems, see http://search.cpan.org/search?mode=module&query=template

PageKit and HTML-Template are quite good as well. I think though that TT is the most mature and maybe the fastest. Haven't looked at them for 9 months so I'm not sure what the state of art is at the moment.

-- NicholasLee - 22 May 2001

... Two years later...

Is still feasible/under consideration/possible to abandon homegrown template system and reuse mature invented wheel?

-- PeterMasiar - 02 Apr 2003

If it is still feasible, I think Mason would be a good candidate. I've been using it for years, so maybe I'm a bit biased ... but I use it for all kinds of things, from simple to complex. Mason is very powerful. Actually have considered porting TWiki to Mason, but that's way beyond my available time. Anyway, see http://www.masonhq.com/ for more on Mason.

-- PascalEeftinck - 18 Sep 2003

Topic attachments
I Attachment History Action Size Date Who Comment
GIFgif drkwskinexample.gif   manage 41.7 K 2001-04-20 - 10:57 SteveRoe Example of our new skin
Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r15 - 2003-09-18 - PascalEeftinck
 
  • 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.