Using fieldgroups to create Multi-page forms

This could be nice and it's not that difficult to implement.
Are you up for a patch?

I thought about this request some more. I can image in very very large forms it makes sense to try to lower the load on the pages. However, in most cases and even in large forms, I don't know if the performance gain would be big.

Why do you want to feature exactly? I don't really see much benefit for this, especially as you described it would not be a real other page. Isn't that precisely how field_group>horizontal tabs currently work?

This is some nice explanation, screenshots. You certainly convinced me.
I keep my response at heart of not having to do it in a multipage (refresh / ajax) way, but would prefer to do this technique in one page but with a new field_group format type.
I am thinking of a good name but I think the best would be to have a "multipage" and a "multipage page" if you know what I mean.
This would be a new library of basic javascript and css, just like I did for horizontal tabs. The server side will only prepare some visibility controls, so the step 1 is active (to get focus by css/js).

In a later phase we could consider to have "multipage" have an option "load in separate pages" which would mean there is a technique to only show part of the form (per bootstrap). This would also be hard on the submission, meaning we need to know when to save. Only at the end as entended? step by step as It makes more sense in some cases ...

So I will create such a thing with your screenshots (2 and 3) with the next and previous to have a nice way of tackling use cases as you are experiencing.

I really appreciate your feedback. Thx

Added to git and ready for testing.
Note the option on the multipage group to indicate whether buttons need to move to the last pane or stay ungrouped.

Ok thanx.
I'll now the request will come for a link to open a modal to for instance register or fill in some other multi-pageable form.
However I think that can be created in various ways depending on the modal framework the site uses to begin with.
Looking forward for the feedback.

Hi -

I'm the author of the http://drupal.org/project/formflow module & part of it does exactly the same as you're building now (thanks to @animelion for pointing it out). Please help yourself to the code if you think it'd be useful & let me know if you'd like me to lend a hand. When this functionality is in the field group module I'll remove it from formflow.

btw there are a couple of usability issues I ran into when building mine:

1. Relating to comment #9, screenshot 1. I added everything not included in a group to the last page - so all the node settings stuff (menu etc.,) won't clutter up every step in the form. It'd probably be better if you could select where in the form these should be output, but this seemed the easiest way to fix the problem.

2. Users should be allowed to submit the form when there are no more required fields in subsequent steps.

Cheers,

Ben

I will clean up the issue queue of field_group and then move over to this issue.
The propositions are great and take over this functionality from formflow sounds good to me.

So if somebody is up for it, please go ahead.
Please DO update this issue accordingly so everyone sees where we're at. Submit the work in a patch so somebody else can easily take over.
Thx people.

- EDIT - I also like all suggested functionality in #9. And I also think we could learn (or use) from that jquery plugin project.

Nobody started this yet? I would like to pick in somewhere :)

I will look at the jquery plugin and the generic formflow module. I can already say that the approach is too generic to be just pulled out of formflow. That module does a lot of extra things like render, validate, submit handlers ... that we don't need.

Description of all features

Title of each step should have extra css class to indicate it's the active one (default)

We need to consider here that the label of a group can be "Step 2 of 4: Your address". We still need to have a counter system so fieldgroup multipage form element takes care of that. I think some configuration ca ben added to the multipage-group.

Subsequent pages/fieldgroups should be listed as well

These will have a class that indicates they are not active. Also note that this should be a configuration. I don't know if all cases will cover this. Sometimes you just want a simple form with not much text.

Change "Next" to "Next page"

We'll do that . This also include the previous link. Should we use all buttons or the previous as a link.?

Add page count

Add a page counter with a configuration to not display it or giving the format (like 1 / 3)

Move addtional settings from core to the last page

TBD

In this latest commit, I did some refactoring so that pre_render function is delegated to the field_group_pre_render_[format_type] function if available. Clear the cache to activate new multipage_pane theming function.

bugfixes:
- The search button was moved by incorrect javascript. This is fixed.
- Next = Next page

features included:
- Option to move additional settings to the latest pane if available.
- Format configuration for the step header.
- Configuration with choice of format for a footer page counter.

Yet TODO:
- steps header. Create a system (preferably in javascript only) that will list all titles of the multipage panes and gather them as header.
- Theming for the buttons that moved to the latest pane.
- Decision to make on the previous link. Should this be a button as well or leave it as a link, like most systems.

Subscribing

Fixed a bug in multipage count number. The registration form had too much of groups in the count. This should be the same as on normal user edit page.

The start / no-start is to indicate which multipage pane is the active one. I could imagine in some cases you would want the people to end up in the second step as the first one is configured with most basic information that is never changed. Or something in that direction.
I don't know if this is worth what it is, but apparently when I wrote it, I thought it did. That's the problem of developers :p they do what they want

The CSS fixed are pushed to git, except for http://pastebin.com/tUQkcCup due to overload on pastebin. So I'll wait for that.

The CSS looks nice.
Although I like it very much, I am not sure if we can just add the colors and buttons as proposed.
I pushed the code to git, but I definitely would like some feedback on the styling.

Shoot people!

There is still a problem with the css of the previous button. It aligns top and should be middle.
I would also prefer the color only white and not that fancy :) I think that's something for the custom themes, no?

You can even add something like a setting on how it's displayed and depend you css or even css file that gets included on it ;)
Go nuts

Not so sure about including such comprehensive Google style css. It looks nice, but how many sites want their submit buttons to look like Google's I think ythat css included in modules should only be very basic - that that is needed in order for the module to function well.

Also, I don't think every line of this css should include the !important keyword. !important should rarely ever be used, as it totally screws up the natural hierarchy of css overrides. This only serves to make it even more difficult for themes to override these Google styles.

Clicking the Next or Previous buttons should probably scroll the page up to the top. At the moment, if you have one page of the multipage form thats quite long, and the next page is very short, when you click the next button to go from the long page to the short page, you then have to scroll up to be able to see any of the form elements on the short page, as they are all right at the top.

I have the same question about the scroll issue in the comment above - is there a javascript fix we can use for this?

In IE7, this throws up

Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
Timestamp: Tue, 8 Nov 2011 13:59:18 UTC


Message: Unexpected call to method or property access.
Line: 16
Char: 56222
Code: 0
URI: http://test.local/sites/all/modules/contrib/jquery_update/replace/jquery/jquery.min.js?v=1.5.2

Problem seems to be in line 135 of multipage.js:

this.nextLink.append('<span id="active-multipage-control" class="element-invisible">' + Drupal.t('(active page)') + '</span>');

This is not a fix, but a workaround as I need it working right now. Commenting out the line seems to have no adverse affect. The line is somefor screen readers, which I'm not bothered about right now. Patch attached so I can include in drush make.

I created a separate issue for the scroll problem so that it doesn't get lost in this long and varied thread. #1341996: Next and previous buttons should scroll to top on multipage forms

Is it still useful to keep this thread open, since everything in here has already been committed?

New issue also created for the IE error I mentioned in #38 and #39. #1342006: JS error in multipage forms in IE. I don't see any point in hiding it away in here.

Is there any word on the page listing functionality?

So you can easily jump to different parts/pages of the form?

Agree with #43 — I'd love to see the page listing functionality. My use case is a lengthy application that people may want to take their time filling out, so it would be nice for them to be able to get a sense of what information is coming up and to be able to jump around without having to go through each page of the form in order.

What are the remaining tasks for this one? I would prefer to close this one as it is a bit messy and unmaintainable. I suppose other issue with specific problems already have come around and there might be more requests included here somewhere, not sure anymore.

Before I close this, can anyone say what is remaining, and please open a separate issue for that?