Difference between revisions of "Wiki Team/Roadmap/Wiki skin redesign"
Jump to navigation
Jump to search
| Line 23: | Line 23: | ||
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 that will be provided with new software. We could prepackage these into specialized skins, and show users how they can customize significant features with skin-specific .css and .js pages for their accounts. | 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 that will be provided with new software. We could prepackage these into specialized skins, and show users how they can customize significant features with skin-specific .css and .js pages for their accounts. | ||
| − | This would serve to educate all users about accessibility and | + | This would serve to educate all users about accessibility, and better accommodate not only the various minorities, without degrading functionality or aesthetics for the majority, but provide new capabilities that can advantage the usability for all. --[[User:FGrose|FGrose]] |
== wiki-devel test design == | == wiki-devel test design == | ||
| Line 48: | Line 48: | ||
* 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]] | * 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. I've found that the excess ink and horizontal lining of solid underlines can be reduced by using a dotted, lightgray bottom-border underline {text-decoration:none;border-bottom:1px dotted;border-color: gray}. (But see also just below.) --[[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. I've found that the excess ink and horizontal lining of solid underlines can be reduced by using a dotted, lightgray 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. | ::[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. | ||
| Line 57: | Line 57: | ||
* 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, 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, | + | * 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 ==== | ==== Fixed width page or 100% of window ==== | ||
| Line 64: | Line 64: | ||
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. | 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. (Side-by-side window comparisons are often frustrated by images and other features that float the text into unusual jumbles.) | : 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. (Side-by-side window comparisons are often frustrated by images and other features that float the text into unusual jumbles.) | ||
| − | : This seems to be an issue of which configuration provides more capability and freedom to use it, and optimizing convenience without restricting capability | + | : 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]] |
| − | |||
Revision as of 17:23, 3 April 2010
- This is a Redesign idea workshop page - Please contribute your ideas!
Design goals
From Bernie in this discussion thread, "I'd like our linkbar to be:
- consistent in style across all webapps (maybe also in content)
- reminiscent of Sugar's UI elements or colors
- in harmony with the look of all our sites
- maybe well detached from the rest of the page (like the gnome one)
- written in very tidy html + css for easily maintainability
- free of frames/iframes, marquees and non-standard html crap
- perfectly readable in text-only browsers, even without css
- ordered the same way across all sites (= easy to memorize)
- wrapping nicely on small screens
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 that will be provided with new software. We could prepackage these into specialized skins, and show users how they can customize significant features with skin-specific .css and .js pages for their accounts.
This would serve to educate all users about accessibility, and better accommodate not only the various minorities, without degrading functionality or aesthetics for the majority, but provide new capabilities that can advantage the usability for all. --FGrose
wiki-devel test design
http://wiki-devel.sugarlabs.org/
Design discussion
Please use this space to share, respond to, and refine comments, in context within the topical areas.
Systems
- MediaWiki 1.16 beta has been announced, http://lists.wikimedia.org/pipermail/mediawiki-announce/2010-March/000089.html, with new features supporting skin changes. They also will be introducing features to support a new default skin, Vector, developed by the Wikimedia Usability Initiative. It would probably server us to base any major changes on the pending default software and skin. See the reference for the many engineering and usability features that will be enabled.
- Bernie has proposed http://wiki-testing.sugarlabs.org/ to pursue this (not yet MW 1.16).
Linkbar
- Consider using a larger/different typeface to better distinguish these inter-site links from the personal wiki navbar links on the same, top line and on the right of the page.
- Link sites - drop people, add translate, ideas?
Color
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. --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. I've found that the excess ink and horizontal lining of solid underlines can be reduced by using a dotted, lightgray bottom-border underline {text-decoration:none;border-bottom:1px dotted;border-color: gray}. (But see also just below.) --FGrose
- 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. --FGrose
- 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.
[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.
- 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, 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. --FGrose
Fixed width page or 100% of window
Bernie and Sascha expressed concerns about the use of fixed width content, and 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. (Side-by-side window comparisons are often frustrated by images and other features that float the text into unusual jumbles.)
- This seems to be an issue of which configuration provides more capability and freedom to use it, and optimizing convenience without restricting capability. --FGrose