I've worked out one reason why there are so many people who log requests in the Support web without apparently reading the SupportGuidelines - it's because you can just type a WikiWord into the 'Go' field at the top, then click Create, and thus create a support request (with edit template as for requests made via the main form on Support.WebHome).

To avoid this, I suggest removing the 'Go' field from Support.WebPreferences - while this removes a little ease of use for experts, they can always edit the URL in the browser's URL bar.

If I could just get most people to read the SupportGuidelines, I wouldn't have to respond to so many requests with 'please supply XYZ as mentioned in the guidelines...

If there aren't any objections, I'll do this at TWiki.org in the next few days. No impact on the TWiki distribution of course.

-- RichardDonkin - 26 Sep 2003

Makes sense, go for it.

-- PeterThoeny - 27 Sep 2003

This is symptomatic that there is no builtin controlled process to creating new topics.

The nearest you get is in EditCgiScript where TWiki realises that there is no such topic:

    $tmpl = &TWiki::Store::readTemplate( "edit", $skin );
    if( ! &TWiki::Store::topicExists( $webName, $topic ) ) {
        if( $templateTopic ) {
            if( $templateTopic =~ /^(.+)\.(.+)$/ ) {
                # is "Webname.SomeTopic"
                $templateWeb   = $1;
                $templateTopic = $2;
            }
            ( $meta, $text ) = &TWiki::Store::readTopic( $templateWeb, $templat
        }
        if( ! $text ) {
            ( $meta, $text ) = &TWiki::Store::readTemplateTopic( "WebTopicEditT
        }
        $extra = "(not exist)";

        # If present, instantiate form
        if( ! $formTemplate ) {
            my %args = $meta->findOne( "FORM" );
            $formTemplate = $args{"name"};
        }

        my $foo = &TWiki::getGmDate();
        $text =~ s/%DATE%/$foo/go;
        $text =~ s/%WIKIUSERNAME%/$wikiUserName/go;
        $text =~ s/%URLPARAM{(.*?)}%/TWiki::handleUrlParam($1)/geo;  # expand U
        $text =~ s/%NOP{.*?}%//gos;  # Remove filler: Use it to remove access c
        $text =~ s/%NOP%//go;        # topic instantiation or to prevent search
    }

    ... joins the main code for edit

IMO, handling a non-existant in here is wrong, this should invoke a separate 'new' function. At present we miss a whole bunch of related things:

1. Access permission to create pages
2. The chance to offer help instructions particular to the web

KoalaSkin is much better here. It has an oopscreate mechanism through which 'New' requests and directly typing the (but not clicking on missing links) are channelled.

The following is a patch that I already submitted to Colas. By including a WebTopicNewHelp text it allows the web owner to specify text that the user should see when creating a new topic. In here you would put your support guidelines.

-bash-2.05b$ diff -u oopscreate.koala.tmpl oopscreate-mbs.koala.tmpl
--- oopscreate.koala.tmpl       Tue Jun 10 09:59:03 2003
+++ oopscreate-mbs.koala.tmpl   Sat Aug  9 23:21:12 2003
@@ -4,6 +4,7 @@
 %TMPL:DEF{"heading"}%Create new topic%TMPL:END%
 %TMPL:DEF{"message"}%
 <form action='%SCRIPTURL%/searchmulti%SCRIPTSUFFIX%/%INTURLENCODE{"%WEB%"}%' method="post" name=create>
+%INCLUDE{WebTopicNewHelp}%
 Create new topic (web page) named:
 <input type=hidden name=type value=create>
 <input size="32" type="text" name=search style="font-size: 9pt" value="%PARAM1%">

Koala skin does not invoke this process when I click on a missing link - I suspect it would be preferable to make all three methods (clicking new, clicking missing link, typing in go) subject to the same route.

-- MartinCleaver - 27 Sep 2003

I think this is an implementation of the idea I also have proposed in PatternSkinCodeChanges. I am for it (all three methods).

The idea is that (after clicking a link "Create new topic" or clicking a missing link) the user is lead to a topic page (instead of a template), TWiki.WebNewTopicViewTemplate (with a similar mechanism as WebTopicViewTemplate). Here the user can enter name, choose parent and topic template.

If the "create topic" is a template it will be difficult for some people to change it. I guess that was the reason to let WebTopicViewTemplate be a topic.

If the user clicks on a '?' (missing link), the topic name and parent should be prefilled. I don't know if this is more difficult to realize if we choose the topic approach or the template approach.

-- ArthurClemens - 27 Sep 2003

I agree the steps above should be taken. There is another major contributing factor for why people don't read the guidelines first: When people have a problem they go to the support web (or mailing list or faq or whatever). In their mind they are holding their problem to the forefront, rather like holding up an x-ray image or jigsaw puzzle piece. They aren't looking at details, the meaning of the words on the page, they are looking for patterns, holes, which match their problem. However the problem occupies at least half if not three-quarters or more of their field of view. The present front page of the support web cannot fit into the tiny space that is left over.

At the same time they are usually stressed, sometimes very highly. A stressed mind with a problem wants relief now. A stressed mind also has less, much less, holding capacity than a relaxed one.

.gak, my son just woke up, I have to go. Anyway, the conclusion is: put the support guidelines and the 'create new support incident' form on WebHome. Everything else goes somewhere else.

next day Having reread the support guidelines I realise they too are long for the front page. The problem is that there are just too many words and too many links. It's too hard for people to hold their problem in their minds and simultaneously read through the great extent of troubleshooting help available. WebHome needs to be pared down to the smallest amount of info that can still be actually helpful -- a difficult problem to say the least.

Something that would go a long way towards helping people is having a better search facility. If KeywordSearchWithImplicitAnd or PhotonSearch cannot be fast-tracked for code review I suggest temporarily availing ourselves of the excellent free google site search.

-- MattWilkie - 27,28 Sep 2003

I've now removed the Go field. Matt's point about the length of the Support guidelines is fair, but it's hard to see how they can be reduced that much - if people can't or won't spend the time reading these (about 5-10 minutes), how likely is it that they'll get the support information and log that? Perhaps an automated 'grab support info' tool would help, a bit like testenv (suggested on ImproveTestenv already) but focused on getting config information, web server error logs, and so on - the problem is that the location of such error logs is not standardised so the user would have to specify this.

I agree about the need for better searching - TWiki's searching is very weak really, compared to Google or even implicit-AND searching, and this is an issue for intranet deployments as well as TWiki.org. Also, some effort on improving the FAQ would be great - perhaps a SupportVolunteers team could be organised to help do this, as well as answer support questions?

-- RichardDonkin - 29 Sep 2003

was the GoBox removed before? it's back...

-- WillNorris - 10 Oct 2005

ArthurClemens has commented in various places that the Go Box (labeled "Jump:") is one of the first thigns that users remove form the WebTopBar. I'm guilty of this. I've moved it to the WebLeftBar and added a "Search" box.

I wonder if a combined Go/Search box similar to the one on MediaWiki/WikiPedia could be implemented?

-- AntonAylward - 10 Oct 2005

The GoBox possibly came back when the Pattern skin was enabled. Anyway, this is not much an issue anymore, it happens quite rarely that a question topic is created via Go box.

GoIsSearch discusses the Go vs search question

-- PeterThoeny - 10 Oct 2005

Right. It discusses it, but has anyone DONE anything about it?

On 07 Jun 2003 DavidJeske suggested a very simple code change.

On 04 Aug 2004 PeterThoeny said "Scheduled for Dakar, big usability enhancement."

But what has been done? It doesn't seem to have made it into Dakar.

-- AntonAylward - 10 Oct 2005

It was postponed to EdinburghRelease on 06 Dec 2004

Yep, an indiaction that we need to do a better job on prioritizing goind forward. Personally I consider this an important usability enhancement, one that moves TWiki away from the geek appeal into the mainsteam.

-- PeterThoeny - 10 Oct 2005