8,288
edits
Changes
Wiki Team/Roadmap/Wiki skin redesign (view source)
Revision as of 22:25, 14 March 2010
, 22:25, 14 March 2010no edit summary
These are just my personal wishes, not strict requirements. ...
These are just my personal wishes, not strict requirements. ...
=== Accessibility ===
We should plan to have an 'Accessibility Features' highlight box on our Main page that alerts users to features and options that will assist their use of the wiki. There we can describe how to take advantage of the new options and preferences. We could prepackage these into specialized skins, and show users how they can customize significant features with user and skin-specific .css and .js pages for their accounts.
This would serve to educate all users about accessibility, and better accommodate the various minorities, without degrading functionality for the majority. --[[User:FGrose|FGrose]]
== wiki-devel test design ==
== wiki-devel test design ==
==== Underscores on links ====
==== Underscores on links ====
* show on hover only - like the Wikipedia MonoBook and Vector skins, I prefer not to clutter the content area with lots of horizontal lines that interfere with the typeface descenders, make reading the text more difficult, and tire the eyes.
* show on hover only - like the Wikipedia MonoBook and Vector skins, I prefer not to clutter the content area with lots of horizontal lines that interfere with the typeface descenders, make reading the text more difficult, and tire the eyes. --[[User:FGrose|FGrose]]
*: The bottom-border underscores move them below the descenders (at many resolutions), so this is an improvement in readability. The excess of horizontal lines in the content text remains an issue in my opinion.
*: The bottom-border underscores move them below the descenders (at many resolutions), so this is an improvement in readability. The excess of horizontal lines in the content text remains an issue, in my opinion. I've found that the excess ink and horizontal lining of solid underlines can be reduced by using a dotted, gray bottom-border underline {text-decoration:none;border-bottom:1px dotted;border-color: gray}. (But see also just below.) --[[User:FGrose|FGrose]]
::[http://www.mail-archive.com/marketing@lists.sugarlabs.org/msg00917.html From] Josh Williams, web designer working on the redesign: I'm with you on having the underscores only appear on hover for the main content, but there's a really big usability problem there for color blind people or users with a grayscale monitor. If you go to http://sugarlabs.org on the XO and set the screen to gray scale it's extremely difficult to find links because there's no visual cue other than color.
::: This is something the new version of MediaWiki has addressed with a new 'Link underlining' preference. It's on the 'Appearance' tab, Advanced options section, and allows Never, Always, & Browser default. Unfortunately, this feature doesn't seem to work with the border-bottom underlines (which do improve readability). Perhaps we can adjust this with the skin.php or skin.js or request that the feature be coded to work with alternate underlining methods. --[[User:FGrose|FGrose]]
==== [edit] section links ====
==== [edit] section links ====
* left or right position - I find the left position of these links, just preceding the section title, interferes with the clarity of reading and scanning the titles. I prefer that the [edit] section links be moved to the right like in the MonoBook and new Wikipedia Vector skins.
* left or right position - I find the left position of these links, just preceding the section title, interferes with the clarity of reading and scanning the titles. I prefer that the [edit] section links be moved to the right like in the MonoBook and new Wikipedia Vector skins.
* contrast - I also suggest that they be slightly less dense or grayed from the rest of the text, so that they are easier to ignore when one is concentrating on reading the content on a page.
* contrast - I also suggest that they be slightly less dense or grayed from the rest of the text, so that they are easier to ignore when one is concentrating on reading the content on a page.
* underscores - like the other non-direct content links, if they only show an underscore when hovered with the mouse pointer, there will be less unessential 'ink' on the page that distracts, tires the eyes, and changes the graphic feel of the page.
* underscores - like the other non-direct content links, if they only show an underscore when hovered with the mouse pointer, we could reduce the amount of unessential 'ink' on the page that distracts, tires the eyes, and changes the graphic feel of the page. For those on monochrome displays, links that are inline with content text are the ones that can't be found. The side bar, table of contents box, editsection, others on utility pages are always links—a fixed feature of MediaWiki—and not arbitrary links like those in content text. These don't need the underline distinction. --[[User:FGrose|FGrose]]
==== Fixed width page or 100% of window ====
[http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg08724.html Bernie] and [http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg08744.html Sascha] expressed concerns about the use of fixed width content, and [http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg08743.html Josh] explained his preference, "...That's true, you can always resize the window. I'm in the camp that it's better to set a maximum width because I think it's harder to read long
strings of text. Also I don't enjoy resizing the window just for sites that do this..." and explained some options as well as requested further discussion.
: I find that I want to reflow text into wide windows often so I can compare versions and different pages by stacking them above and below each other. I'm frustrated by sites with fixed width because this prevents reflowing the text into long windows. Because of this, more text is hidden from single view and reducing my effectiveness by forcing me into vertical scrolling and shorter comparisons.
: This seems to be an issue of which configuration provides more capability and freedom to use it, and optimizing convenience without restricting capability. --[[User:FGrose|FGrose]]