Page MenuHomePhabricator

label column in HTMLForm is sometimes compressed even when there is excess space on the side
Open, LowPublic

Description

Partial screenshot of Special:Preferences#preftab-5 (Watchlist) with garbled subsection.

Use full screen with, or full line width, respectively,
for the "Display options" subsection in Special:Preferences#preftab-5 (Watchlist)

Attached sceen shots show that the subsection layout looks pretty garbled,
and that there is plenty of space which can be used to make it look better,
even with a rather small screen width.


Version: 1.18.x
Severity: minor

Attached:

Details

Reference
bz28388

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 11:30 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz28388.
bzimport added a subscriber: Unknown Object (MLST).

Partial screenshot of Special:Preferences#preftab-5 (Watchlist) with garbled subsection, in English.

Attached:

happy.melon.wiki wrote:

Each subsection is a three-column table with the labels in the first column, the inputs in the second, and error messages in the third. What you're saying is that the first column should be wider so that the labels do not linewrap, rather than leaving wasted space on the right-hand side. Is that right?

That is right for this subsection.

Since many do not have labels, it is not true for other subsections. For example in the subsection following this one, I sugest to shrink the left column away for all rows but one.

My general suggestion is "more flexibility".

Occasionally, "Label Input Space" is bad for i18n, and "Text1 Input Text2" was a better way to go. See also:
http://www.mediawiki.org/wiki/Localisation#Have_message_elements_before_and_after_input_fields

happy.melon.wiki wrote:

(In reply to comment #3)

That is right for this subsection.
Since many do not have labels, it is not true for other subsections. For
example in the subsection following this one, I sugest to shrink the left
column away for all rows but one.

Alignment should not be inconsistent within sections; the start of each input should line up. See http://www.mediawiki.org/wiki/Style_guide/Forms etc.

My general suggestion is "more flexibility".

Flexibility is the enemy of consistency, and consistency is an important part of accessibility.

Occasionally, "Label Input Space" is bad for i18n, and "Text1 Input Text2" was
a better way to go. See also:
http://www.mediawiki.org/wiki/Localisation#Have_message_elements_before_and_after_input_fields

You added (http://www.mediawiki.org/w/index.php?diff=246667) that yourself; don't then cite it as independent support :P I do understand that it may make sense from a localisation perspective, but that's missing the point of the form: a form is there to capture data, and the data is different to the description, and different to the errors. We certainly need to flip the layout in RTL languages; that's something we don't currently do and that's bad. But breaking up the alignment or semantic separation is not a good idea.

I do not necessarily suggest "inconstency" within a subsection though there may be exceptions. I don not mind aligning similar things in an input form in columns, but I sincerly doubt that aligning things across multiple pages (at least as appearance to the majority using JavaScripts is concerned) is of any value to users, I even doubt that large block of similar data need a common alignment when the outcome is awkward to read. In print, tabular data bearing no relationship, be it contextual or formal or layoutwise, end and restart at section headings. So we would not do anything bad or unusual, if we layouted our preferences page accordingly.

There is even a way to combine the two worlds. Good prints use implicit tabulator stops for their series of sections of tabular data, when possible. With PHP and HTML, it is possible to weigh the approximate maximum widths of columns within each section, and relate them to each other, finally distributing colspans accordingly. So, we have a constant layout per section with some flexibility between sections and a common grid for them all. This would at least eliminate "holes" (large white square blocks).
It may well suffice to fix this issue and related ones.

(In reply to comment #4)

http://www.mediawiki.org/wiki/Localisation#Have_message_elements_before_and_after_input_fields

You added (http://www.mediawiki.org/w/index.php?diff=246667) that yourself;
don't then cite it as independent support :P

I did not want to give a wrong impression. Indeed, I wrote at least the initial version of that section, and few others in this group. Nevertheless, it is a summary of previous discussions in several contexts, at least one of which was in the MediaWiki/WikiMedia environment.

It is aplicable to our current subject matter. Look at this:

  • Display options --

Days to
show in [_7_______]
watchlist:
Maximum 7 days
Maximum number
of changes to
show in [_250_____]
expanded
watchlist:
Maximum number: 1000

  • Advanced options --

...

and compare it to:

  • Display options -- Show [_7______] days in watchlist. Maximum: 7 days

Show a maximum of [_250____] changes in expanded watchlist.

Maximum number: 1000
  • Advanced options --

...

Isn't the 2nd both more readable and much better English?

happy.melon.wiki wrote:

No, it's not. Or rather, it might be better English, but it's not a good form. The problems begin when you allow "1" as an option for number of days, as that screws up the pluralisation, and get significantly worse when you try and include errors and fields which are not the same length. What you *actually* get when you do inline forms is something like this:

  • Display options -- Show [_7____] days in watchlist. Maximum: 7 days ERROR:RUNESTONES NOT ALIGNED

Now let's include [a_really_long_text_field] to screw things up
Show a maximum of [_250____] changes, but because the field is a different

length this is all misaligned

The right hand text is not aligned, and the errors are particularly out-of-place. Or of course, you could line everything up:

  • Display options -- Show [_7____] days in watchlist. Maximum: 7 days ERROR: RUNESTONES NOT ALIGNED

Now let's include [a_really_long_text_field] to screw things up
Show a maximum of [_250____] changes, but because the

field is a different
length this is all misaligned

And you're back to essentially the same problem as before.

Fundamentally, users read forms vertically, not horizontally [1], if they can't very easily pick out the fields they need to fill in, and the text which describes what those fields are, then items get missed off, errors get shown, and people get unhappy.

[1] http://www.cxpartners.co.uk/thoughts/web_forms_design_guidelines_an_eyetracking_study.htm

matmarex set Security to None.