From: David Stone on
In article <slrnhmjs63.4no.spamspam(a)bowser.marioworld>,
Ben C <spamspam(a)spam.eggs> wrote:

> On 2010-02-03, Jukka K. Korpela <jkorpela(a)> wrote:
> > Ben C wrote:
> >
> >> On 2010-02-03, Jukka K. Korpela <jkorpela(a)> wrote:
> >>> David Stone wrote:
> >> [...]
> >>>> At least, the answer
> >>>> grid _looks_ better if the answer choice columns are equal width.
> >>>
> >>> Well, why don't you make th grid a single table then? In a single
> >>> table, columns are of the same width out of necessity.
> >>
> >> No they aren't. Presumably you meant something else, but I can't
> >> figure out what.
> >
> > Right. I should probably do something else than post to Usenet until I get
> > back to my senses.
> Ah, I think you meant all the cells in one column of a table are the
> same widths as each other.
> > I thought David referred to having corresponding coluns in different tables
> > of equal width, but obviously it was about setting two or more columns in a
> > single table to have the same width.
> I don't know what he meant actually. You might have been right the first
> time.

Unfortunately, the link for my particular test case keeps getting
snipped out of the replies in the thread. You can see exactly what
I (David) am trying to do here:

- although I think between the various responses throughout this thread
I have a better idea of how to handle the columns.* Now I just have to
figure out the rows (see my reply to JK elsewhere in this thread).

* I'm sure there are still better ways to handle the css on this table,
including taking advantage of the fact that there can only be one first
column, but I have other things to take care of first!
From: Jukka K. Korpela on
David Stone wrote:


At the design level, this raises many questions. For several reasons,
including accessibility, the simulation of paper forms is not the optimal
approach to questionnaires with agree/.../disagree choises. Some points on

Note that in the current approach, it is impossible to associate labels with
the radio buttons, thereby violating essential accessibility requirements,
since a button would logically have a two-dimensional label (row, column),
which is impossible.

If you use the approach of using a single-character text input field for
each question, the current layout issue vanishes, since there would be just
a single column for the answers - or no column at all, since you could
actually have

Question bla bla bla? [ ]
A question with a longer text? [ ]

There would be no functional reason to put the controls in a column, except
possibly making it easier to the user to check out that all questions have
been answered (or left knowingly unanswered) - but you can and should check
such things in the form data processing anyway.

>>> I would also prefer if all table rows were equal height but, since I
>>> cannot predict the number of text lines in each row - particularly
>>> as page width varies - I'm not sure of the best way to achieve this.
>> If it's tabular data, I don't see why the rows should be of equal
>> height. Different amount of data requires different heights.
> If you look at the test page I was referring to, you will see it is
> a questionnaire similar in nature to a Myers-Briggs personality test.
> My concern is that, if any one column in the response section is wider
> than the others, it might subliminally suggest that the respondent
> select that option.

That's possible. Using text input field eliminates that problem. This is
safer than any method of setting column widths, since such settings may fail
for various reasons (usual CSS caveats, common oddities in column width
implementations in browsers).

> As for the row heights, it simply bothers me.
> Also, it might suggest that a particular question was not so
> important.

Maybe, but I think it's really an esthetic issue that bothers you.

Besides, the amount of text in each question (possibly resulting in
noticeable empty space) could equally well subliminally suggest something.

> I don't know
> if either of these concerns have any real validity: the only way to
> find out would be to run two versions of the questionnaire, one with
> equal column widths and row heights, and one without, and see if
> respondents gave different answers between the two.

That would actually be possible online, using tools that randomly select one
of two versions. Such methods are however somewhat tedious and usually pay
off only if you expect considerable commercial differences in effects (say,
one page layout results in bigger sales to a statistically significant
degree). There's no reason (except perhaps amount of work) why such
variation could not be purely stylistic (one of two stylesheets selected at

> So if, for the purposes of a particular page, you had to make sure
> that all <tr>'s in a single table were the same height irrespective
> of the number of lines of text wrapped in each <td> of the first
> column, how would you do it?

Given the premises, I would use (gasp!) height="..." attributes in td and
and th elements in HTML and override (when possible) them with CSS settings
that use better units (the em unit). I would of course need to make a guess
on the maximum amount of lines needed in normal browsing conditions, for
some values of "normal".


From: David Stone on
In article <upEan.72996$La7.14287(a)>,
"Jukka K. Korpela" <jkorpela(a)> wrote:
> David Stone wrote:
> >
> At the design level, this raises many questions. For several reasons,
> including accessibility, the simulation of paper forms is not the optimal
> approach to questionnaires with agree/.../disagree choises. Some points on
> this:

Aside from accessibility issues, I'm not sure about the simulation of
paper forms being a bad thing, since the user will at least be very
familiar with the format of the latter (especially as a student taking
undergraduate courses with large enrolments!)

That said, using <select> (as per one of the suggestions on your page)
does reduce the display content and visual "bulk" of the page, and
greatly simplifies the presentation. Here's the alternate version:

As you can see, the remaining issue becomes the choice of the default
displayed (selected) item, which is necessary to avoid (a) predisposing
the respondent to a particular choice and (b) make it easier for the
server-side script to determine that a selection has been made for
each question. This also avoids having to set widths on the table
columns, amongst other things.

Overall, I think I prefer this version to the original using radio
groups on several counts. It would be interesting to get others'
opinions, though!
From: dorayme on
In article <7svls2F2eqU1(a)>,
Barely Audible <anywhere(a)> wrote:

> Thanks Guys - You answered my question very well AND managed to not
> descend into a slagging match ;-)

Hang on! We might be able to fix that, it's never too late. Hey
Travis, you are fink! What do you say to that? And where the hell
are you? Come out and play you miserable poltroon! <g>