Last modified: 2011-04-04 14:31:47 UTC
Created attachment 8366 [details] 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.
Created attachment 8367 [details] Partial screenshot of Special:Preferences#preftab-5 (Watchlist) with garbled subsection, in English.
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
(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?
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
