I have very big form, it could have maximum ~1000 elements. It has many embedded forms which has another embedded forms, obviously they are collapsed by default.
My form has some entry points from which user can start, most of controls are not required, form is splitted into parts. Each subform can be folded to summary box.
I think that workflow with that type of form is ok. User can open it and in one page he can make many types of changes in data and in most cases those actions aren't connected each other.
Are there any design references, researches about such big one page forms design? Maybe some standards about designing UI with input controls pattern?
You need to provide a workflow. A form that big on a single page will confuse people and lead to people not even bothering to fill it in.
Break it into smaller forms, and provide a wizard-style navigation process to move from one page to the next as the user fills in parts of the form.
Even then, 1000 data points is a lot for a single form, and a lot to ask people to fill in during a single session. So you would be well advised to allow people to leave the form partially filled in, and return to complete it later, without having to re-do what they've already entered. Some sort of session save facility is required.
Related
I'm having a very difficult problem atm, one that I can not explain... at all. I really hope someone here may be able to shed some light on this predicament.
On my website I have a self-developed module that displays some kind of registration form. The registration form consists of different parts:
Personal information
Educational Information
Linguistic Skills
Local/Exchange Specific information
Some optional additional remarks.
Using AHAH and the AHAH Helper module I have created (read: programmed) this form to be 'multipage'. It has the header on top describing what part of the total registration you are currently in, and which parts you have yet to complete. You have a previous/next button to navigate between the different pages of the form.
This is all controlled by AHAH, and I keep track of the pages using a hidden form element with a default value 'current_page'. Anyway that is kind of besides the point.
The important part of the above explanation is that the data of all the different parts persists through the different pages by using the form_state variable. AHAH Helper keeps the previous values entered in the form saved in the 'storage' of the form_state.
Now some of the users seem to be experiencing the following problem upon registering:
While they are filling in their information, and some AHAH call is triggered in the form (e.g.: Pressing the next button, Checking the email address for validity, checking birthdate for >= 17) after the AHAH call is finished, the values within the form elements, that had already been filled in, have been replaced by completely different values.
A name of a different person, his age, his email address etc. Even though this person, I assume that this is what is happening, is filling out the form on a different, private computer, in obviously a different session.
My users do not have to login on the website in order to register using this page, I'm not sure if that is causing an issue?
Anyway, as far as I can tell, I can only recreate the problem when I try filling out the form with different data from different browsers on my computer, concurrently. In that case I can manage to corrupt the form_state data. But as the users are on different, private computers, which presumable use different sessions/cookies/what-not, how is it ever possible for form_state data to be changed to form_state data of another computer who is also filling out the form??
I don't get this? Is there some kind of inherent flaw in using AHAH (& AHAH Helper) for keeping the form_state? If there is, is there some kind of work around? Am I just making a huge newby mistake somewhere in my module code that prevents the form from working correctly?
Is there please, anybody, that can shed even a little bit of light at all on this problem? I am absolutely, and completely clue-less and I can not begin to imagine what is going wrong and how and even IF I can fix it at all.
Please help me! :S
Thanks in advance!
Best Regards,
Tom
Edit:
This problem describes a problem in drupal 6.x
I'm answering my own question after having found the solution (quite a while back, but I forgot about this question).
The problem is that the form_state for the different computers is kept apart using session information from drupal.
However, this did not seem to work correctly with the AHAH forms for users that were not registered.
Having users register before being able to fill in these forms solved all the concurrency issues.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I've been searching a long time for some guidance or examples of web form design of large forms (dozens of fields - maybe 50+) for a user base that will be trained on the application.
99.9% of the guidance seems to be geared toward "accessibility" or "intuitiveness" which are, by all means, valid goals. The issue is that a form that will be used on a one-off or infrequent basis by users who will likely be encountering it for the first (or only) time has much different considerations required compared with a form for data entry to a business application that will be used repeatedly all day long by users who are trained on the app.
If I'm designing for a one-off (say a sign-up form) then I want to focus on designing the form so that the user can't help but flow naturally through the steps and end up completing their goal and feeling all warm and fuzzy.
If I'm designing for an experienced user that will use the form 20x a day, they are going to want it designed to minimize the clicks and navigations, etc. They don't care [as much] about looks or flair and subtle cues to help them work through the form. They know the form like the back of their hand and just want to be able to enter data as quickly as possible and see as much as possible in one view.
The requirements that I'm getting from the users is that they want to see "everything" on one screen. They don't want to have to scroll. They want to minimize clicking to other pages to continue working.
Does anyone have any suggestions/links/dire-warnings??
Thanks,
Dave
My instinct is to tell you to break it up into sections the user can navigate between, to minimize the amount of continous data entry they have to do, as well as keeping the sections you have to validate to a minium. Get all the way to the bottom only to have to scroll back up to the top... annoying!
Since you want a large form, however, my suggestions are:
Validate as you go. As soon as a user leaves an input or section let them know everything is okay. Don't glue them to a control though, use visual feedback (like backgrounds going red or similar).
Don't lose that page! Use whatever technique you can (including background submits) to store the user's states. Funnily enough, a certain user driven programmers community website does that...
Tab navigation! Set the tab order! Your keyboard wizards will love you
Although you might want to jam as much as possible onto one line, don't. Keep good spacing and vertical navigation - people are used to scrolling vertically, and good spacing makes things readable.
There's lots more, but, as you might expect, there's an even better answer, here
We touch on the key drivers for designing forms for high-usage, trained users in our book "Forms that work".
The key points are:
Try to cram everything onto one page, as described. Having to click from screen to screen becomes very tiring very quickly when you're using the same form all day every day.
If you must separate off some items, do extremely careful observational analysis to discover which items are genuinely used rarely. Put those ones on the 'extra click' screen.
Abbreviate the labels ruthlessly, taking advice from the users on what abbreviations are required. They'll rapidly stop reading the labels anyway, working mostly from the absolute position of fields relative to each other...
... which means: don't ever allow fields to move about. Make sure they retain their absolute position; this is essential for speed of completion
Make sure that the form is entirely navigable using keystrokes alone. This is essential for speedy completion by experienced users
Find out where the answers come from to go into the fields. If they are typing in stuff from another document (it does still happen, believe me) make sure that the field are arranged in the same absolute positions to each other as is shown on the layout of the document they are typing in from.
Don't worry too much 'intuitiveness'; these people are going to be trained.
Bounce rate is completely irrelevant, so you can skip any advice you see about 'conversion' or 'bounce rate'. These users don't have the option to go elsewhere and do a different form.
Email me directly if you'd like to discuss this in more detail: Caroline Jarrett. More contact details on Forms that work - our book's web site
I've got two suggestions. Keyboard and consistency. The one thing you want want when using a form like that so often is the ability to do it with your eyes closed.
The focus should be at the first field, from there on it should take the exact sequence if keystrokes to fill and submit the form every time. Normally this means and type till all fields are filled after which you can press enter to submit.
And try to get audio feedback in there when something goes wrong, often people type blind and have their eyes on a piece of paper and not on the screen, a simple beep to tell them to look at the screen really helps.
hmmm,
I understand that the client wants it done on "one" page however if this will rarely be used like you say I would give it to them in bite sized pieces or your bounce rate will go through the roof.
here are some links using jquery to forms similiar to what I am refering to:
http://www.thecodemine.org/
http://cardonadesigns.com/wordpress/thoughts/ajaxish.php
http://jquery.bassistance.de/validate/demo/multipart/
to name a few.
Here are the two scenarios:
First one: You have a CMS you log into go to the page manager, select a template, then add a page into the system, edit the page, save it done.
Second one: You sign in, then go to the URL you want to exist but doesn't exist yet but still shows up as a template to enter in stuff. For example, "/articles/article" and since the URLs were mapped to be dynamic, the article template shows up and has the placeholders to edit right there. Different types of pages or templates would be mapped to different URL patterns such as "/product/[product-number]" etc etc.
Is there any security concerns for doing the latter since I like the second one better in terms of programming as there is no management of pages, just authentication then navigating to the desired page. The first one is more structured and is good listing them out or individiual permission settings.
Please advise.
Beyond the authentication considerations, I think both approaches are fine. I see them as ultimately accomplishing the same thing through different user experiences. To answer the question, I would paper prototype each, then pull users into a room and perform a quick / informal usability study, giving them tasks such as "create a page with ..." etc. Evaluate which model performed better. You really should answer this question by including the users that will use the system.
So I've been having a cordial debate with my coworkers (developers and designers) about the autofill tools for web forms. This is an important development question as it affects how forms might be built.
Q) What is the adoption of autofill tools, such as Google Toolbar or Chrome's built in feature?
Q) What are the most popular autofill tools?
Discussion appreciated. First answer with a reputable study gets the award.
Personally, I do not like auto-fill tools, and toolbars for that matter. Aside from the loss of screen real estate, there's too much bloat that comes with them. Also, with the way browsers versions are increasing, auto form fill applications are sometimes not supported in newer, more modern browsers.
I've worked in Government, Law enforcement, health care, and other public and private institutions and I have yet to see a good working form autofill tool, and if I did find a good one I can grantee that someone will be calling tech support because they submitted X amount of items with the exact same data.
HTML Forms can be built many ways, and forcing someone to build it a specific way is going to limit people, thus a form should be able to be built however someone wants, hopefully following W3C standards.
That being said, the most intuitive ones are those built into an application - where the developers/BA's create the auto-fill rules based on business cases and the correct algorithms, where users can define specific fields and parameters for data in those fields. Forcing an application to be built to match a 3rd party auto fill tool, which could change at any moment, or not be supported in the future, seems risky, I hear bells.
Update:
As far as revenue concerns, or a revenue stream for such a venture, you have to have an insight on the types of users that would use this software.
A form filler needs to be more than a generic: "This is a login page, let's put a username / password in". or a contact page "This is the previous data you used for a contact me page, fill it in".
A previous system I developed was an Action Item tracking system, with build in workflow / document management. Users asked for an auto fill for these items, which on the first request seemed utterly insane (demented is the word I wanted to say, but my manager helped me keep it bottled up). How would an auto-fill utility know exactly what to fill - but as I talked to the customer they expressed the following, which is valid for all autofill tools:
When I enter in a value say "Jane Smith" for "assign this task to", it would be nice if your system would automatically put "In Progress" for the item, as I always select "In Progress" as the status for this user.
As well, this worked for other users and fields as well. There was a specific flow on how this user entered data. "Jane Smith" items were always set to a specific department, status, and if the Item Type was say "correspondence" the Estimated Time was always 8 hours.
That type of auto-fill is what we custom made for them, and they payed well for it because it saved them a lot of time, mouse movements etc. AutoFill the way it is now is annoying at best for some people. But it's the pattern of the data that matters. It has to be intuitive and learn.
Once we developed this (it was easier because it was our application, we knew what was going on), about 90% of our customers jumped on board in the first week because of the time savings, sanity savings, and they didn't need to do ANYTHING to set it up - which was key.
I guess this is less a direct problem but more of an implementation question.
For drag and drop interfaces. How do people store the order of the elements that are being re-arranged. Since a user expects the order to be preserved when the user refreshes the page, how do you store that kinda information in a relational database or other persistent layer?
A number system seems extraneous requiring multiple updates anytime anybody arranged anything and I couldn't think of a nicer system for storing that information especially if the user doesn't have to click "Done" or any other button after re-ordering. (IE Facebook Photos)
Any help would be appreciated.
One approach would be a linked-list style: for each element, you store what is after it (or both before and after, for a doubly linked list). This way, when you move something, you only have to update the affected elements. Since you don't typically need to retrieve, say, the 2357th element (more typically you need to recreate the entire list) the performance impact should be fine.