findability1Add my vote for this tag usability1Add my vote for this tag user_interface1Add my vote for this tag create new tag
, view all tags

Feature Proposals » Topic display name


Current State: Developer: Reason: Date: Concerns By: Bug Tracking: Proposed For:
ParkedProposal PeterThoeny None 2012-05-13     KampalaRelease

Edit Form

DateOfCommitment:   Format: YYYY-MM-DD
Create the possibility for a display name (the way a topic is shown as link) for every topic.


Display (topic) names are useful for several reasons. They:

  • Are less geeky than WikiWords and may broaden the user base
  • Show a more relevant name than is possible within WikiWord constraints
  • Give meaningful names to autogenerated topic names
  • Create links that can be picked up by search engines (normally almost no twiki pages show up when looking up my name on Google, while a link "Arthur Clemens" will be indexed - of course my name is just a silly example)
  • Make better navigation menus because long link names are split by the space delimiter
  • Remove almost all need for underscore_wiki_words (underscore names achieve the same at almost no performance loss, but introduce new linking syntax)

There are several ways to create a display name:

  1. Manually entered in a 'name' form field, to show: "Topic display name" with the current topic
  2. Set by a variable NAME in the topic text
  3. Based (automatically) on a person's name, to show: "Arthur Clemens" with my signature
  4. Based on the first header in the topic (AutomaticLinkLabelBasedOnHeading), to show "Feature Proposal: Topic display name" with this topic
    • Expensive with looking up for each topic, but may be set in a variable when saving the topic
    • May be useful on some sites
    • The other way around is also likely: the first header is generated from the topic's name

Why not always use display names?

  • WikiWord topic names make easy links and are generally easier to remember than a less contrained display name
  • A topic name does not change that often, and when it does relinking is possible
  • A topic name can be written as a logical part of a sentence that may be broken when a display name is used that changes
  • A topic name is a (human readable) page id; sometimes it is important to refer with certainty to a specific page

If we want to keep all that, we can say:

  • Do not change the appearance of all WikiWord topic names automatically into display names, but make this optional for each link
  • So do not change the working of the notation SomeTopic or [[SomeTopic]]
  • Create instead a new syntax to show a topic's name. For instance:
    • [[^SomeTopic]] (the ^ refers to alias - and is not a legitimate url character so does not clash)
    • ^SomeTopic
    • SomeTopic.name (OO)
    • [[SomeTopic][]] (leave link label empty, so default to the topic display name)

More rules:

  • The name variable may be set:
    • in a form field
    • in a topic variable (Set NAME = )
    • on a More page
    • in a meta field like PARENT
    • by a plugin
  • The name may be derived from the user's name values when creating a user page
  • A display name may be used with search results, so an equivalent $name parameter should be build for formatted searches
  • A name variable may be set using a url param, for instance when creating a topic by a form

-- ArthurClemens - 16 Feb 2006


This is exaclty what I want! The most wanted feature is a good looking page title in the browser window!!!

In my opinion, it is not necessary to use the costly TOC algorithm but instead use always the '---+' header one tag for page titles, as even if not using a header but some sections, in most cases nobody want section A to be a header for a document, that contains also section B and C (in the same level). So, if no TOC is requested, there should be no need for an extra rendering-just-for-toc-generation step. On most pages this header tag will used together with '!!', so '---+!!' is definitelly a header, no need to search for more.

So, what minimal effort has to be done?

  1. change the line containing %TOPIC% to %PAGETITLE% in the templates
    (for transition time a construct accepting both variables like %IF{'defined PAGETITLE' then='%PAGETITLE%' else='%TOPIC%'}% could be there)
  2. automatically find the value of PAGETITLE (or NAME if you want) if not set manually, which could be a simple regexp that matched the first occurrence of '---+'
  3. enhance URL syntax to support '^' notations
  4. enhance and maybe other makros

Some guidelines for the documentation when to use short and when long links would be a good idea, too.

So, anybody there, who is not convinced yet? Are you happy with a start page called 'WebHome' instead of 'Welcome to the Collaboration Plattform of XYZ'? Please try Google:WebHome - I got more then 12.000.000 results and more then 6.000.000 for Google:'WebHome Main'. Looks funny, and I'm sure, your company XYZ is under the top ten. smile

PS. As mine label ist not the famous XYZ, I'm still looking for a quick patch against Dakar to reach the second step as fast as possible. Atm I set PAGETITLE manually. frown

-- TobiasRoeser - 22 Feb 2006

There is no need for the IF. Add the Topic Display Name var to the core and default it to %!TOPIC%

-- RafaelAlvarez - 23 Feb 2006

What is the preferred way to set a variable (PAGETITLE) programmatic, that can be seen in a template file? Is it neccessary to write a plugin? And when, what is the best call (to TWiki::Func) to set such a variable.

-- TobiasRoeser - 30 Mar 2006

I think that we need a either a new plugin handler (to make it a plugin) or to change the way the WikiWord links are rendered.

-- RafaelAlvarez - 30 Mar 2006

Sorry, but the latter part is not clear for me. What I want to know is how to set a (internal) variable PAGETITLE (our page title var) calculated while processing the page so that the value of PAGETITLE is available when the page gets rendered using a template. So the value of this variable PAGETITLE should expanded in the template like any other variable e.g. TOPIC. Why we have to change the way of rendering WikiWords?

-- TobiasRoeser - 31 Mar 2006

Ahh, you mean that. Just set a preference in the page. Ex:

  • Set PAGETITLE = Topic Display Name

will be rendered as "Topic Display Name" wherever %PAGETITLE% is used.

I was thinking more along the lines that when TopicDisplayName is referenced, Topic Display Name is rendered. For that you need to modify the way wikiwords are rendered.

-- RafaelAlvarez - 31 Mar 2006

A thanks for clarification. But the Set PAGETITLE option is what I use already (see post from 22 Feb). I want to set this programmatic instead of manually. So, while TWiki parses the page, it recognizes a ---+!! and if it not finds a Set PAGETITLE then is assumes the heading of the page as PAGETITLE. This way, you can always override the page title, but if not, its default is the page heading. But to render this title, we have to set a preferences variable which is visible in the view template anyway. But until now, I could not find any TWiki function, that can set a new preferences variable.

For topic references, I like Arthurs suggestion. Don't change the default behaviour and provide a new link style e.g. [[^SomeName]] which expand to the full page title because of the presence of the '^' sign.

-- TobiasRoeser - 31 Mar 2006

The first step would be adding a handful of Preference functions which would operate on the settings part of a topic; i.e. SetPreference, GetPreference, ClearPreference. These could then be used to set the pagetitle in some automatic, as-yet-unspecified way.

-- MeredithLesly - 31 Mar 2006

A thanks, then I was right, that there is not such function at the moment. frown

Ok, first I will get my SearchByCreateDate patch finished. Afterwards, I will try to prepare some patches for discussion, but this can take some time, as I have to get prepared for my final examinations. smile

-- TobiasRoeser - 31 Mar 2006

To support discussion I've created a wireframe that shows the separate phases of topic display names: creation, editing and linking.

Wireframes of topic display names

-- ArthurClemens - 17 Apr 2006

hm, i think you've left off the most useful notation: [[Corporate identity]].

of course, it would be even nicer if you could simply type Corporate identify, and twiki would automagically resolve the link, but phrase-based linking is a completely different feature discussion...

-- WillNorris - 17 Apr 2006

Exactly, it is complementary. Topic display name is about getting a name (phrase) when referring to the topic id or WikiWord.

  • I want to get the display name in another topic. Of course I could write [[Will Norris]] every time I need a link to WillNorris, but that wouldn't be convenient. I want to write ^Main.WillNorris (or equivalent notation) and get Will Norris displayed.
  • There needs to be a way to get the topics display name when doing a search. For instance with $name.

-- ArthurClemens - 17 Apr 2006

A picture is worth a thousand words.

-- RafaelAlvarez - 17 Apr 2006

To summarize the current state, as this discussion stagnates:

This functionality is completely accepted, at least the issue, that it should somehow possible to display nicer page names and to refer to them from other sites. As Meredith stated in her post from 31 Mar 2006, the big blocker are some missing " Preferences functions which would operate on the Settings part of a page". So all we need is a code/design proposal. Unfortunately, I'm not as familar with this part of TWiki's heart as I would be. Can somebody assist/guide/mentor me, where to start. Hints on some docsm where the current preferences system is described, would be useful.

-- TobiasRoeser - 29 Apr 2006

What is the best way to start this? I think first we need to agree where/how the topic name is stored (META?).

-- ArthurClemens - 20 May 2006

There are two ways of creating topic preferences. One is indeed done via META and adding the functions to TWiki::Func shouldn't be that hard. (I didn't know how when I wrote my 31 Mar comment.)

-- MeredithLesly - 21 May 2006

I really like the idea to have a display name instead of the wiki name when linking to a topic. Part of that is already in the BlogPlugin in a different vesture where %CITEBLOG{"Blog.BlogEntry911"}% will expand to "<Headline>" by <Author> (<Date>) of that posting, where <Headline>, <Author> and <Date> are formfields. It would be greate to make this more userfriendly, i.e. not using a twiki tag. Making a "display name" a standard meta data seems to be the right thing to do. Even nicer if I can put in a TML expression that gets expanded as I'd like to have "%FORMFIELD{"Headline"}%" by %FORMFIELD{"Author"}% (%FORMFIELD{"Date"}%) in it for example.

-- MichaelDaum - 28 Jun 2006

Thought there already is a FORMFIELD 'variable' (see TWikiVariables#FORMFIELD_fieldname_renders_a_fi).

  • Yes, but this would require topics to have a form. And if they have a form already, the form would need this topic name field. And the syntax to request the value is not easy to use. -- ArthurClemens - 28 Jun 2006

-- FranzJosefSilli - 28 Jun 2006

Topic display name is also what Confluence does: Rename page is no longer a separate function. Just edit the page and change the page title, and Confluence will rename all the links to the page for you. Confluence - Where did everything go? - Rename (plus screenshot).

-- ArthurClemens - 18 Jul 2006

Oh, I like the interface changes to confluence discussed on that page. There are some questions and remarks:

  • What is their url pattern? There seem to be three different url styles that link to the same space: (1) tiny urls forwarding to (2) space-pagename urls and (3) viewpage.action+pageId urls.
  • (1) and (3) are pretty ugly and aren't thought to be memorizable by humans, I guess
  • Having different urls linking to the same page is bad for google.
  • How do they resolve page name clashes for type (1) and (3) urls?
  • Every page in confluence has a pageId, so pages can be referred to independent of their name.
  • Editing the page name as a separate input field as well as its parent on the same screen makes perfect sense. Editing the parent this way should be possible in TWiki too. Note that there is a magnifier icon probably opening a separate name selection box thereby decoupling it from generating the edit dialog (performance).
  • Last not least: they have a usability process
    • Of course. They design what to build, and how to build it. Write and design specs. Code the backend and the interface. I have tried this approach when I was new to TWiki, but here things work differently. There is no weight behind proposals, except for personal interests. Which is explainable, but a shame nonetheless. -- ArthurClemens - 19 Jul 2006

-- MichaelDaum - 19 Jul 2006

I want you all to remember one thing.

If you would like a major part of your links to not show the name of the topic but some data stored in the topic that this link points to then it means that for every such link - some code has to open the target file and read the data.

We have such a similar feature today called LINKTOOLTIPINFO

Those of you that have tried it - will know that TWiki is running far far slower with this activated. And you can from pure logic guess that opening many files and read a string of each file many links point to in a topic will slow down TWiki.

So make sure this feature - if implemented is made so when you do not use it - it adds no extra load. We need to speed up TWiki. Not slow it further down.

-- KennethLavrsen - 23 Jul 2006

Probably a good idea to think of a cache mechanism for this, i.e. along the lines of what TagMePlugin is doing.

Another approach could be to do this in AJAX or similar, allowing for a fast first time roundtrip.

-- SteffenPoulsen - 11 Oct 2006

The name variable should be stored in a META setting because it inherently belongs to the topic itself (not so much meta data as TagMePlugin).

And because it is a reserved word, we cannot just use META:PREFERENCE (or it could be deleted or changed name in the settings interface). Logical seems to introduce a new META:TOPICTITLE field.

Caching can be done as TagMePlugin does with the difference that to feed the cache the topics' META:TOPICTITLE value is read.

-- ArthurClemens - 11 Dec 2006

so long as i can set a web / twiki wide variable to that defined the title to be %SPACEDOUT{%TOPIC%}% , and thus never have to see / set / define a redundant META to be that??

-- SvenDowideit - 11 Dec 2006

Is your point using a topic variable, or using SPACEDOUT?

-- ArthurClemens - 11 Dec 2006

my point is that I set a web wide variable to give me a html title - often like


-- SvenDowideit - 12 Dec 2006

OK, but the issue here is to display this name in another topic. And to do this without too much performance loss.

-- ArthurClemens - 12 Dec 2006

After coming back one year later I see that there still is no consensus. Pitty, i.e. as Arthur made a very good proposal. I like having a META:TOPICTITLE variable including the related interface changes to edit. We need this. Can someone please sum up the counter-arguments, please?

-- MichaelDaum - 16 Mar 2007

I like Arthur's proposal, it is intuitive.

Things to consider:

  • With I18N, are some characters removed/expanded when building the linkage name (aka topic name) from the display name?
  • Allow user to change topic name when creating new topic?
  • How does a rename of topic work? Chance the display name and topic name?

-- PeterThoeny - 16 Mar 2007

The major warning I keep on repeating is the performance issue.

Each time you view a topic a WikiWord link shown with this feature, TWiki will have to read the meta from the topic files to be able to show them. It cannot be done without a major performance hit unless we radically introduce it in connection with an indexed cache.

And it is about time people think beyond a minor release and address this greater problem. Besides display names, access rights, patents-child relations, the topic summaries and the topic names themselves should be in an index so searching for them can happen much faster.

-- KennethLavrsen - 18 Mar 2007

Kenneth makes a good point - something like TWikiCache is increasingly important for features like this.

This should be I18N-transparent as long as it's done properly, only valid topic alphanumeric characters, whether I18N or not, should be allowed. Performance of the feature without I18N is a much bigger issue.

Would be great to get hold of the TWikiCache code, if only for my home TWiki which is a bit slow!

-- RichardDonkin - 18 Mar 2007

I do not see any progress on the discussion topic. The spec is defined but technical solution that will work is missing. A topic needs a driver who is committed to implement it.

KennethLavrsen's summary of the proposal.

  • Spec is agreed
  • Implementation has caused at least Kenneth and also Richard to raise concern about the performance if this gets implemented under the current storage model. This means that this is probably a proposal that needs to get re-addressed for TWiki 5. In a DB storage model this proposal could be implemented very easily without any significant performance hit by having the right indexed tables in the DB with topic display names.
  • Proposal is put in parked state ready to get picked up during TWiki 5 development.

-- KennethLavrsen - 25 Apr 2007

Mmm, by thinking about it, I have another technical solution. Just define a perfect functional mapping between TopicDisplayName and TopicFileName. For instance we could use the Web URL quoting of URLs:

  • TopicDisplayName = Kenneth Lavrsen's summary of the proposal
  • TopicFileName = Kenneth%20Lavrsen%27s%20summary%20of%20the%20proposal
If you look at it, this is what the SpacedTopicPlugin implements (but one way)
  • we also could have a rendering strategy for the URL context like the one used in blog e.g. Kenneth-Lavrsen-s-summary-of-the-proposal

-- ColasNahaboo - 31 Jan 2008

Good proposal, resurrecting it from ParkedProposal to UnderInvestigation.

I suggest to use a topic display name in this sequence until found:

  1. Form field name "Title" (already in use by several TWiki applications such as Support forum)
  2. Preferences setting TITLE
  3. Topic name %TOPIC%

Anyone driving this?

-- PeterThoeny - 2010-07-29

Ping! Anyone interested in implementing this?

-- PeterThoeny - 2011-08-23

New VarTOPICTITLE proposal as a first step to implement this proposal.

-- PeterThoeny - 2012-05-11

I am committed to implement this as per Arthur Clemens's wireframe on 17 Apr 2006.

-- PeterThoeny - 2012-05-14

How about introducing a new topic metadata %META:TOPICTITLE{title="Topic Title"}% ?

  • The save script would have the topictitle parameter to set it.
  • %META{...}% variable would be enhanced to have %META{"title"}%.
  • %SEARCH{...}%'s format parameter can have $topictitle referring to it.
  • WebTopicEditTemplate would have ---+!! %TOPICTITLE% while WebPreferences would have * Set TOPICTITLE = %IF{"'%META{"title"}%' = ''" then="%META{"title"}%" else="%SPACEOUT{%TOPIC%}%"}%

There are people having a topic title in a form field or using some other ways to provide topic titles. They are not affected at all by introduction of the TOPICTITLE attribute.

This is in a sense a counter proposal to VarTOPICTITLE.

-- HideyoImazu - 2012-05-30

Hideyo-san: See my answer in VarTOPICTITLE on 2012-11-21.

-- Peter Thoeny - 2013-01-27

New related proposal that does part of this proposal: ShowTopicTitleInLinks

-- Peter Thoeny - 2013-01-27

Discussed at KampalaReleaseMeeting2015x07x02:

-- Peter Thoeny - 2015-07-02

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng Topic_display_name.png r1 manage 159.9 K 2006-04-17 - 00:04 ArthurClemens Wireframes of topic display names
Edit | Attach | Watch | Print version | History: r52 < r51 < r50 < r49 < r48 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r52 - 2015-07-02 - PeterThoeny
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.