It's a good idea to exercise some restraint, not using every possible technique just because we can, and keeping a lid on the number of different techniques that we use. Otherwise, it's sort of like a document laid out by an amateur who goes wild and uses too many fonts and colors.

However, if it's important in some places, I can go along with what you say. Let's see who else responds and where the needs are.

I vote for sentence casing. It's more natural to read, more modern (as you noted) and makes it easier to recognize Names Of Things and FIELDS from the other text without punctuation. I'd even be OK with a convention which allows all lowercase on certain elements, namely anything where the text would be a sentence fragment anyway. (Button labels come to mind.)

Funny side note: IBM did a study way back in the early mainframe days to determine whether, if they could only use upper or only use lower, which was more readable. The study showed that lowercase was the better choice, hands down. It's easier to distinguish similar letters, even with a "worn ribbon" and so on. As the story goes, an executive decided to go with uppercase anyway because without it, it would not be possible to capitalize the name of God.

-- Bruce

The incorrect example was supposed to indicate that controls should not touch, but always have a little space between them. Obvioulsy it's not clear, so I'll try to reword. Suggested wording is also welcome.

And, it allows for longer, more descriptive prompts.

However, there are cases where screen density is preferred to long scrolling screens. So, which to use depends on the situation.

That said, we plan to make it changable, probably on a per user/per page basis. Since BOD and SmartControl allow for both terse (shorter, to the left) and verbose (longer, above) prompts for every field, it is a very simple matter to switch between them.

1. Overall screen density is probably not much different, unless the fields are much wider than the labels.

2. I don't see where Luke W says he prefers right alignment. The loss of scanning efficiency (which he points out) seems much more important than the nearness to the actual fields.

3. Can we automatically make the labels bold in the vertical layout? Or maybe we could just always make them bold.

4. Maybe we could indent the actual fields a tad, to make it easier to scan the labels. By doing so, we would recover some of the advantage of the left justified horizontal layout.

1. Screen density is double in left vs. top prompts. I.e., you can fit twice as many fields in the same vertical space if the prompts are to the left.

2. He said that in person at the conference. What he litterally said, in answer to a question from the audience is:

"If you want people to go thru your form quickly, put prompts above or right justified. If you want them to slow down, and take more time, be more careful about what they enter, make the left justified." I took notes :)

You have argued elsewhere about nearness of prompts to fields being very important. In your simple example above it doesn't look like it'd make much difference, but sometimes the prompts have to be longer and hence fields with shorter prompts can be separated by quite a bit of white-space.

When you tab thru fields to do data entry, rather than read and click, this can lead to confusion.

3. Automatically bold in vertical layout - yes. But I wouldn't do it in the left prompt format. Luke specifically recommended against it. Again from my notes.

4. Not sure what you mean here.

In item F you say prompts to the left should be left justified.

I saw Luke speak at a conference in January and he said that:

1. Left justified prompts are better if you are looking at the page trying to find a certain field. I.e., it is better for scanning the prompts.

2. Right justified prompts are better if you are tabbing thru the fields., i.e., you know where you are and want to know what you should be entering.

Personally, I prefer the look of right justified prompts, but I rarely do data maintenance. I wonder which case is more important in iMIS. Data entry, or data editing? Or maybe this is another case where it depends on the context (screen)?

We'll do it in CSS of course, so it will be easy to change from one to the other (system wide). But,

a. SHould we support both, in different situations?
b. If we standardize on one or the other, what should be the default out of the box?

In his article, Luke recommends NOT using the background behind fields or prompts without a very good reason (e.g., to highlight the most important thing). It makes the screen visually more complex and harder to process.

You don't mention a rule about it one way or the other but it is shown with a background in the example.

I suggest removing it from the example and making a rule about when it may be used.

At the time this was initially done, we were using background color to distinguish read-only values from other text. It's probably not the best way, but we do need a way to maintain a clear distinction, especially if we are going to do mostly vertical labels.

My preference is to put some kind of a box around a read-only value, but make it visually different from an editable value. Many systems use a light grey background within the box to indicate a read-only value. There is a value in using an established convention, but really, it could be anything.

Good idea to use the background color to indicate the selected field and the one where the cursor is hovering.

Might still want the vertical scheme for in some places for rapid entry. How much rapid entry is done in iMIS? Is it mostly certain pages?

I think it does need its own patterns, but I agree with Edie that these can wait until we have the regular data entry off the ground.

In my posts below, I didn't really mean "Rapid" data entry, as opposed to just data entry. I was distinguishing Data Entry from Data Editing. e.g., in Data Entry you generally tab from field to field filling in each of the values. In Data Editing you are going into an existing record to make a change to just a few fields.

My thought was that when tabbing from field to field, one would want to more easily see what field they are updating so having a prompt that is close is best. When editing just a few fields of several, one would want to be able to scan the prompts more quickly to find what they are looking for.

So are you championing the vertical layout or right aligned labels?

I think we give up too much with right aligned labels. Vertical is not a bad compromise, though. If we indent the actual fields a small amount. (See revised example in d above.) Then its not too hard to scan when editing, and the labels are still close to the fields so it's easy to see the relevant label.

The vertical layout is a bit awkward for check boxes, however, and it requires greater use of columns to make effective use of screen space.

Everything considered, I think horizontal, left aligned is the best (except for rapid entry), provided we do the background color as suggested by Jeremy. (See the revised main example, above.)

Just want to make the right choice.

My current opinion is:
1. Use Vertical on the public stuff and anywhere width is a problem. Too often a public site's design is width constrained so vertical is always safe.

2. Default to Left aligned for staff (to save vertical scrolling) but give the ability to switch any page to vertical on a per user personalization basis.

I'm not a big fan of the flow thing Jeremy described. I wouldn't mind it for myself, but I think it is too big of a departure for our clients.

Something like the highlighting might work but I'm not sure I want to pay the price in performance. Probably not worth it.

I agree with using vertical where width is a problem. Letting people switch might be OK too, although each page will tend to be designed for one and probably won't work well with the other.

As I said before vertical will work well too.

Is anyone else following this and want to chime in?

Come on, be the champ!

I don't think performance is an issue. The mouseover highlight is accomplished in IE7 with strict doctype and FireFox via pure CSS. If using IE6 they just won't get that, no biggie. The highlight on focus of select box is accomplished with some simple javascript (which works in IE6, too).

Not to mention, in addition to the highlight on focus, we can add another line of script in that function to auto-expand the containing PanelTemplateControl if it happens to be collapsed when the user tabs into it...this is very slick.

jeremy

I didn't realize that performance would be a problem. Where would this come in? Is it because the downloaded page size is bigger? How significant is it?

http://www.humanfactors.com/downloads/layout4.asp

The discussion starts for real under the heading "Solution."

This is in a discussion about design for Windows, but the same advice is repeated in a web context, just with less detail.

Normally, I think checkboxes should have prompts/text to the right. But in some forms, this can look weird. I would suggest:

1. When using checkboxes, the prompt is always to the right
2. When it would look better to the left, use Yes/No radio buttons instead.

What do others think?

I agree, I like the checkbox labels to the right. I'm not sure what our yes/no radio buttons look like. Do we have an example somewhere?

Here's one from a voting site.  The "No Answer" choice is not necessary,
obviously.

I fully agree with Rob's comment.
Stacey Tarr