create new tag
, view all tags

The position of the edit bar should be a preference

(Headings added by MichaelSparks 14 June 2003 to make navigating this discussion easier)

The edit bar shown at the bottom of the screen for people to edit with should be a preference. Currently it is hardcoded in the templates as: "Edit | Attach | New | Ref-By | Printable view | Raw view | Normal view | See diffs | Help | More... "

Making the edit bar a preference would:

  1. Lessen the need to edit files in /template and thus simplify installation and upgrades
  2. Provide commonality between skins
    • including the ability to turn off the edit bar / have it show in a dual state like PeterMasiar's SimpleSkin
    • allow administrators to change it on one skin and have it apply to all skins on the site
    • ...
  3. ...


  • Difficulty I guess this is a trivial change.
  • Impact High


  • It would probably need to be a FINALPREFERENCE at the web level
  • It may have a performance impact

Core team comment:

  • ...

Code Contributions:

  • If you have implemented this feature, please attach the code to this page.

Related topics:

-- MartinCleaver - 11 Jun 2003

This can be done using FlexibleSkin

If you use the FlexibleSkin approach, this can be put in the bottom bar. That way it is trivial to edit the links.

-- ArthurClemens - 11 Jun 2003

Why not use CSS and/or Frames ?

MattWilkie has, in the SeeToo skin, done something fundamental in this area.

  • The whole of the screen is the topic - no borders, decoration or Windows-XP-like descoration eating up screen real-estate.
  • The menu bar "floats" at the top of the screen and stas there as you scroll up and dcown the topic.

All this is done with CSS. By comparison, the way the Tiger skin works seems like a throw-back to a "framset" model. before you dismiss them, framesets do have the benfit of not having to redraw a lot of the screen.

The menu items on the left only cause the middle display area to be redrawn.

Pardon the commercial site. Again frameset, but hierarchially nested context. See the littke "books"? Click one to open it. OK, so this may seem simplistic, but the millions of mymidions have been conditioned by Microsoft's rools to work like this and find it familiar and even call it "user friendly". If they're conditioned it already its a classic example of "don't make me think" interface design.
  • Sorry, I just can't resist to comment here: the little books just look like smal icons, not like buttons. If you're interested, read a bit about Donald Norman's The psychology of everyday things ( book, article about ) and the notion of affordances. In short: if it looks like a button, people will be inclined to push it, if it doesn't, people will fail to see its intention. -- ArthurClemens - 12 Jun 2003

Yes, I know that framesets are [[FeatureXIsIsNotEvil["evil" in Wiki terms.]] But what is something like Tiger skin if not something that looks just like a frameset? Are we not making a virtue of a necessity because we don't know how to make a Wiki work in a frameset?

There is a middle ground.
The top bar and the left menu bar and the scrolling body of each of those examples can be done entirely with CSS. Yes, the whole lot gets re-drawn evey time as is "the Wiki Way". Matt and I have been discussing this. The main impediment is Microsoft and the fact that IE5 and IE6 don't correctly implement CSS2. It takes time to experiment with work-arounds and find discussion of them on the 'Net. We'll get there in due course ...

For those of you registerde, look at http://www.techrepublic.com/article.jhtml?id=r00720030605shm01.htm&fromtm=e032

-- AntonAylward - 12 Jun 2003

Frames go against the Wiki Way - they exclude users, "just" a skin issue

Refactored comments on suitability.

  • Using frames is inappropriate for lots of reasons. This comment was framed in the mode of feature x is/ is not evil. -- PeterMasiar - 13 Jun 2003
  • This led to a response from AntonAylward (14 Jun 2003) claiming that, [[FeatureXIsIsNotEvil#Troll_Point_No_feature_is_evil_i][the feature itself was not evil just it's use and context] can cause problems, as well as benefits.

Also I've added some comments on feature x is/ is not evil as to why I feel frames are wholely inappropriate in a Wiki context. Frames were designed for certain uses at a certain time. Many people encourage their disuse. Even many CSS advocates would argue that virtually everything anyone uses framesets for can be done using CSS! (or CSS+DHTML which falls back cleanly on old/odd browsers)

That said, this topic as far as I can tell is actually about moving the edit bar - this is "just" a skin issue(*), not a core twiki issue. Implementation of the default layout (whatever that might be that year) using something like FlexibleSkin - ie modifiable in the browser - is what makes most sense IMHO. In all my skins, the edit button is at the top smile (But I leave the save button at the bottom to inconvenience the user to encourage re-reading of content)

  • I say skin issue, not usability. The desire to put it there stems from usability, the ability to put it there is a skin issue. I say "just", because it only affects one small area of twiki, just as important as all the other bits.

-- MichaelSparks - 14 Jun 2003

I have created a topic UsingFramesInTWiki to discuss the tradeoffs of using frames. I am presently using a very, very, minimal skin that has one frame for command buttons, and another for the text.

-- AndyGlew - 26 Jun 2003

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2003-06-26 - AndyGlew
  • 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.