Wikipedia talk:WikiProject Usability/Archive 3

Usability in Help: namespace

See usability-related discussion initiated at Help talk:Footnotes#The bigger picture: use of "H:", "Phh", "Ph" and other related templates in Help namespace --Francis Schonken 12:43, 20 May 2006 (UTC)

Sidebar redesign discussion

A discussion is underway concerning the redesign of the sidebar which is displayed on every page of Wikipedia. See you at Wikipedia talk:Village pump (proposals)/Sidebar redesign --Nexus Seven 00:27, 11 August 2006 (UTC)

Image size recommandation

Is a policy on image sizes will be good? I was pushing the use of thumb in an infobox discussion, and I think the flexibility of a size not specified in pixels is better. --Marc Lacoste 09:56, 28 August 2006 (UTC) To content my opponent in this discussion, is anybody knowing a trick to not show the borders of a thumbnail?

Project directory

Hello. The WikiProject Council has recently updated the Wikipedia:WikiProject Council/Directory. This new directory includes a variety of categories and subcategories which will, with luck, potentially draw new members to the projects who are interested in those specific subjects. Please review the directory and make any changes to the entries for your project that you see fit. There is also a directory of portals, at User:B2T2/Portal, listing all the existing portals. Feel free to add any of them to the portals or comments section of your entries in the directory. The three columns regarding assessment, peer review, and collaboration are included in the directory for both the use of the projects themselves and for that of others. Having such departments will allow a project to more quickly and easily identify its most important articles and its articles in greatest need of improvement. If you have not already done so, please consider whether your project would benefit from having departments which deal in these matters. It is my hope that all the changes to the directory can be finished by the first of next month. Please feel free to make any changes you see fit to the entries for your project before then. If you should have any questions regarding this matter, please do not hesitate to contact me. Thank you. B2T2 14:26, 26 October 2006 (UTC)

Template:click is up for deletion

Template:click, which uses a wikitext/HTML/CSS hack to make links unclickable in graphical browsers, but adds confusing links to other browsers, has been proposed for deletion. Poll is at Wikipedia:Templates for deletion/Log/2006 December 17#Template:Click. —Michael Z. 2006-12-17 17:03 Z

Yay! — Omegatron 15:41, 18 December 2006 (UTC)

Redlink in project documentation

Wikipedia:WikiProject Usability/Infobox accessibility has a prominent redlink in it. — SMcCandlish [talk] [contrib] ツ 20:36, 16 March 2007 (UTC)

Converting main page to CSS

Hi all,

I'm afraid that I thought I had a solution to this issue, but when I implemented it I broke the main page :-( I am rather sorry that I did that. However, it is possible to convert from tables to divs and apply styles. Given that HTML should be about structuring information, and not really about layout, I would like to see a lot more div tags and a lot less table tags!

Our current main page is actually quite hard to skin. For instance, I wanted to include, in my own css file, line-spacing changes. However, these changes break the main page for me. If the main page had the infoboxes in div tags, then it would be a lot simpler to implement this change.

A trial is currently at User:Ta bu shi da yu/MainPage2, there are significant problems with my markup, however. If anyone could help, I'd much appreciate this! - Ta bu shi da yu 02:20, 8 May 2006 (UTC)

I'd be overjoyed if people could help you with this. (and converting the Community Portal and Help:Contents redesigns into CSS layouts too). -Quiddity 17:36, 8 May 2006 (UTC)

The use of tables for layout in templates and whatnot is so rampant it makes me want to cry. Vagary 09:01, 24 May 2007 (UTC)

Regular users can't edit the site-wide CSS, so it's all they can do. It's better than no layout... — Omegatron 13:56, 24 May 2007 (UTC)

I have made a version of the main page using inline CSS. Please view it at User:OliverRigby/CSS Main Page and feel free to make any comments, alterations and suggestions. There is a short discussion at Talk:Main Page#The_main_page_rewritten_in_inline_CSS regarding this at the moment. Many thanks. -OliverRigby (talk) 22:02, 20 January 2008 (UTC)

Comments requested

There's a thread at Template talk:Navigation bar about the usability of the recently created template:Navigation bar. Please comment there if you're interested in this. Thanks. -- Rick Block (talk) 18:46, 26 October 2006 (UTC)

Infobox accessibility issue

Moved to Wikipedia:WikiProject Usability/Infobox accessibility. -- Rick Block (talk) 01:40, 21 September 2006 (UTC)

Template:cquote is up for deletion

Template:cquote, which formats block quotations as a table with purple quotation marks linked to image pages, has been proposed for deletion. Please vote or comment at Wikipedia:Templates for deletion/Log/2006 December 12#Template:Cquote. —Michael Z. 2006-12-13 17:20 Z

And it's already been closed. I knew as soon as I put the TfD template on it, they'd come running. — Omegatron 19:26, 13 December 2006 (UTC)

Gah. And agreed, that's a ghastly template. Next time... -Quiddity 20:50, 13 December 2006 (UTC)

browser testing of backround transparent image

Hi! Hopefully this is good forum to ask help for browser testing of one idea I have.

Namely I try to enable blended background image to be used for example in navigation box headers. It's easy to do in (new) non-IE browsers, but IE would need some "hacking". In my commons page ( commons:User:TarmoK/wikibar ) I have made test page to test the solution for it and it works for IE6, FF and Opera, but I'd be glad to get help with other browsers, especially IE7 and as well Mac-s browsers.

If you have free moment to take little time to do small addition to your monobook.css in commons and then check this test page (and update the table in bottom of page), I'll be greatful. Thank you in advance and all comments are welcome --TarmoK 13:49, 25 December 2006 (UTC)

Removing Clickable images from Portals

The user Suruena has created the page Wikipedia:WikiProject Usability/Clickable images and has gone to all the portals and removed their clickable links. Mainly in the links to other WikiProjects section. I noticed this project does not link Wikipedia:WikiProject Usability/Clickable images on its mainpage. I also noticed its a policy that has only had one contributor: Suruena. Personally, removing the links is a major disadvantage to the portals and I am tempted to report it as vandalism. Mkdw^talk 04:18, 12 January 2007 (UTC)

As discussed in different places [1][2][3], {{click}} is very a problematic template (CSS hack with usability, accessibility, browser-compatibility, and even copyright problems). And although in its documentation it clearly says "Do not use this template unless absolutely necessary," it is frequently abused (it was used even in a user signature!). I understand that clickable images are nice, but it simply has too many problems (AFAIK MediaWiki currently has specific syntax for clickable images, but it is disabled in the Wikipedia, think why). In the last vote for deletion the consensus was delete, but it can't be deleted because this template was used in thousand of pages (this is the fact it was heavily abused). So I started this wikiproject to change that dangerous trend. The experienced wikipedians that participated in that vote for deletion, some members of the accessibility project, and some administrators have helped me in my task (and acknowledged the policy), but currently I'm the only active contributor to this project. Probably this means I started the project too quickly (more collaborators are welcome), and this is all my fault (maybe a link from the main page of the Usability WikiProject will help, what do you think?). However, I have changed several hundred pages and very, very few people has complained (only two wikipedians), the rest agree with the policy and even have thanked me.

I hope this response helped to change your mind about the vandalism issue, but I'm agree with you probably I wasn't able to explain correctly the project. Thanks, and sorry for this very long text! :-) Best regards, --surueña 23:46, 12 January 2007 (UTC)

What suruena said. 'click' is a bad hack that needs to disappear. (thanks from me too, suruena, for putting energy into fixing/removing it :) —Quiddity 04:31, 13 January 2007 (UTC)

This is a an example of a small group of people in Wikipedia imposing their will on the whole of wikipedia against the wishes of other editors. --- Safemariner 21:40, 20 January 2007 (UTC)

I don't understand. Does this mean we wont be able to use pictures as links? --Seans Potato Business 20:20, 20 February 2007 (UTC)

It is possible to use the new ImageMap extension to provide the same functionality -- clickable images. See Wikipedia_talk:WikiProject_Usability/Clickable_images#Extension:ImageMap. --Aude (talk) 20:26, 20 February 2007 (UTC)

How did you pounce on my message so quickly? :D --Seans Potato Business 20:31, 20 February 2007 (UTC)

I'm watching this page. I'd be glad to help if you try ImageMaps and can't get it to work correctly. --Aude (talk) 20:35, 20 February 2007 (UTC)

Oh, ok, thanks. It's okay, I don't make clickable pictures - I just wanted to know if it was still possible. :) --Seans Potato Business 20:39, 20 February 2007 (UTC)

Requesting Spoken Articles - Priority To Those That Need Them

It would be nice if there was a place where visually impaired people might go to request that an article is turned into a spoken version, assuming that they would really prefer this over their computer's own text-to-speach capability. --Seans Potato Business 20:30, 20 February 2007 (UTC)

See Category:Spoken Wikipedia requests. --Quiddity 19:23, 26 May 2007 (UTC)

MoS and accessibility

Participants here may be interested in the following Wikipedia Manual of Style debate: Wikipedia talk:Manual of Style (dates and numbers)#Appending a period. The gist is that the MoS current says to leave the period off of abbreviations of units of measurement, entirely, when this is really only appropriate for some of them, such as mm, km, dB, etc., and is not appropriate for those that are abbreviations of Imperial/American units such as feet, inches, miles, etc., which have traditionally used periods, and do so with the recommendations of the vast majority of style guides. The usability issue can be illustrated with an example: "The rod is 40.6 cm (16 in) in length" (or worse yet, "has 40.6 cm (16 in) sides"; screen readers (at least some of them) are going to say "16 in sides" which will sound like "16 insides". Some of the MoS regulars are strongly resistant to the idea of restoring periods here, and I suspect that only usability/accessibility concerns are going to make a dent with them. PS: There are several other debates relating to updating this subsection of the dates and numbers section of MoS, at Wikipedia talk:Manual of Style (dates and numbers)#Overhaul "Units of measurement" section which may be of some usability interest. I fear that the main debate I'm mentioning here is rarely raised because it is shouted down with "This is old news! We don't want to talk about it again!" attitudes (a quick review of that talk page shows several blantant examples of this ignoring of WP:CCC already); its going to take more than just me to get this fixed, I believe. PS: even from a sighted-user usability vs. accessibility issue, the current MoS-recommended practice is terrible, since English speakers parse the string "in" as a preposition not as an abbreviation for "inch(es)". — SMcCandlish [talk] [contrib] ツ 20:44, 16 March 2007 (UTC)

Firefox issues

I'm not sure if this is the right forum for discussion, but I wonder if there is any specific project aimed at resolving issues between different browsers showing templates etc. differently. For example, this template is practically illegible in FF but fine in MSIE. I want to have a go at resolving it, but wonder if there is a place where I can get assistance?

— superbfc [ talk | cont ] — 11:19, 12 April 2007 (UTC)

Check my reply at the template talk page. I was able to fix one little thing. I'll see what I can do about the squashy-ness. ~ Amalas rawr ^{=^_^=} 16:02, 12 April 2007 (UTC)

Thanks, I already sorted the squashy-ness (compare it to this) as someone has removed a parameter they thought was superfluous, but was required in Mozilla.

— superbfc [ talk | cont ] — 16:20, 12 April 2007 (UTC)

Help pages

As someone recently aptly commented, Wikipedia's help pages are a "mind-numbing maze". There is page after page after page of different people explaining different aspects of the same thing in different ways, link after link which one has to follow, seemingly without end, without ever having any clue about where one "is" in this maze. In five minutes I found NINETEEN different pages that explain different aspects of how to create links. After that I lost the will to live.

Is there any ongoing effort to try to clean up these pages? If there is then I may be able to contribute from time to time when I'm feeling enthusiastic. Matt 13:13, 28 April 2007 (UTC). —The preceding unsigned comment was added by 81.156.127.107 (talk)

Yes, but it's inactive currently: Wikipedia:Help Project. Believe me, it's even more complicated than you think. Anyone trying to clean up our help pages inevitably realizes that one really has synchronously coordinate a cleanup of meta:help:contents and mw:help:contents too, which is a monumental task. --Quiddity 19:23, 26 May 2007 (UTC)

Animated Picture of the Day

The current Picture of the day, Image:Translational motion.gif is extremely distracting; it may well cause problems for users with cognitive disabilities. It appears to breach WAI-WCAG Web Content Accessibility Guidelines. I've proposed that it be replaced ASAP, and that we have an agreement to only use still images for PotD in future? Thank you. Andy Mabbett 23:23, 14 May 2007 (UTC)

WAI / Section 508

I got a question from a large teaching/research institution intending to introduce Mediawiki: Has Mediawiki been tested against WAI and/or Section 508 standards with regards to disabled users in general and users with impaired vision in particular. Does anyone here know anything about this? Cnyborg 15:53, 21 May 2007 (UTC)

Eliminating {{click}}

{{click}} is a usability problem. It's widely used, and in many cases, that use is replaceable with ImageMap. I've been, over a while, converting easily convertible instances of the template to roughly equivalent ImageMap code. Just recently I wrote a program in AppleScript that does the conversion automatically, which has sped up my efforts tremendously. If anyone else in the Usability project is using Mac OS X and wants to help out converting things, the script is at User:Nihiltres/Click-to-ImageMap and is useful for quick copy-paste-script-copy-paste conversions that are much faster than manual conversion. The script warns in the case that the conversion is obviously not valid syntax (i.e. does not contain an image or a link, or uses template or parameter references incompatible with ImageMap). It was a quick write-up once I had the idea to do it, though the code's still a bit messy. If someone finds this useful, let me know. :) Nihiltres^{t.l} 15:37, 29 December 2007 (UTC)

Main Page ANG

Hi everyone, I was looking to edit the main page of the Anglo-Saxon wiki, and I thought using the Dutch version as a base would be great; the only thing is the width of the right-side is a bit too much. I'm not very good at programming, but if someone would be able to help out, I'd appreciate it. --JamesR1701E (talk) 15:44, 16 August 2008 (UTC)

Personal list of usability problems

To prepare for the upcoming Wikipedia usability study, I wrote up a list of usability problems and proposals. Any comments are welcome. Cheers, AxelBoldt (talk) 17:48, 27 December 2008 (UTC)

Well done. Perhaps other editors should look at a long article, a short article, and history/discussion and try to find usability problems. Try not to read other people's lists of problems until you try to come up with your own, in case you introduce some bias. Also, don't try to come up with solutions until you're done finding all the problems. Then just post a link here. Hopefully there are some people actively watching this page. Here is my list of usability problems. –M^T 04:08, 29 December 2008 (UTC)

WCAG 2.0

Should Wikipedia work towards meeting WCAG 2.0 guidelines? At what level? Please join discussion at Wikipedia talk:Accessibility#WCAG 2.0. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:24, 10 January 2009 (UTC)

Wikipedia and its condition of Editorial Friendliness

Wikipedia and its policies regarding the creation of articles and the limitations of content that is allowed_{(i.e. original research)} negatively impact Wikipedia's friendliness towards editors and image uploaders. It should be this Wiki Projects responsibility to campaign to improve the usability for editors in Wikipedia.Spitfire19 (Talk) 20:55, 1 March 2009 (UTC)

The [edit] button

There is a proposal here to make an alteration in the position of the [edit] button. Input to the discussion is welcome. Mjroots (talk) 13:08, 27 May 2009 (UTC)

Making WIKI more Dyslexia Frinedly

The current prefeence options do not conform to the needs of dyslexic visitors of WIKI, infact WIKI could be described as an alien environment for dyslexics The are many cause of the dyslexic symptom, the two main categories are visual and auditory neurologogical information processing problems. Most dyalexia freindly werb sites follow a standard convention of providing at least six different background options for the whole web page such as the UK British Dyslexia Accossaition web site http://www.bdadyslexia.org.uk/ they also offer font choice and font colour choice but that may be too technicla for WIKI at this time. The research basis for all of this can be viewed at http://www.dyslexiaservices.com.au/Six-Year_Follow-Up.htm

Those who have the auditory problems that can cause the dyslexic symptom prefer text to be presnted with more spacing and using multi coloured fonts, which again many be not too tewchnically possible just now but have a look at http://www.apduk.org/ and the prefer listed infoirmation which appears in the guide indexes to be presented something like this http://capdlinks.homestead.com/Dyslexia.html

another issue on my skins page I found the following ________________________

• Chick (Preview) (Custom CSS) (Custom JS)
• Classic (Preview) (Custom CSS) (Custom JS)
• Cologne Blue (Preview) (Custom CSS) (Custom JS)
• Modern (Preview) (Custom CSS) (Custom JS)
• MonoBook (default) (Preview) (Custom CSS) (Custom JS)
• MySkin (Preview) (Custom CSS) (Custom JS)
• Nostalgia (Preview) (Custom CSS) (Custom JS)
• Simple (Preview) (Custom CSS) (Custom JS)

__________________________

all of the CSS and JS options are dead RED links which lead to a blank page could this be remedied. My concern is that the options I am asking for should be standard options for Visual dyslexics to choose from just like say the Monobook option which many non dyslexic may prefer.

So I ma asking fro SIX more skin options which would comply with the standards i mentioned above so that these dyslexics can set the background for all of their wikipedia experiences.

I hope this is in the right place to make these observations, i have Auditory Processing Disorder as the cause of my dyalexia and i find working in WIKI a stressful nightmare

dolfrog (talk) 16:59, 11 June 2009 (UTC)

Icon

Does this project have some userpage icon? I'm usually not into those, but for this project, it'd really be worth it. You know, the kind of "this user uses Firefox, this user is an atheist" etc. It'd be a good way to spread the word. --Anime Addict AA (talk) 13:34, 11 September 2009 (UTC)

Wasting Time

I don't know how much time I waste because there aren't separate tabs for:

• Edit this page (article)
• Edit this page (discussion)
• History (article)
• History (discussion)

I have a really slow connection, and this drives people away. And this applies for templates. There should be 6 short cuts, not just those 3 view, edit, discussion letters.

You can't make a new section tab for articles, cause which headline would you use?

In view source pages, the new section tab doesn't even have to appear, since it would be impossible to add ANYTHING anyway.

I can't understand why there are a "million" blue links on the left, and 6 simple tabs can't be put into the web pages.174.3.98.236 (talk) 11:25, 8 February 2010 (UTC)

If you create an account (log-in) you can add this script (Wikipedia talk:WikiProject User scripts/Scripts/Six tabs) to your display (Special:Mypage/skin.js), which will do what you ask.

It's a common frustration, but having 6 tabs by default would overwhelm many potential new-contributors.

Hope that helps. -- Quiddity (talk) 19:37, 8 February 2010 (UTC)

Actually, I don't think this would be the case. I scares off people because some people choose not to register.174.3.98.236 (talk) 23:51, 8 February 2010 (UTC)

The argument is very tenuous.

I choose not to register, and requiring someone to register to use scripts is a form of elitism, which goes against the spirit of wikipedia.

It is likely not to cause confusion, considering the mass of links already ALWAYS visible, on every wikipedia page, not to mention the hidden huge logo that links to the main page, and also that people who edit already should have some kind of computer knowledge.

Like I said, what happens when people have slow connections; people who have little financial money, in some parts of africa, may want to edit wikipedia, but their internet connections are so poor that they give up on more, vigorous, contributions, because of this lack of functionality. This issue has been brought up many times and many people agree with this.174.3.98.236 (talk) 00:05, 9 February 2010 (UTC)

It's impossible to let anon-accounts use scripts, because there are frequently many people sharing a single IP address, and IP addresses aren't consistently assigned to the same user. If one anon wants a black background and white text, then everyone sharing that IP would be forced to use the same. There's nothing elitist about it at all!

Registering is actually more private than being an anon - nobody can tell what geographic region a registered account is editing from - versus an IP address, which anyone can perform an ip2location lookup on. -- Quiddity (talk) 19:34, 9 February 2010 (UTC)

The scripts themselves are not elitist. The fact that 6 tabs are not available to non registered is elitist. There is obvious consensus that 6 tabs is more useful than the current scheme.174.3.98.236 (talk) 23:26, 9 February 2010 (UTC)

There is not "obvious consensus" at all. Most editors do not have those extra tabs. I don't have the extra tabs, nor do I want them. There's nothing "elitist" about giving more options for customization to registered accounts than to IPs. Because it's customization, it only applies when you're logged in to your account; if customizations such as extra tabs were enabled for IPs, they would be the default, and who says everyone wants them? rʨanaɢ ^talk/_contribs 22:13, 17 February 2010 (UTC)

I might not have data to back up my claim, but nor do you.174.3.98.236 (talk) 16:44, 18 February 2010 (UTC)

I have an old account that was blocked: 100110100. This was 4 years ago. Is there anyway to unblock it? I'm very different now and the misconduct is something I don't do.174.3.98.236 (talk) 00:26, 9 February 2010 (UTC)

There's no reason to. If you want an account, you can create a new one. rʨanaɢ ^talk/_contribs 15:47, 9 February 2010 (UTC)

I would like the name back.174.3.98.236 (talk) 23:26, 9 February 2010 (UTC)

The IP has just been blocked for 3 hours for disruptive changes of list guidelines. Not a good start, and the original account has a long block history. However, the fact that he has acknowledged that might count in his/her favor. This isn't the place to ask though, the original account's talk page would be more appropriate. The account would keep the old block history. Dougweller (talk) 16:05, 11 February 2010 (UTC)

(Formatted in response to the above comment.174.3.98.236 (talk) 05:57, 14 February 2010 (UTC)) The talk page is blocked.174.3.98.236 (talk) 05:55, 14 February 2010 (UTC)

User talk:100110100 is not blocked. Do you remember the password to that account? If so, you can login and post a message to that talk page.--Father Goose (talk) 08:52, 14 February 2010 (UTC)

Usability of GeoTemplate

Comments on the usability of {{GeoTemplate}} (the page listing mapping services found by clicking on coordinates in articles) are invited, at Template talk:GeoTemplate#Usability redux. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:31, 17 March 2010 (UTC)

Ideal column width for references

The widely used Template:Reflist has a feature named colwidth, to determine the width of a references column (and therefore the number of columns on any given screen size). The current recommendation for the parameter is 30em ("em" is a flexible measuring unit, see also Em (typography)). That produces two columns on a 1280×720 screen, three columns on a 1366×768 screen, and four columns on a 1680×1050 screen. Is that recommendable from the usability perspective? --bender235 (talk) 15:54, 6 April 2010 (UTC)

As a second perspective, I've been preferring 25em, because this produces 2 columns on browsers which aren't quite maximised on 1024*768 screens; it only drops to one column once the browser gets down to about 800 pix wide. Quite what it does on very wide screens I don't know, since I don't have a large enough monitor to test them. I'm posting a note at Template talk:Reflist to inform them of this discussion. Modest Genius ^talk 16:11, 6 April 2010 (UTC)

I did some testing a year or two ago and decided 25em was best (at that time). According to most typography textbooks a line should contain about 40-60 characters (including whitespace and periods etc) or it becomes hard to read. Now with newer browsers and a new stylesheet it might have changed though. Since the reflist and main content area use different text size it becomes more or less impossible to achieve this with both the reflist and content area though, a point I have (unsucessfully) been trying to make before. :)Apis (talk) 19:08, 17 May 2010 (UTC)

I really think a larger width for each column (maybe 40 or 50em) would be better. I keep running into refs that take up an extra row for a small bit of text. If a line should contain between 40-60 characters and 1em is the largest possible width of a character, it seems about right.
--Gyrobo (talk) 20:04, 20 May 2010 (UTC)

The "1em is the largest possible width of a character" is a bit shaky, as it always depends on the typeface, but even assuming that were exactly the case, we'd still have to recognize that few sentences consist of all uppercase W's or M's (and, well, thank God for that). Most characters in a proportional font are going to be much smaller (I believe "W" is larger), so a smaller number of ems would be appropriate if you're targeting a certain number of characters per line (cpl).

You (Gyrobo) mention the premise (which may not be what you believe) that a line should contain between 40-60 characters. I have seen 66, 72, and 75 cpl mentioned often, so the 40 cpl sounds quite small. I have also seen 12 words per line (wpl) mentioned as closer to an "ideal line length". In that case, we have to figure out some average number of characters per word. I'll leave that for others, although my game-show guess is "6". No, 5. No, wait: 6. Well, if I win the jackpot with that guess, it suggests 72 to 84 characters (incl. spaces) on a line, which are somewhat large relative to, say, 66 cpl. So probably I should have guessed "5" or googled for actual data.

With 72 cpl, though, a matching col width setting would be more like 45em (I use 5/8, or .62, based on some Lorem ipsum tests I've done). 30em gets us something like 48 cpl; 25em about 40 cpl.

Of course, this is just a rough bunch of numbers without the real research that ought to be put into it; maybe I can make time to do it better in the next few days. What also needs to be remembered is that readability depends not only on column width/line length, but also linespacing, font size, typeface, and paragraph length. For refs, we could say we have short paragraphs, but that's only true when some spacing is evident between citations. And that usually only happens when the last line in a citation is incomplete, that is, when it noticeably fails to use a complete line's space. In this sense, the readability is enhanced when, as you say, the last line contains only a small amount of space. And yes, that means space efficiency (and paper usage, for articles printed out) is worse.

I'll try to look at this some more. — JohnFromPinckney (talk) 15:53, 29 October 2010 (UTC)

I've been asked to comment here by Bender, as I created the {{column-width}} template. I used the most prevelant value used in {{reflist}} of 30em as a default, not knowing anything about the recomendations. To have an informed consensus, perhaps it is best to demonstrate the effect of several values, and to explain how the width is actually calculated. Here are the examples of all the suggestions above:

This is 20em.

This is 25em.

This is 30em.

This is 35em.

This is 40em.

This is 45em.

This is 50em.

These are the basic renditions using the default font-size. As you know, using 'em' as a measure depends on the font-size. Since references use a smaller font of 90% (when using {{reflist}}, and also dependent on browser settings and personal CSS settings), this will affect the column-size as well, but will by defention contain the same ammount of text on a line.

This is 20em.

This is 25em.

This is 30em.

This is 35em.

This is 40em.

This is 45em.

This is 50em.

The column-width CSS property is also the minimum column-size. In other words: columns will never be smaller then the given value, and can be up to twice the given width. Here are columns with the four given values:

• This is 20em.
• This is 20em.
• This is 20em.
• This is 20em.
• This is 20em.
• This is 20em.

• This is 25em.
• This is 25em.
• This is 25em.
• This is 25em.
• This is 25em.
• This is 25em.

• This is 30em.
• This is 30em.
• This is 30em.
• This is 30em.
• This is 30em.
• This is 30em.

• This is 35em.
• This is 35em.
• This is 35em.
• This is 35em.
• This is 35em.
• This is 35em.

• This is 40em.
• This is 40em.
• This is 40em.
• This is 40em.

• This is 45em.
• This is 45em.
• This is 45em.
• This is 45em.

• This is 50em.
• This is 50em.
• This is 50em.
• This is 50em.

What I see on my screen (1280 wide and default font settings on Windows) is 25em and 30em displaying 3 columns, 40em giving 2 columns, and 50em results in only one column. But this can be different for other users, depending on their own browser font settings and personal CSS. So it should be up to you to choose what seems the best value. Have a look and resize your browser window to see the effects. Personally, I prefer 30em. Cheers. — Edokter • Talk • 01:01, 28 October 2010 (UTC)

Thanks, Edokter. This exploration using blue shaded backgrounds to represent widths seems designed to address only the bit of confusion about how many columns one might see. However I think (I mean I feel) that the number of columns has little impact on usability; surely what's more important is the length of a text line and how hard it is to follow the text from line to line while reading. These examples with 13 characters (incl. spaces) per line with only a few lines won't tell us about that. — JohnFromPinckney (talk) 15:53, 29 October 2010 (UTC)

There's currently a followup to this at Wikipedia:Village_pump_(proposals)#Recommending_columns_in_reference_lists_longer_than_20_entries. Rd232 ^talk 08:38, 15 December 2010 (UTC)

There seems to be a Firefox bug that prevents the examples other than 20em (and possibly 50em) to work properly on a 1080p screen (Firefox 3.6.13 on Windows 7). I don't normally read web pages like that because the lines are way too long, but I tested this page and I only get a correct look for the 20em example (gives me 6 equal columns). For the 25 and 30em, I get 3 columns, and the last one has the wrong size. For 40 and 45em I get only 2 columns, and the last one has the wrong size. Only 50em seems to balance two columns. So, you may want to do some testing before mandating wiki-wide implementation and the like. Tijfo098 (talk) 12:27, 20 December 2010 (UTC)

Proposed change to the tag line

Copied from this thread at Jimbo's talk page.
On all pages that are not protected/semi-protected, the tagline should read: "From Wikipedia, the free encyclopedia. You can edit this page." followed by a button marked "edit" linking to a very short, simple few sentences about how to, and a link to the Talk and Edit pages of the article. That, alone, would double the editor activity overnight. I think that would be a good thing. Anthony (talk) 18:20, 30 May 2010 (UTC)

Call me an elitist, but I don't know if we really want to generate an income of editors which are still unable to understand that anyone can edit Wikipedia after so many years of its existence and the subtitle in the main page. --Cyclopia^talk 19:22, 30 May 2010 (UTC)

If we make it easy and obvious, stupid people might start editing? Interesting hypothesis. Only one way to find out, and it could be undone. Anthony (talk) 20:15, 30 May 2010 (UTC)

This is all quite interesting and should be raised with the usability team. Based on my non-Wikipedia experiences (at Wikia), encouraging more people to edit does not result in a reduction in quality, so I disagree with Cyclopedia's view. But, in the end, it is, as Anthonyhcole says, an empirical question. Most things are. :-) --Jimbo Wales (talk) 22:59, 30 May 2010 (UTC)
End of excerpt.

Are there any technical barriers to this? Anthony (talk) 13:01, 31 May 2010 (UTC)

I don't think this is the appropriate page to ask. Try WP:VPT for the technical end, and MediaWiki talk:Tagline + WP:VPR for consensus to change. HTH. -- Quiddity (talk) 18:58, 31 May 2010 (UTC)

Thanks Anthony (talk) 19:36, 31 May 2010 (UTC)

RfC on Consensus

Given WP:CONLIMITED, to what extent and under what circumstances can individual WikiProjects and users customize article appearance with individual styles that deviate from site-wide style guidelines? Interested contributors are invited to participate there. -- Quiddity (talk) 19:19, 30 June 2010 (UTC)

Navigation menus

Hi all. I'd like to propose a new project for this WikiProject Usability. I suggest to work with the Wikipedia:Help Project on greatly improving the navigation menus in help pages. That would make it really easier for newbies to get involved. Thus increasing participation.

Context of this proposal

The two major usability issues on Wikipedia (that makes it hard to edit) are:

1. Complexity of wikisyntax: you just want to add a few words to an article and you get 30% of text lost somewhere in the 60% of code you don't understand.
2. Help pages and tutorials are many (too many in fact). But they're so baldy structured and unorganized that the user get lost after a few clicks. There are small pieces of menus scattered throughout the help namespace without coherency. Also, the user doesn't know when he should stop reading. It's not always indicated which pages are a necessary step to begin. And it's almost never indicated which pages are further reading or pages for advanced users.

The Usability Initiative did not manage to increase participation yet. They knowingly decided to begin with several easier improvements of reduced impact. They are currently working on template folding. The Multimedia Initiative and Liquidthreads are going to solve major usability issues.

But nobody is taking care of major usability issues produced by editors. I'd like to show there is a need to employ a usability expert to guide this usability project. And first we need to demonstrate the potential of this project. :-)

How are we going to achieve that

I can provide references, make a comprehensive tutorial, and evaluate the changes being made. But I can't do more since I'm already working on the accessibility project right now and the number of help page is enormous. So we need to form a task force. Users from this project plus the help page project plus volunteers gathered with an announcement (Signpost?) should do the trick.

I already made a few improvements to Wikipedia:WikiProject Usability/Areas, and especially Techniques for navigation menus.

If you want to have a look at what such a menu could look like, take a look at the WikiProject Accessibility.

So: who is interested and wants to volunteer to give a hand - even the slightest occasional hand? Kind regards, Dodoïste (talk) 02:11, 13 September 2010 (UTC)

There's an overview of previous and work-in-progress menus at Wikipedia:Help Project/Overview which [hopefully] makes things a little clearer as to how we got where we are! There has also been talk of a article complexity scale in the past, which hasn't been implemented yet ( e.g. Wikipedia_talk:Help_Project/Overview#Article_complexity_scale ). The trouble is with the help pages, it easy to get distracted when one finds a page or set of pages that needs dire attention... but there's lots of occasional editors on random pages and a dedicated core of others and things are improving... Lee∴V (talk • contribs) 09:26, 13 September 2010 (UTC)

We also have Help:Help and Help:Getting started which aim to make the system clearer for users, but they are not fully integrated yet - i.e. not really the first links one gets to... Lee∴V (talk • contribs) 09:52, 13 September 2010 (UTC)

Thanks for the links. They are interesting from a historical point of view.

So, are you willing to give a hand on this task? If at least one user is enthusiastic about it I'll make a tutorial. Otherwise I'll take care of it later. Dodoïste (talk) 16:58, 17 September 2010 (UTC)

Readability issues and small text size

I just made a quick draft out of the explanations I gave here and there about this issue at Wikipedia:WikiProject Usability/Readability guidelines. This project does not yet address readability issues, despite readability being an very important component of usability. I'd like to have your comments on that, and see if some project members are interested by this issue. If so, we could make a proper guideline out of it and enforce it. Dodoïste (talk) 01:01, 29 September 2010 (UTC)

I'd like to point out two things about this issue (and thanks to Dodoïste for raising it here as well as for his work in moving WP accessibility efforts forward):

1. When we specify that some text (for example, column headings on music artist discographies) should be 75%, we are saying that we want the text — column heading text, no less — to be 25% smaller than what the user has specified as his/her preferred font size or, in the case of those who passively accept their browser's defaults, 25% smaller than what the user is used to for standard text. I believe this not only makes the page less readily usable, but it's also damned rude of us.
2. The Readability guidelines pointed to by Dodoïste above includes the sentence (near the end), "Usability guidelines recommend a default font size of at least 12 points (about 16 pixels, but pixels are evil)." I think pixels are okay, but my computer sure goes through a lot of them. More seriously, I presume Dodoïste refers to the problems when specifying font sizes in px units, which I don't deny. However, I'd like to point out that specifying sizes in points when creating Web content is appropriate only for printing, since (AIUI) what my computer does with a size spec in points depends on my display and resolution settings. With the possible exception of discussions related to our CSS stylesheets for print media, I'd like to see us drop talk of points or pixels in favor of em units, or percentages. (I realize Dodoïste has pointed to an experiment which talks in terms of point sizes, but I'd hope to keep our focus on what we should/shouldn't specify, even if the discussion uses other measures for what's usable.)

Regards. — JohnFromPinckney (talk) 02:12, 29 September 2010 (UTC)

Thanks for your useful comments.

1. Yes. Could you rephrase my draft to make it clearer? Sadly my English is not that good, so I have a hard time to express nuances or subtle explanations.
2. Point taken. :D You're absolutely right, and I shared the same thought. But I just don't know how to solve this easily. If I can find a usability reference that indicates the conversion into such formats for the Web, that would be perfect. Otherwise it will require a bit of experiments to find the correct values by testing.

Kind regards, Dodoïste (talk) 13:20, 29 September 2010 (UTC)

Yes, I'd be glad to help, on both counts (although your English is very good). Any real help will take a while, though, since I'll be away for a few hours tonight. That pesky Real Life intrudes again. — JohnFromPinckney (talk) 14:29, 29 September 2010 (UTC)

Such nice words. Thanks. :-) I just added a few examples using ems and relative sizes. Oh by the way, the only real life is Wikipedia. And our virtual life sure gets often in the way. I may well hate my virtual life as much as non geeks, it's only a matter of perspective. :D Dodoïste (talk) 19:31, 29 September 2010 (UTC)

Proposal for post-highlighting CSS feature

See Wikipedia:Village pump (proposals)#Add projectwide css to highlight different posts in a discussion.

As this concerns a proposed usability change, I invite any interested parties to provide input at the above thread. /ƒETCHCOMMS/ 03:36, 29 September 2010 (UTC)

Template update: em and strong

I've updated Template:Strong and created a matching Template:Em. These not only make it easier to use the <strong> and <em> which can be styled differently than non-semantic boldface and italics, the templates should also thwart the ability of the average bot or WP:AWB run to turn intentional semantic use of the strong and em elements into wikimarkup plain bold and italic. I've already found one bot (Yobot (talk · contribs)) that has been making invalid changes of this sort, and have asked the operator of the bot to make it stop doing that, but inevitably there will be other bot authors and various random editors, who (manually and with AWB) will make such changes because they don't understand Web semantics and separation of content and presentation. These templates should put up at least a minor barrier to willy-nilly undoing of semantic markup. And it's a little easier to type {{{em|whatever}} than <em>whatever</em> (and only three characters longer than ''whatever'' so there's not much excuse for not using {{em}} when intending emphasis instead of purely typographic (book titles, etc.) italics. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 10:18, 29 September 2010 (UTC)

I replied first at the accessibility project since I saw it there first. Plus, this is an accessibility issue, and has little to do about usability. I see you are interested in semantics, XHTML, and such so you'd better join the accessibility project. Usability is about being easy to use, intuitive, affordance, pretty, useful and so on, it's not about code at all. Yeah, this very project is very confused about what is usability as of now, and making it clearer is definitely on my to-do list but it will have to wait.

Seeing your extended reply I believe I misunderstood your message. Anyway, let's continue at the accessibility project talk page. Dodoïste (talk) 13:02, 29 September 2010 (UTC)

Color subpage

Back in December 2006, User:Quiddity marked as "{{historical}}" Wikipedia:WikiProject Usability/Color (a page I have just now encountered for the first time, via googling). Since that time, Dodoïste has made a series of constructive edits to the page, and has done so above the "historical" warning. (Indeed, the latter now looks as if it is given as an example of the good use of color, combined with a discreet border.)

It's not obvious to me that the page should be marked as "historical". It never was, and still is not, much edited; but it shares this with many other pages. It's part of this WikiProject, which is not obviously inactive. It does not purport to be a project-wide guideline. (If it did, I'd want to tinker with it; but even without tinkering, I think it would be a net plus.)

The template says: "Either the page is no longer relevant, or consensus on its purpose has become unclear." Coloring of text and background within WP will always be relevant to WP. The purpose of the page seems clear enough (and commendable to boot): nudging toward clarity and legibility. So I suggest that the template should be removed.

(I'm inclined just to go ahead and remove it, but I'm instead gritting my teeth and going by the rulebook here.)

Though Quiddity and Dodoïste are both members of this Project, I'm alerting them to this message of mine. -- Hoary (talk) 07:38, 1 May 2011 (UTC)

I do believe that most of the content at Wikipedia:WikiProject Usability/Color can still be useful. The page should be restructured and detailed, but most of its content is fairly accurate. Cheers, Dodoïste (talk) 11:51, 1 May 2011 (UTC)

I now notice that Quiddity is away on a break. Pity.

If anyone objects to removal of the template, I'm most willing to read and consider and perhaps be persuaded by their argument. But I suggest that if nobody objects within two weeks, one of us should remove it. -- Hoary (talk) 10:06, 2 May 2011 (UTC)

Succession boxes

We're discussing the use of colours in succession boxes over at WT:SBS. Some input in regard to Usability and Accessibility would be appreciated. Thanks. Bazj (talk) 12:48, 1 May 2011 (UTC)

Two-dimensional tables of content

We are having a discussion at TfD about Template:Imperial election TOC, which is a single-purpose table of contents template. In particular, another user and I are disagreeing over whether this specific ToC template improves or impedes the usability of the article.

I would very much appreciate comments and constructive criticism from anyone who has a strong feeling on the accessibility and usability of the article, particularly around the use or deletion of this template. It's worth reading the whole discussion, but the three main suggestions so far have been as follows:

1. [1]: The status quo, with a two-dimensional ToC provided by a bespoke template
2. [2]: A standard hierarchical ToC, separated by centuries
3. [3]: A standard hierarchical ToC, with no H3 separation

Any opinions on how best to handle the ToC in order to optimise the usability of the article — not necessarily limited to these three suggestions — would be gratefully appreciated. — OwenBlacker (Talk) 11:19, 23 July 2011 (UTC)

New template requested — Discreet abbreviation

Hello,

See this discussion.

--Nnemo (talk) 00:09, 25 September 2011 (UTC)

Disabling of preference for wikieditor

A patch has been merged into mediawiki which removes the preference for enabling/disabling the WikiEditor and enables it for all by default. A discussion regarding this is ongoing at Wikipedia:Village_pump_(technical)#Disabling_of_preference_for_wikieditor. All users are requested to comment.--Siddhartha Ghai (talk) 08:24, 7 April 2012 (UTC)

RFC on image categorisation

The RFC at Wikipedia_talk:WikiProject_Categories#Image_categorisation is of some interest to this WikiProject. -- Alan Liefting (talk - contribs) 13:31, 10 June 2012 (UTC)

Text on category pages

The usability of some category pages id under discussion at Wikipedia_talk:Categorization#Text on category pages. -- Alan Liefting (talk - contribs) 01:01, 12 June 2012 (UTC)

Color

I've removed the {{historical}} tag from Wikipedia:WikiProject Usability/Color, per the archived discussion. I don't remember what perspective I was bringing to that original decision to tag it as such (in 2006). I'm sure my intentions were great! Probably related to other pages duplicating the information, in a more high-traffic (more visible, and likely to be used) location?

Anyway, these appear to be the current guidelines regarding color. Any efforts should be towards aligning them, and minimizing redundancies. -- Quiddity (talk) 23:25, 25 July 2012 (UTC)

• Wikipedia:Manual of Style/Accessibility#Color - (WP:COLOR)
• Help:Using colours - (WP:COLOURS)
• Wikipedia:Manual of Style/Text formatting#Color
• Wikipedia:Link color
• Wikipedia:Don't edit war over the colour of templates

Potential collaboration/taskforce/WikiProject

Gauging interest I am posting the same message to Wikipedia talk:WikiProject Images and Media, Wikipedia talk:WikiProject Usability, and Wikipedia talk:WikiProject Accessibility to see if there is interest in a collaboration regarding adding subtitles to audio. Recently, the TimedText namespace became active and I decided to test it out with two subtitles: TimedText:Sufjan_Stevens_-_Casimir_Pulaski_Day.ogg.en.srt for File:Sufjan Stevens - Casimir Pulaski Day.ogg and TimedText:They_Are_Night_Zombies!!_-_Sufjan_Stevens_-_clip.ogg.en.srt for File:They Are Night Zombies!! - Sufjan Stevens - clip.ogg (someone else has created TimedText:Björk_-_Mutual_Core_sample.ogg.en.srt for File:Björk - Mutual Core sample.ogg as well.) I also worked with Rich Farmbrough (talk · contribs) to create {{Subtitles}} and categorize audio files with subtitles. This leaves 7,087 audio and video files which lack subtitles (note that not all need them as some have no spoken audio.) Does anyone want to help me? —Justin (koavf)❤T☮C☺M☯ 19:18, 5 November 2012 (UTC)

Wikipedia:User Advocacy

Folks watching this page may be interested in the Wikipedia:User Advocacy effort. --RA (✍) 22:20, 9 July 2013 (UTC)

Comment on the WikiProject X proposal

Hello there! As you may already know, most WikiProjects here on Wikipedia struggle to stay active after they've been founded. I believe there is a lot of potential for WikiProjects to facilitate collaboration across subject areas, so I have submitted a grant proposal with the Wikimedia Foundation for the "WikiProject X" project. WikiProject X will study what makes WikiProjects succeed in retaining editors and then design a prototype WikiProject system that will recruit contributors to WikiProjects and help them run effectively. Please review the proposal here and leave feedback. If you have any questions, you can ask on the proposal page or leave a message on my talk page. Thank you for your time! (Also, sorry about the posting mistake earlier. If someone already moved my message to the talk page, feel free to remove this posting.) Harej (talk) 22:48, 1 October 2014 (UTC)

UX job openings at WMF

Hi, There are currently some job openings in the WMF's UX team, that I thought might be of interest to someone here, or you might know someone to nudge. Hope that helps. :) Quiddity (WMF) (talk) 01:55, 28 October 2014 (UTC)

WikiProject X is live!

Hello everyone!

You may have received a message from me earlier asking you to comment on my WikiProject X proposal. The good news is that WikiProject X is now live! In our first phase, we are focusing on research. At this time, we are looking for people to share their experiences with WikiProjects: good, bad, or neutral. We are also looking for WikiProjects that may be interested in trying out new tools and layouts that will make participating easier and projects easier to maintain. If you or your WikiProject are interested, check us out! Note that this is an opt-in program; no WikiProject will be required to change anything against its wishes. Please let me know if you have any questions. Thank you!

Note: To receive additional notifications about WikiProject X on this talk page, please add this page to Wikipedia:WikiProject X/Newsletter. Otherwise, this will be the last notification sent about WikiProject X.

Harej (talk) 16:58, 14 January 2015 (UTC)

Accessibility versus convenience in indentation (RfC at VPPOL)

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia:Village pump (policy)#RfC: Accessibility versus convenience in indentation

While primarily framed in terms of accessibility and the avoidance of WP:POLICYFORKs, this also has usability angles (from both directions: editorial convenience versus WP:REUSE and other circumstances in which semantically correct code is important).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  13:41, 3 December 2017 (UTC)

WikiProject collaboration notice from the Portals WikiProject

The reason I am contacting you is because there are one or more portals that fall under this subject, and the Portals WikiProject is currently undertaking a major drive to automate portals that may affect them.

Portals are being redesigned.

The new design features are being applied to existing portals.

At present, we are gearing up for a maintenance pass of portals in which the introduction section will be upgraded to no longer need a subpage. In place of static copied and pasted excerpts will be self-updating excerpts displayed through selective transclusion, using the template {{Transclude lead excerpt}}.

The discussion about this can be found here.

Maintainers of specific portals are encouraged to sign up as project members here, noting the portals they maintain, so that those portals are skipped by the maintenance pass. Currently, we are interested in upgrading neglected and abandoned portals. There will be opportunity for maintained portals to opt-in later, or the portal maintainers can handle upgrading (the portals they maintain) personally at any time.

Background

On April 8th, 2018, an RfC ("Request for comment") proposal was made to eliminate all portals and the portal namespace. On April 17th, the Portals WikiProject was rebooted to handle the revitalization of the portal system. On May 12th, the RfC was closed with the result to keep portals, by a margin of about 2 to 1 in favor of keeping portals.

There's an article in the current edition of the Signpost interviewing project members about the RfC and the Portals WikiProject.

Since the reboot, the Portals WikiProject has been busy building tools and components to upgrade portals.

So far, 84 editors have joined.

If you would like to keep abreast of what is happening with portals, see the newsletter archive.

If you have any questions about what is happening with portals or the Portals WikiProject, please post them on the WikiProject's talk page.

Thank you.    — The Transhumanist   11:02, 31 May 2018 (UTC)

Proposal to revamp the left sidebar

Hi all! I've been taking on a number of usability-related initiatives recently, such as redesigning the main welcome template to streamline it. I'm thinking about taking on a pretty major task next — trying to build a consensus to revamp the links in the sidebar that appears at the left of every page to improve usability and ease of navigation. I posted about it (including a bit of historical context) to test the waters at the Village Pump Idea Lab, but to take it further, it'd be nice to have collaborators to help craft a solid initiative. Would there be anyone here who might be interested in joining me for that? Or, if this project is as quiet as it seems, is there anywhere else I ought to turn? Sdkb (talk) 06:27, 30 March 2020 (UTC)

RfC: 2020 left sidebar update

 Following a half-month incubation period at the Village Pump Idea Lab, a major RfC has been launched consisting of a series of independent proposals to modify the sidebar located on the left side of every page in the desktop default skin view of Wikipedia, aimed at improving usability and ease of navigation. You are invited to join the discussion at Wikipedia:Requests for comment/2020 left sidebar update. {{u|Sdkb}} ^talk 21:51, 10 April 2020 (UTC)