I've been ignoring them in the first redesign excercise but now it's time to give them the attention they deserve: FORMS

The current form (we are talking about the view you get when you edit a record) is far from ideal. The main points I'd like to address are:

• Awkward field length variations
• Color coding only for mandatory fields: this is not accessible
• Label wrapping for long labels
• Grouping / clustering possibilities only limited
• No hide/show possibilties on user level (directly via the GUI)

A lot of research has been done already on form design, although most of it focuses on web form design, e.g. for a registration form but most of the heuristics are applicable for application forms as well.

Two column design: Although in most cases not recommended, I think we should keep this layout, as OB ERP has a lot of fields and a lot of horizontal space. Using a one column layout would be a waste of real estate. 

Jakob Nielsen did a bit of research on forms versus apps and although outdated, it still offers some great takeaways: 

• In-context help: Having this information on the main screen is preferable because users dislike going off to separate help screens
• Eliminating irrelevant steps: Users never need to see questions and options that don't apply to them.
• Customizability: (this example is really spot-on!) For example, an expense reporting application might require users to enter driving distances to get reimbursement for personal automobile use. If an employee often travels the same routes (say, to the airport or an important customer site), the application could provide one-click access to frequently used distances and list them by name (say, "office to JFK").

Luke Wroblewski wrote a great article on form layout. The most important conclusions here are:

• Vertical alignment of labels is best when the time to complete a form needs to be minimized and the data being collected is mostly familiar to users. 
• Bold labels are preferred to give them visual weight and not have them compete with field values over the user's attention.

Enough for the first stab. I've modeled the first concept which can be found on the UX Lab Web Album (the last 7 images). It is quite unusual for application forms as it takes up a bit more vertical space due to the top labels. However, the two-column layout and collapsible sections offset that. Gray labels in collapsed sections are clickable: this opens the section and moves focus straight into the field. The first section contains help/guidance. I'd say that the user can choose to save the view and reuse the settings for all other forms of the same kind. This way you can hide sections that you don't use all the time and reach a super fast data entry, also using the keyboard. Next to the section label, we could place a "check" or "x" sign, indicating whether all mandatory fields in the sections are satisfied or not.

Special attention to:

How to emphasize mandatory fields: using *, using icons, using field coloring. In that same set you can also find a concept with and without seperating horizontal lines.

Process guidance using in-form bubbles that are triggered on completion of certain fields. The same thing but now using the top status bar. I really like the last idea, imagine how easy this can be for novice users! Of course you should be able to switch it off. Same hint could also be placed on the form itself, using the "introduction" section.

This should keep you busy for a while :-). Let me know the first reactions, so we can take it to the next level. Examples of Great Form Design out there will also be highly appreciated.

Form edit on smart phones...how crazy would that be...? Some phones already come with a 800x480 resolution. The form design shown before uses 880 px. Scraping 80 pixels of the width would actually make it possible to display the form on a smart phone without horizontal scrolling!

If you were to move the colapsable section headers (with the twisties) to the top then the forms would render on 640 px width even.

Here is a form layout concept using two columns and right aligned labeling. Very similar to the current OB forms.

I have put them alongside the concept with the top aligned labels here to be able to compare.

It is clear that the right aligned labeling is much more information dense & thus space efficient. Note that the font used in the left concept is Arial regular 11pts whereas the right concept used Verdana Bold 11pts which is approx. 25% narrower. Also note that the first label in the right column needs wrapping in order to fit.

The same concept now using collapsable sections.

What's your preference?

--- comment from Josep Mitja via web album comments ---

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Rob,
This is my preferred layout. It is more dense, and actually I think readability is better than top aligned labels (but then you are the usability expert).
You should also try to mock-up the section separators.

Finally, I have to say that I prefer the current schema of single column, half column and double column fields. for example the "Description" field above is perfect for double column. Also, IMO, fields such as Order Date look awkward in single column fields (there is too much empty space).

Josep

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

>>Here's the right aligned version with section headers: http://picasaweb.google.com/lh/photo/85HBhG7gdQCwhQ4YVBdBSQ?feat=directlink (Rob)

Rob,

I like very much your latest proposal for header labels [1]

What is your opinion on the half-column and double colum-width option for certain fields?

Finally, one of the things I would also like to see in the new interface is the ability to include explanatory texts next to any field. This is a feature request I logged in the past [2] , and should not be confused with "help on hover" functionality.

Cheers,

Josep

----------------

[1] See http://picasaweb.google.com/obuxlab/OpenbravoConcepts?feat=directlink#5324939605533408018

[2] https://issues.openbravo.com/view.php?id=4583

Rob,

It feels like an enternity since I have posted.  It is good that we are looking at form redesign.  I like the articles by the way.

I agree with Josep and like the right aligned labels best along with the compressed fields when looking at the verticleness.  However, I think that the group-boxes are a nessecity though they take away the compactness of the form and, in my opinion, make it harder to read.  One solution that I think that would be a combination of form compactness but still allowing expandable group-boxes would be to group fields in a 1px group box with a expander/compressor icon.  When the group is compressed the group-box label/name would show, but when expanded  you would just see the 1px group box surrounding the fields, and keep the compactness.  I hope that makes since.

Still working with ZK....... I'm having difficulty with tomcat right now. I really have fudged  some stuff on my 'puter. woohoo!  But still I'm loving all the features of ZK.

I hope to be back and contributing more in the future.

Michael

ps  Rob if you are using a series of images to develop your mock-ups it might be useful to post them somewhere so that someone could use them to make their own.  So if you are layering images in PhotoShop it would be handy to have the layer compnents to make it easier for people to do their mock ups

@Josep: Half-column and double colum-width do not look good to me but then I mean: just cosmetically. Check the mockup and compare it with the next slide in the album. I also have some more concrete con-arguments why I think it's bad. Saving space is only partially true: no vertical space is saved and horizontal space does not really matter as we can't have two fields side by side in a 1 column width anyway. The good thing about double column width is that it allows for more space for e.g. textual input. The description field would benefit, certainly. Bút...for large amounts of text, such as metadata, descriptions, I had proposed to use the Yellow Tab (our virtual child) in earlier proposals. Check a Feb mock to see what I'm getting at. Imagine in the bottom pane you´d have a Notes or Description subtab...

@Josep: Explanatory fields for fields: this would be great. Space could be a problem and permanent presence could be obnoxious. We had a great discussion on this earlier. That´s why I liked the popup/layer field help so much, because it is on demand. Your sketch would obscure other fields. But I think it is worth exploring a permanent field help area. SquareSpace uses neat field guidance just below the field, in a smaller font. This is doable in our form, as long as you can switch it on and off. Form would probably double in verticl size, but then: who cares? Good feature for novice users, comparable to learning to ride a bicycle with trainer sidewheels. When you master the skill, you can switch/take them off.

@Michael: About the grouping: I am trying to visualize what you describe here (I´m looking forward to the day that we use crayons in this forum :-)) but...do you mean you would just show a box, without the header label? I think the header label is essential, to get an idea of the form's flow and sequence of steps, especially for the more complex forms. To reassure you: I do not think vertical space is going to be sacrificed to badly when using straightforward section headers...what about this mock?

@Michael again: We are very excited about your experiment for a proto with ZK for our GUI. Please let us know if you need help. Ah yes and I agree with the sharing source files for design work...I had not thought of that...collaborative design in Open Source just did not happen yet ;-) Let me think of a place to store them + how to go about it. Greenfielding here!

Also check the Toolbar studies (flick through the subsequent images to get the overview). I wasn't really happy with the buttons and toolbar semantic clustering and the proposed concept introduces some "Ordnung" here.

Thanks guys / R.

Josep, I gave it a good night sleep and came up with this mockup for explanatory field texts. The idea is that you toggle the explanatory text boxes on and off. In terms of "verbosity", we can link out to wiki help (that could be placed in the Yellow Tab) or just cap the amount of characters. Obviously the form will expand vertically when the field text boxes appear.

Note the message in the status bar area: "Field help texts are now switched on. Click toggle button to hide them."

In all our forms we show the Client and Organization fields as the first two fields on our forms. I learned that the Client field is useless and serves as a "filler" next to the Organization field, that is needed in some cases. How often "some" is, I d like to figure out.

I can imagine that you would perform actions for the organization you belong to. So if you are a user working for organization X, then you would create sales orders, pay settlements, and whatever you do, for that organization X. If you want to do the same for another organization Y, you could just change organization via the user log-on page and start doing the same for the organization Y.

This way we could save one full row in the form by removing both client and organization fields. You would always see in what organization you are logged into, in the top toolbar (see mockup here, look at the "ColumbOrg" next to the red log-out cross icon)

I want to make sure nobody gets hurt so I am asking: Is the above scenario reasonable? Or would you want to do stuff for organization X while being logged on to organization Y?

If you really want to do one thing for organization X and then the same thing for Y, perhaps we could add an action "move this sales order to another organization" in the Action dropdown button (yellow button in this image)

Check out this badboy: 3 columns over a width of 900 pixels. It's a great space saver. Fields are still 270 px.Notice that it combines the section headers of the classic right aligned concept with top aligned field labels. When used wisely, this could be a winner. Also because you don't have to use 3 columns. Use 2 when vertical space allows.