UsabilityIdeasArchive

Always be careful to throw away old ideas. This page will document them for the future.

---

Post usability problems right here: interface and navigation difficulties, problem features, docs and help quality, suggestions and ideas - newest on top.

• Use your judgement on issue-or-Bug calls (ex: annoying button placement is probably an issue; Bug's relate to program actions, not simply hardcoded template stuff).
• Put your entry in one of the sections below: Searching, Editing, Distribution, etc. If none is applicable, create a new category
• If comments develop here, move entry to a separate FeatureEnhancementRequest topic. If no one comments, either move to the OldUsabilityIdeas, or if you're determined, start a new FeatureBrainstorming or Request topic anyway.

---

---

File Attachments

Change file uploads so that selecting a file's action and then uploading a different filename will not create a new file in progress

This has caused a lot of confusion in my company, even though right at the bottom of the action page it clearly says what is going to happen if they change the filename. It goes against the principle of 'least surprise' apparently. They are probably right, so I think this should be fixed.

For example, you upload a file called a.txt. You then click on 'action' for that file, and decide to upload an updated version of that file. Your next version is a2.txt. You upload the file, but it doesn't get renamed on the fly and updates a.txt, it creates a new file in the file list called a2.txt. Confusing for StupidCorporateUsers.

-- NathanOllerenshaw - 01 Jul 2003

I'm determined to fix this, as it is the last thing that my StupidCorporateUsers are complaining about. I've made a feature request at UpdateAttachmentsDontWorkAsExpected.

-- NathanOllerenshaw - 02 Jul 2003

I concur, this would be a useful change. With a slight change in wording, it's not only stupic corporate users who get confused.

-- MattWilkie - 02 Jul 2003

Status

This is an interaction flaw that should be repaired. Taken up by NathanOllerenshaw. See UpdateAttachmentsDontWorkAsExpected for progress.

---

Make managing attachments more intuitive

The attachment management screens should work more like a normal file manager.

• 'action' column should have 'view', 'move', 'rename', 'delete' links on each row.
• 'attribute' column managed via checkmarks on each row.
• No need to display 'Update attachment' - just allow for an upload. If the name is the same as an existing attachment, it's an update (warn user?).

-- TomKagan - 27 Dec 2002

The main difference between a file manager and a web interface is that with the file manager you can change options real time, whereas on the web you need to submit your changes. So moving all attachment editing options to the attachment table would not make things always clear: when does the change take effect? Changing the properties of one attachment at a time makes sense.

I do agree that visibility can be improved:

• 'action' can be changed to 'edit'. See KOALAwiki.
• View, Move, Delete ("Move to Trash") can be made buttons.

If the bug above (Uploading a different filename should not create a new file) is solved, you can keep 'Update attachment'. Uploading a file with a different name should then replace the old file.

-- ArthurClemens - 31 Aug 2003

Status

Changes proposed in PatternSkinCodeChanges. -- ArthurClemens - 31 Aug 2003

---

Searching

Make simple search look for all words (instead of phrase search) implemented

At the moment simple search looks for the literal occurence of the phrase entered. In my opinion this is a usability problem as the average user is used to a different behaviour: When using search engines (e.g. google) the default often is to search for all words entered.

Thus I propose to change the simple search to KeywordSearchWithImplicitAnd by default.

-- DanielKabs - 10 Feb 2003 Updated: -- DanielKabs - 12 Feb 2003

Status

Feature implemented by KeywordSearchWithImplicitAnd and SearchScopeForTopicAndText and is scheduled for CairoRelease. CairoRelease has been completed and published with TWikiRelease01Sep2004.

---

Combine search in topic text and topic title patch available

In WebSearch I have to select either one through radio buttons, but why can't they be checkboxes? Now I have to perform the search twice. -- ArthurClemens - 05 Jun 2003

Status

Patch available at SearchSuggestion, by SamHasler. Suggestion: check code and include in Core, implement change in WebSearch.

---

Editing and topic creation

Automatically create new webs

Currently if you got to a topic in a web that doesn't exist you get the oopsnoweb page.

It would be nice if it was configurable if you get oopsnoweb (which links to ManagingWebs where it can be created) or if it created the web automagically.

-- SamHasler - 10 Feb 2004

Save in edit-mode should be designed more convenient

The normal user works on documents by using the Desktop-metaphor, which can also easily be applied to TWiki by "save" and "save & close" options during editing. (see BetterSaveBehaviour)

-- AndreUlrich - 09 Feb 2004

Status

Code for direct-save is already available -> SaveContentWithoutEdit and has only to be integrated into the TWiki-Codebase. User interaction has to be designed and translated to templates.

-- AndreUlrich - 09 Feb 2004

---

Redirect to WebTopicEditTemplate topic when clicking on question mark link

From Support Web:

I would like to let the user select a template when creating a new topic. I understand (or think ) that this can be done by editing the WebTopicEditTemplate topic and adding a combo box containing all existing templates or whatever (see PerTopicTemplates ).

But what if the user does not use the "Go" box to create the new topic but by adding a WikiWord and clicking the question mark? Can I somehow redirect to the WebTopicEditTemplate topic?

(I would like to see a behaviour similar to that of MoinMoin Wiki, see http://twistedmatrix.com/users/jh.twistd/moin/moin.cgi/WikiSandBox )

-- KlausNowikow - 25 Jul 2003

Should this become default behaviour? If you work with templates, then this would be a big improvement. If you do not, however, this will take an extra step. Implementation issue: if you have a combination of parent AND template selection on WebTopicEditTemplate (see DynamicEditTopicTemplate), some values have to get prefilled.

-- ArthurClemens - 20 Aug 2003

Status

---

Set "Release edit lock" checked by default

See comments at: PleaseUseReleaseEditLockCheckboxVariable

-- ArthurClemens - 06 Jun 2003

Status

---

Simplify deleting a page implemented

As it is now, a page is deleted by 'moving' the page to the '_deleted' web. This is a little awkward. This 'move' should be hidden from the user with an action link. A 'delete' link should handle this transparently to the user.

-- TomKagan - 27 Dec 2002

Status

Patch available in DeleteTopicShouldNotFollowIt. Patch is also applied in TWikiAlphaRelease and TWiki.org. Idea can be moved to OldUsabilityIdeas.

---

Create a separate page for Delete

Deleting a page is currently done on the same page as Move and Rename. But you will never combine these actions on a topic. Less options == less confusion and better focus on the job to be done. Suggestion: create a separate template page for deleting topics. Same goes for Moving and Renaming.

-- ArthurClemens - 17 Aug 2003

See also: TrashButton and DeleteTopicShouldNotFollowIt.

Status

---

Reveal the actual to-be-generated link targets when previewing

Say that you are creating a link to some less trivial location, i.e. not just a wikiword, but instead using a plugin or some sort of %MACRO{foo}% to have the final target of the link resolved on-the-fly when viewing the page. Another example is when using this sort of link:

[[MyCoolPage][that cool page]]

What is percieved as an unneccecary extra layer of implicity is the fact that you'll never be fully assured that generated links will point to their correct location until you have actually clicked "Save" and can view the results.

I think that a really slick solution for this could be to generate a simple client side script to make the "resolved" link targets show up in the status bar of the browser instead of the rather unhelpful https://twiki.org/cgi-bin/oops/Blarf?template=oopspreview when hovering the respective links in preview-mode.

-- ConnyBrunnkvist - 09 Feb 2003

If you limit the problem to "Make sure I create a correct link in edit mode", you can create a link to a pop-up window where you can browse the topics in the web, or maybe other webs as well. See for instance the pop-up in http://www.visiblearea.com/cgi-bin/twiki/edit/Patterns/Test_page (link "List of all topic names").

-- ArthurClemens - 09 Jun 2003

Status

---

extend 'Edit' and 'Preview' to automatically unlock page when possible

A short javascript should be included on those screens hooked to the DOM onUnload() event. The script should be smart enough to not unlock when the user hits 'Back' from within the 'Preview' screen and to warn the user if they are about to discard changes.

-- TomKagan - 27 Dec 2002

Why not just set the TWiki preference for topics to be unlocked-on-save by default? ( RELEASEEDITLOCKCHECKBOX = checked )

-- MattWilkie 28 Dec 2002

Sorry, I wasn't quite clear. The suggestion is about what happens when you abandon editing, not when you save your changes. The option box to which you refer works only if you click "save." Right now, the only clean way to abandon an edit is to click "cancel". Adding the javascript hook would automatically unlock the page for the other ways a user can abandon the edit ("back" button, closing the browser, typing in new url, etc.) Currently, any other action besides "cancel" leaves the page locked.

I just spotted another case where another small Javascript can help. If a user saves a page, then clicks "back" to get to the previous edit, they are now working on an unlocked page. Hooking the another DOM event - onLoad() - on the edit page could tidy this up too without breaking the the wonderful cache fixes RichardDonkin implemented.

-- TomKagan - 30 Dec 2002

Status

---

Relative anchors (<a href="#anchorname">) should work in preview mode

Perhaps a few other anchor types should work in preview mode as well.

-- TomKagan - 27 Dec 2002

I would like to see this.

I would also like relative anchors to have a different class name so they can be stylised differently from regular links using CSS. E.g. <a href="#anchorname" class="alocal"&gt becomes dark blue, or whatever, instead of the regular link blue.

-- MattWilkie - 28 Dec 2002

You can do this right now via CSS2 selectors, plus greater flexibility via CSS3 selectors

-- TomKagan - 30 Dec 2002

Can someone show how? Or give a link?

-- ArthurClemens - 10 Jun 2003

Status

---

Make users more confident in the locking mechanism

JointEditingAndEditLocking describes a problem with locking; changes of a person can get lost either if a person breaks another one's lock, and in some cases also if no locks are broken by a user.

Status

---

Access Keys

One of the least known features of HTML is the accesskey attribute for links and forms, which allows the web designer to define keyboard shortcuts for frequently-used links or form fields. If the access key is defined on a link, your browser will follow the link; if defined on a form field, your browser will set focus on that field. See AccessKeys for a discussion on which keys might be defined for Twiki.

Status

---

Preference-based Topic Edit Lock

Feature: A Lock checkbox that allows individual topics to be Edit Locked. It should be Preference-based, using Users and Groups to set who's able to toggle the Lock, typically, a site admin group. It could remove the Edit link, or disable it and cross it out, or replace Edit with a "Locked" message,... It should be easy to access the checkbox, probably on the control switch at the bottom of the page.

Uses: Mainly to lock Site Info pages with important content (ex: instructions) and more complex layouts. Also, for ClosedTopics and TopicToDelete topics. Possibly also for temporary locks, ex: work-in-progress page.

"Workaround": HTML commenting out of access controls hides them. This can definitely handle all of the above. It would be more usable if there was a Lock checkbox that could be set to an admingroup. (Would an INCLUDE work?)

Status

---

Cancelling out of create new page goes to error, not orignal page CancellingANewPage

When you click the ? after a WikiWord for a topic that doesn't yet exist, in order to create the new topic, but then click [Cancel] to go back, you DON'T go back to the page you came from, instead, you reach the "page doesn't exist" screen. Getting back to the original requires backing up with the browser Back button. This is confusing, particularly since a number of the not yet created topics are NewUserExamples.

-- MikeMannix 21 Nov 2001

Status

---

WebForm Change button is awkwardly positioned

In the Edit screen, the default positioning of the form [Change] button is easy to accidentally click instead of [Preview Changes] -- ?

True. The WebForm link could be placed left-aligned, and the change button right-aligned. The button could also be a link to make it less obtrusive.

-- ArthurClemens - 31 Aug 2003

Status

Improving TextFormattingRules

Gateway topic for shorthand improvement discussions is TWikiSyntaxDiscuss

Shorthand notations don't expand without white space

Certain TWikiShorthand items don't expand without white space on either side. This makes text formating (bold, ital) and use of square brackets to make more readable links, difficult. You have to mix HTML with TWiki notation. (need a list of instances)

-- MikeMannix

Let me try to show an instance   Oops, can't off hand. But I have had this problem. When I find a good example, I'll try to come back & post it.
-- RickArchibald

Status

---

Quicker insertion of your signature

"<== This is your signature for easy copy & paste operation" - It's getting old doing that over and over again. And everytime I quick select my sig, MSIE insists on also selecting these three extra spaces after "dd mm yyyy ".

Ok - it's easier than entering the correct signature and date by hand, but it's still select-copy-click-paste... I suggest presenting users of javascript-enabled browsers with the following:

"<== This is your signature for easy copy & paste operation **[Click here to insert]**"

...and by a single click, the properly formatted signature would be inserted in the edit-textarea at the cursors current location.

-- ConnyBrunnkvist - 16 Feb 2003

Shows what I deserve for not reading this page first! I just added AddSignatureButton to FeatureEnhancementRequest saying this very thing. Sorry for the duplication!

-- BruceMcKenzie - 11 Apr 2003

Also see a simple markup solution: Copy box.

-- ArthurClemens - 05 Jun 2003

This is already provided for IE users by JavascriptBasedEditor, which is live at TWiki. I've just used it to add my signature

-- JohnTalintyre - 06 Jun 2003

Also see SmallerSignatures which proposes ~~~~~ to be replaced by Main.UserName - 01 Jan 2004 and date on save (which is similar what WikiPedia does).

Status

---

TWikiShorthand to HTML conversion improvements

I used to mix up HTML and TWiki shorthand, because I was using TWiki more as an easy publishing tool than for pure collaboration. But for what I'm doing now, pages that will be contributed to, I'm trying to stick to shorthand only. A few big annoyances - relatively minor considering everything that can be done, but still worth fixing:

• having to leave a space after the closing * and _ for bold and ital
• entering web prefixes to topic names
  • entering long VARIABLES: %TWIKIWEB%, %MAINWEB%
  • entering % signs doesn't feel right when they come up a lot
• a few things more to add...

I can imagine, with a very few fixes and additions - like shorthand for a couple of type and background colors - TWiki shorthand could on its own be really simple, intuitive and produce nicely presented results with no extra effort...

-- MikeMannix - 27 Sep 2001

Status

---

TWikiShorthand replacement for Double Rule

New TWikiShorthand rule for a (wider? colored?) HR to replace the double rule convention separating the statement at the top of a topic, from the discussion following it. Divisions between sub-threads in a topic discussion can still be served by regular Shorthand HR ---.

This would make the statement easier to see, and possibly encourage and reinforce use of this convention when applicable.

-- MikeMannix - 21 Nov 2001

Status

---

New Shorthand for indenting a line

Moved to TWikiMarkupForBlockquotes (a child of TWikiSyntaxDiscuss) -- MattWilkie - 09 Jan 2004

-- StephanMeyer - 18 Oct 2003

New Shorthand for padded spacing

Move to PaddingSyntax by -- MattWilkie - 09 Jan 2004

-- RickArchibald - 08 Jan 2004

---

%ENDCOLOR% is longer than </FONT>

I'm not sure if this belongs here, move it if you like. I never use the %ENDCOLOR% variable because it is defined as </FONT> & is so much longer to type. How about something shorter, like 'EC'? I know I could implement this on the 1 TWiki where I am an Admin, but that's not the only one I use.

-- RickArchibald - 08 Jan 2004

This is an argument of 'having to remember these things in your head'. 'EC' is something not familiar, you need to remember that. I am sure you can come up with another dozen or so shorthands for variables. The main thing is that I don't want to guess when I am writing, and I don't want to look it up if I don't really have to.

In fact, it is bad habit to write abbr. f.i.; i.e.: the text is still understandable but so much harder to read.

So sometimes it is better to have the full notation instead of using shorthands. If you are your twiki's only user, there is no problem of course in defining them.

-- ArthurClemens - 08 Jan 2004

---

New Shorthand for highlighting text

Feature: A new TWikiShorthand rule that allows quick and easy highlighting of blocks of text.

• user-selectable highlight color?
• tiny signature icon with author name as rollover tip (to ID if someone highlights someone else's copy)?

Status

"More" editing

Moving a page should update preexisting page in destination

As it is now, the destination web cannot have a page of the same name as the source web. TWiki should just 'check in' the moved page to the destination web. The previous page in the destination web would be relegated to the revision history automatically.

-- TomKagan - 27 Dec 2002

Status

---

Layout

FAQ output better readable

The TWikiFAQ would be more readable (and usable) if output could show the bold text "FAQ:..." on the top of search record and wiki page name small at the botom of search record (oposite as it is now).

This would probably need either %Search... command extension (e.g. FAQ parammeter) or definition of a new command.

(May be this should be placed into Search section as TWikiFAQ uses that command)

-- DaliborSvoboda - 31 Jan 2005

No need for anything so complicated. I added the following to the search on that topic:

format="   * [[$topic][$summary]]$n $n"

As well as being more readable it also means that anyone tabbing through links, or using find as you type on mozilla/firefox, can just hit enter to go to the topic.

-- SamHasler - 31 Jan 2005

Improved template features

The usability of TWiki sites could be improved, as with most websites, particularly for Wiki novices. Here are a few ideas, I'd be interested in what people have found useful:

• Pop-up tooltips on the standard templates, e.g. to explain what Ref-By does, and what the '>' links does (very hard to get people to use this...)
• Design a new template for usability, based on actual usage - e.g. change the Go box to a search box, as I have frequently seen my colleagues just type a word in there expecting a search.
  • This is exactly what I did for the first few days. Actually, I still do it, not because I don't know it's for wiki pages only, but because the result of wiki-not-found is a real search form. :)
    Easy solution: Changing the text from "Go" to "NamedPage" or similar.
    Better solution: entering text searches for a wiki page of that name. If an exact match is not found automatically spawn a search for the entered term. -- MattWilkie - 03 Oct 2001
  • More discussion and an implementation is available at GoIsSearch -- MW - 27 Dec 2002

• An optional 'slicker' template/skin design that includes a nice CSS setup (sans-serif fonts, smaller heading fonts, change link appearance on mouseover), button images with JavaScript mouseover effects, etc - not to everyone's taste perhaps, but would make TWiki sites look more like a 'designed' website. I'm not a big fan of JavaScript but it does make things look nicer, and if it's done carefully so it's optional, it shouldn't break things. Not strictly a usability issue but would help in acceptability by people who are not so into text-based websites. See BetterSkins for an example.
  • CSS Layout: I've found a website that has what I think might be the ideal CSS-based layout for TWiki. Using the principles in this layout allows one to put the content before the navigation elements for text browsers and uses a very simple browser detection method. I've started trying to build a skin around it, the going is slow so far. If anybody who is more familiar with TWiki innards wants to take a shot at it the template can be seen at glish.com. [ MattWilkie 01 Nov 2001 ]
  • CSS Layout II: Matt, We seem to be following some of the same paths! glish is cool. It includes the elegantly simple sheets from http://bluerobot.com/ (I'm gonna get in touch with them) which is worth checking for their implementation - I used a two-column on TWiki, no problem as is, except there's afloating DIV tags spot that separates the cols in the text box that can't be touched (that's in an obvious direct usage). Also, http://www.webnouveau.net/ has links to a zillion table-less sites - interesting for a look. All these and more are found on http://www.webstandards.org/ - the Web Standards Project, that's definitely relevant. Finally, http://www.alistapart.com/ is great, gets deep into CSS, crosscompatibility, etc, and is another of the glish examples, in full glory. (BTW, this topic addition is a good illustration of one of the changes problems - you may have had to look around to find it since it's not at the bottom.) -- MikeMannix - 01 Nov 2001
    • Note: These layouts seem to work fine on Opera, IE, and NS6, but not NS4.x; go to CSShark for the NS4 workaround. --Main.PeterNixon - 16 Nov 2001
  • CSS Layout III A good start on an all CSS based template has been made at SeeSkin. -- MattWilkie 28 Dec 2002

For an excellent selection of short articles on web usability, see http://www.useit.com/papers/ (Jakob Neilsen's site) - worth thinking about how some of these ideas could apply to TWiki sites.

-- RichardDonkin - 10 Jun 2001

I totally agree. We found we had to do all of the above to get acceptance by some people - see BetterSkins. I'm hoping that this can be added into the core, but various changes will be needed including

• Macros for displaying revision information in different ways
• A header/footer system, so that other pages have similar look - see BetterSkins
• For full capability - optional session info so that menu items can change depending on permissions

All of this does mean more Javascript and cookies, but the vanilla/classic skin should still be there for those that don't want this.

-- JohnTalintyre - 11 Jun 2001

Please - don't. This will end up us poor non-Scripters with a less usable TWiki.

All of the above can be done from TWiki and doesn't need scripting.
Yeah, I know, Perl sucks. It's easier to add features using scripts, since this doesn't require digging through thousands of lines of scarcely documented code written in a write-only language.
Still, many people can't use this stuff.

It's OK if scripting is used for building a quick prototype. In particular if you're more fluent in JavaScript than in Perl. But stuff that goes into the main distribution shouldn't depend on scripting unless strictly necessary.

Just IMHO and my 2c.

-- JoachimDurchholz - 27 Nov 2001

Status

• Pop-up tooltips: Should be implemented in new default skin.
• change the Go box to a search box: implementation available in PhotonSearch and GoIsSearch
• skin with CSS: still a pending issue if this is allowed for the default skin. See TWikiSystemRequirements and BetterMarkup

---

Priority Announcement Method

was Topic Announcement Field(s)

Idea is to have one or more "built-in" announcement fields for comments that would appear (at the top) in all topics in a web. Could be done using INCLUDE - by the individual installer (a Hint), or as part of the default templates.

This is a quick idea, still rough. For one thing, it would be good to have a way to selectively target which topics in a web get an announcement message.

Also, is there a (significant) performance hit if one or more empty INCLUDES are permanently active?

-- MikeMannix - 21 Nov 2001

The original suggestions above were pretty weak. Really, the idea/request is to find one or more ways to highlight certain topics, give 'em priority, so that as many Codev visitors saw whatever message. This would be requests for feedback, voting on stuff, things like that. Text blocks, like INCLUDES across multiple pages, or the big yellow banner during the Oct SF crash are one approach. Email is maybe effective. I tried stuff like - erm, ExtraExtra on the control bar, to create a headline page. Do people regularly check into Dev News... Whatever, it seems that topics easily slip into the pack, and there's no easy way to do highlights.

Maybe a semi-tacky-flashy graphic button on Codev home, linking to a page that's used strictly for important things, vetted by Peter or some group, ie: not devalued by filler and ignored. Lights up when there's something new. Whatever gets the job done@

-- MikeMannix - 29 Dec 2001

Status

---

Add WEBCOPYDATE to TWikiPreferences

This may really not be the place for this, but I don't understand this topic enough to be making a new main heading for "TWikiPreference Variables". Here is a section from our TWikiPreferences:

• Copyright notice:
  • S et WEBCOPYRIGHT = Copyright © %WEBCOPYDATE% by the contributing authors
  • S et WEBCOPYDATE = 2003-2004
  • S et "WEBCOPYDATE" here, & it will propagate thoughout the TWiki,
    just be sure to use %WEBCOPYDATE% in any WEBCOPYRIGHT definition

If you have only the one standard copyright notice, there is little point to this; but if some of your site's webs have different notices, then you can have just the one date stamp which needs to be updated in only one place. (Needless to say one of my webs didn't update properly this Dec.)

-- RickArchibald - 08 Jan 2004

---

Viewing

all hardcoded icons/buttons/links should have TITLE attribute set

The design of the WebHome or AdminTools overview table is nice. Especially the icons allow a shortcut to important pages and actions:

Web	Description	Links
Main	TWiki home with users and groups for access control
TWiki06x01	Official documentation of the TWiki-6.1 Release
Blog	Blog of the TWiki.org community
Codev	TWiki development: the core collaboration zone for the TWiki Project.
Plugins	Repository for TWiki Plugins, Skins and Add-Ons.
Sandbox	Sandbox test area. Use this workspace to try out TWiki.
Support	Tech support for the TWiki collaboration platform.
TWiki	TWiki documentation, welcome, registration and other starting points
TWiki01	Official documentation of the TWiki Release 01-Dec-2001
TWiki02	Official documentation of the TWiki Release 01-Feb-2003
TWiki03	Official documentation of the TWiki Release 01-Sep-2004
TWiki04	Official documentation of the TWiki Release 4.0
TWiki04x01	Official documentation of the TWiki Release 4.1
TWiki04x02	Official documentation of the TWiki Release 4.2
TWiki04x03	Official documentation of the TWiki Release 4.3
TWiki05x00	Official documentation of the TWiki-5.0 Release
TWiki05x01	Official documentation of the TWiki-5.1 Release
TWiki06x00	Official documentation of the TWiki-6.0 Release
WikiWed	Keep track of Wiki Wednesday events
Webs are color-coded for identification and reference. Contact info@twikiPLEASENOSPAM.org if you need a workspace web for your team.

Legend:

Search the web See recent changes in the web Subscribe to get notified of changes by e-mail Usage statistics of the web Web-specific preferences

Although tere is a legend underneath the table, the icons can be puzzling for the new user. It would help a lot if you could hover your mouse over an icon and the explanation would be shown in a bubble help. To do so, you'd have to assign this text by setting the TITLE tag in the <img> element. For example check these:

The icons in the WebHome sitemap or on the AdminTools page don't have the TITLE attribute set. Instead they use the the ALT attribute. But this attribute is only showed when loading of images fails or has been disabled in the browser. You can only see the difference if you use a decent browser like Mozille and not IE.

Even more, buttons like Checkpoint and Quietsave could have a TITLE tag set to convey their function, too.

Some icons and links already have this explanatory TITLE tag. Examples: the links used in the WebForm or the smilies created by the SmiliesPlugin.

I think, the wiki implementation should be more consistent about the usage of the TITLE attribute.

-- DanielKabs - 10 Sep 2004

timeout on "Put it back" message

Make a timeout for the display of the topicmoved comment displayed at the bottom of a moved page.
"Someweb.SomePage moved from Someweb.SomeOtherPage on 16 Jul 2003 - 13:30 by HolgieBob - put it back"
If the page is intentionaly and correctly moved (and maybe a looong time ago) then the comment generated will just be a slight annoyance on an otherwise perfect page.

-- HolgieBob - 14 Aug 2003

Another topic has a complaint about the put it back message being too prominent (something to do with PatternSkin?) I like Holgie's suggestion.

-- MattWilkie - 14 Aug 2003

Status

---

Make topic and date links on WebChanges page include last changed time

This allows the new links that haven't been read yet to appear as unread links.

A link to "WebHome" that appears on the changes page would have ?changeseconds=783487234 where the number is the time in seconds that corresponds to the date/time the file was changed. This way browsers that store the links, and mark unseen links differently from seen links can present unseen links in a different way answering the question of whether you have seen the change or not.

-- JohnRouillard - 06 Sep 2002

Status

A good idea, but no takers (as of 08 Oct 2003).

---

Status notes should have a date

The status icons like and would be more useful they had a date associated with them. What is new to you is not necessarily new to me.

For example: ^{04 Sep 2002}

Perhaps this would be better as a GoodStyle convention rather than a server side feature.

-- MattWilkie - 04 Sep 2002

In my opinion even adding %N% manually is a bad idea. As you can see on this page - where comments aren't simply added to the end of the page but in the page - a mechanism to tag new and updated comments in the TOC would be very helpful.

I think showing a WhatsNewIndication should be implemented as a server side feature by integrating in into TocVariableDev. Advantage: the icons would be added and removed automagically in the course of time.

What about making this a feature request?

-- DanielKabs - 10 Sep 2004

Status

No implementation to date, but has been discussed in a variety of contexts. The "home-plate" of such discussion is probably WhatsNewIndication.

---

Reverse page titles

Reverse the page title so stacked multiple tabs/windows read "Usabi ..., Coffe ..., Scrip ..." instead of "Twiki ...,Twiki ...,Twiki ...,Twiki ...,Twiki ...".

Status

moved to ReversePageTitles feature request.

See implementation at: http://www.visiblearea.com/patterns/

---

URL topics

Make TWiki 'browser autocomplete' friendly

This is related to the shorter URL idea. Turn on autocomplete in a newer browser (ex: MS IE 5.5). Go to a bunch of twiki pages and edit some. Now suppose you want to go somewhere on the web and type in the address bar:

intranet/twiki

then the autocomplete feature, which always alphabetizes the URLs to autocomplete, will always offer "edit" before "view", for example, the autocomplete drop-down list might look like this:

intranet/twiki/bin/edit/Main/Mytopic
intranet/twiki/bin/edit/Main/MyOtherTopic
intranet/twiki/bin/view/Main
intranet/twiki/bin/view/Mytopic
intranet/twiki/bin/view/MyOthertopic

This is a drag, since the intention is usually to view the entry, not edit the entry. So to use the autocomplete feature in this case, the user has to use down-arrow several times to get to the 'view' entry they want-- if they even know what that really means! If the "shorter URLs" ideas are implemented, typing in full addresses to go to a topic might be a more common practice (at least I would hope), and people may end up going to 'edit' instead of 'view' if they hit autocomplete too soon.

Now that's the problem.

Here is one solution. Rename 'edit' to something non-alphabetical, such as '_edit', so these entries for autocomplete always appear last. That's assuming the browser uses a string compare which puts '_' after a-zA-Z.

Other solutions? Anyone?

hummmm.. ok I am totally unorignal, this is related to RenameViewToAview though I prefer renaming to _edit rather than Aview.

-- TWikiGuest - 07 Jul 2002 (jcline at ieee.org)

I like _edit better also. -- RandyKramer - 07 Jul 2002

See for possible directions:

• RenameViewToAview and RenameViewToAviewWorking
• CoolURIsDontChange
• CommonFrontEndCgiScript

-- ArthurClemens - 18 Jun 2003

Has anyone looked into using the ApacheRewriteRule engine to translate urls of the form: from intranet/twiki/Web/Topic to intranet/twiki/bin/view/Web/Topic ?

Yes. See ShorterURLs.

I'm not an Apache expert, but it seems like this should be doable, although you probably have to explicitly enumerate all of the webs.

This might not help much for autocomplete (but it might), but it would certainly help when typing the URL in by hand.

-- ScottGargash - 01 Jul 2003

Status

There is working code and/or configuration instructions in ShorterURLs and ShorterCaseInsensitiveURLs (windows servers get case insensitivity for free). An in-twiki solution is probably still desired for performance and simplicity reasons.

-- MattWilkie - 25 Sep 2003

---

Distribution

Simpler TWiki distribution

I started a topic in SimplerTWikiDistribution before I noticed this list, but the basic idea is this: The out-of-box TWiki install has a ton of stuff that I don't want my users to see or be bothered with. I spend more time stripping away after install than time spent installing to begin with. The TWiki, Know, and Test webs are great as examples but I want to have 1 web at install, next to nothing but essentials on the front page, and advanced features at least one click removed.

Not a distribution, but a sort of mini-howto for making a simplified site based on a 'standard' installation can be found here. -- JaneJennings (link is dead as of July 1, 2003) - MikeBoone ((still available at web .archive.org))

-- LesOrchard - 27 Jan 2002

There are a couple of minimal distribution suggestions, sort of on their own, separate from better templates and more preconfigured functions and examples, more to do with direct cutting away.

• less feature buttons (links) on toolbars; simple way to add them as required (bottom toolbar, mainly)
• less included pages
  • no RCS files
  • no Test and Know webs
  • tightly edited documentation set in TWiki web
  • minimum general info in Main web (move support topics to TWiki docs)
• on an entirely different, serious core code level, but still a cutting away: replace RCS

Probably missing a another thing or two.

-- MikeMannix - 12 May 2002

Maintenance of a TWiki could be eased greatly if there was a clearer separation between topics and supporting files on the one hand and system files on the other. The pub directory is currently a mixture of both, which makes it difficult to implement backup and revision control strategies. Please see PubsDirectoryShouldNotHoldSystemFiles for more explanation.

-- ThomasWeigert - 12 May 2002

Status

A hot topic which keeps cropping up in many different forms, one of which is easier installation and upgrades. No solid implementation yet. The TWikiUnixInstaller is the most comprehensive all-in-one code contribution so far but it diverges quite widely from the core.

The second major form is better usability. TimDistro is a beginning attempt to build a simpler distrubution. PatternSkinCodeChanges is farther along, but is not yet publicly released (still in the archicture design phase).

-- MattWilkie - 25 Sep 2003

---

Nomenclature for TWiki and Main webs

Implementing the Cairo release has brought up with my users the old confusions about the TWiki and the Main webs. Using the Pattern Skin and the new WebLeftBar has helped a lot with the navigation on the TWiki at the same time as highlighting the problem of the nomenclature of TWiki and Main webs (which I had been able to mask a bit in my old implementation). In short the questions are raised in this way:

• The whole site is called a TWiki so why is there a web that is itself called TWiki?
• Why are some of the user functions handled on the Main web (list of users e.g,) and other user functions (registration, reset passwords, etc) handled on the TWiki web?
• And why is it called the Main web anyway - surely the Main web is the web that holds the subject content relevant to the purpose of the site?

These confusions have an impact on usability - users want to have a pretty good idea where they are at any point and the relationship of that point to the rest of the site - that is they are forming a mental map of the site as they move through it. So newbies get easily confused when TWiki is used both as the name for the technology relevant to the whole site and then find that there is also a "physical" web called TWiki.

I think it would be much clearer for users if (perhaps in a future release):

1. 1. The TWiki web was named something like Documentation
   2. The Main web was named something like Users
   3. User registration and password functions were moved over to the Main/Users web

I know how much everyone puts into developing the TWiki and that there must be a history to the nomenclature sitting behind all this so I trust that these reflections are taken in the constructive way I mean the to be.

Comments/feedback perhaps from web managers of other Twiki sites would be appreciated.

-- SueLocke - 29 Sep 2004

I like how NaturalSkin uses the word "System" for the TWiki web, Main could be called "Users and Settings". Main doesn't seem to be descriptive enough. Main usually means "primary" but really users shouldnt' be messing with Main at all, unless it's their own user page. Topics should go out in a more focused category web. Both System and Users and Settings are system orientated, whereas everything else is content orientated. Making a definite dividing line would improve usability, although I admit this would affect the openness of the system. I've also thought about making WebPreferences into a special topic rather than a content topic. This comes from more of a corporate setting, where I don't necessarily want uses mucking with look and feel (ie: fonts, logos, grpahics, etc.)

-- DaveCampbell - 21 Feb 2007

Why do people always want to turn TWiki into a Corporate content management system where everything is closed? TWiki is a wiki. It is its main strength. Proposals like these - if implemented - turns TWiki into a closed traditional stupid old over-managed CMS where very little innovation takes place. How do I limit this? How do I block that? How do I prevent users from creating that? The whole idea of TWiki is to enable people and give a huge tool package to give the users the possibility to add structure and flow with self made twiki applications.

It will not help your users that WebPreferences is turned into a non-topic when you also want to limit them from editing it in the firsts place.

Read KennethLavrsen to understand where I come from.

Yes Main web is badly named. Try to rename your own to Users. It is possible in TWiki 4.1.1. And when you have completed the task then try and evaluate what effort it takes to upgrade a TWiki with 700 webs and 10000 users and 100000s of topics and repair the damage afterwards. Our current loyal customers should always have highest priority and upgrading has to be possible without spending a staff year on it afterwards. And noone has come up with a good and safe way to do it. But if someone does I would vote for changing Main to Users.

In my company "System" is a department so I would not be happy if TWiki web was suddenly called System. I think TWiki is a fine name for that web.

-- KennethLavrsen - 21 Feb 2007

---

Web is bad nomenclature, use Zone instead

Moved the discussion to RenameWebToZone and created a FeatureEnhancementRequest.

Nutshell summary: use zone instead of web . In the wild web has nothing to do with organisation, and everything to with chaos. Using "zone" avoids the confusion of meanings in the term "web" while keeping system pages like ZoneHome and ZonePreferences at the end of the topic list.

-- MattWilkie 04 Jul 2002

Status

Discussion looks to be a permanent logjam. A method of renaming system pages and updating links can be lifted from one or both of TWikiUnixInstaller (bootstrap.sh) and WindowsInstallCookbook (Re-locking RCS files)

-- MattWilkie - 25 Sep 2003

---

Short version format for TWiki versions

TWiki uses a unique date approach to versioning - TWiki 01-Sep-2001 Production - and then Alphas and Betas simply by date Beta 17-Aug-2001. This is confusing and awkward to use in internal situations, for feature and bug tracking, where it should be easy and quick to note what version an entry refers, for practical purposes. For example, at some point on the way to 01-Sep-2001, TWiki became way different than the 01-Dec-2000 version, and features and fixes would then start to apply strictly to the current Beta forward only. Offhand, I can't think of how this is usually handled, but some sort of 3.0, 3.1b set-up would help, so that Codev users could see at a glance what version a topic related to.

Related case in point: The last Production Release is 01 Sep 2001, however, on this site, %WIKIVERSION% displays TWiki-6.1.1-branch, Sun, 02 Jul 2023, build 31079.

-- MikeMannix - 31 Oct 2001

There is now the new A-Z city name project naming convention, beginning with Athens... Not sure how this affects things. <g> -- MikeMannix - 02 Dec 2001

Status

is this still a relevant concern?

-- MattWilkie - 08 Oct 2003

---

Make it easy to know where to post specific comments

For somebody who has not been previously involved with particular discussions it is difficult to determine the most appropriate page (topic) to comment when the theme covers several pages.

This has started to be addressed with:

• a new how-to section and title for ReadmeFirst (on the top toolbar)
• by reorganizing the Codev home page: it's a clean, annotated menu of Codev content
• with a Categories link on the top-of-page toolbar (it lists all of the Codev page categories - click to call up a particular set of topics), and Topics, an alphabetical, title-only list of all topics in the web (displays way faster than Index
• with a new TopicStatus field in each topic, identifying active and dead pages
• when it's finished, the MasterRefactor project should unify a lot of the themes that thread through multiple topics and long periods of time, with gateway pages for major discussions

-- MikeMannix - 21 Nov 2001

Status

This is a very general issue, though significant, and such there isn't any real "solution". The people who have been participating in the discussions do have an idea of where to newcomers' contributions would be most effect and the onus is on them to direct them so (gently!).

-- MattWilkie - 08 Oct 2003

---

User acounts

Silent Personalization

I've recently had occasion to use two other wiki softwares, UseModWiki and WikkiTikkiTavi, which both have a really nice and smooth silent user identification system. Basically the only thing a user needs to do is fill out their preferences (available from the top of any page) and voila! they have an account. It's so unobtrusive it's beautiful.

This is exactly what I need for our intranet site, where I am forcing registration for only one reason: so that WebChanges isn't all attributed to TWikiGuest.

Status

Currently available for MS Windows intranets, see WindowsInstallModNTLM and LoginNameAndNtlm. There is promise for unix+ms intranets with Samba3 using LDAP (follow squid proxy news) but nothing solid yet.

For internet sites, nothing has been developed yet.

-- MattWilkie - 25 Sep 2003

---

obvious login/logout mechanism

The twiki-way of logging in/out is not at all obvious relative to the way most other websites do it. There should be an explicit login/out mechanism to match the rest of the world (in addition to the current method).

This is a frequently asked question: LogOutButton, LoginPage, ReAuthentication, WhereIsTheLoginPage

• I second that, especially since I've gone dual-identity to avoid flooding WebChanges with my own name. On IE5.5, sometimes I can log out simply by closing all TWiki screens. Next, restarting the browser. Sometimes that doesn't work. Trying to do something like rename that requires relog in seems to work - if I enter a new uid/pwd, it takes effect a couple screens later after the rename or whatever. This also happens in office, when logging in to someone else's machine to show show, print or something, and then have to log out again. -- TWikiBot - 29 Dec 2001

UPDATE: The Evil Empire Twiki has done this. See EvEm for code. Evil Empire is no longer using twiki, however the old site is still running (and still looks very sharp).

A simple way to make a logout page is by a mix of software and user education: make a wrapper page which recommends the user to click on an inaccessible file and then cancel, and provides feedback afterwards. BoudRoukema - 10 Jan 2004

• See HowToMakeATWikiLogoutPage

Status

so far as I have been able to determine, the EvEm topic has the only contributed code for this. The CoreTeam does not seem to have any interest in it (as it is currently presented).

-- MattWilkie - 25 Sep 2003

---

Discussion

Make templates editable on the fly

MattWilkie, what was the reasons to delete suggestion "make templates editable on the fly"? I missed it when it was added, but I read it now and I liked it. I was thinking about somethink like this myself. Is it not reasonable? Security risk? Other reason?

I see, you implemented it in Flexible skin. So no security risk? So you want to corner it for your skin only? Maybe other skin developers might want to implement it, too?

-- PeterMasiar - 06 Jun 2003

FlexibleSkin is not mine, it is being developed by AntonioTerceiro. Thanks for the thought though, I wish I had figured templates in topics out. Also, I didn't delete the suggestion. I moved it to OldUsabilityIdeas under the "Implemented" section as part of the refactoring effort started by ArthurClemens a few days ago. (...following what's new through the Diffs eh? This highlights a different kind of usablity issue...but one I don't have the wit right now to elucidate clearly.)

-- MattWilkie - 08 Jun 2003

On the templates editable on the fly, I do not think it is an actual need. From my experience, what I think is needed:

• Do not put things that do not slow down TWiki at runtime, it is already too slow as it is. (a template engine being called at page view may be overkill)
• Make it easy to apply new looks (install a packaged "theme"), not necessarily on the live site. You need flexibility to tweak a site look on a toy site, and then an easy upgrade mecanism to update the main site look. And anyways, most people do not tweak their site look, they just copy a nice one.

So I'd better have a "one-click" install / uninstall of templates, with no added runtime overhead than on-the-fly editing. But of course we can technically have both.

-- ColasNahaboo - 10 Jun 2003

It will be great to have both. Currently we don't have any I agree that one-click install is more important that ease of tweaking - but ease of tweaking is the way to get many options to install from.

Using more standard templating engine like TemplateToolkit will add more value improve skin development. So if you want it to happen - try to persuade CoreTeam! (and I know it will not be easy )

-- PeterMasiar - 11 Jun 2003

---

numerous status updates above

It seems to me that many of the good ideas here are languishing from lack of visibility (not to mention coders who aren't busy on other things) and the difficulty of going search through one big page to edit/change/update any given entry. Or to see what's new for that matter. Perhaps it would be better to have special class of FeatureEnhancementRequest dedicated to usability?

(and why isn't that just FeatureRequest anyway?)

-- MattWilkie - 08 Oct 2003

consolidated shorthand ideas under the _Improving TextFormattingRules heading; moved some of them to their own topic._

-- MattWilkie - 09 Jan 2004

-- Contributors: CarloSchulz - 15 Mar 2007

Discussion