"Stephen Bain" wrote: I don't think this is the problem, but the fact that the image upload summary automatically becomes the text of the new page, so users asume that if they upload a new version, the new summary will replace the previous text, which is not. So he wants to preserve the original text and thinks he needs to retype all the image page text. I have seen this but on the opposite way. People which want to update the page text and reupload the same image over it (thus not changing it). First upload: Text goes to summary and image page. Next uploads: Text appears only on summary. Platonides

Timwi wrote: Our upload interface came under some heavy criticism from a usability expert at Wikimania hacking days. The point was well taken by the dev team, and we discussed ways to improve it at the time. In particular, we proposed to implement a wizard-style interface allowing upload to either commons or the local wiki. The timeframe for implementing this is probably on the order of months, assuming it's left to me to implement. I have some other things to do first. -- Tim Starling

Tim Starling wrote: Only the upload interface? o.O I'm glad to hear that plans exist to improve things, and even more that they came from a usability expert. Thanks for the info :) Timwi

Interesting MediaWiki / Wikipedia usability study. I've had a brief look at some of the suggestions that seem easiest to me to do something about: Page 13, the "[Edit]" links are too far up from the horizontal line that marks a new section (thus leading new users to think they are for the section above, not the section below). Tried adding: ---------------- div.editsection { vertical-align: bottom; } ---------------- to main.css ; that made no difference (in Firefox). Any CSS guru want to indicate whether it's possible to do this (move the "[Edit]" text down closer to the horizontal new section line), and if so maybe how ? Page 22, fix bug with &nbsp; has this already been this fixed? Couldn't see the function for adding &nbsp; on my toolbar, but may have missed it. Page 26, single-sign-on should help with the confusion about commons and :en or :de requiring different logins. Page 26: To have the 'Upload' in the Wikipedia toolbar go to commons, this just needs to be added to LocalSettings.php for the relevant Wikipedia : $wgUploadNavigationUrl = 'http://commons.wikimedia.org/wiki/Special:Upload'; (However, it may make most sense perhaps to enable this after Single-Sign-On becomes active). Page 39: The categories should show above the textarea in a preview, not after it at the bottom of the page. This seems to happen because the Skins are structured to show the body text (which includes both the preview and the textarea), and then the categories. For example from skins/MonoBook.php : ----------------- <!-- start content --> <?php $this->html('bodytext') ?> <?php if($this->data['catlinks']) { ?><div id="catlinks"><?php $this->html('catlinks') ?></div><?php } ?> <!-- end content --> ----------------- Probably what's needed is to separate bodytext into the stuff before catlinks (the preview of the wikitext), and the stuff after it (the textarea). Or alternatively to insert catlinks into bodytext at some previous stage. includes/EditPage.php::showEditForm() seems to be where the preview (generated by calling $this->showPreview() ) gets mixed in with the edit form content (e.g. the textarea and form tags seem to be started and ended here). All the best, Nick.

On 10/10/06, Simetrical &lt;Simetrical+wikitech(a)gmail.com&gt; wrote: There's something about some en: admins making them explain everything in mind-numbingly excessive detail. Something that would take a simple subject-verb object sentence gets turned into three sentences with four dangling modifiers and two words over four syllables. Just in case someone didn't get a TERRIBLY IMPORTANT detail shoved in their face right there, y'know. Large chunks of Mediawiki: space need rewriting in Comprehensible. - d.

On 10/10/06, Steve Bennett &lt;stevage(a)gmail.com&gt; wrote: Point me at a pile of them. [[Special:Allmessages]] is the entire Mediawiki: space. Heh. Check [[:en:WT:RFA]] for the latest on the horrors of RFA. - d.

"Steve Bennett" wrote: Click here links are discouraged. Would be better to use "You can [[whatever page|do X]]" though it doesn't seem terrible. If the message were "Click [[Special:preferences|here]] you change the images size" the user would arrive to his user profile, not related to images (have i changed it?). The former at least implies that some browsing (go to 'files' tab) is needed.

On 10/10/06, Steve Bennett &lt;stevage(a)gmail.com&gt; wrote: http://www.w3.org/TR/WCAG10-HTML-TECHS/#link-text , but the general idea is good. Platonides' [[whatever|do X]] is better, with maximally descriptive link text. On 10/10/06, Gerard Meijssen &lt;gerard.meijssen(a)gmail.com&gt; wrote: However, the details of local processes can only be added by admins, and that's a large part of what's important for this kind of thing (what doesn't belong on the wiki, what naming conventions are used, etc.). The generic messages in the default package will probably have to be made significantly wordier by local admins if they want it to be informative. That's not a reason not to trim them down in some places in the default package, of course.

Steve Bennett wrote: I'm surprised you think that's better. "Click here" links are generally considered evil, and I generally agree with that. "Click here to do X" only tells me how to do X *now*, not where to go if I ever want to do X. Timwi

"Steve Bennett" &lt;stevage(a)gmail.com&gt; wrote in message news:f1c3529e0610140027u76fe39e2o6b2ef20968f56a25@mail.gmail.com... No - as I said in an earlier post, the biggest problem is with accessibility. People using screen readers navigate a site using a links list generated by their screen reader, which is useless if all it says is 'Link 1: click here, Link 2: click here, etc.'. - Mark Clements (HappyDog)

On 10/15/06, Jay R. Ashworth &lt;jra(a)baylink.com&gt; wrote: Fair enough. Anyway I will wait till I have a concrete example of bad usability that we can discuss ways to improve before continuing this. Steve

On 10/15/06, Timwi &lt;timwi(a)gmx.net&gt; wrote: This form (bullet points clearly presenting a menu of options) is good. I was really criticising the form of having a sentence with various words linked, some of which are like menu options, and some of which just provide background material. I agree that it's better ;) Emerging mentality? I think that's a dying trend - Microsoft even apologises these days when Windows borks up. "We're sorry for the inconvenience, but X application needs to be shut down". The emerging mentality, if any, is now that software is a *service* that you pay for, and hence tries to do anything possible to satisfy you. Heh, I was about to accuse you of that. Let's say that my proposed "more usable" version was only marginally better. But some genuine examples would be good for further discussion. Steve

On 10/16/06, christoph.huesler(a)css.ch &lt;christoph.huesler(a)css.ch&gt; wrote: Never used a screenreader. Do they really just read out the text of the link with no surrounding context? Steve

Hoi, When the messages are translated, they are translated as literally as possible in order not to misrepresent what is intended. The messages are typically created during the development stage. Saying that overly verbose messages are outside of what developers do is not necessary helpful. It is the English interface that is leading in this way and I am sure that the English community is less active in messages than any of the other language communities because they have not the same need to change things. Thanks, GerardM Simetrical wrote:

Hoi, It may be that they are fiddled with. But not EVERY message needs translating like it is needed for all other languages. Thanks, GerardM On 10/10/06, David Gerard &lt;dgerard(a)gmail.com&gt; wrote:

Am Mittwoch, 11. Oktober 2006 04:36 schrieb Stephen Bain: it's in the german wikipedia, exactly because of that open usability study. greetings

If I understand correctly, I think the current plan for this ( a.k.a. http://bugzilla.wikimedia.org/show_bug.cgi?id=4525 ) is to : * Reapply http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=16962 * Reapply http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=16963 * Apply something like this: http://files.nickj.org/MediaWiki/wikibits-right-click-diff.txt * One last remaining problem is that right-clicking on the "[edit]" link will jump into edit mode (if you have the edit-on-right-click option enabled in your Preferences), instead of doing the usual right-click context stuff (e.g. show context menu with: Copy link location, Open in new window, etc) as it does at the moment. This is because the edit mode starts on right click on the h2/h3 header, and the span for the "[edit]" is now inside that header. It may be that another span is required around the actual h2/h3 header text, and the enter-edit-mode JavaScript needs to be activated on right-clicking that. * Bump the $wgStyleVersion in includes/DefaultSettings.php * Update the expected results in maintenance/parserTests.txt to reflect the above changes. This has the following benefits: * Should work even if you have JavaScript turned off. * Should work if you're on a device which doesn't have JavaScript, but which has CSS (if such a thing exists). * Rather than sending a DOM and then runtime patching it with JavaScript (as per DE), it's sending the right thing first time around, so it aesthetically feels cleaner. * Strictly personal preference, but as a general rule I feel that if something can be done either through straight HTML+CSS, or through JavaScript, that HTML+CSS is generally the preferable option. Current state-of-play I suspect is that the person in the driver's seat for this (Simetrical) is possibly trying to weigh up whether the benefits are worth the transition costs. All the best, Nick.

The script (which is used at frwiki, too) shouldn't make any problems. It searches for divs of the editsection class, if it can't find any, it just does nothing. As the new version uses span instead of div the script reacts as if there where no headings in the page.

XForms would be ideal to deal with it + and they can be implemented very fast. Only problem is the lack of support - but there's a solution for simulating XForms-Behaviour using AJAX: http://ajaxforms.sourceforge.net/ Introduction to XForms: http://www.w3.org/MarkUp/Forms/2003/xforms-for-html-authors.html Part 2 - handling "wizard style forms": http://www.w3.org/MarkUp/Forms/2006/xforms-for-html-authors-part2.html greetings -- Julian Fleischer aka Warhog