create new tag
, view all tags

Feature Proposal: WebTopBar and WebBottomBar Should be Customizable on a per-web basis


I've read the arguments at Bugs:Item2136. I disagree. I agree with WillNorris, "I expect Web prefixed topics to apply web-wide." The failure of WebTopBar to be modifiable violates the Principele of Least Surprise.

Also, in a large company, there is a higher likelihood that teams will wan to customize the WEB top bar separately from the Site top bar. For example, Engineering vs Marketing vs Sales vs HR...

I'm in a company with 1000 webs and 14000 people. We had this functionality in Cairo... perhaps our admins instaled it themselves in a custom version of the skin, but the point is we have been using customized web top bar at my company.

Now, in TWIki 4, as installed, it no l;onger works. People are unhappy. Web look and feel is broken.

TWiki should never sacrifice functionality, customizability, and power for "simplicity" of creating the templates.

(Typo fixed 2010-08-08. We had 1000 webs in 2008, not 100 - VickiBrown)

Description and Documentation

copied from Bugs:5498

Arthur says "I haven't come across the question that often on IRC or Support.". Keep in mind that TWiki is used predominately behind corporate firewalls - where questions come up in local forums. This question has arisen again in our local discussion list and is ikn our bug database. It's not an uncommon question, only a question that doesn't get taken to twiki.org.

Use a conditional. IF %WEB%.WebTopBar exists, use it, else use the page in %TWIKIWEB%=. But TWiki should be customizable web by web.

-- TWiki:Main/VickiBrown - 03 Apr 2008

quickly reading Bugs:Item2136 Kenneth seems to be indicating that he'd like to see a feature request with analysis and discussion - I presume mostly to make sure there are no hidden gotcha's

Its not going to be hard to implement as a 'if local WebTopBar exisits, use it, else fall back to the TWiki web one - so I don't really understand why not - but that just shows that maybe more discussion is needed ?

-- TWiki:Main.SvenDowideit - 04 Apr 2008

I agree with Kenneth and Sven. This report is not about something documented that is supposed to work but doesn't (a bug), but about something that could work in a different (enhanced) way: a Feature Proposal.

-- TWiki:Main.GilmarSantosJr - 04 Apr 2008

Well, no, actually, it Was documented and USED to work and no longer does.

WebTopBar was customizable pre- TWiki 4. IN fact, somehow, two of the webs at our company are still able to customize WebTopBar. The name of the page implies a web-specific page.

It used to work; it stopped working. It's expected. Therefore: bug.

-- TWiki:Main.VickiBrown - 16 Apr 2008

I just checked Cairo (last release before TWiki 4.0).

The WebTopBar belongs to the PatternSkin only and is called one place: twiki.pattern.tmpl

%TMPL:DEF{"topbar"}%<div class="twikiHidden"><a href="#Content">Skip to topic</a> | <a href="#PageBottom">Skip to bottom</a><hr /></div><div class="twikiTopBar"><div class="twikiTopBarContents"><form name="top" action="%SCRIPTURLPATH%/view%SCRIPTSUFFIX%/%WEB%/%TOPIC%"> %INCLUDE{"%TWIKIWEB%.WebTopBar"}%</form></div></div>%TMPL:END%

So it is included from TWIKIWEB. Not from local web.

Next let us look at TWiki.WebTopBar

<div class="twikiLeft">
<a href="%WIKILOGOURL%"><img src="%WIKILOGOIMG%" border="0" alt="Home"/></a>
<div class="twikiRight twikiSearchBox">
<table border="0" cellpadding="0" cellspacing="0">
<td><label for="go">Jump: </label><input type="text" id="go" name="topic" size="16" /></td>

From this you can see that the part that can be tailored is the WIKILOGOURL and WIKILOGOIMG so you can replace the image and the link that clicking on the image leads to per web by setting the two variables in WebPreferences. This is still the case.

And what about the documentation in Cairo?

The WebTopBar is described in PatternSkinCustomization.txt and it says

These parts are dynamically included topics:
   * Top bar: TWiki.WebTopBar 
   * Left bar: included topic WebLeftBar (one !WebLeftBar topic per web)
      * Personal links block: %MAINWEB%.%<nop>USERNAME%LeftBar. Your own personal leftbar: %MAINWEB%.%USERNAME%LeftBar
   * Bottom bar: included topic TWiki.WebBottomBar 

So documentation says clearly that you find the WebTopBar in the TWiki web. So the only real valid argument is the name of the topic.

NOW how big a problem is it for an admin to change the WebTopBar to be local to each web?

We move forward to 4.2.0

The inclusion has now moved to viewtopbar.pattern.tmpl

%TMPL:DEF{"topbar"}%<div id="patternTopBar"><div id="patternTopBarContents">%INCLUDE{"%TWIKIWEB%.WebTopBar"}%</div></div><!-- /patternTopBar-->%TMPL:END%

So all you have to do is remove the %TWIKIWEB%. from the INCLUDE and put a WebTopBar in each local web.

Or you can change the line to

%TMPL:DEF{"topbar"}%<div id="patternTopBar"><div id="patternTopBarContents">%INCLUDE{"%TOPBARWEB%.WebTopBar"}%</div></div><!-- /patternTopBar-->%TMPL:END%

and define the TOPBARWEB in Main.TWikiPreferences to be "TWiki" and re-define it in those webs where you want an alternative top bar.

There are other ways to do similar thing.

Without access to the templates but as admin you can alter the TWiki.WebTopBar to include a local topic !%BASEWEB%.LocalWebTopBar.

And another fun way is to edit the WebTopBar in the TWiki web to say

%INCLUDE{"%IF{"istopic '%BASEWEB%.LocalWebTopBar'" then="%BASEWEB%.LocalWebTopBar" else="%TWIKIWEB%.LocalWebTopBar"}%"}% 

Or again editing the template replace the simple include by

%INCLUDE{"%IF{"istopic '%BASEWEB%.WebTopBar'" then="%BASEWEB%.WebTopBar" else="%TWIKIWEB%.WebTopBar"}%"}%

The latter is probably the most logical.

So this is not such a big deal and relatively easy for anyone to implement as it suits them

But now comes why this needs to be discussed as a feature proposal.

What annoys me when I upgrade TWiki is that my tailored WebTopBar gets overwritten. And additionally I would not want to have a copy of the top bar in each web because I use the same bar everywhere.

So maybe I would rather have the template default to including Main.WebTopBar and fall back on TWiki.WebTopBar.

Such a change deserves a little discussion. Therefore a proposal topic should be made. (Copy all of this to it).

-- KennethLavrsen - 16 Apr 2008

Interesting. I really though that WebTopBar was per-web in Cairo. Did my company edit the templates?

I still think that WEBTopBar needs to be per-web in TWiki (it's expected. It looks like WebLeftBar. It "should work")

I would recommend putting the conditional into the template as you indicate above. It's logical and it "just works" seamlessly.

TWIki should not sacrifice power and functionalioty for "simplicity" in the skin templates.

And I absolutely agree that things like this that get customized need to move into Main and out of TWIKIWEB

-- TWiki:Main.VickiBrown - 17 Apr 2008



WhatDoesItAffect: Documentation, Skins, Usability



These things come at a price. You propose to add a check for the existence of a topic, for every page view. Can anyone shed a light on the performance penalty for this?

-- ArthurClemens - 17 Apr 2008

Valid point Arthur. This will hit every single page view.

-- KennethLavrsen - 17 Apr 2008

You are already checking for the existence of a topic TWiki.WebTopBar (which happens to exist by default) none the less, the call is there. As I understand the FeatureProposalBugFix above, We could be checking for WebTopBar instead which could be an

by default (or until changed by a Site Admin, per web, post install. I'm not sure there much of a penalty for the
but I'm hardly qualified to say. FWIW I think its a reasonable feature to have considering the importance of backward compatibility with previous installs which expected the behavior with web specific WebTopBars created during older versions. besides its just nice to have Web Specific Top Bars (if for no other reason than to allow different company departments to display their own Web logo)

-- TravisBarker - 18 Apr 2008

To be propoerly consistent with TWiki's approach to customisations, this feature should actually:

  1. if Main.WebTopBar exists, INCLUDE it (this topic should not be shipped
  2. else INCLUDE the default, and shipped Main.WebTopBar

The end user then has the option to make it more complex. Same thing for WebLeftBar really, as some users would prefer leftbar to also not change.

-- SvenDowideit - 18 Apr 2008

A customizable top bar is a "nice to have" feature, but it should be done with usability in mind. The logo in the upper left corner is commonly understood to link to the homepage of the site. Don't change it unless you want to violate the "don't make me think" principle. It makes sense though to personalize the top bar by web. This can be done with a web specific image, text or color without touching the home logo. See for example the screenshots 1 and 2 of the Wind River Intranet TWiki at HomePageNavigation.

-- PeterThoeny - 18 Apr 2008

Travis. As I showed above the WebTopBar has always been site wide. I have checked in both Cairo and the TWiki4.0/4.1 versions. Vicki has a large site where someone at some point has customized some webs to have a local top bar. There is no compatibility issue here.

What Sven proposes is also my personal preference. I always use a customized WebTopBar but it is site wide.

Travis. The problem with performance is not the INCLUDE. An INCLUDE does not check for the existence of a file. It assumes it is there and just includes it. It is the IF statement in my example.

%INCLUDE{"%IF{"istopic '%BASEWEB%.WebTopBar'" then="%BASEWEB%.WebTopBar" else="%TWIKIWEB%.WebTopBar"}%"}%

Before anything is INCLUDEed an "istopic" check is run and as far as I know this takes time and it is time added to every page view. We need to measure this penalty.

Using a new TWiki Variable TOPBARTOPIC that defines the location of the WebTopBar (which defaults to TWiki Web) would be very flexible. It would be even more flexible if this variable defined both web and topic name of the WebTopBar.

  • Sven and I could have our preferred behavior by defining this variable in Main.TWikiPreferences to point to a WebTopBar in the Main web. This would not be altered when upgrading.
  • Vicky would simply define this variable to be WebTopBar without any prefixed web name. Again defined in Main.TWikiPreferences to it does not get altered when upgrading TWiki.
  • Default value defined in TWiki.TWikiPreferences would point to TWiki.WebTopBar making it 100% backwards compatible with existing TWikis. The default would be defined as " * Set TOPBARTOPIC = %TWIKIWEB.WebTopBar.
  • A TWiki variable in the template would not cost performance. We already use TWIKIWEB in the current template at the place where we include the top bar. Instead we just make an %INCLUDE{%TOPBARTOPIC%}%

Having web based top bars is not a request we have heard often before. In fact it is the first time I hear it. But I can understand the need. But the need can be fulfilled in many ways and more or less automated.

I would prefer the new twiki variable way because it allows more flexibility.

With this I can even define the %TOPBARTOPIC variable in individual topics and use a very customized top bar on special pages.

Only negative is that it adds "yet another variable".

-- KennethLavrsen - 18 Apr 2008

This is also assuming that the customised WebTopBar is always the same hight (64px). In my case I have been asked to create a new top bar for a particular web that is 123px high. To do this I took the viewnotopbar example template and edited it to make a new skin that changed the top bar and the positioning of the rest of the page elements. Now my skin path looks like myskin, tagme, webpermissions, pattern. According to firebug, the performance hit isn't that great.

-- DavidPatterson - 18 Apr 2008

Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r10 - 2010-08-08 - PeterThoeny
  • 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.