New Foswiki release 2.1.6 is available with important security fixes.
Sourceforge foswiki email lists being discontinued. Subscribe to the new Foswiki announce and discuss lists at MailingLists

Feature Proposal: Render form with more attractive appearance


The current form has the name of the form prominently rendered at the very top, both in editing and in viewing modes.

However, the name of the form is the least important thing about the form. In fact, for the user in view mode it is probably completely unimportant, and even for editing it matters only when changing the form.

Description and Documentation

Therefore, I suggest to
  1. In view mode, remove the top row containing the form name from the rendered form.
  2. In edit mode, remove the top row containing the form name and the "replace form..." button from the rendered form. Instead, Place the "Replace form..." button in a less prominent way below the form, preferably rendered as a link, similar to the "Add form..." button. The name of the form could be written in small print as part of the link such as "Replace ChangeProposalForm...".


This affects both the rendering code as well as the templates (for the appearance of the replace form button).

-- Contributors: ThomasWeigert


-- ThomasWeigert - 02 Dec 2006

We need to be careful not to remove some of the strengths of TWiki.

TWiki is a structured wiki where any user can contribute both with topic content and by building twiki applications. And modifying existing twiki applications including adding new values to forms etc etc. And knowing which form is used in an application is essential for the not to experienced user to understand how the application is built up.

I am really worried that those that try to make Twiki into traditional webmaster syndrome web applications get too much influence over TWiki. The whole point of wikis was to get away from the traditional old webmaster syndrome prefab static applications where users are either read only users or at most can submit some info in a few data fields and everything else is closed to them.

If that is what people want then choose another tool than TWiki. The main strength of TWiki is that anyone can make TWiki applications and anyone can copy design and ideas and build their own based on work already made and then I am deeply concerned with too much hiding of the design elements such as forms.

I really like that it is very visible what a Twiki topic is made from. And IF you need to prevent a few applications from being modified then put an ALLOWTOPICCHANGE on the form topic. It still allows people to see the design and copy it.

But let us not start hiding everything or make it less accessible.

As an advanced user I would also hate having to go to edit mode to see the name of the form used. Now I can click on the form and edit it right away.

Never forget that TWiki is in its basic mode a wiki and if we remove this essential foundation we destroy the real reason why TWiki exists.

-- KennethLavrsen - 02 Dec 2006

I agree with Thomas here. Editing forms, or replacing the form should only be done by very experienced users. Many of my users click on the form title (which is a link, by TWiki's normal mechanisms) in search of help about the form, and then they are confronted with a table they don't understand at all. I think a ratio of 1 application designer to 10 people who enter data to 100 people who just read isn't too uncommon.

For TWiki application designers who want to copy from an existing form, the name of the form can be shown in edit or raw mode. That's what they are used to if they steal from other pages. It can be formatted as a link to make inspection easier.

-- HaraldJoerg - 03 Dec 2006

The ratio 1/10/100 will for sure never get any better if you start hiding everything from your users.

You guys are starting falling back into web masters syndrome.

We can make the webform name less prominent but it has to be visible in view mode.

I have a much better ratio of application designers, data enters and readers. We are more like 20/60/100 and that is because I do not hide things, I do not limit access rights (and remove access rights when people add them where they are not needed) and I train more and more people to become application designers. Even if these applications are simple they add a lot of value to the teams that use them.

TWiki is an incredible enabler if you allow people to use the tool. Hiding and limiting access is BAD.

Are you sure people do not understand the table when they click on the form? If made properly it contains help in the right most column. Knowing the field names, their type, their values and the tooltip is a good help. Especially if you write proper tooltips. And if you add a little extra text in the form topic it is a really good helper for your users.

-- KennethLavrsen - 03 Dec 2006

Ken, this is not about preventing users from doing anything. Note that there is nothing about this suggestion that changes anything about the ability of the user to modify topics. I think you are misinterpreting what this proposal is about.

What this topic is about is not showing users usesless information. When I view a topic I could not care less what form was used in the topic. I care about the information that is shown.

Even when I edit the topic, I usually don't care about the form.

I only care about it either (i) when I create the topic or (ii) when the form is somehow not suitable. This is a very, very small percentage of the time I interact with TWiki.

But the form name is very prominently displayed, distracting from the real information on the page.

Most of my users complain about this at least once, but eventually give up and learn to ignore this useless information. But whenever new users come on board, they complain or wonder about this "feature".

-- ThomasWeigert - 03 Dec 2006

I have no doubt that your intentions are good but the proposal is none the less to hide the Form Topic Name from the users. And this I am strongly against. But I can easily accept to have the form topic name in a less prominent position. But it must be visible and a link.

It is true that the users do not need to view or edit the form very often. But that does not justify hiding the information, because when they need the information it is usually important.

  • They need to view it because they are not sure what the fields are all about. Just look below. You see BugTracking. What is this field for? Or what about CurrentState. I see a value. What are the other values it could have been? This is important information. I don't want to hide the access to the answers which are usually in the form topic - if it is made properly. Ie. with tooltips.
  • They need to edit it because the list of choices does not contain the value they need (e.g. the latest version of a software tool that you raise a bug report for).
  • They need to see the form to copy it for their own application.
  • They need to learn the natural way how things work in TWiki and they do not learn anything if you hide things.

I have been watching several proposals here on Codev recently that were about hiding user interface to help the newbies. And I disagree strongly. Some may say that TWiki has a too complicated UI when they have seen TWiki for 10 minutes. But none of them shall ever tell me that a few links on a page prevents them from reading the information in TWiki. And once they are past the first one hour as a user they will need the current UI to be able to to effective in the use of TWiki. And this is where we have to focus. TWiki must be effective in the 5000+ hours a user may use TWiki and not optimized for the first one hour.

Naturally the UI should scare away the user during his first hour but I do not believe our current PatternSkin does that at all. I think we have a beautiful and well working PatternSkin.

BUT if I am to come with a constructive proposal for this then I will need to illustrate it. Ie. I'LL BE BACK - wait before you burn me in flames wink I will produce some screenshots.

-- KennethLavrsen - 03 Dec 2006

OK. I have produced two screenshots. One showing the current PatternSkin design. And one which is a proposal which tries to meet both the requirement to not let the form topic name look like an essential part of the normal viewing navigation. And at the same time does not hide the information from the user and still allows the link to also work as a form field helper.



And remember. This proposal would be for 4.2. We have feature freeze.

-- KennethLavrsen - 03 Dec 2006

I also propose against fully hiding the link and suggest to look at a less obtrusive position.

-- ArthurClemens - 03 Dec 2006

Ken's screen shot 2 would satisfy my goal. I would suggest to put the link outside of the box, though, i.e., just under the form. Similarly with the "Replace form" link.

-- ThomasWeigert - 03 Dec 2006

Agreed. The second screen shot looks very good.

-- HaraldJoerg - 03 Dec 2006

Looks good indeed. No-brainer for TWiki 4.1.

-- PeterThoeny - 05 Dec 2006

No-brainer or not - I'd prefer it to be postponed until all release blockers for TWiki 4.1 are sorted out. The "long tail" of 4.1 is getting longer every day....

-- HaraldJoerg - 05 Dec 2006

This is anyway a skinning issue. I have done this now for pattern skin; other skins may implement their own layout. Bugs:Item3253.

-- ArthurClemens - 05 Dec 2006

Thanks. Can you do the same for editing mode? Also, could you not put the box around the form link? Just have it at the right below the form box?

-- ThomasWeigert - 06 Dec 2006

Which box and which link? You mean not inside the box, but outside? In that case it cannot be aligned to the right of the table. Right-align will make it align to the page at the far right.

-- ArthurClemens - 06 Dec 2006

Please do not make enhancements to 4.1. Wait for 4.2 We have a feature freeze. And this includes PatternSkin

-- KennethLavrsen - 06 Dec 2006

I have reverted the change.

-- ArthurClemens - 06 Dec 2006

Thanks Arthur. Sorry for being a pain but I have to be a little sharp to get that 4.1 out.

Looking forward to see this in 4.2. Thomas has added it to TWikiFeature04x02 so we do not forget it.

-- KennethLavrsen - 06 Dec 2006

Arthur, thanks for the change. I guess we shall have to wait for 4.1.1.

What I meant was this... there is a border around each table row. I was suggesting to put the link to the form beneath the border for the last row, as it is now, but not within a border itself. So the link is just sitting at the right edge of the form below the border of the form.

-- ThomasWeigert - 06 Dec 2006

That is not possible unless you wrap the table inside a second table. Which is kind of ugly code wise.

I wouldn't get too fixed on this because we need to get ready to have the form data not in a table but in a more free layout.

-- ArthurClemens - 06 Dec 2006

Am I dreaming? I've been wanting this for years, it's been a constant pain in the bum for users that's made me hate using forms, and example 2 (or similar) is a perfect solution.

Is there any way we could get this change as some kind of optional package, while waiting for 4.2? Please? Huh?

-- SueBlake - 14 Dec 2006

Sure. Drop formtables.pattern.tmpl into your templates folder. Some details may change in the near future, but this may help you for now.

-- ArthurClemens - 14 Dec 2006

This has been a long debate and my suggestion for better usability has not been favored so far: Move the change/add form from the edit screen to the more screen. I see it again and again that new users change a form or add a form to a topic and do not know what they are doing. For example, I remove quite often UserForms from personal sidebars on DataForms are part of application logic; forms should reduce the complexity for users, not add complexity ("don't make me think").

-- PeterThoeny - 14 Dec 2006

I agree with Peter. It makes sense to move any DataForms management to the "more topic actions" screen. In fact TWiki user should never need to change a form. This is only for TWiki application developer and even application developers don't need to do that so often as a TWikiForm is typically attached to a topic upon topic creation using an HTML form.

-- StephaneLenclud - 15 Dec 2006

Agreed, but see Ken's strong response above and on the related bugs item...

-- ThomasWeigert - 16 Dec 2006

If I understand correctly, Kenneth's point was mainly about not removing the link to the form. I agree, the link to to form definition should stay, but less prominent as discussed above. Kenneth, can you give your opinion on moving the change/add form button to the "more screen"?

-- PeterThoeny - 16 Dec 2006

Since the Patch04x01 has been branched out a long time ago it is perfectly OK to checkin this again in MAIN.

But this opens a principle decision. Should the plugins web contain the Patch release version or the MAIN branch version? This is a generic question for all default plugins.

I think I favour that we put the MAIN version so people have a chance to upgrade if they dare but it also opens up for trouble when a plugin depends on a 4.2 API which 4.1.X does not have.

-- KennethLavrsen - 06 Mar 2007

Not sure what the question of Plugin branches has to do with this topic. Please advise.

-- ThomasWeigert - 06 Mar 2007

It was a remark of principle nature since this is the first time the question arise. PatternSkin is an extension.

-- KennethLavrsen - 12 Mar 2007

Just to wrap up. The concensus is

  • Make the link to the form topic less prominent.
  • The more screen proposal was added later and I personally did not notice it until now. I would like that proposal to be seen as a new proposal on its own topic. And I would personally be against it as it makes the work flow of editing much more difficult. In fact many also complain that you cannot attach documents while in edit mode. Then I would rather change the user interface of the edit mode so that it becomes possible to both change form and attach files from the edit screen in a way so newbies do not make accidental form changes.

The original proposal was a more attractive form and that was agreed by consensus. The exact artistic implementation should be left up to Arthur.

-- KennethLavrsen - 23 Apr 2007

Not implemented in time for the feature freeze deadline for 4.2.0 and deferred to Georgetown.

-- KennethLavrsen - 29 May 2007

I am also in support of Kenneth's suggestion : it would be better to change the user interface of the edit mode so that it becomes possible to both change form and attach files from the edit screen in a way so newbies do not make accidental form changes.

-- KeithHelfrich - 29 May 2007

I agree that the "move change form to more screen" feature should be treated as a separate feature proposal. Just to iterate again, I remove or re-add forms on a weekly basis on's Main web because people click around and do not know what they are doing. As of today, AlexanderHeldLeftBar, BarkhaAgrawalLeftBar, CarloDiMeglioLeftBar, ChadChervitzLeftBar, DavidParadisLeftBar, DhirajKumarLeftBar, HoangXuanLeftBar, MartinPtacekLeftBar, NealSampsonLeftBar, PattiShortLeftBar, SamHochbergLeftBar have or had a UserForm attached to it. A form is part of the application logic, regular users should not be bothered with adding/removing forms.

-- PeterThoeny - 30 May 2007

Changing this to Discarded. Form layout has changed, and this discussion is too old.

-- GeorgeClark - 19 Nov 2015
Topic revision: r5 - 19 Nov 2015, GeorgeClark - This page was cached on 22 Jun 2018 - 16:46.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy