Here's an extract of a conversation between myself and a friend which (hopefully) highlights why good UI design is important to encourage contributions.
[13:03] Roman: argh how do I upload a new version of an image without re-typing all of that text on the upload form? [13:04] Timwi: I don't think you need to retype it all [13:04] Roman: i really expected an "upload new version" link on the image page [13:05] Roman: I can't expect it to preserve the text fields if I don't type anything [13:06] Roman: see, i wanted to make a tiny improvement to an image that's already there, but now I won't do that because it's too hard
On 10/8/06, Timwi timwi@gmx.net wrote:
Here's an extract of a conversation between myself and a friend which (hopefully) highlights why good UI design is important to encourage contributions.
There's an "Upload a new version of this file" link right there on the page, it's just a question of whether the current place is the best. Perhaps when looking at a media page, the "upload file" link in the toolbox could be replaced with or supplemented by a link to upload a new version?
"Stephen Bain" wrote:
There's an "Upload a new version of this file" link right there on the page, it's just a question of whether the current place is the best. Perhaps when looking at a media page, the "upload file" link in the toolbox could be replaced with or supplemented by a link to upload a new version?
-- Stephen Bain
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
Stephen Bain wrote:
On 10/8/06, Timwi timwi@gmx.net wrote:
Here's an extract of a conversation between myself and a friend which (hopefully) highlights why good UI design is important to encourage contributions.
There's an "Upload a new version of this file" link right there on the page
I totally knew that someone would reply saying just that. I really don't know how I could make myself any more clear. This is NOT about uploading files. This is NOT about the presence or absence of any particular link. This is about UI design in general, and how its neglection costs Wikipedia contributions.
Timwi
Timwi wrote:
Stephen Bain wrote:
On 10/8/06, Timwi timwi@gmx.net wrote:
Here's an extract of a conversation between myself and a friend which (hopefully) highlights why good UI design is important to encourage contributions.
There's an "Upload a new version of this file" link right there on the page
I totally knew that someone would reply saying just that. I really don't know how I could make myself any more clear. This is NOT about uploading files. This is NOT about the presence or absence of any particular link. This is about UI design in general, and how its neglection costs Wikipedia contributions.
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
On 08/10/06, Tim Starling tstarling@wikimedia.org 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.
Obviously, the volunteers to implement it have of course posted to the thread just before you ;-p
- d.
Tim Starling wrote:
Our upload interface came under some heavy criticism from a usability expert at Wikimania hacking days.
Only the upload interface? o.O
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 [...]
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
Timwi wrote:
Only the upload interface? o.O
I invited Celeste to the hacking days to brief us on the general findings of the OpenUsability.org evaluation of the German Wikipedia:
http://openusability.org/download.php/89/germanwikipedia_usabilitytest_edit....
She focused on the image upload interface as it was identified as one of the worst current usability offenders.
Only the upload interface? o.O
I invited Celeste to the hacking days to brief us on the general findings of the OpenUsability.org evaluation of the German Wikipedia:
http://openusability.org/download.php/89/germanwikipedia_usabilitytest_edit....
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 has this already been this fixed? Couldn't see the function for adding 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.
Very interesting usability analysis. We should take this stuff to heart. A lot should be fairly simple to implement (although much is non-development, e.g., too-verbose messages/help).
On 10/10/06, Nick Jenkins nickpj@gmail.com wrote:
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 ?
On 10/10/06, Simetrical Simetrical+wikitech@gmail.com wrote:
http://openusability.org/download.php/89/germanwikipedia_usabilitytest_edit....
Very interesting usability analysis. We should take this stuff to heart. A lot should be fairly simple to implement (although much is non-development, e.g., too-verbose messages/help).
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, David Gerard dgerard@gmail.com wrote:
There's something about some en: admins making them explain everything in mind-numbingly excessive detail. Something that would take a simple
I'd love to go over some of these excessively wordy messages and trim them. Especially all the ones that go, "You can do X at the [[whatever page]]". Instead of just "Click [[whatever page|here]] to do X".
(if I were an admin) :)
Steve
On 10/10/06, Steve Bennett stevage@gmail.com wrote:
On 10/10/06, David Gerard dgerard@gmail.com wrote:
There's something about some en: admins making them explain everything in mind-numbingly excessive detail. Something that would take a simple
I'd love to go over some of these excessively wordy messages and trim them. Especially all the ones that go, "You can do X at the [[whatever page]]". Instead of just "Click [[whatever page|here]] to do X".
Point me at a pile of them. [[Special:Allmessages]] is the entire Mediawiki: space.
(if I were an admin) :)
Heh. Check [[:en:WT:RFA]] for the latest on the horrors of RFA.
- d.
Hoi, The best place to trim the cruft from the messages is still the Betawiki. From here many of the messages are translated for many many languages. When the English is without cruft there, it will have a healthy effect on the translation for so many projects. Thanks, GerardM
http://nike.users.idler.fi/betawiki/Etusivu
David Gerard wrote:
On 10/10/06, Steve Bennett stevage@gmail.com wrote:
On 10/10/06, David Gerard dgerard@gmail.com wrote:
There's something about some en: admins making them explain everything in mind-numbingly excessive detail. Something that would take a simple
I'd love to go over some of these excessively wordy messages and trim them. Especially all the ones that go, "You can do X at the [[whatever page]]". Instead of just "Click [[whatever page|here]] to do X".
Point me at a pile of them. [[Special:Allmessages]] is the entire Mediawiki: space.
(if I were an admin) :)
Heh. Check [[:en:WT:RFA]] for the latest on the horrors of RFA.
- d.
"Steve Bennett" wrote:
I'd love to go over some of these excessively wordy messages and trim them. Especially all the ones that go, "You can do X at the [[whatever page]]". Instead of just "Click [[whatever page|here]] to do X".
(if I were an admin) :)
Steve
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.
"Platonides" Platonides@gmail.com wrote in message news:egfrut$7fc$1@sea.gmane.org...
"Steve Bennett" wrote:
I'd love to go over some of these excessively wordy messages and trim them. Especially all the ones that go, "You can do X at the [[whatever page]]". Instead of just "Click [[whatever page|here]] to do X".
(if I were an admin) :)
Steve
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.
There are also concerns with e.g. "Click [[Special:Preferences|here]] to change your settings, click [[Special:Upload|here]] to upload a file.".
People accessing the site using a screen reader would find their link list (the main source of navigation) simply has a bunch of links that all say 'here'. For proper accessibility, all links should contain sufficient description about their destination within the text of the link.
- Mark Clements (HappyDog)
On 10/10/06, Steve Bennett stevage@gmail.com wrote:
I'd love to go over some of these excessively wordy messages and trim them. Especially all the ones that go, "You can do X at the [[whatever page]]". Instead of just "Click [[whatever page|here]] to do X".
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 gerard.meijssen@gmail.com wrote:
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.
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:
(if I were an admin) :)
From the musical "Wikipedian on the roof".
Steve Bennett wrote:
On 10/10/06, David Gerard dgerard@gmail.com wrote:
There's something about some en: admins making them explain everything in mind-numbingly excessive detail. Something that would take a simple
I'd love to go over some of these excessively wordy messages and trim them. Especially all the ones that go, "You can do X at the [[whatever page]]". Instead of just "Click [[whatever page|here]] to do X".
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
On 10/13/06, Timwi timwi@gmx.net 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.
The only justification I've seen for them being considered "evil" was that it's redundant: you're on the web, you click on hyperlinks, therefore a hyperlink that says "click here" is redundant. However, redundancy isn't always bad: it reduces ambiguity. Is a link that says "download" a description of what downloading is, or a place where you can actually download? A link that says "click here to download" is unambiguous.
So my reasoning says that if you're quickly navigating an interface, and you know that the link to change your user parameters is there somewhere, a link that says "click here to change your user parameters" is quicker and easier to use than some text that says "There are various <A...>user parameters</A> that you can set, including <A...>language</A> and <A...>stylesheet</A." There, the first link is something that you can actually do, while the second two are just information *about* that activity.
I've probably overlooked something though.
Steve
"Steve Bennett" stevage@gmail.com wrote in message news:f1c3529e0610140027u76fe39e2o6b2ef20968f56a25@mail.gmail.com...
On 10/13/06, Timwi timwi@gmx.net 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.
The only justification I've seen for them being considered "evil" was that it's redundant: you're on the web, you click on hyperlinks, therefore a hyperlink that says "click here" is redundant. However, redundancy isn't always bad: it reduces ambiguity. Is a link that says "download" a description of what downloading is, or a place where you can actually download? A link that says "click here to download" is unambiguous.
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 Sat, Oct 14, 2006 at 09:27:19AM +0200, Steve Bennett wrote:
I've probably overlooked something though.
Google.
Google makes good use of the *contents* of a hyperlink. I've never *searched* google for "click here", but...
Cheers, -- jra
On 10/15/06, Jay R. Ashworth jra@baylink.com wrote:
Google.
Google makes good use of the *contents* of a hyperlink. I've never *searched* google for "click here", but...
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
Steve Bennett wrote:
On 10/13/06, Timwi timwi@gmx.net 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.
The only justification I've seen for them being considered "evil" was that it's redundant: you're on the web, you click on hyperlinks, therefore a hyperlink that says "click here" is redundant.
That is by far not the only justification.
Consider something like this:
Click _here_ to change your user preferences. Click _here_ to view a random article. Click _here_ to submit a bug report.
Compare that in readability and usability with this:
* _Change your user preferences_ * _View a random article_ * _Submit a bug report_
There are so many advantages to the latter that I don't even know where to begin listing them. (1) The links are like command buttons: what they do is written right on them, not somewhere next to them. (2) The links are bigger and therefore easier to click. (3) The links have unique text and are therefore easier to navigate to via the keyboard. (4) Google indexing. (5) This list of links will stick up much more visibly if there is a paragraph on text above and below it. (6) Extra explanatory text could be added to the right of those links that can be ignored by users who find the link text clear enough already (it is visually separated from the link). (7) This may sound silly, but I always thought "click here" is a manifestation of this emerging mentality that the user should to something for the computer, not the other way around. The latter option gives the user more of a feeling of being in control.
So my reasoning says that if you're quickly navigating an interface, and you know that the link to change your user parameters is there somewhere, a link that says "click here to change your user parameters" is quicker and easier to use than some text that says "There are various <A...>user parameters</A> that you can set, including <A...>language</A> and <A...>stylesheet</A."
I agree with this. But as I'm sure you know, this is not an argument for "click here" links (it's the false dilemma fallacy).
Timwi
On 10/15/06, Timwi timwi@gmx.net wrote:
Compare that in readability and usability with this:
* _Change your user preferences_ * _View a random article_ * _Submit a bug report_
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.
There are so many advantages to the latter that I don't even know where to begin listing them. (1) The links are like command buttons: what they
I agree that it's better ;)
separated from the link). (7) This may sound silly, but I always thought "click here" is a manifestation of this emerging mentality that the user should to something for the computer, not the other way around. The latter option gives the user more of a feeling of being in control.
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.
I agree with this. But as I'm sure you know, this is not an argument for "click here" links (it's the false dilemma fallacy).
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/13/06, Timwi timwi@gmx.net wrote:
I've probably overlooked something though.
Yes. What about visually impaired people using screen readers? a list of links which all say "click here" is not very helpfull for them, but "change your preferences", "upload an image", etc. just tells them what they can do with the links.
chris
On 10/16/06, christoph.huesler@css.ch christoph.huesler@css.ch wrote:
Yes. What about visually impaired people using screen readers? a list of links which all say "click here" is not very helpfull for them, but "change your preferences", "upload an image", etc. just tells them what they can do with the links.
Never used a screenreader. Do they really just read out the text of the link with no surrounding context?
Steve
"Steve Bennett" stevage@gmail.com wrote in message news:f1c3529e0610160321nb4ed444u82034f320c2d54f6@mail.gmail.com...
On 10/16/06, christoph.huesler@css.ch
christoph.huesler@css.ch wrote:
Yes. What about visually impaired people using screen readers? a list of links which all say "click here" is not very helpfull for them, but "change your preferences", "upload an image", etc. just tells them what they can do with the links.
Never used a screenreader. Do they really just read out the text of the link with no surrounding context?
Steve
There is a links list, and that is exactly what it does. It is not the only way of rendering the page, but it is often where a reader (listener) will start out when browsing, just as we visually scan the page for blue links that go where we want.
- Mark Clements (HappyDog)
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:
Very interesting usability analysis. We should take this stuff to heart. A lot should be fairly simple to implement (although much is non-development, e.g., too-verbose messages/help).
On 10/10/06, Nick Jenkins nickpj@gmail.com wrote:
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 ?
http://bugs.wikimedia.org/show_bug.cgi?id=4525 _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 10/10/06, Gerard Meijssen gerard.meijssen@gmail.com wrote:
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.
Check [[:en:Special:Allmessages]]. The messages are fiddled with lots and lots.
- d.
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 dgerard@gmail.com wrote:
On 10/10/06, Gerard Meijssen gerard.meijssen@gmail.com wrote:
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.
Check [[:en:Special:Allmessages]]. The messages are fiddled with lots and lots.
- d.
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 10/10/06, Nick Jenkins nickpj@gmail.com wrote:
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 ?
The div containing the edit link is the first element in the HTML in each section. Then comes a <p> containing the anchor to the section, then the section heading itself. So the edit link is really not aligned with anything, it's just set to float:right, underneath the clearing <p> at the end of the section above.
The div can be pushed down with margin-top, but that's not a very elegant solution:
div.editsection {margin-top: 10px; }
On one of the projects, I forget which one, the edit link appears not at the right hand edge, but next to the heading text. That makes it clear which section the link refers to, and prevents the problem of images or other elements overflowing preceding sections displacing the floating editsection links.
Am Mittwoch, 11. Oktober 2006 04:36 schrieb Stephen Bain:
On 10/10/06, Nick Jenkins nickpj@gmail.com wrote:
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 ?
The div containing the edit link is the first element in the HTML in each section. Then comes a <p> containing the anchor to the section, then the section heading itself. So the edit link is really not aligned with anything, it's just set to float:right, underneath the clearing <p> at the end of the section above.
The div can be pushed down with margin-top, but that's not a very elegant solution:
div.editsection {margin-top: 10px; }
On one of the projects, I forget which one, the edit link appears not at the right hand edge, but next to the heading text. That makes it clear which section the link refers to, and prevents the problem of images or other elements overflowing preceding sections displacing the floating editsection links.
it's in the german wikipedia, exactly because of that open usability study.
greetings
Nick Jenkins wrote:
Only the upload interface? o.O
I invited Celeste to the hacking days to brief us on the general findings of the OpenUsability.org evaluation of the German Wikipedia:
http://openusability.org/download.php/89/germanwikipedia_usabilitytest_edit....
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 ?
Why don't you just copy the JavaScript from the German Wikipedia? (Look at http://de.wikipedia.org/wiki/MediaWiki:Monobook.js under "BEGIN Mooving of the editsection links" (and yes, they really did misspell "moving" -- I'm not an admin there so I can't fix it! :) )
Timwi
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 ?
Why don't you just copy the JavaScript from the German Wikipedia? (Look at http://de.wikipedia.org/wiki/MediaWiki:Monobook.js under "BEGIN Mooving of the editsection links" (and yes, they really did misspell "moving" -- I'm not an admin there so I can't fix it! :) )
Timwi
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.
On 10/16/06, Nick Jenkins nickpj@gmail.com wrote:
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.
Actually I was mostly making myself busy with other things. I've already dropped a line at the dewiki MediaWiki talk for Monobook.js, which is about all I could think of to inform scripters. Maybe post on the enwiki technical VP too. I should have something ready fairly soon, anyway, which ideally would collapse to something that looks like the dewiki edit links without CSS *or* JS.
I've already dropped a line at the dewiki MediaWiki talk for Monobook.js, which is about all I could think of to inform scripters.
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.
On 10/17/06, dbenzhuser dbenzhuser@gmx.net wrote:
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.
Yes, but that's not desired behavior, is it? Well, whatever.
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.
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
On 10/9/06, Timwi timwi@gmx.net wrote:
Stephen Bain wrote:
There's an "Upload a new version of this file" link right there on the page
I totally knew that someone would reply saying just that. I really don't know how I could make myself any more clear. This is NOT about uploading files. This is NOT about the presence or absence of any particular link. This is about UI design in general, and how its neglection costs Wikipedia contributions.
Ok. I did go on to say that from a UI perspective, a more logical place for the link would be the toolbox, where users are already accustomed to going when they want to upload a file.
As Platonides said I may have misunderstood what you were getting at, that you were talking about the upload form once the user has followed the link. Perhaps you could suggest how this could be improved? Autofilling the form with the current text would seem logical. The user may need to change the text if they are changing the file so there's no point removing the fields.
wikitech-l@lists.wikimedia.org