Hi Chip,
I understand you dilemma for an XML is a pain. I was just suggesting the
label first and any other event would be a click on the label which would be in
the Tree View. I guess you just have to improvise the rest depending on what
the starting point is.
Bruce
Sent: Friday, October 18, 2013 8:47 PM
Subject: RE: form design/layout question
David,
Thanks for all the great ideas; I really liked them all.
Also, I don't know what I was thinking, but I can't use a treeview control
down the left, because I cannot define xml controls which occupy the same space
on the right, and have them switch out depending on which set I want to be
active at the moment (at least, I don't know how to do that). So, unless each
screen was a duplicate in layout of the others, I can't just have the user
change the fields with a control; I have to do something like you describe.
Like it or not, I'm back to something close to a wizard (except for the trick
you mentioned of assigning numbers to each screen so the user can "hop" quickly
to a particular screen).
Thanks.
Chip
From: David [mailto:[email protected]]
Sent: Friday, October 18, 2013 8:45 AM
To: [email protected]
Subject: Re: form design/layout question
Chip,
Personally, I would have prefered a set of edit boxes, with each their
hotkey, for navigation. Now, it is perfectly well, to group them, and have each
group with its hotkey as well.
When comes to a treeview style, it may look nice and tidy for sighted people,
but for a blind user, it is not a good idea, when you require all fields to be
filled in. The user will have to do a bunch of tabbing back and forth, to "SEE"
if he has filled in each field. If you let the screen hold a set of edit boxes,
the user will tab through the screen, and directly get to know if he has filled
in a field, or missed something.
I do see your point about the form running out of space, if you go for
magnified text, or low-resolution screens. Here is another way of doing that,
which I see many online forms do. Split your form into two or more screens.
Give each screen the title: "MyForm 1 of 3", "myForm 2 of 3", and "myForm 3 of
3". The user now will know, that he is to expect the form to continue on the
next screen. Instead of the OK button - which you only will find on the last
screen of the form, your previous screens will hold a "next"-button.
Each screen, could hold one or two groups. You could even let each screen act
as a tab, and just have Next- and Previous-buttons, for quick navigation
between each screen. What I see many online forms do, is to have the first
screen retrieve info like your name - First, Middle and Last name. Second
screen, or say page, would hold info about your contact info - grouped with one
group for Address, and another with Phone numbers (Home, Office and Cellphone).
The third page, would take information as to delivery addresses, the fourth
page would take info like Comments and instructions, the fifth would handle
your payment details. Well, you get the idea.
The benefit of splitting your form into several pages, is that you can easily
have it fit into even small screens. You can make each screen tidy, with
several sub-groups, on each of them. And, you can even resize the different
groups. Let's say your first screen holds one big group, which you can let take
the hold screen. Your second screen, would have two groups, which it is natural
to have Vertically located - the one above the other. Like Address and Phone
info. The third screen, may hold controls that would better be presented in
four sub-groups, that are Horizontally located, to give the best vissible
effect. As you see, each page of your form, can be resized and reformated,
according to the kind of info you want to retrieve for that particular set of
controls. And, as already stated, long as your titles are indicating the index
and total numbers, the user will know what to expect.
You want to make it even more sofisticated? I have seen forms, where the
titles would be like: "Name, 1 of 3"; "Address, 2 of 3"; and "comments, 3 of
3". This kind of entitling each screen, will quickly inform the user, what kind
of info will be expected from this page. You could use the title of each page,
much like the header of each group - or, even as a supplement for the headers.
You could even let the user have a set of tiny buttons at the bottom of each
screen, numbered (and Labelled) from one to four. Press the 1-key on your
keyboard, and page1 will be displayed; press the 4-key, and you are directly to
the fourth page of the form. Now you have given the user full control of his
navigation, even quicker than things like CTR-Tab, in a Tab-form.
Above, I have used the ordering form as an example, since that is something
we all know - at least, all who has ordered anything online. :) You taylor it
to your project, but at least you should get the idea. The last benefit of this
approach, that I want to point out at this moment, is the chance for you to
increase the form, at a later state. Overcrowding your "one-page-form" with a
load of controls at this point, will make you unhappy when your project
increases, and you have to retrieve one or two extra pieces of information. A
page-divided form, will give you far more expansion facilities. You could
either just insert one control more on two of the pages, or even add on five
new pages if necessary. You even can let one page contain only edit boxes -
like the one for names. The next screen - for address - could hold a number of
edit boxes for text entries (Street, House number and zip code), and a combobox
for the static info (like the Country, Province or State names). Since you can
format each page of the form the way that best suits the info, you can easily
make a layout including different control types.
Should be fully possible, to make such a page-divided form, in such a way
that it suits both blind, low-vision and fully sighted people. And, you would
never need to overcrowd any of the pages. If you have too many fields for one
page, simply just take the controls to the next page. I.e, if you cannot fit
both Address and Phone numbers into one page, just let them have each their
page.
OK, a bit extra work, and your XML will soon grow big. But, Chip and the
rest, it may prove worth the extra hazzle. BTW, here is one last point. If you
have all controls on one screen, and want First-Letter navigation to each edit
box, you soon will run out of characters. In a Page-Divided form, you can let
the A-key go to one edit box. On the next page, you will have the A-key
available again, taking the user to its own edit box. This way, you can always
- or very close to that - use characters that are logically connected with the
info in each control.
----- Original Message -----
From: Chip Orange
To: [email protected]
Sent: Friday, October 18, 2013 1:57 AM
Subject: form design/layout question
Hi all,
I am designing a form where I need to get a significant amount of info from
the user (perhaps 15 to 20 controls). I can fit all the controls on one large
form, and I'll try to group them into groups with titles and visible frames to
make them appear logical, and not just scattered all over the screen.
Or, the alternative, would be to do something like the WE control panel,
where you have some listbox or treeview on the left controlling which groups of
fields you see on the right. I have at least 3 groups of controls, perhaps 5
if I did it this way. The user would be required to go through the listbox and
visit all 5 groups and tab to the right and enter the info for each group.
This seems to me to be more tedious when all the fields are required (not
when you're just trying to jump to one particular field to make a change).
In my case all my fields are blank, and the user can type in the info or
has a choice of command buttons to retrieve the data.
What I'd like to know is which type of window would you rather work with?
One with all the fields seen at once, or one where you must go down a listbox
of groups, and then go throu each group of fields, and then return to the
listbox?
Reasons would be appreciated. Especially if low-vision users might find
one format better.
I will say that I could be certain, when a low resolution monitor is being
used, that the second method would more likely fit on screen.
Thanks for any thoughts.
Chip
