Page titles

Can we simplify and unify page titles?

This project does not yet follow the guidelines as layed out in UserExperienceTaskTeamProjects. Please help improve this page.

Summary

We need to consolidate user interaction with page titles.

Entering a page title at the top of a topic often feels redundant. The user has already entered a topic name. The syntax is difficult: next to using nops in the title, to prevent that the page appears in the TOC, the user must enter:

---+!! !WikiName title

To have a 'formal' page title (stored in a page's metadata), NatSkin has a default formfield for the page title. This may be a good idea to use for other skins as well, but a number of questions need to be answered:

• Where can we show the benefit. Is it useful to show the page title in search results, for instance? If so, will this work for kino search as well?
• How can integration be improved in the flow from topic creation to editing and saving? Currently title values are not copied to the edit screen.
• How can we improve communication to the user? Is the distinction between Name and Title clear (as on NatSkin's create new topic page).

Action Items

tbd

Contributors: ArthurClemens

Discussion

The TopicTitle (page title) feature as it is implemented on Foswiki is the result of two plugins:

• NatEditPlugin:
  • adds a TopicTitle formfield to the editor
  • stores the submitted TopicTitle either into a formfield of the same name or as a META:PREFERENCE
• DBCachePlugin / DBCacheContrib:
  • caching topictitles making it available as a structural property
  • implementing a renderWikiWordHandler() to use the TopicTitle as a display name for WikiWords when the user has not provided one him/herself.

This means that the current TopicTitle feature is available to all skins. It is actually been sponsored by a client that runs an old twiki-4.1.x engin using pattern. It has been tried hard to encapsulate the needed UI within the edit templates of NatEditPlugin to be compatible with all existing skins.

NatSkin uses the TopicTitle to create a nice HTML title. But that's it for NatSkin afaics.

Using the renderWikiWordHandler() also means that this TopicTitle will be used seamlessly everywhere, as long as no display text for the WikiWord has been specified otherwise.

So far the state of the current work.

There are still a couple of problems in terms of usability:

Users might get irritated when a WikiWord does not render as "!WikiWord" but instead as "Some title that he entered" in the TopicTitle input field. However, I think that this is actually a problem that will only show up initially. Other wikis have a similar, even worse, problem to remember a topic you want to link to and actually placing the link onto the page. We need to check that on user behavior. Carlo, what do you think?

Renaming a topic in a broader sense now is either changing the TopicTitle but keeping the TopicName, or changing the TopicName, however the TopicTitle stays as it is. That's a problem as both concepts (TopicTitle & TopicName) are decoupled, that is they might change independently. This is obviously a sword that cuts two ways: (a) you are relieved from WikiWords giving you back controll of what a topic link looks like (b) you carry the burdon of redundancy where information is stored in two places being not connected to each other.

The latter problem can be addressed when a new page is created by automatically deriving the TopicName from a free-form TopicTitle the user is expected to type in. There's a jquery plugin, called jquery.wikiword, that allows to derive a WikiWord automatically (as the user fills out a form) from a couple of input fields, i.e. the TopicTitle input field.

This obviously does not ease the redundancy a user is about to maintain. But maybe users will simply care less about the TopicName as soon as they feel comfortable using the TopicTitle to "rename" the topic.

In other wikis, changing the TopicTitle (page title) will also change the TopicName (url) with it. Well, a CoolUrlsPlugin would be a step in that direction, where we get away from WikiWords in the url and use some+topic+title+in+the+url instead. The database backend that is already caching TopicTitles will be able to map that onto the real TopicName.

From that point on we levelled the concept TopicName down to a pure database ID to refer to the entry in the web. Well and database IDs should not change that often anyway. Renaming a TopicName in nextwiki/twiki is not bugfree anyway (does change META data as well thus breaking WikiApps).

On another point: have a look at our current Tasks web and its WikiApp. What we see here is that the Summary field is actually clashing with the concept of a TopicTitle as discussed so far. That leads to the point where we'd like to keep that kind of formfield information on a standard so that the engine underneath will pick that info up and use it rendering display names for wikiwords, breadcrumbs and in the html title. The according change to the BugsContrib would be to rename the Summary field to TopicTitle and convert all txt data accordingly.

I think, there is still a separate need for a Summary field. This kind of information is quite different in nature from a topic's title. It is often use as a tagline in addition to the title, or as a subtitle. You wont put it into link texts but they make much sense as a tool tip or in a search result's summary field. %SEARCH currently computes a summary rather expensive by grabbing the first n chars from a topic and then plain-ifying it. The summary generated that way is not very useful in many cases, i.e. where there is non-content within that top area.

So basically what I was going to say is that all three concepts (1) TopicName = database ID (2) TopicTitle = title perceived by user and (3) TopicSummary = a kind of tagline all have a very distinctive meaning and use.

-- MichaelDaum - 07 Nov 2008 - 08:19

I allow me to make two observations, although I am not member of the task team:

1. The jquery plugin you mentioned should not eliminate a page name in case I enter the page name first and after that the title. Presently it does.
2. From a visual point of view I like the idea of separating the name from the title. When I noticed it for the first time, I was a little surprised when I saw that the rendered text does not coincidate with the page name, but as you already stated, it will be only an initial "problem".
   But there is a much more practical problem: When I am editing text and want to create a link to another page, I do not know how it is called and therefore I cannot create a link. Ok - I can hover over the page title and have a look at the URL to look up the page name, but you cannot expect that from a normal user. So there has to be found a way how to show one and/or the other.

-- SebastianKlus - 17 Nov 2008 - 19:38

Sebastian, good remarks. I agree that it is actually harder to create a proper link if you are not exposed to the TopicName all the time. I have seen this to be a problem for other wikis as well. Some even require you to know the page ID, which is obviously even worse. I don't know how much this is of an issue in real life. I guess that users will simply get used to it and somehow know which are the TopicNames that they want to link to.

Now about the create new topic dialog. Carlo rightfully pointed out that having the second TopicName formfield that is filled automatically by wikifying the TopicTitle is too geeky. Next version will simply hide it.

-- MichaelDaum - 18 Nov 2008 - 08:48

Hiding this may create problems with existing topics, where a new unique page id (topic name) is needed.

Linking to the right page could be done by hooking on the WYSIWYG selection list.

-- ArthurClemens - 18 Nov 2008 - 09:38