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:
- Lessen the need to edit files in /template and thus simplify installation and upgrades
- 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
- 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:
- If you have implemented this feature, please attach the code to this page.
- 11 Jun 2003
If you use the FlexibleSkin
approach, this can be put in the bottom bar. That way it is trivial to edit the links.
- 11 Jun 2003
Why not use CSS and/or Frames ?
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
- 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
(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.
- 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.
- 26 Jun 2003