Recycle bin for ideas from UsabilityIdeas

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

Rejected ideas

Toss out homegrown template system in favor of The Template Toolkit

'nuff said! -- TomKagan - 27 Dec 2002

This proposition has surfaced before in TemplateToolkit and a couple of other places too I think. In July 2001 PeterThoeny thought the toolkit was unsuitable because of it's large size (among other things).

-- MattWilkie 28 Dec 2002

Vague ideas

Research by Introspection

What if we kept a running diary of how we use Twiki, screen by screen, and why or to what purpose we selected each function. What's going on behind your eyes when Twiki is in front of them?

I'd place such a diary at: TWikiCognition

Related topics: AlternativeNavigationMethods, InterfaceClutter

-- SocinianClarke - 02 Oct 2001

Maybe a little unrealistic to expect of people. Getting in the habit of making quick notes on this page would probably accomplish the core hands-on refinement, especially with at least one active editor monitoring, checking for patterns and insights. Also, I suggested in TWikiUsabilityTesting setting up a bunch of basic tests for standard functions (ex: "find 'x' starting from here"; "create a new page and enter some text") that anyone can run. In a loose way, like the steps and answers on the TWiki Virtual Domain Installation chart in TWikiOnWebHostingSites.

-- MikeMannix - 22 Nov 2001

Implemented ideas

no Main prefix for UserName

The one usability connection that I would make is that we allow any topic in the Main web to be linked without the "Main." prefix. It is a great nuisance to have to write Main.ThomasWeigert, rather than just ThomasWeigert and this is often forgotten by beginning users.

-- ThomasWeigert - 12 May 2002

This has been discussed in depth before, RenameMainWebToHome + RenameTheMainWeb , and maybe a few other places besides. One suggestion I haven't seen is to introduce a new syntax. For example instead of having to write Main.UserName or Users.UserName how about just .UserName ? Or +UserName ? Or something?

-- MattWilkie - 13 May 2002

Just read "Autolinking topics" at the end of this page. This may be a moot point now?

• I don't think so because Autolinking topics seems to be processing heavy. Unless there is a specified global name space as sugested by MartinWatt in TopicNotFoundInThisWeb or an alternate prefix like -- which everybody is using already anyway -- MW 27/09/2002

-- MattWilkie - 14 May 2002

I just discovered the FindElsewherePlugin yesterday which appears to do exactly what I want here - effectively it makes any webs you define into global ones. If it does not find the link in the local web it will go to the global one. There are also a couple of patches in FindElsewherePluginDev that will flag cases where a name is matched in more than one web, and display all the links. I just set Main to be my global web, and now UserName resolves from any web. So far so good. Not sure of the performance impact yet though.

-- MartinWatt - 27 Sep 2002

Well, not implemented, but solved with the FindElsewherePlugin. -- -- ArthurClemens - 17 Jun 2003

Hidden access control method

It is often useful to not clutter a page with access control settings. fortunatly puting access control sections inside of comment markers works just fine. E.G.

<!--
   * Set ALLOWTOPICCHANGe = Main.SomeGroupHere
-->

(the lowercase E in ALLOWTOPICCHANGe will hide it from being accidently interpreted by TWiki.)

This is invisible in the browser, but still provides access control. If somebody needs to see it they can look at it in raw format. This probably should be mentioned in the docs under TWikiAccessControl.

Added to docs! -- MikeMannix - 02 Dec 2001

make WIKITOOLNAME TWiki and create a SITENAME variable

The way is used now is confusing and only works well on TWiki.org, because both the site and the application are "TWiki". Elsewhere, the %WIKITOOLNAME% is used sometimes to represent the app, and others where a company or site name would be more appropriate. Making it just "TWiki", creating a new %SITENAME% variable, and cleaning up the docs and other pages included in the distribution would make it a lot easier to customize an installation.

-- MikeMannix - 22 Nov 2001

I second this. [Main.JoachimDurchholz - 27 Nov 2001]

In Athens, WIKITOOLNAME is now defined in the TWikiVariables docs as the TWiki site or company name. It's now just a matter of replacing the variable with "TWiki" in the appropriate spots, in the topics (documentation, etc) included with the TWiki distribution!

-- MikeMannix - 01 Dec 2001

This is really fixed? After just installing the latest 'release' version, I've had a field day with search & replace on this very problem. Although, I see the problem in a different way. There are legitimate uses of the name TWiki (ex: "You are on a TWiki Site.") and the name of the site (ex: "You are in the Bozoserver.Main web."). So, WIKITOOLNAME really should be SITENAME, and the use of the variable % WIKITOOLNAME should be replaced by the literal TWiki in some cases. In my opinion. Otherwise, it's 30 minutes of search & replace after the default install..

I guess the real thing I noticed w/r/t this is the default data/TWiki dir needs splitting in two: a "site admin" web (where WIKITOOLNAME really is SITENAME and should expand always to BozoServer) which contains all the site prefs & etc, and a "user docs" web (where WIKITOOLNAME shouldn't exist and should just be TWiki, since that's what the s/w really is).

Somehow related to this is the TWikiPreferences topic, which has nothing to do with TWiki, it has to do with the Site, or should be called SiteVars or something. I know that's been ranted about elsewhere too.

-- JonathanCline - 30 Apr 2003

Hope it's ok to add my 2 cents. Please don't consider SiteVars (no ext.) because programmers that do Mivascripting would probably be really thrown for a loop. Not sure how a server, with the MIVA various programs installed, would react. The sitevars file holds system variables (and can be part of a URL).

-- AnitaBrown - 24 May 2003

Autolinking of topic names instead of WEBNAME. prefix

You would not need to enter web prefixes if TopicNotFoundInThisWeb was implemented...

-- MartinCleaver - 28 Sep 2001

THIS IS A BIG FEATURE! There's a pretty thorough discussion at the above topic. But this should be really thought through and done properly if it could be troublesome to revise, and have to upgrade existing data.

-- MikeMannix - 22 Nov 2001

Apparently solved. Will update. -- MikeMannix - 12 May 2002

Edit Templates from within TWiki Topics "On the Fly"

Create a template that consists mostly (if not 100%) of a series of %INCLUDE{"SomeTemplateTopicX"}% through %INCLUDE{"SomeTemplateTopicZ"}% so that the entire Template (at least most aspects of it) are changable from WITHIN the TWiki itself via the edit-topic feature! Example has been implemented at Nevada Missouri Net See Nevada's TWikiTemplates These TemplateTopics can be edited as a normal topic essentially allowing "Skin Modifications" to be made on the fly, by any person listed in the SkinGroup.

• Allows for more flexability
• Makes the format of the TWiki itself up for improvement by its users (who are listed in SkinGroup)
• Makes it MUCH easier (IMHO) to make little changes to the Skin without the hastle of reloading the entire template each time.
• Creates a solution for the problem of not having a good way to preview changes made to template files. (use back button even after save is made)

-- TravisBarker - 20 Jan 2003

Implemented in FlexibleSkin

-- MattWilkie - 06 Jun 2003

Shorter Topic URLs (quicker navigation, easier mnemonics)

In information sharing, sometimes I end up navigating to info for a person and then emailing them a link. This link is pretty ugly and is horrible as a mnemonic:

http://intranet.example.com/twiki/bin/view/Main/OfficeLocations

Also note that with some browsers which have autocomplete (ex: MS IE 5.5), these autocompleted URLs when typing in part of the name can confuse the average user.

It would be ideal to have a minimal URL, like this:

http://intranet.example.com/?Main.OfficeLocations

In this case, index.cgi is the view cgi-bin. This way, I can tell our sales guy, "Just go to http://intranet/?Product.Releases"

Or, explicitly,

http://intranet.example.com/view?Main.OfficeLocations

or less ideal, but perhaps more security minded(?),

http://intranet.example.com/view/?Main.OfficeLocations

The question-mark is how some wiki's implement things based on their CGI's (I think).

Also, a short method might be implemented which defaults to the main web:

http://intranet.example.com/view?OfficeLocations

Where that 'web' obviously doesn't exist, so it checks the 'Main' web for it's existence.

The first thing to be done is to put the main twiki bin's into individual directories (easy, be careful of security however). Secondly, rewrite the CGI's to parse the environment rather than the target URL. (It's been a while since I've written low level perl CGI so I forget the details.. the experts here get the idea I hope.)

Ok, thanks for listening.

humm, this is similar to some ideas in CommonFrontEndCgiScript and also to ShorterURLs

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

Been answered on ShorterURLs. -- ArthurClemens - 18 Jun 2003

Solved Questions

How to add TWiki icon to title?

Moved to AddIconToTitle. -- ArthurClemens - 09 Jun 2003

Most requested features list

Feature: A ranked-by-vote list of most requested features. This is pretty common on many OSS and other projects. A poll would be good, possibly a growing set of topical polls, covering different feature areas.

The content of this page - short blurbs - as a poll page would be good... not necessarily something that should necessarily be a TWiki function... PollPlugin? -- anonymous?

See: PollPlugin and PollPluginDev -- ArthurClemens - 18 Jun 2003

To be removed ideas

Better StandardColors table

The StandardColors table is quite hard to read in places where the font color resembles the cell color. I've fixed this and put the result in StandardColorsImproved.

-- JbBell - 16 Mar 2002

This seems to've vanished...??? -- MikeMannix - 12 May 2002

I think this entry can be removed. Any objections? -- ArthurClemens - 09 Jun 2003

I'm unclear what has happened here. Recently I installed the February 2003 release, and lo and behold, it appeared my suggested StandardColors table had been implemented. Did I duplicate something that was in the development version already? It's fine if that's so, I'd just like to get proper credit if the new table did come from my suggestion (you may remember, the old one used an exclusively black font, making the darker colors' codes unreadable).

--Main.JbBell - 09 Sep 2003

Make skin change a regular html link

In TigerSkin (which looks great btw) the link to change the skin is located in the javascript pulldown menu. This is a problem for browsers that can't use TigerSkin (e.g. lynx which has no javascript support) since they have no obvious way of changing the skin to something that is compatible with the browser.

I ran into this problem because I use different browsers depending on what platform I'm on. I can work around it by adding ?skin=default to the url to get the default skin which has a simple skins link that allows me to select a compatible skin for the current session.

If the skin change link is always a regular link, it will allow the interfaces to degrade gracefully in that a new skin can be chosen regardless of the limitations of the browser.

-- JohnRouillard - 27 Nov 2001

Should be implemented by the skin. The entry is so old I think this can be removed. -- ArthurClemens - 17 Jun 2003