Talk:Main Page/1

From Wikimedia Usability Initiative

Project Scope

Wikipedia only?

Is this initiative for Wikipedia only? Isn't (or shouldn't) it actually for Wikimedia as a whole? ;-) --- Best regards, Melancholie 22:22, 21 January 2009 (UTC)[reply]

Keep in mind that this is a grant, so we can't decide on how to spend the money... it needs to be spent within the terms of the grant or we don't get it. Based on that, one would assume the primary focus is on Wikipedia. However, what is realized could probably be applied to other projects (or even tested on them too, who knows? ;-)). Cbrown1023 talk 22:40, 21 January 2009 (UTC)[reply]
But still, there is a point about that question. Of course, the terms of the grant have to be respected. However, when Wikipedia's usability is being improved, some issues have to be elaborated further. What part of the scope is on the underlying Wikimedia software? If the scope expands beyond the software of Wikipedia, does it also go into the parts of the content contributed by the regular editors? Usability is also about stuff like the content and layout of the homepage, category names and structure, other navigational elements and concepts, integrated help, graphical elements, etc. Some or all of those are usually open for contributions from volunteers. If the results of the project and the drive of the community in these particular areas are contradictory, how are these settled? Not that there are no ways to handle any particular case, but I think there should be some extra effort to establish and articulate the project's framework to the community. On this page, for example. Yuzz 03:15, 22 January 2009 (UTC)[reply]
Agreed. I think they have to clear the project scope first (or actually create one - this is a torso). We will be hardly forking a new version of MediaWiki specially for Wikipedia... So I guess the work done on MediaWiki in scope of this project must be mirrored in other projects. Did the donor know that Wikipedia is only one of Wikimedia projects and how it is bound to MediaWiki?--Kozuch 14:20, 26 January 2009 (UTC)[reply]
When you look at what kind of people will be hired for this project, it become clear that this is about the MediaWiki software with a clear focus on the English Language Wikipedia. GerardM 15:51, 26 January 2009 (UTC)[reply]

Language

Vocabulary/terminology/glossary

I would like to see dealt with the confusing way we talk about Wikipedia, with different names for the same thing. Like "talk page" - which has the name "discussion" on the article side of a page.--Ziko 23:17, 21 January 2009 (UTC)[reply]

It is worth evaluating the terminology used for the menu through the usability testing. --Shuhari 23:13, 3 February 2009 (UTC)[reply]

Basic ideas and wishlists

My two cents

Hi, I want to share my little ideas:

  1. Change the "edit" tab to "modify". In Spanish "editar" is a very formal verb. Perhaps "modificar" would be better.
  2. Add a link in the top or bottom of articles with this text "Submit an error or suggestion" targeting to "/w/index.php?title=Talk:blabla&action=edit&section=new". It would be a good way to improve the feedback with sporadic readers. People don't know that clicking in "Talk" tab they can suggest changes in content.
  3. Add a request link in all categories, to include new articles. A new way to request articles.

Regards. Emijrp 11:12, 22 January 2009 (UTC)[reply]

Terminology is very much a subject at Betawiki. When a certain word is to be used in preference to another in a language, Betawiki is the place where such changes are made. Thanks, GerardM 15:55, 22 January 2009 (UTC)[reply]
The Cologne Blue skin for example has a "add section to talk page" link alerady. So, whether or not it is shown depends on CSS and skin, I believe. --Purodha Blissenbach 14:31, 28 January 2009 (UTC)[reply]

Another shopping list:Talk, Discuss, History

Issues I find unhelpful on editing and commenting.

  • When editing, you are requested to: (1) make a note of the reason, (2) declare it as Minor (or not) and (3) sign with ~~~~. It is easy to overlook/forget any or all of these.
  • When reading a Discuss/Talk page, there are frequently discussions several years old, relating to the content of the page at that time which are no longer relevant.
  • When you are finished editing, press the left hand "Page" button, you are returned to the definitive page. But, when you are finished discussing, and press the same button, you are returned to the Discuss page not the actual Wikipedia page. (This is because technically the Discuss/Talk page is a page in its own right)
  • When you are finished editing, look at the modified page, and decide it needs editing further, this becomes two (or more) entries on the History.
  • When you look at the list of changes under "History", frequently the "First 50" only shows a few days of changes, because there are large numbers of tiny edits. You have no way to see when the major changes were made.

Here are some simple (I hope) suggestions followed by more radical ideas.

  1. The Wiki software to count keystrokes processed in the edit, and use this to determine automatically whether the edit is "minor". For example, 200 keystrokes may edit or add a sentence or two, a larger number would be a paragraph and a small number might be a spelling correction.
  2. The Wiki software to insert the user's ID name (or IP address?) plus date, at the foot of the edit box, (with the user having the option to edit if they really want).
  3. When you have chosen "Edit this page", the edit box should show the text of the page, not including the data on categories, templates, and all the other garbage that gets in the way. This should be in a separate edit box clearly marked, or if it has to be kept together then show the 'meta' information in a contrasting colour (cyan?)
  4. Where a user has edited the article several times in a short time, these to be displayed on "History" as a single edit by that user. I would propose "short time" is defined as any series of edits, by the same user/IP address, where the interval between edits is less than 2 hours and no other user has edited in between. Note: in entering this section, I have edited the page 5-6 times. Clearly it was functionally one edit and there is no benefit in archiving the intermediate stages.
  5. Talk/Discuss pages to have a different appearance from regular pages, aimed at the different way they are intended to be used, and a direct and obvious link back to the discussed article.

More radically, the History and the Talk/Discuss need a major overhaul, preferably by bringing the two concepts closer together, so that the interested onlooker can see what changes were made and for what reason: without being swamped by data on minor spelling or punctuation edits, and without being swamped by discussion on changes people would wish to see, would disagree with, were made years ago, etc. Sussexonian 13:00, 5 September 2009 (UTC)[reply]

MediaWiki usability wishlist

I guess the word "Wikipedia" in the project description is a mistake. The usablity is about MediaWiki and hence about ALL Wikimedia projects. I think integrating currently existing gadgets directly into MediaWiki would be interesting too.

Here is my MediaWiki usability wishlist (others feel free to add stuff):

  • spellchecker
A spell-checker is part of a modern browser.. just try the add-ons. There is software that does provide improved usability for discussions. It just needs adopting. Thanks, GerardM 15:53, 26 January 2009 (UTC)[reply]
  • a non-wiki UI for discussion pages - wouldnt something like forum posts be better? Often, newbies unfamiliar with the wiki-markup want to ask and they do not know how (like I didnt).--Kozuch 14:09, 26 January 2009 (UTC)[reply]
Agreed - the current system is not ideal for clear discussion management. Witty lama 03:42, 13 February 2009 (UTC)[reply]
mw:Extension:LiquidThreads [1] --Church of emacs talk 10:16, 23 February 2009 (UTC)[reply]
I agree! Helder 18:00, 3 March 2009 (UTC)[reply]
  • Slightshows for image galleries
  • Offering multiple bit-rates for streaming video files
  • A more intuitive article "history" function that scrolls through the previous versions smoothly. Finding a particular revision now is a matter of trial and error with a non-intuitive radio-button system.
  • Syntax highlighting or WYSIWYG-like editing for text and page layout.
  • A pop-up box to enter a reference/footnote that then automatically formats the code for you. Same thing for Templates and Tables.

Several suggestions

i18n an L10n:

  1. Interface messages: There are plenty of words, expression, phrases, that could be translated this way or another for a given language (e.g. user, contributor, reader, {{NS:2}}, …). There are references being made from one message to another (select parameters and klick <button text> where button text is as well contained in a message on its own).
    We could have a sort of precompilation step that allows to include such stuff by reference, thus making it much easier to adopt to varying names, depending on Wiki, or adopt changes made in one place everywhere. This will, imho significantly increase the quality of localizations and thus the usability and understandability of interface messages.
  2. There are plenty of places where wikicode, html entities, or language tagging (<span lang="zxx" xml:lang="zxx">…</span>) of — normally untranslated ubiquitous english computerese words or expressions — would be required in interface messages, but are prohibited in a localizations because these items are rendered verbatim. This needs to be generally modified so as to render flawless (x)html, and to make life easief to localizers, and to allow page contents be correctly referenced in search engines. This increases Wikipedias usability both direct, and indirectly.
  3. Allow interface messages, and help pages, to branch depending on both skin, and current rtl/ltr mode of the actual page, so as to allow better targetted messages of the kind Follow language links at left/right/upper/lower edge of the current browser window. etc.
  4. add a "sticky" equivalent of uselang= to the command line to as to allow logged out users and link setters to confine readers or themselves to a language of their choice while following links inside the wiki and following interwiki links until they actively change the language.
  5. See https://bugzilla.wikimedia.org/show_bug.cgi?id=17246

Help

  1. Help pages very often do not really reflect reality, and with the exception of the 5 major languages, are not at all, partially, or poorly translated. Settings of the wiki are hardly ever taken into account, worst visibly in the realm of user rights, or when extensions are being used that exend the wikis capabilities, but never bring the appropriate help pages with themselves.
    I suggest to have a general system of extensible help pages that (e.g. with the assistance of parserfunktions or some similar techiques) fully automatically adopt to wiki settings (usually in Localsettings.php) including extensions. There also should be a set of hooks to automatcally include, or link to, local policies (e.g. users having the right to delete pages see basic help on page deletions, plus (linked or inserted) what the local policies of page deletions are; while users not permitted to delete pages read about the policies and what to do in order to make others, (admins) delete a page for them, but do not (normally) read of the things they cannot do anyways).

Editing

  1. Consider using a "gloabl edit button".
  2. The "edit" page is crowded and cluttered with overwhelming amounts of superfluous unused information. While it is of course necessary to inform users of their rights and so on, there is no need to bang them on their heads each time a page is edited, by the way forcing them into time consuming scolling before every edit. They can be reminded every now and then, or if terms were changed, but they should be left alone otherwise, at least upon request. Custom CSS is fine, but requires advanced skills that most haven't.
  3. Add an "inspect wikicode" tab. Of course that is the same as "edit"+don't save, but many do not understand that, and fear to use "edit" in order not to accidentally screw something up.
  4. Skin cologne blue with "floating" sidebar has an overlap of the editing field with the side bar which should better be avoided.
  5. Enhancing and simplifying things during editing:
    1. Wiki syntax highlighting or color coding might be helpful in the edit window (unfortunately there is no way to do that with browser standard without pressing a "syntax highlight" button.
    2. Wiki syntax hiding, i.e. collapsing lengthy items like tables, might be an option, too. Again it's hardly possible with standard browser means. ;-(
  6. linking wiki code is a mess:
    1. Drop the quasi-but-only-partial-and-then-not-always syntactical identity of true (clickable) internal links, media transclusions, interlanguage links, interproject links, and foreign interwiki-links. They've been a design flaw from their very beginning, and drive unexperienced editors nuts. "Accidental" interwiki/interlanguage links are among the most persistent editor errors. Even MediWikis own coders cannot avoid them, and may be unable to correct them (bug 11344)
    2. For skins distinguishing internal and external links, make that distinction based on reality rather than syntax. Having to use a fullurl occasinally for links to the own wiki is bad enough, but it should not appear as an external link. Allow copy&paste URLs of, e.g. "edit-diff" pages in wikitext without having to resort to "span class=plainlinks", etc.
    3. Some interlanguage links, many interproject links, and some internal links are currently not portable between wmf projects, and even less so to other wiki outside the wmfs realm. While this may not be always possible with the outside world, increase the portability, and make it 100% between wmf wikis. Allow, e.g. user pages of one user, linking to all his or her user pages elsewhere, to be copied 1:1 between all wikis of the wmf, without invalidating a single link in them, even if none of them is using an external link syntax.
    4. Allow the "pipe followed by empty" syntax to strip leading "#"s (at least), such as in [[#Section 2|]] → [[#Section 2|Section 2]]. (see bug 17675)
  7. Solve bugs 15345 and 14880 and add the category picker gadget that Commons has to Wikipedia.

Searching

  1. Add a 2nd type of search field that can be used in the side bar, having two sets of radiobuttons, or a set of radiobuttons + a checkbox, allowing to select an (even numbered) namespace, plus object/talk, and do the Ajax autocompletion accordingly. Allow installations to select either or both search groups.
  2. at the end of the list shown by the Ajax search feature, add a selection to advance a page alphabetically - thus in the end leaving it to users to page to the very end of all available page titles.
  3. make the size of the Ajax search list selectable in the user preferences (both width, and line count) with reasonable upper, and lower, limits.
  4. Allow multipe redirects (with some upper limit on chain lenghts installable via LocalSettings.php) and show the chain of redirects when the target page is displayed.

Page Rendering

  1. add an outdent (without bullet, that is) inside nested lists. This would allow to continue on a previous indentation level after a sublist or indentation, which currently works only on the zero-th level of indentation.
  2. add a javaskript allowing to select an arbitray word, or group of words, and have them automatically searched for in the wiki — or alternatively — make every word that is not a link already, and that can be found in the remaining pages of the wiki (as to be searched by default according to the users preference) an unmarked type of link to the appropriate search, maybe with a mouseover or title showing the (approximate) number of hits.

Lists

  1. See https://bugzilla.wikimedia.org/show_bug.cgi?id=17246

General clutter on various pages

  1. See https://bugzilla.wikimedia.org/show_bug.cgi?id=17585

--Purodha Blissenbach 15:50, 28 January 2009 (UTC)[reply]

Uploading images in other languages

Another statement in the FAQ is :

For example, many people have difficulty creating new articles, uploading images.

We should try to increase the internationalisation of Commons.wikimedia.org. At present the rules on Commons is that most categories (except animals and plants which are written in latin) have to be written in English. Are we going to find technical solutions to have language aliases for categories, and put all languages on the same footing, without having English in a central, core position, like now ? Teofilo 15:10, 24 January 2009 (UTC)[reply]

I also feel the usability of Commons especially uploading process can be improved, however the initial project scope of the Wikipedia usability initiative does not include Commons. The reason is that we believe there are enough work to be done to improve usability of editing Wikipedia. --Shuhari 01:47, 4 February 2009 (UTC)[reply]
But the FAQ says (see above) that “many people have difficulty [...] uploading images”. And upload process is at Commons, except special cases like fair use. — Delhovlyn (talk) — [feel free to correct my bad English! =) ] 12:39, 9 February 2009 (UTC)[reply]
We're currently working on a separate grant proposal specifically to improve Commons usability; if that doesn't get funded, we may be able to make at least some basic improvements (like uploading or embedding an image directly from the edit window) in the scope of this project.--Eloquence 01:48, 12 February 2009 (UTC)[reply]

Copyright and License on the usability.wikimedia.org website

See what I wrote on http://meta.wikimedia.org/wiki/Talk:Wikipedia_Usability_Initiative Teofilo 13:29, 18 April 2009 (UTC)[reply]

In setting up the new wikis, this detail got overlooked. Please see that the footer now represents the correct copyright information. Trevor Parscal 19:04, 21 April 2009 (UTC)[reply]


Search form usability

This is a concern focused on Wikimedia Commons, where the main space, where people spend most of their time is the "Category:" space. I suggested a few improvements of search boxes and search forms on that page, on the Village pump there. Teofilo 13:36, 18 April 2009 (UTC)[reply]


Browsing subcategories

Most people don't realize that they have to go to page 2 (when a category is bigger than 200 files) to find all subcategories : see http://commons.wikimedia.org/wiki/Commons:Village_pump#Category_problem

Teofilo 22:40, 22 April 2009 (UTC)[reply]


Other user experience projects

MediaWikiUX

Hi, It is great to hear that there is a wikipedia usability initiative. We are group of volunteers, user experience designer, creating a mediawiki skin for the design commnity. We have thinked two mounths about usability, ergonomy... of our interface. We share this here on Sourceforge. If you want some explainations on this skin usability and navigation tips just ask !

Yet we couln't have programation yet so we are trying to make it by ourselves (wich would lead to an awfull code as we are not programers) or trying to get resonable costs for development. So if you know someone who can help, for free or a resonable compensation, please just tell us (designwikisurvey[at]gmail.com). The skin is to be released open source (colors would be changed on public released version).

Have a nice day

--Ttibot 04:55, 24 May 2009 (UTC) (see my user page for elements on the feedback we had gathered to non mediawiki used people)[reply]

Retrieved from "https://usability.wikimedia.org/w/index.php?title=Talk:Main_Page/1&oldid=4919"