We are designing a web app for tour operators and the initial data looks like the attachmentcurrent mock, any ideas to simplify. some of the fields will be calculated those will be removed, and some unneeded things can be hidden (eg, if return travel is not required then return travel details are not loaded).

Appreciate the time for looking thru.

We have made a few adjustments as per the comments received and it now look like revised version. But i feel that in this design my tab movement would not be nice. it would go down 2 tabs, then right. Any more tips. The advantage being all is seen in one shot.

  • 1
    Can't see the page in Picasa
    – JohnGB
    Oct 20, 2011 at 10:25
  • try imgur.com Oct 20, 2011 at 10:35
  • page not found. have some rep to post the image here.
    – colmcq
    Oct 20, 2011 at 10:36
  • possible duplicate of What makes a good form?
    – ChrisF
    Oct 20, 2011 at 12:32
  • 1
    asince they're automatically calculated there is no need for user input, yes; but I'm wondering if its worth having them in at all, even as read only? You're looking to reduce distractions and cognitive burden I say...
    – colmcq
    Oct 25, 2011 at 8:37

1 Answer 1


Well, I guess you're not going to post a picture. Who needs one anyway?

My recommendations pretty much summed up here:

What makes a good form?

A good place to start is Luke Wroblewski and his various writings on form design eg http://www.lukew.com/presos/preso.asp?22 But to add: From my experience building hundreds of forms, I can recommend the following:

1.Minimize the number of fields in the system. This might require a bit of to and fro between you and the business analyst + a little bit extra user research but you'll be amazed at how many superfluous fields there might be.

2.Clear path to completion: arrange fields and field descriptions in a way that the eye is led down the screen to the call to action buttons.

3.If there are compulsory fields mark them clearly.

4.Validate fields as the user types not after submit; offer in-line instructions

5.If you have a stack of fields, either tab them into discrete sections (like you indicate) or walk the user through a sequence of pages to final completion. edit: tabs won't work for sequential information or when there is compulsory information in each tab. It is a good approach, I have found, for containing different types of content in a system that the user updates or uses over a period of time.

6.Progressive disclosure. I allude to this is in 5). This is a way of avoiding cognitive burden or information overload. Put simply, present information in a series of simple steps instead of one big whole.

7.Break up longer forms into visually distinct regions. This allows you to group slightly different field sets together and will help the user build a mental model of the system, it is also a way of giving the impression that the system is less burdensome than it really is (again, this could be argued to be a type of progressive disclosure).

  • 1
    This is a good reference that has given me better ideas. For each point i have mentioned my actions 1. Almost all fields are needed, however i have hidden 10 fields based upon the IncludeTravelFromHome & IncludeReturnTravel, also 2 fields No Of Nights & Departure Date are calculated so have shown in readonly mode 2. Have to do 3. Have to mark compulsory fields 4. validation done inline 5. tab not practical since data is sequential, pages might be feasible 6. progressive disclosure seems the answer but then user neednt go sequentially so might be a issue 7. grouped into field sets Oct 25, 2011 at 2:44
  • 1
    No need to show calculated data in read only mode at this stage. Have a confirmation page where the user can check their data, and present it there. Oct 25, 2011 at 14:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.