Wiki Team/Roadmap/Wiki skin redesign - Revision history

Walter: /* Color */

2010-04-04T13:32:23Z

Color

← Older revision		Revision as of 09:32, 4 April 2010
Line 43:		Line 43:
	==== Color ====		==== Color ====

	*		*

	==== Underscores on links ====		==== Underscores on links ====

FGrose at 22:24, 3 April 2010

2010-04-03T22:24:41Z

FGrose: Reverted edits by Patrol (Talk) to last revision by FGrose

2010-04-03T22:23:50Z

Reverted edits by Patrol (Talk) to last revision by FGrose

Patrol at 22:17, 3 April 2010

2010-04-03T22:17:48Z

← Older revision		Revision as of 18:17, 3 April 2010
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~~ 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]]		This would serve to educate all users about accessibility and provide new capabilities that can advantage usability for everyone, better accommodating the various minorities, without degrading functionality or aesthetics for the majority. --[[User:FGrose\|FGrose]]

	== wiki-devel test design ==		== wiki-devel test design ==

Patrol at 22:10, 3 April 2010

2010-04-03T22:10:31Z

← Older revision		Revision as of 18:10, 3 April 2010
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/msg00968.html discussion post])

	::[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, ~~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]]		* 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, and other links on utility pages are always links—a fixed feature of MediaWiki. These don't need the underline distinction. Arbitrary links like those in content text are the ones that benefit from a distinguishing underscore. --[[User:FGrose\|FGrose]]

	==== Fixed width page or 100% of window ====		==== Fixed width page or 100% of window ====

Patrol at 20:48, 3 April 2010

2010-04-03T20:48:19Z

← Older revision		Revision as of 16:48, 3 April 2010
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. --[[User:FGrose\|FGrose]]		: This seems to be an issue of which configuration provides more capability and freedom to use it, and optimizing convenience without restricting capability. See [[#Accessibility]]. We could set a default that most prefer and include the capability to set personal preferences. --[[User:FGrose\|FGrose]]
			: Eben entered [http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg08940.html comments] that he prefers a maximum width, explaining that adjusting the width in a tabbed browser is frustrating when you are working with multiple windows.

FGrose at 01:18, 16 March 2010

2010-03-16T01:18:59Z

← Older revision		Revision as of 21:18, 15 March 2010
Line 1:		Line 1:
	<noinclude>{{TOCright}}		<noinclude>{{TOCright}}
	[[Category:Accessibility		[[Category:Accessibility]]
	</noinclude>		</noinclude>

FGrose at 01:18, 16 March 2010

2010-03-16T01:18:40Z

← Older revision		Revision as of 21:18, 15 March 2010
Line 1:		Line 1:
	<noinclude>{{TOCright}}</noinclude>		<noinclude>{{TOCright}}
			[[Category:Accessibility
			</noinclude>

	: This is a '''Redesign idea workshop page''' - Please contribute your ideas!		: This is a '''Redesign idea workshop page''' - Please contribute your ideas!

FGrose at 20:24, 15 March 2010

2010-03-15T20:24:47Z

← Older revision		Revision as of 16:24, 15 March 2010
Line 32:		Line 32:
	==== Systems ====		==== 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 [http://usability.wikimedia.org/wiki/Main_Page 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.		* 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 [http://usability.wikimedia.org/wiki/Main_Page 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 ====		==== Linkbar ====

FGrose at 03:55, 15 March 2010

2010-03-15T03:55:57Z

← Older revision		Revision as of 23:55, 14 March 2010
Line 44:		Line 44:

	* 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, ~~gray~~ 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.

← Older revision		Revision as of 18:24, 3 April 2010
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~~ 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]]		This would serve to educate all users about accessibility and provide new capabilities that can advantage usability for everyone, better accommodating the various minorities, without degrading functionality or aesthetics for the majority. --[[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/msg00968.html discussion post])

	::[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, ~~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]]		* 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, and other links on utility pages are always links—a fixed feature of MediaWiki. These don't need the underline distinction. Arbitrary links like those in content text are the ones that benefit from a distinguishing underscore. --[[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. --[[User:FGrose\|FGrose]]		: This seems to be an issue of which configuration provides more capability and freedom to use it, and optimizing convenience without restricting capability. See [[#Accessibility]]. We could set a default that most prefer and include the capability to set personal preferences. --[[User:FGrose\|FGrose]]
			: Eben entered [http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg08940.html comments] that he prefers a maximum width, explaining that adjusting the width in a tabbed browser is frustrating when you are working with multiple windows.

← Older revision		Revision as of 18:23, 3 April 2010
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 ~~provide new capabilities that can advantage usability for everyone,~~ better ~~accommodating~~ the various minorities, without degrading functionality or aesthetics for the majority. --[[User:FGrose\|FGrose]]		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]] ~~([http://www.mail-archive.com/marketing@lists.sugarlabs.org/msg00968.html discussion post])~~		*: 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, ~~and other links~~ on utility pages are always links—a fixed feature of MediaWiki. These don't need the underline distinction. ~~Arbitrary links like those in content text are the ones that benefit from a distinguishing underscore.~~ --[[User:FGrose\|FGrose]]		* 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~~. See [[#Accessibility]]. We could set a default that most prefer and include the capability to set personal preferences~~. --[[User:FGrose\|FGrose]]		: 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]]
	: Eben entered [http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg08940.html comments] that he prefers a maximum width, explaining that adjusting the width in a tabbed browser is frustrating when you are working with multiple windows.