create new tag
, view all tags

Create New Topic

Proposal from PatternSkinCodeChanges. Go there for an overview of other changes and page flow diagrams.

Table of contents:


It should be obvious to users how to create a new topic. The current way to create a new topic is:

  • Type a unexisting topic name in the Go field
  • Click on a question mark link after an unexisting topic
So users have to remember the workings of twiki, and are not visually supported.

Because of our memory capabilities are limited, visibility acts as a good reminder of what can be done with a device. A good reminding method is to put the burden on the thing itself. Designers should give as much succinct clues to the users as possible on the device itself, without overwhelming or confusing the users. This supports the phenomenon of recognition over recall. Our ability to recall information is inferior to our ability to recognize it from some visual cue. Therefore, if there exists a good relationship between the coding or placement of the control and what it does, it makes the appropriate task easy to find. In turn, there will be very little to remember on how to operate the control and its corresponding effects, maximizing the use of the knowledge in the world and minimizing the use of the knowledge in the head. paragraph from page about Donald Norman's "Philosophy on Design for Everyday Interaction"

Improvement for the visual appearance of the question mark is in NewTopicLinkStylePatch.


I propose the following changes:

  1. In the topic view template, show a link or button labeled "Create new topic".
    1. Clicking will lead to the new TWiki Web topic TWiki.WebNewTopicViewTemplate
      • This page shows the user the options:
        1. Enter new topic name
        2. Select topic template
        3. Select topic parent
        4. A button to cancel topic creation
      • See implementation example: NewTopicTemplate
      • Colas has warned that this page should not look like an error page, and that there should be the text "You are creating a new topic" (ClickNonExistTakesToOopscreateNotEdit)
    2. For some configurations, the current behavior of the Go field can be kept. However, I think that for most cases usability can be improved by replacing the Go box with a search field and the currently proposed "Create new topic" button.
  2. Clicking on the question mark link after a topic-that-does-not-exist-yet leads also to a new TWiki.WebNewTopicFromLinkViewTemplate (instead of directly to topic edit)
    • This page is similar to TWiki.WebNewTopicViewTemplate, but the topic name is not editable and the parent is prefilled.
    • If the user is not allowed to create a new page, either an alert should be inserted on the page, or an alternative TWiki.WebNewTopicNotAllowedViewTemplate should be presented.
  3. Cancelling the editing of a new topic leads the user back to the TWiki.WebNewTopicViewTemplate he just came from. He can choose another template here for instance. So topic creation is a 2-step process, and cancelling when editing too. See also CancellingANewPage.

Summary of new pages:

  1. TWiki.WebNewTopicViewTemplate - after clicking on the link "Create new topic"
  2. TWiki.WebNewTopicFromLinkViewTemplate - after clicking on a question mark link
  3. TWiki.WebNewTopicNotAllowedViewTemplate - after clicking on a question mark link and the user is not allowed to create a new topic

I guess it is best to have a basic topic that can be included in the more specific topics above.

  • Flow diagram:

-- ArthurClemens - 03 Dec 2003

Discussion 1

Downsides of a new topic link (NB, I often install one for the reasons you list) are that it breaks the "wikiness" of a site:

  • The ability for people to create new topics which aren't linked dramatically increases the number of OrphanedPages in a web.
  • You change the topology of the links inside the web from a densely interlinked web of topics into a selection of StandalonePages with low linking. This in itself can (and IME does) discourage people from SerendipityLinking or RandomlyThrowingWordsTogether to see if they link. (link first mentality)

Having a means to discourage these downsides is a good idea. What can be worse in some respects is if the default way to create all pages in a wiki comes from a "new topic" approach you rapidly endup with pages that read as one way discourses rather than refactored discussions. Even worse - you can get heavy resistance when changing pages to be more wiki-like (eg linking to common concepts even though pages don't exist but should).

These aren't reasons not to have this kind of link, but motivations for thinking of ways of mitigating the problems it can cause. One possible solution which seems to be an interesting compromise is to have a modified CommentPlugin that allows headings to be associated with things, which if the ideas become sufficiently interesting can get spun out as topics in their own right - in the same way people often discuss things and refactor out pertinent parts of pages into other pages.

-- MS - 07 Dec 2003

  1. One piece of feedback I received a few months back was that when my user hit "New Topic" from WebHome he was surprised that, on completion, WebHome now did not link to his newly created page. He said, in his opinion, that unless this was fixed people would not grok TWiki without being trained.
  2. My users kept on creating things in the wrong web until I added a "select web" option on the "New Topic" page.

-- MartinCleaver - 08 Dec 2003

Reaction and solutions

To 1:

One's first reaction could be to laugh at this 'dummy' behavior. But I think the issue is more serious. The problem of this user is probably a faulty mental model of the workings of TWiki. If he sees topic creation in line of creating a folder in a directory, it is indeed disconcerting that the new topic does not appear at the place he created it.

As users interacts with a product, they form a mental model of how that product works. The model grows incrementally based on cause and effect observations of user actions and product response. [...] There are two consequences of an inaccurate model: either the user builds inefficient patterns of use into his or her way of working with the product, or the user abandons functionality because the mental model shows it to be unreliable or taxing. Either way the user’s productivity — and satisfaction with the product — takes a hit. - User Interface Engineering -- "Tabbed Dialogs" Article

Note: user's mental models are often wrong in principle but correct in effect.

You have two choices. You can try to change the user model. This turns out to be remarkably hard. You could explain things in the manual, but everybody knows that users don't read manuals, and they probably shouldn't have to. You can pop up a little dialog box explaining that the image file won't be embedded, but this has two problems: it's annoying to sophisticated users, and users don't read dialog boxes, either (we'll take more about this in Chapter Six).

So, if the mountain won't come to Muhammad ... your best choice is almost always going to be to change the program model, not the user model. [...] An important rule of thumb is that user models aren't very complex. When people have to guess how a program is going to work, they tend to guess simple things, rather than complicated things. Joel Spolsky: User Interface Design for Programmers - Chapter 2: Figuring Out What They Expected

What the user needs to do is:

  1. Enter a topic title, go to edit the topic and save (the new topic will be added to the big bag of topics of the current web)
  2. Go to another topic
  3. Add a link to the new topic

So obviously some users do not have this model. The question is how many users have this problem. Is Martin's user an isolated case, or do many more users have an inaccurate mental model?

As a test, I asked my collegue interaction designers what they expected what would happen after they created a new topic. They are not familiar with the TWiki or with wiki sites in general (in fact they should use this site, as they should partake in the interaction design patterns repository, but hey, I can't just change someone's motivation...).

You should know that my "Create new topic" link is in the left nav bar.

Person 1: "I would expect that the new topic is listed on the home page, under Recent changes". Maybe after I travel a bit through the site (some deeper levels) I would imagine that the parent link of the the new topic could be created automatically [it's not].

Person 2: I think it will be listed in the Topic list, and temporary under Recent changes and on the homepage [correct]. However, if I base the topic on a "Patterns" template I would think it will be added to the patterns repository [partially incorrect: the page looks like an index, but is created manually].

Person 3: The new topic can be found in the topic list. It is because the "Create new topic" is in the global sidebar, it is separate from the topic page. So I am interrupting my topic flow [reading] by creating a new topic [correct].

Of course these are my colleages and not intranet users. And these persons have some idea how the internet works. The value in their remarks lies in that they recognize that "Create new topic" is a global function, separate from the current topic they are reading, so that clicking the link will remove them from the topic.

To 2:

These users probably don't realise that TWiki webs are physically separated. Which is illogical actually, because it is different then the concept of topics: created once you can link to it from anywhere by just typing the title. So users must know that TWiki webs are separate bags of topics (text files). In fact you can consider TWiki webs as separate sites, but

  1. the visual appearance does not enhance this idea
  2. it is strange to consider the Main or User web as a separate site, because they are fundamentally part of all other pages (for instance each name links with Main.)

Possible programming enhancements:

  • Automatically set the topic from where the "Create new" link is clicked as the parent. So "Create new topic" functions in fact as "Add child topic to current topic".
    • List the current topic (parent to be) in the "Select parent for the new topic" list.
    • There is still a problem with WebHome, as you don't want to have a few hundred child topics of the homepage. Topics created from WebHome should have no preset parent.

Possible UI enhancements:

  • In the menu, list the child topics of the current topic. Then there will always be a visible link of the new topic (if the parent is set). This feature used to work on my site, but I just discovered it is broken :-(
    • This can address the problem of orphaned pages, because the visibility of the new topic will diminish the chance of neglect.
  • Add a subtitle: "Add a new topic to [current web] web", to remember the user where the topic will be created.
    • Or add a dropdown box to let the user select the web where to create the topic in (expert usage).
  • Make TWiki webs visually more distinct.

-- ArthurClemens - 08 Dec 2003

Discussion 2

I agree that this is an important shortcoming of the current TWiki architecture that needs to be fixed. I see the issues can be split into several distinct concerns:

  • Template Selection: Selecting alternative templates is something that I ran into as a deficiency very early on when using TWiki to establish several sites.
    • One Template per Web?: No! Template selection becomes especially important if you want to consider Webs as NAMESPACES and not a means to select the template used. My personal opinion is that Webs are generally only a superfluous complication, and that in general, there is not a concern for namespace conflict on a given TWiki site. That is, you really want to find the topic, no matter which web it is in on the site, and if you use the same topic name in several different webs you are asking for mental exhaustion. The Topic name should mean only one thing on a given site regardless of the web it is in. This is the meaning of a namespace, and therefore, the entire site should be a single namespace. It also supports the concepts of Seredipity Linking, etc, that are mentioned above. Given this conclusion, it becomes natural to want to support several different templates within a single web, making template selection during create essential. I assume that the fact that webs are still considered important is due to other concerns, such as keeping searches efficient by searching over certain webs, and using different templates. Indeed, you can force primitive template selection by using HTML dialog to create a new page and choosing the template as a result of that form, i.e. selecting by URL parameter. This is deficient in that it does not allow template selection if the topic is not found.

  • Topic Creation Method: The method of creating the pages, i.e. through the GoDialog or search, or clicking on a WikiWord: I agree that this can be improved. In general, I think it is useful to think of this in terms of WorkFlow. The same infrastructure used for general-purpose WorkFlow can be used to support it, and using WorkFlow analysis can be the method of analysis for creating topics. Currently, there are two methods for creating a new topic, as outlined below.
    • Context Linking: This is the WikiWord method, when the word is added to a topic and then the question mark clicked. Indeed, in this method, more robust dialogs are necessary to enforce no spaces in the actual file name (unless other changes are made to the code), and selection of the template, per above. The nice thing about this method is that it is automatically linked to the topic where it is found.
    • Unlinked Creation: This is the method that is the result of using the GoDialog and not finding the topic, and then clicking [Create], or through any proposed direct [Create] link in the NavigationBar. The GoBox, per other discussions, is probably better considered a WebSearch box, which looks for both the topic name and/or the phrase in the content.

      With this method, however, there is no method provided for linking this to the rest of the TWiki. I claim that this concern can be eliminated by providing two things:

      1. MultipleFormsPerTopic - More than one form can be added to a particular topic template, thereby allowing a basic level of tracking for all topics, such as which logical area to add it (much like the TopicClassification field of this Codev web) and other forms that are appropriate for the type of topic being added.
      2. MultipleTemplatesPerWeb - More than one template can be applied to a given web, which is what I have been ranting about above.

Both of the topic creation methods above suffer from some of the same deficiencies:

  • More robustness in helping the user to insure that the topic name is correct is important.
  • One "bug" here is that if the users specifies a topic name with spaces, they are not removed and a file name with spaces is created. (I enhanced the filter to include spaces removed to eliminate this problem by including spaces, easy to do in the configuration file. But without this enhancement, files with spaces will break the file selection method used by grep.

-- RaymondLutz - 08 Dec 2003

Possibly redundant: currently you can select from multiple templates (see NewTopicTemplate). But I see you propose to improve the selection method by adding explanations, am I right?

  • No, that was not my point. Indeed, I have implemented the use of several templates in the same web, but in order to do that, it is necessary to construct an HTML form that will pull in the Topic Template in response to the user filling in the form. The point was that when a user enters a Topic Name (WikiWord) into the GO box, it will take him to the oops page, and from there, it is not available to select which template is to be used. I'm not saying that it would be impossible or even difficult to change this, just that the facility is not there, and in the WebPreferences page, there is only one default Topic Template specified. On the other hand, there are multiple Forms that can be specified for a given web. -- RaymondLutz - 10 Dec 2003

-- ArthurClemens - 08 Dec 2003

Refactored rest of multiple webs discussion out to MultipleWebs -- ArthurClemens - 10 Dec 2003


Unfortunately, that will suppress the issue that webs may be today created simply to provide a default template that will be used when a users clicks on an undefined WikiWord. If you have a means to have MultipleTemplatesPerWeb, as proposed, and a means to select amongst the templates when starting a topic (by any route, including clicking the undefined WikiWord), then that fully decouples the question of webs from the ability to define templates. That would satisfy my needs.

-- RaymondLutz - 11 Dec 2003

But... my flow diagram shows that after clicking the question mark, the user will be lead to the NewTopicTemplate, and that he can select there one of more topic templates.

-- ArthurClemens - 11 Dec 2003

Much good thought going on here... Raymond, thanks for bringing up the important distinction between namespaces and templates.

I think I like the proposed a "create new topic" button and the followup process as described. I'm not as confident the same process should be followed for in-topic new links though (the infamous ?'s). By definition the context for in-topic links is already obvious. The user has already decided where they want the topic to be in relation to the rest of the wiki by choosing which topic to put the UncreatedLink in. Following that with the same dialogue as used for the [new topic] button is essentially the same as presenting the user with an "Are you sure?" modal popup window.

So when following an in-topic create link consider this: 1) go directly to the edit page, 2) add the rest ('topic template' & 'parent' list boxes, 'cancel' button) of the new creation processes to the page header (or wherever makes the most sense within the current page design). The point is that experienced users should be able to smoothly carry on with a minimum of hassle.

-- MattWilkie - 11 Dec 2003

The idea of going to the same page after clicking the ? link, is to let the user choose from a template. It could also offer a solution to the problem presented in CancellingANewPage.

I like the idea of facilitating the frequent user. But I see a few problems with your proposal:

  • I am not so sure about setting the parent in the Edit page, as the loading time of the page will increase to intolerable (for instance go to a Codev's More page right now - you wouldn't want this on the Edit page). This is a reason to put Select parent to a separate page (I am following the idea of Sam Hasler on NewTopicTemplate).
  • Putting a "select template" option on the Edit page will presumably reload the Edit page with the content of the topic template. This can get a nightmare if someone has written a lot on the page, and then tries to select a template (perhaps the user is thinking he can format the layout with this). All editing will be replaced with the empty topic!

-- ArthurClemens - 11 Dec 2003

I disagree that the same context is automatically appropriate. Let be give a current example I am wrestling with, that illustrates this:

I have a long list of dates and events in a chronology of history. Here is an extract:

Date Event Description
1637 DescartesMethod Descartes's Discourse on Method
1638 GalileosTwoNewSciences Galileo's Two New Sciences
1640 JanseniumBegins Jansen's Augustinius, beginning of Jansenism in France
1642 EnglishCivilWar English Civil War, (1642-1648)
1644 DecartesPrincipiaPhilosophiae Decartes's Principia Philosophiae
1644 MiltonsAreopagitica Milton's Aeropagitica
1665 NewtonDevelopsCalculus Newton makes early scientific discoveries and develops calculus (1665-66)
1667 MiltonsParadiseLost Milton's Paradise Lost
1678 SimonsCritique Simon's Critical History of the Old Testament pioneers textual criticism of the Bible

Adjacent to these "literal" entries is a SEARCH directive, that will list as well entries that are sucked in from topics that include the details of the events that are shown, such as the following:

%SEARCH{"[E]ventForm;\-\-\-\+;value=\"CE\"" regex="on" nosearch="on" nototal="on" noheader="on"  format="|$formfield(EventDate)  |[[$topic][$pattern(.*?\-\-\-\+\s*(\S[^\r\n]+).*)]]  |  |"  excludetopic="EventTopicTemplate|EventDate|EventForm|OtherRegionName|WebPreferences|WebHome"}%

The operation I would like to have is that when the famous '?' is clicked, that the a template will be used that will be appropriate for the event, which includes the EventForm to help categorize the event. For those events that don't have any detailed information, they would still appear in the table as the undefined WikiWord plus famous '?'. You will note that many of the events are actually important epochal books that were written. I have another set of templates and forms that are for Book Reviews. However, I have put that in another web to get the template to default. Unfortunate, as I would really like these in the same namespace. I would also like to have MultipleFormsPerTopic in the case when the event is also potentially a Book Review so that the fields that are appropriate for a book are included but are not included when the event is not a book (like a war).

One other interesting detail is that the dating scheme used for dates in TWiki and most other computers has a real hard time with CE vs BCE dates. For the time being, I have these in separate tables, as the dates go in reverse order for BCE dates.

Therefore, I disagree that adopting the parent Topic Template is appropriate for the child topic, and more than one may be appropriate, and more than one form may be appropriate when the child topic is created.

One possible approach would be to denote the default template using a topic-specific directive like %DEFAULTTOPICTEMPLATE%. Then, the famous '?' would go to the template which would be fine in the case I mention.

-- RaymondLutz - 11 Dec 2003

To get to a solution that works for everyone/most of us: (Raymond,) would it work for you to have the intermediate Create new topic page where the user selects the template, or do you search for a more restrictive solution that implies (unchangebly) the template to be used?

-- ArthurClemens - 12 Dec 2003

Why not cover all the bases? Allow passing of default template, a subset of templates to pick from, or a flag to force it straight to the edit page?

-- SamHasler - 12 Dec 2003

To answer your question, I think the following is what is required:

  • A means to allow more than one Topic Template to be selected when the user begins a new topic:
    • From failure to find it (these functions should be combined):
      • From Go Box lookup failure.
      • From search failure.
    • From famous '?' clicking, and in this case:
      • a means to set a set of default topic templates for use from the parent topic (Where the '?' is clicked).
      • if a single default topic template is defined, the user would not be asked to further select the template.
      • Otherwise, the user would be asked wo select from the set of default topic templates or from the full set of topic templates.
    • From embedded HTML form, if template is not specified, or if a (sub)set of templates is specified.
  • more robust checking of the format of the file name created to disallow spaces and strange characters, OR improvement in the grep strings used for searching to allow spaces and strange characters.
  • The method of accomplishing this SHOULD walk the user through it, not be a hidden button somewhere, if there are multiple templates defined.

Why not cover these bases?

-- RaymondLutz - 12 Dec 2003

Pushed to DakarRelease.

-- ArthurClemens - 24 Jul 2004

This topic had the state "ConsensusReached". Given that it does not have a CommitedDeveloper, I cannot change it to "ReadyForReleaseMeeting", so I'm putting it "UnderInvestigation".

-- RafaelAlvarez - 16 Sep 2008

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng Flow_NewTopic.png r1 manage 63.0 K 2003-12-03 - 23:16 ArthurClemens Flow diagram
Edit | Attach | Watch | Print version | History: r27 < r26 < r25 < r24 < r23 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r27 - 2008-09-16 - RafaelAlvarez
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.