Tags:
stale_content1Add my vote for this tag create new tag
, view all tags

Move Change/Add Form buttons to "topicaction"

There have been a number of complaints on the placement of the button to change forms. The attached modifications to

  • bin/edit
  • templates/edit.tmpl
  • lib/TWiki/Form.pm
moves that button right next to the "Preview Changes" button in the edit view. Depending on whether the form is present or not the button displays "Change form" or "Add form", respectively, as shown in the graphic below:

TWiki Home TWiki . Know . WebHome (edit)
Change topic

Don't forget - if you change something, do it in GoodStyle and follow the TextFormattingRules.
-- Main.TWikiGuest - 08 Nov 2002   <== This is your signature for easy copy & paste operation
Topic WebHome . { | Cancel edit }
NOTE: If you Preview, then go Back and can't find your changes, use the browser's Forward button (not Preview), then Save. Your changes will be fine, and you can Edit again. This is caused by a caching bug in Internet Explorer, which gets activated if you use the pop-up help links in this page.
Copyright © 2001 by the contributing authors. All material on this collaboration tool is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.

If a form is attached, the button changes to the "Change form" button:

TWiki Home TWiki . Know . WebHome (edit)
Change topic

Don't forget - if you change something, do it in GoodStyle and follow the TextFormattingRules.
-- Main.TWikiGuest - 09 Nov 2002   <== This is your signature for easy copy & paste operation
WebForm </th bgcolor="#99CCCC">
TopicClassification </th bgcolor="#99CCCC">
OperatingSystem
  </th bgcolor="#99CCCC">
OsHPUX    OsLinux    OsMacOS   
OsSolaris    OsSunOS    OsWin   
OsVersion </th bgcolor="#99CCCC">

Topic WebHome . { | Cancel edit }
NOTE: If you Preview, then go Back and can't find your changes, use the browser's Forward button (not Preview), then Save. Your changes will be fine, and you can Edit again. This is caused by a caching bug in Internet Explorer, which gets activated if you use the pop-up help links in this page.
Copyright © 2001 by the contributing authors. All material on this collaboration tool is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.

See also ChooseFormButtonIssues, FormChooserPosition.

-- ThomasWeigert - 08 Nov 2002

A patch against today's version of the Beijing beta on SourceForge is attached.

-- ThomasWeigert - 09 Nov 2002

The form button in this patch certainly looks nicer compared to the current location. However, it increases the likelyhood of hitting the button accidentally.

I would like to see the button moved to the More screen as discussed in FormChooserPosition.

-- PeterThoeny - 09 Nov 2002

I don't think that the button is more likely to be hit in the place next to the preview page. The problem with the original placement was that when you scroll down a page to hit the "preview changes" button, this button comes in sight first. If you don't carefully study the inscription, you are tempted to hit it. That happened to me often...

In addition, this solution is consistent with, e.g., the "attach" screen, where we also have two buttons in the topic action bar: the "Upload file" and "Change properties" buttons. Incidentally, these perform similar functions... Note that nobody has ever complained that they accidentally hit the "Change properties" button when the "Upload file" button was meant...

Moving it to the "More..." action would be changing the mode of interacting with TWiki. Currently, this button is accessible from the Edit mode. Note that in Edit mode there is no "More..." action. Thus either we would have to

  • remove the ability of changing the form from the Edit mode by moving it to "More...", or
  • add a "More..." action to the Edit mode.

I was thinking of turning this button into an action, but that would involve quite some changes, I think, as this button is part of the form.

Thus, I think that the solution presented here is the preferable one, as it is most backwards compatible from a user interface point of view. It merely makes the user interface more consistent (no buttons other than in the topic action bar, same location for adding and changing form buttons).

I am open to suggestions, though. If the preference is to move the from change functionality to the "More..." action as described above, I am willing to look into that as well.

-- ThomasWeigert - 09 Nov 2002

Is safe to change form if page is not locked? Will changing form at More page check and warn if page is locked? Fine if More does, but if not, maybe Edit page is better (locked) place to change form... Just my paranoid $.02 worth... wink

-- PeterMasiar - 11 Nov 2002

Peter, I agree with your point. I prefer to do this in the edit mode as being less of a change and safer. I have a working solution that solves the problems described in ChooseFormButtonIssues, FormChooserPosition. I propose to update according to this proposal.

-- ThomasWeigert - 11 Nov 2002

SaveContentWithoutEdit allows you to change the form used on a topic with one button click. It is still dangerous as you loose your old form data (i'm thinking of changing this in a later release)

Arthur - do you need more info to use this on the more page?

-- SvenDowideit - 04 May 2004

I vote for the form either being off the edit page, below the Preview button, or right-justified. I also think the button's name should change to "Change Form".

-- DuckySherwood - 04 May 2004

I am not sure what the benefit is of putting the button on the More page. I think the problem with this button is its position and the similarity with the "Preview changes" button. The latter can be solved by changing the button to a link. The former by placing the link at the right of the table header, maybe even in a smaller font. Putting it in the same row as "Preview" and "Cancel" would dislocate form and action.

-- ArthurClemens - 04 May 2004

mmm, i was going to agree with you, but then i thought about how rarely i change Which WebForm a topic is using, and was wondering why we'd want to confuse most of the people that never use it

-- SvenDowideit - 04 May 2004

That's true. But the question is why put it in a place away from where you would need it? I would like to reserve More for options to meta view topics.

  • thats a good point too :() talk about difficult smile -- SD
    • No, I mean: to have a meta point of view, not meta data in topics smile -- AC

-- ArthurClemens - 04 May 2004

Anything that confuses new users should be moved out of the way. On TWiki.org I see people frequently change forms out of the blue in the Main web and Sandbox web. Forms are typically used by TWikiApplication and workflow like here in Codev. A form on a topic need to changed very rarely.

Therefore I thing the best place to change the form is the More screen. This is consistent with the change parent feature (both should be done with a SaveContentWithoutEdit.)

-- PeterThoeny - 07 May 2004

I think there are two reasonable solutions:

  1. Put the form button on the more screen
  2. Put the form button next to the "Preview Changes" button
For the latter you can see the demo above, and code that does it attached. I can send a newer patch if that is desired. We have been using variant (2) for a long time now, and the complaints about hitting the wrong button by accident have totally stopped. I am using this button also for controlling work flows imposed by forms (see WorkFlowAddOn).

-- ThomasWeigert - 07 May 2004

Given that:

  1. many people skip preview
  2. the form is a piece of meta data

I'd vote for it going on the more screen.

  • Do you want to suggest to put the form entirely to the More page? Since the field data are meta data smile No, you cannot enforce logic to a web interface. -- ArthurClemens - 07 May 2004

-- MartinCleaver - 07 May 2004

Anything that confuses new users should be moved out of the way. -- True to a large extent, but one cannot generalize. I don't think it should be removed. Putting it in More is too far away.

Imagine a user that wants to replace the form (he notices the page has the wrong form when editing it). Now, can it be changed at all? There is no indication anymore. Maybe he remembers, maybe he has read the documentation (probably not). But suppose a collegue shows him he has to go to More. First save the topic, then go to More, press button to change the form. Back to More. Now to topic view, click edit, now he can enter form data. Complicated.

Of course some steps can be squashed together, but somehow this does not feel right. To solve the problem of the button location, a new problem is created.

Put the form button next to the "Preview Changes" button -- I really want to have only one (submit) button there. I am attacking the Attach page too. One button makes visual scanning immediate, two buttons and one has to select and click the right one.

I think there are two reasonable solutions

I can think of a few alternatives:

  1. As suggested above, make the button a small link and put it at the right. Rephrase it to "Choose different form".
  2. Create a row below the web form and add a link (no button) there.
  3. Create a small button at the bottom of the form like the EditTablePlugin, visually distinct from other buttons on the page.

  • The form change page can be more informative to point users to correct usage and show what to expect, to reduce uninformed changing of a form.

For myself I prefer solution 1.

Better illustrate this:



WebFormChoose different form
TopicClassification
TopicSummary
InterestedParties
ScheduledFor
ImplementationDate
RelatedTopics
SpecProgress
ImplProgress
DocProgress


Cancel

-- ArthurClemens - 07 May 2004

Apart from the lack of DirectSave, I like this.

-- MartinCleaver - 08 May 2004

I think that there are some practical problems with this suggestion. The change form button needs to be a button if we maintain the current programming logic as it actually submits the form. You cannot do that with a link, I think? In other words, the solution depicted with the small link at the right involves makeing larger changes than just fiddling with the button.

-- ThomasWeigert - 08 May 2004

for work i just did the following - it gives a grey text to the right of the template name similar to what Arthur did - but there is no UI hint that it is clickable. most of my users will never want to click on this, and i actually would prefer to move it away to the Advanced page.

[Form.pm]
sub chooseFormButton
{
    my( $text ) = @_;
    
    return "<input type=\"submit\" name=\"submitChangeForm\" value=\" &nbsp; $text &nbsp; \" class=\"TWikiSubmitChangeFormButton\" />";
}
[CSS file]
input.TWikiSubmitChangeFormButton
{
   padding: 0;
   color: lightslategray;
   font-size: 75%;
   text-decoration: none;
   background-color: #99CCCC;
   border:0px;
   float: right;
}

i'm liking css smile

  • Sven's slightly more hidden Change Form button:
    Sven's slightly more hidden Change Form button

-- ArthurClemens - 19 Jul 2004

Hmm, hiding the button via css is just a quick workaround for this issue. Here at TWiki.org I fix topics in the Main web and Sandbox web with incorrectly added/changed forms several times a week. People are just confused with this "Add form" or "Change form" option. The only person who needs that is the administrator or poweruser. So the More screen seems to be a better place. This also reduces the perception of feature kreeping in TWiki.

-- PeterThoeny - 20 Jul 2004

I am still not convinced about putting the button/link on the More screen. Until I hear counter-arguments I stick by my opinion I wrote on 7 May.

The button is an advanced feature, for power users, but this button should not be placed 2 screens away. Especially not when you have to remember (no visual clue) how to change the form.

On 7 May I offered a few alternatives. The status so far:

  1. Make the button a link
    • With CSS, like Sven's solution. I don't find this a quick workaround, but opinions may differ.
    • With HTML. This is a practical problem because the button submits a form and this is not possible with a link.
  2. Make the button visually distinct from other buttons.

So far option 2 can still be investigated.

-- ArthurClemens - 20 Jul 2004

For whatever it is worth, the change form button serves double duty in my work flow addon to create a work flow (by attaching a work flow form), and once a work flow is entered, to change state.

Making this a link would break my applications.

I suggest that we make it a button and move it next to the preview button, as described above, and as also coded in the referenced patch. This patch has been in use in our organization for several years now.

-- ThomasWeigert - 20 Jul 2004

I think we all agree that the existing functionality should not be broken. So if we make the button a link, it should only look like a link while it is still a button.

Looking again at the screenshots at the top, from 2002, I had to think of something I made for a skin at my day job. This is the screenshot of the topic action part (preview screen):

Example of the separation of topic action buttons in 2 rows

The area where the red arrow points to could be used for the "Add form" and "Change form" button. I would still prefer to make the button visually a link, like in Sven's example, so it is visually downplayed. But without CSS this could also work: the bottom row is used for the main action buttons, the upper row for "helper" actions. The color variation helps to identify an order of importance.

-- ArthurClemens - 20 Jul 2004

I have some form-based tracking systems where people change a formfield (e.g. set state of a project from "ongoing" to "done") in order to set state. Having a button labeled "Change" confuses many of these people, since the natural assumption is that this state-setting task involves "Changing" the form. Just moving/shading the button will not fix that UI problem (my quick and dirty "solution" was to rename the button to "Replace entire form", which is less confusing). Also, having Edit.pm spew out a table for the form button is unfortunate if you are using a custom skin, though perhaps that is already "fixed" by the addition of CSS classes to that element.

-- ClaussStrauch - 22 Jul 2004

Clauss, same case at my workplace. We have several workflow applications and tracking applications. They all have topics with application specific TWiki forms, those topics are based on template topic with cutomized TWiki forms. Users are never supposed to change the form, but they need to change the state of a ticket or route a ticket by using a pick list or radio buttons in the form. They get confused with the "Change form" option because it suggests that you can change the state of a ticket. So this option is just confusing for our several hundred active TWiki users. They are not interested that a topic is composed of topic text and a form, and that you can add/change/remove a form, they simply want to use the TWiki application to get some tasks accomplished. Although I can't assert with over 40K topics, but I am not aware of any case where an end user needs to change a form.

Making the "change form" less visible by using a link instead of a button possibly helps to reduce the confusion of our users, but it does not avoid it.

Thomas, in your case, could the application be changed so that the "change form" functionality is application driven instead of user driven? The application could present a list of appropriate forms; the user selects one; the application goes into edit mode and changes the form.

Arthur, you are concerned that the user will not remember where to go to change a form in case it is moved to More. This could be addressed by adding some help text in the edit screen (could be made less intrusive with a tooltip message on the Form name link (or on a small help icon))

-- PeterThoeny - 23 Jul 2004

Peter, I think we both are saying the same thing (if I understand you right). For an example of how we use the "change form", please look at WorkFlowAddOn. Basically, a work flow is attached to a topic by changing/adding the form to be a special form representing a work flow. That action removes the change form button and replaces it with controls that allow executing the work flow. It should not be allowed for the user to change a form once the work flow has been initiated, as this would destroy the work flow.

Maybe it was a mistake implementing the work flow management by overloading the "change form" button. I was led to that by (i) that work flows typically involve forms to represent the state of the flow and (ii) that once you associate the work flow you do not want to have the change form button available.

So in summary, I don't believe that users ever need to change the form manually. They do need to be able to associate a form with a topic, and maybe they would like to delete a form?

-- ThomasWeigert - 23 Jul 2004

One thing that troubles me in the discussion is the (to me) new notion of "users", where these are depicted as people that "are not allowed" or "are not supposed" to change the form on the page. This appears very much like a (conventional) web application where end users cannot change and edit but can fill in forms. The page logic is designed by a information architect, interaction desiger, application builder, whatever, and changes will be implemented by one or a few persons. These builders know the ins and outs of TWiki. End users are ignorant or don't care about the underlying design. To prevent messing up, the pages must be designed fool proof.

On the other hand (other installations) you have users that can actively edit and change and set up pages, including forms. This is more the Wiki way. The pages don't have to be designed fool proof, pages are flexible and errors can be reverted easily. Users don't know everything about TWiki, are perhaps beginning TWiki users or admins. My suggestions above have been targeted towards this group and this kind of design.

Because of TWiki's nature - not purely a Wiki but also a web application environment - we will need to foster both kinds of users.

  1. Fool proof design: Change button and "WebForm" link are redundant and possibly dangerous to use. Should be ommited from the form or page. "Master" options can go to a "hidden" place like the More template.
  2. Flexible design: the form button and link should be placed where they are needed: nearby the form.

My ideas about the placement/visibility of the Change button still stands. The button label "Replace form" is a good improvement.

Now I have these suggestions:

  1. Create an option to hide form controls. This option should be on the web form page. When checked, the button Change and the link WebForm will not be shown.
  2. By default, the button and link are shown
  3. Change the appearance of the Change button:
    1. Make the Change button look like a link with CSS (see above)
    2. Either:
      • position it to the right
      • put it just above the topic action buttons at the bottom of the page
  4. Change the button label to "Replace form"
  5. Create an option on the More page to replace the web form.

-- ArthurClemens - 23 Jul 2004

I'd like to throw my support behind Arthur here. While I have some users of the "should never be allowed near the change form option," I have many others that should be encouraged to know and use this option. I'd rather see it become more useable, and less confusing rather than restrict its existance from the logical spot.

-- SvenDowideit - 24 Jul 2004

Arthur, I think you are confusing TWiki with a wiki. TWiki includes a wiki application, namely the text area that one edits. However, TWiki is a much broader web-application development platform: A TWiki installation may include many other applications, such as the work flow applications we discussed earlier. Each application has its own rules of what users can do. For example, in a wiki, users should not be restricted from editing anything. However, in a work flow application there are certain rules that need to be followed, as this is the whole point of a work flow. The various TWiki applications must and can coexist. However, care has to be taken that constraints or freedoms from one application do not automatically get transferred to other applications. You can read more on the distinction between TWiki (the web application development framework) and a wiki (a web-based white board application) on TWikiWhatWillYouBeWhenYouGrowUp.

  • No, I am talking about 2 uses: Because of TWiki's nature - not purely a Wiki but also a web application environment - we will need to foster both kinds of users. Both kinds of installations exist. And they are not only workflow applications. -- ArthurClemens - 25 Jul 2004

-- ThomasWeigert - 25 Jul 2004

however, the TWikiApplicationServer should not come at the price that you remove the differentionating factor that TWiki has, and that is that is can be used as a fully fledged (and uncrippled) wiki. So at worst it should be configurable, at best i still think it should act and feel like a wiki, with the ability to add applications (rather than the other way round)

-- SvenDowideit - 25 Jul 2004

Agreed. Note that both Peter and I are merely saying that when you have invoked an application that assumes you do not monkey with the form, that you can impose that in your application.

When modifying the twiki controls, one needs to be cogniscient which application the controls belong to. For example, the "add form" or "change form" buttons belongs to the form application, the "attach" link belongs to the attachment application, etc. One needs to consider the impact on these applications when suggesting changes. For example, when you move the "change form" button to the more screen, you require the form application to modify/control the more screen also. That seems inappropriate.

It is clear that the position of the current "change form" button is wrong as it is unduely prominent. However, fixing this should not break the form application or derivative applications.

-- ThomasWeigert - 25 Jul 2004

What's your opinion of optionally hiding the form controls as I suggested?

-- ArthurClemens - 25 Jul 2004

Thomas: In regards to "when you move the change form button to the more screen, you require the form application to modify/control the more screen also". This is not necessary the case since you can control the form add/change/removal with parameters passed to the edit script. That is, your application can present a form that lists possible forms to choose from, and the edit script will take care of the rest.

It looks like we agree that TWikiApplications should be secured from users accidentially changing the form.

I do not see frequent need to change forms when collaborating the WikiWay. Arthur, can you elaborate?

  • Users can add topics freely and create web forms by themselves. They can decide at topic creation (not the automatic version) what form the topic needs. So although the forms will not change frequently, they are added when the topic is created. It should also be easy to remove the form. -- ArthurClemens - 25 Jul 2004

Arthur, although it is not KISS, your suggestions from 23 Jul addresses most needs at the cost of more work to be done.

-- PeterThoeny - 25 Jul 2004

Yes, Peter, we agree. Two minor comments:

  • What I meant to say is that if the application needs to remove the "change form" functionality, it would have to modify the more screen, if the "change form" button were to be put there.
  • If there is no "change form" button on the edit screen, the application implementing the work flow via forms needs to also either change the edit screen or provide a skin. Given that skins are not additive, this would be quite onerous.

-- ThomasWeigert - 26 Jul 2004

I am trying to get the "change form" button in the fieldset, like this:

Change form button (link style) in fieldset

But how do I set a variable value for the label? Something like:

&lt;input value=%CHANGEFORMLABEL%&gt;

Form.pm should define the CHANGEFORMLABEL variable dependent on the state (no form, or change form), where the label values are "Add form" and "Replace form".

-- ArthurClemens - 28 Jul 2004

While there is no variable defined, the rendering of the form button is done with the label being passed as a parameter, see Form::chooseFormButton. Its sole argument is the text that will be shown as the label on the change form button.

-- ThomasWeigert - 29 Jul 2004

Hmm, how do I pass this from the template to Form.pm? Because the location of the Change button is now moved out of the form table.

-- ArthurClemens - 29 Jul 2004

Same way as before. You use a parameter substitution at the template level, or you expand a variable in the code that renders the page on which you show these buttons (should now be in lib/TWiki/UI/Edit.pm.

-- ThomasWeigert - 30 Jul 2004

How does the implementation in PatternSkin work in practice? Is it an improvement?

BTW I found a link how to make a text link a submit button: http://javascript.about.com/library/weekly/aa082701a.htm

Sometimes a big, ugly, browser submit button doesn't quite go well with the rest of the page design. Fortunately, it's easy to submit a form using JavaScript, allowing you to create your own submit buttons using text or images. Forms have a submit method that you can call that works just like the standard submit button. By placing a link around text or image, you can call the submit method when the user clicks on the link.

<a href="javascript:void(document.myform.submit())">Submit Me</a>

Note: void tells the browser to ignore the return value from the function being called. Otherwise, if the function returns a value to the href, the browser may attempt to change pages and navigate to the returned value.

-- ArthurClemens - 19 Sep 2004

I like it, Arthur.

Share your opinion of this idea by selecting one of the radio buttons below and clicking the button.
It would be nice ... 1 2 3 4 5 6 7 8 9 ... I want this so much it hurts

Average desireability: 7.66666666666667

-- MartinCleaver - 20 Sep 2004

Ehm, what are we selecting now? Desire for a link as submit button?

-- ArthurClemens - 20 Sep 2004

Note that JavaScript without fallback is not in line with the TWikiSystemRequirements

-- PeterThoeny - 23 Sep 2004

True. It also doesn't fit in Accessibility guidelines.

-- ArthurClemens - 24 Nov 2004

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng CssChangeForm.png r1 manage 4.7 K 2004-07-20 - 08:48 SvenDowideit Sven's slightly more hidden Change Form button
PNGpng fieldset.png r1 manage 10.0 K 2004-07-28 - 13:13 ArthurClemens Change form button (link style) in fieldset
Unknown file formatdiff moveformbutton.diff r1 manage 5.7 K 2002-11-09 - 05:06 ThomasWeigert Diff to Beijing beta of 09 Nov 2002
Unknown file formatgz moveformbutton.tar.gz r2 r1 manage 8.6 K 2002-11-08 - 19:48 ThomasWeigert Modified files from Athens release
GIFgif topicaction.gif r1 manage 4.8 K 2004-07-20 - 22:45 ArthurClemens Example of the separation of topic action buttons in 2 rows
Edit | Attach | Watch | Print version | History: r61 < r60 < r59 < r58 < r57 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r61 - 2006-01-03 - 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.