User:Billw58/Prefs Options
- Gale 03Jun12: Thanks for the work Bill. The new front page has numbers for the other list it has (the major sections) and this is a list too. Numbers reinforce the importance of Prefs and show the order (which is ambiguous otherwise.
If we have numbers I am +1 on across first, -1 on down first. I like bullets (when aligned properly) +0.75. I'm -0.75 on having neither bullets or numbers. I agree it is not really right in the context of the whole page. If most want neither bullets or numbers, then maybe a subtle border around the Prefs block?
- Bill 03Jun12: The PrefBull template aligns the bullets properly, but screen readers will say the link to the graphic every time encountered whether a template is used or not. I thought the bullet graphics were out because of this?
By the 'prefs block' do you mean the table of 16 sections? I've added that to the No Numbers section.
I could make a case for prefs sections to be listed alphabetically. After all, until you see an image of the prefs dialog what does the order matter? Perhaps users could find what they're looking for faster in a alphabetical list? My point is that numbering to show the order of the prefs sections as presented in the dialog is not that important. - Gale 03Jun12: I had not seen your discovery before now that screen readers say the link to the graphic. I understand with "real" Wiki bullet points (asterisk) they say "text"? Can you remind me why we cannot make this a proper list, given we are still using this in "More Details" - is that fixed now for browsers like Chrome?
I agree ordering Prefs alphabetically might help user sometimes but it would be more confusing to then see a different order when you got there. I would not do it unless we actually say that the list is alphabetical.
I can live with no bullets or numbers if needs be with the enclosed box (that is what I meant) but still -0.25. This is primarily about visuals (not giving users an undifferentiated mass of links in amongst already dense text) and consistency. Perhaps we should wait for Ed as he started this.
- Bill 03Jun12: The horizontal list items are not fixed in Chrome and Safari. Look at this page in Safari. AFAICT the floating horizontal list items appear work properly on the current front page because they are at the bottom of the cell. But look at the current front page in Safari - there is a blank line below the "importing - exporting - metadata editor" line. Since the vast majority of Mac users will be using Safari or Chrome (Camino is very marginal and I believe Firefox is too), we should get this right for those two browsers. If this means using fake lists or some other form of presentation then I think that should be seriously considered.
VoiceOver behaves differently in Chrome and Safari - Safari says "text" when it encounters a real bullet, Chrome says nothing and skips it (I think). With your change to the PrefBull template, Voiceover in Safari says "wiki bullet dot P N G image".
My point about alphabetizing was that order is not really that important and thus I don't see the point of needing the numbers.
I've never been that concerned about the "wall of links", nor about slavish consistency in using lists versus tables on the front page. If we feel that the table of prefs sections must appear to be a list then I vote for the numbers - at least screen readers will then say e.g. "one. link, devices preferences. two. link, playback preferences...". - Gale 03Jun12: I am sure David B would prefer a list for Prefs as it "is" a list, but if he accepts major sections as not a list then he should accept Prefs like that. Again, my beef against the prefs table with no numbers or bullets is first, ease of reading and second, consistency (not for lists vs headers in the code, but that this list and the major sections list should look similar with some text or graphic before the items).
Midori is identical to Safari in how it displays this page. "More details" using tables is needlessly expanded IMO, but I think it will be unacceptable for both sighted and VI users and for consistency to solve that by removing the list style. Is the webkit issue having extra space when closing a list with </ul> AND using "clear:both" somewhere? See http://gaclrecords.org.uk/samples.html which displays identically on Safari and Firefox both there and on this page. The first pair of channels is one list and the second pair is two lists. I also tried (within your existing code below) adding a "clear:both" div and immediate end div (so we did not clear the li or ul at all) but it did not prevent extra space. Basically we could I suppose put some conditional in the CSS for webkit browsers that styled the second order lists with negative margin-bottoms?
If we use a real unordered list for the Prefs, do we have any "clear:both" webkit issues with that? I'm coming round to accepting that an unordered list is at least as good as a list with numbers. But if a real unordered list is hard to implement and you don't want to spend a lot of time on it then it pretty much looks like numbers or the current headings in that box...
- Bill 03Jun12:
- I agree that the two table options are not good: the first because of the spacing and the second due to readability.
- My third option (still in progress as I write: I've got an unbalanced div in there somewhere) is no better than the second version.
- Yes, the webkit issue appears to be with using "clear:both" touching </ul>. Note that I am learning CSS as I go and am rapidly delving into advanced CSS without a proper grounding. I try things out until they work. I do not know at the moment how to use conditional CSS to do something different for webkit browsers.
- I believe that if we use a real unordered list for the prefs we'll have to use "clear:both" and will encounter the same problem. As I recall that is why I'm doing what I'm doing in the prefs section.
- Could you try your list examples, but creating rows of floating list items using "clear:both" to force a new row on your HTML (non-wiki) page? That might tell us something, if only that wiki has defeated us.
- Later: Never mind. I looked at the page source and wiki is not doing anything strange with that list construct. All the HTML is there exactly as specified on the page, except for the links which should not affect the formatting.
- Yes, am I rapidly reaching the end of my rope on this. I would accept numbers in the prefs list, but I would really like to see the webkit issue solved for the More Details section.
- On a whim I've added numbers to the lists in my third go at the More Details section (the no lists, no tables version). Perhaps that is a reasonable compromise (once I get the last niggle worked out in the formatting).
- Peter 4Jun12: The fundamental question that we have to ask ourselves is: "Is what Bill has worked on here and on his new front page better than what we already have, do we prefer it?" If the answer to that question is "yes", then we should implement it - if the answer is "no" then we should abandon it and let Bill get on with his life <smiles>.
Implementing it now will not, of course, preclude us from tweaking it in the future.
Like Bill the "wall of links" large or small is not a matter of concern to me - it has a certain aesthetic cleanliness which is visually pleasing - unlike the clutter of numbering. - Bill 04Jun12:
- I've trimmed this page down to what I believe are the three remaining contenders.
- As noted, the first two examples render the same with webkit and gecko based browsers, so are my preference. We can tweak how the horizontal "list" items float (specifically the width percent or pixels) if we think that would help the appearance.
- I think the bullet lists are out since the More Details section renders improperly in Safari and screen readers will say "wiki bullet dot P N G image" for each bullet encountered in the Prefs section.
- I have a mild preferences for "No numbers", but will accept the numbers if that's what it takes to resolve this.
In the following two sections the "More Details" part renders the same in Safari and Camino (webkit vs gecko).
Numbers across first
More Details for the Project Window
Additional Menus on Mac:
Additional Track types:
Details for importing and exporting:
1. LAME MP3 export and FFmpeg import/export libraries for more formats
2. On-Demand Loading of uncompressed files
How to arrange Toolbars
Preferences - changing your settings
Preferences are at the bottom of the Edit menu (or in the Audacity menu on Mac).Many settings can be changed including keyboard shortcuts and the interface language.
Preferences settings can be reset to default at any time.
No numbers
More Details for the Project Window
Additional Menus on Mac:
Additional Track types:
Details for importing and exporting:
LAME MP3 export and FFmpeg import/export libraries for more formats
On-Demand Loading of uncompressed files
How to arrange Toolbars
Preferences - changing your settings
Preferences are at the bottom of the Edit menu (or in the Audacity menu on Mac).Many settings can be changed including keyboard shortcuts and the interface language.
Preferences settings can be reset to default at any time.
Bullets (using the PrefBull template)
Note that screen readers will say "wiki bullet dot P N G image" for each bullet in the Preferences section.
The "More Details" section renders with extra lines before each first-order list item in Safari and Firefox on Mac.
More Details for the Project Window
- Additional menus on Mac:
- Additional Track types:
- Details for importing and exporting:
- LAME MP3 export and FFmpeg import/export libraries for more formats
- On-Demand Loading of uncompressed files
- Importing
- Exporting
- Metadata Editor
- How to arrange Toolbars
Preferences - changing your settings
Preferences are at the bottom of the Edit menu (or in the Audacity menu on Mac).Many settings can be changed including keyboard shortcuts and the interface language.
Preferences settings can be reset to default at any time.
