Ref: http://bugzilla.wikimedia.org/show_bug.cgi?id=1629, http://de.wikipedia.org/wiki/Wikipedia:WikiProjekt_Usability/Test_Februar_2006
From the latter, we have
"Two users who started their first-time editing with a paragraph instead of the whole page were not confused by the syntax. However, they were faced with another problem: The location of the "Edit" links seemed to relate them with the paragraph above, not the one below. Therefore, when clicking the "Edit" link below "Geschichte", they expected to see the heading "Geschichte" and its contents. . . .
"This expectation was not met, instead "Weblinks" appeared in the editor window. They were confused, did not know what to do. Finally, both participants deleted (!) the existing and valid text, and started to add their own text."
We've known for well over a year now that this is a problem. I would like to finally fix it. Specifically, I intend to remove the editsection float style, so it's at the beginning of the section line, to the left. The alternative is to have it as the German Wikipedia does, with the section edit link on the right of the header; however, this a) is kind of annoying as the link jumps around, and b) requires a change to the document structure (admittedly just a reordering of elements, but it may well break some fragile stuff regardless). It does arguably look better, though, and that could be done instead (opinions?). A comparison of the three styles is available at http://www.mediawiki.org/wiki/User:Simetrical/Edit_links_comparison.
Before this goes into effect, it would be only courteous to inform existing wikis about it and the reasons for doing it. I'll prepare a little message and get someone with bots everywhere (Yurik?) to post it on all the wikis' MediaWiki talk:Common.css pages, I think, before I commit it, and so well before it goes live, along with instructions on how to reverse it preemptively if desired.
Are there any objections to this?
Er, this seems not to be showing up correctly in the archives. I just got the first line, which reads a little impolitely as the entire post. Can people confirm if the whole thing went through okay?
On 6/25/07, Simetrical Simetrical+wikilist@gmail.com wrote:
Ref: http://bugzilla.wikimedia.org/show_bug.cgi?id=1629, http://de.wikipedia.org/wiki/Wikipedia:WikiProjekt_Usability/Test_Februar_2006
From the latter, we have
"Two users who started their first-time editing with a paragraph instead of the whole page were not confused by the syntax. However, they were faced with another problem: The location of the "Edit" links seemed to relate them with the paragraph above, not the one below. Therefore, when clicking the "Edit" link below "Geschichte", they expected to see the heading "Geschichte" and its contents. . . .
"This expectation was not met, instead "Weblinks" appeared in the editor window. They were confused, did not know what to do. Finally, both participants deleted (!) the existing and valid text, and started to add their own text."
We've known for well over a year now that this is a problem. I would like to finally fix it. Specifically, I intend to remove the editsection float style, so it's at the beginning of the section line, to the left. The alternative is to have it as the German Wikipedia does, with the section edit link on the right of the header; however, this a) is kind of annoying as the link jumps around, and b) requires a change to the document structure (admittedly just a reordering of elements, but it may well break some fragile stuff regardless). It does arguably look better, though, and that could be done instead (opinions?). A comparison of the three styles is available at http://www.mediawiki.org/wiki/User:Simetrical/Edit_links_comparison.
Before this goes into effect, it would be only courteous to inform existing wikis about it and the reasons for doing it. I'll prepare a little message and get someone with bots everywhere (Yurik?) to post it on all the wikis' MediaWiki talk:Common.css pages, I think, before I commit it, and so well before it goes live, along with instructions on how to reverse it preemptively if desired.
Are there any objections to this?
Yes, whole thing arrived fine here.
On 6/25/07, Simetrical Simetrical+wikilist@gmail.com wrote:
Er, this seems not to be showing up correctly in the archives. I just got the first line, which reads a little impolitely as the entire post. Can people confirm if the whole thing went through okay?
On 6/25/07, Simetrical Simetrical+wikilist@gmail.com wrote:
Ref: http://bugzilla.wikimedia.org/show_bug.cgi?id=1629, http://de.wikipedia.org/wiki/Wikipedia:WikiProjekt_Usability/Test_Februar_2006
From the latter, we have
"Two users who started their first-time editing with a paragraph instead of the whole page were not confused by the syntax. However, they were faced with another problem: The location of the "Edit" links seemed to relate them with the paragraph above, not the one below. Therefore, when clicking the "Edit" link below "Geschichte", they expected to see the heading "Geschichte" and its contents. . . .
"This expectation was not met, instead "Weblinks" appeared in the editor window. They were confused, did not know what to do. Finally, both participants deleted (!) the existing and valid text, and started to add their own text."
We've known for well over a year now that this is a problem. I would like to finally fix it. Specifically, I intend to remove the editsection float style, so it's at the beginning of the section line, to the left. The alternative is to have it as the German Wikipedia does, with the section edit link on the right of the header; however, this a) is kind of annoying as the link jumps around, and b) requires a change to the document structure (admittedly just a reordering of elements, but it may well break some fragile stuff regardless). It does arguably look better, though, and that could be done instead (opinions?). A comparison of the three styles is available at http://www.mediawiki.org/wiki/User:Simetrical/Edit_links_comparison.
Before this goes into effect, it would be only courteous to inform existing wikis about it and the reasons for doing it. I'll prepare a little message and get someone with bots everywhere (Yurik?) to post it on all the wikis' MediaWiki talk:Common.css pages, I think, before I commit it, and so well before it goes live, along with instructions on how to reverse it preemptively if desired.
Are there any objections to this?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 6/25/07, Simetrical Simetrical+wikilist@gmail.com wrote:
Ref: http://bugzilla.wikimedia.org/show_bug.cgi?id=1629, http://de.wikipedia.org/wiki/Wikipedia:WikiProjekt_Usability/Test_Februar_2006
From the latter, we have
"Two users who started their first-time editing with a paragraph instead of the whole page were not confused by the syntax. However, they were faced with another problem: The location of the "Edit" links seemed to relate them with the paragraph above, not the one below. Therefore, when clicking the "Edit" link below "Geschichte", they expected to see the heading "Geschichte" and its contents. . . .
"This expectation was not met, instead "Weblinks" appeared in the editor window. They were confused, did not know what to do. Finally, both participants deleted (!) the existing and valid text, and started to add their own text."
We've known for well over a year now that this is a problem. I would like to finally fix it. Specifically, I intend to remove the editsection float style, so it's at the beginning of the section line, to the left. The alternative is to have it as the German Wikipedia does, with the section edit link on the right of the header; however, this a) is kind of annoying as the link jumps around, and b) requires a change to the document structure (admittedly just a reordering of elements, but it may well break some fragile stuff regardless). It does arguably look better, though, and that could be done instead (opinions?). A comparison of the three styles is available at http://www.mediawiki.org/wiki/User:Simetrical/Edit_links_comparison.
Before this goes into effect, it would be only courteous to inform existing wikis about it and the reasons for doing it. I'll prepare a little message and get someone with bots everywhere (Yurik?) to post it on all the wikis' MediaWiki talk:Common.css pages, I think, before I commit it, and so well before it goes live, along with instructions on how to reverse it preemptively if desired.
Are there any objections to this?
I bet this ends up less user-friendly and intuitive than leaving it where it is.
On 6/25/07, George Herbert george.herbert@gmail.com wrote:
I bet this ends up less user-friendly and intuitive than leaving it where it is.
Why do you think that, given the usability study's result?
On Mon, Jun 25, 2007 at 10:01:22PM -0400, Simetrical wrote:
On 6/25/07, George Herbert george.herbert@gmail.com wrote:
I bet this ends up less user-friendly and intuitive than leaving it where it is.
Why do you think that, given the usability study's result?
There was already a change after the user study. The edit link was not placed in the same line as the heading of the next section, but before it. This was indeed very confusing.
Today, the edit link is in the same line, and I think there's no need to change that.
Regards,
jens
On 6/26/07, Jens Frank jf@mormo.org wrote:
There was already a change after the user study. The edit link was not placed in the same line as the heading of the next section, but before it. This was indeed very confusing.
Today, the edit link is in the same line, and I think there's no need to change that.
Well, it's true that my CSS fiddling did move down the edit link slightly, but frankly, I doubt it's enough. Think about it: there's a clear line *under* the link. If you look at it, it looks like it belongs to the section above, separated from the one below by a horizontal rule.
We could all ask our wiki-ignorant friends what they think. That's about what a usability study consists of, after all, just a little more thorough. :)
On 6/26/07, Sebastian Moleski sebmol@gmail.com wrote:
As long as you implement it in a way that still allows the edit link to appear just to the right of the heading (the "German Wikipedia way"), no objections here. Ideally, this would be configurable so that each project and each user can set up their own defaults.
There should be no change at all in how the German Wikipedia way works either way we go, although I'll check that out firsthand before instituting changes. Those using the current default can preserve it with a one-line addition to MediaWiki:Common.css, and likewise for individual users.
On Tue, Jun 26, 2007 at 01:08:39AM -0400, Simetrical wrote:
On 6/26/07, Jens Frank jf@mormo.org wrote:
There was already a change after the user study. The edit link was not placed in the same line as the heading of the next section, but before it. This was indeed very confusing.
Today, the edit link is in the same line, and I think there's no need to change that.
Well, it's true that my CSS fiddling did move down the edit link slightly, but frankly, I doubt it's enough. Think about it: there's a clear line *under* the link. If you look at it, it looks like it belongs to the section above, separated from the one below by a horizontal rule.
That argumentation suggests that the heading belongs to the above section, too. I think the line is not seen that way by our readers.
We could all ask our wiki-ignorant friends what they think. That's about what a usability study consists of, after all, just a little more thorough. :)
I'll ask some colleagues who aren't wiki editors and will tell you tonight about the results.
On 6/26/07, Sebastian Moleski sebmol@gmail.com wrote:
As long as you implement it in a way that still allows the edit link to appear just to the right of the heading (the "German Wikipedia way"), no objections here. Ideally, this would be configurable so that each project and each user can set up their own defaults.
There should be no change at all in how the German Wikipedia way works either way we go, although I'll check that out firsthand before instituting changes. Those using the current default can preserve it with a one-line addition to MediaWiki:Common.css, and likewise for individual users.
Different behaviour for different wikis is a very bad idea. That would be confusing. The edit link should be placed in the same way on all WMF wikis.
jens
On 6/26/07, Jens Frank jf@mormo.org wrote:
There should be no change at all in how the German Wikipedia way works either way we go, although I'll check that out firsthand before instituting changes. Those using the current default can preserve it with a one-line addition to MediaWiki:Common.css, and likewise for individual users.
Different behaviour for different wikis is a very bad idea. That would be confusing. The edit link should be placed in the same way on all WMF wikis.
They already are different. I also remember quite well how strongly dewiki users reacted last year when the edit links suddenly appeared in a different place than from what they used to. There was also extensive discussion about where the edit links should go and there was even some talk about doing a community-wide vote on it. If the edit link position were standardized across all wikis you can be sure that this will happen again. People tend to get irrate when someone external messes with their habits.
As to the confusion different positions may bring: the question was raised because of usability concerns meaning the solution proposed here is meant to address new users who aren't familiar with the softwaree's interface or its functions. Chaning the edit link position addresses that by making the relationship between the links' position and their function more intuitive to new users.
My guess is that it's not anywhere near typical for new users to be active in multiple wikis so that different edit link positions wouldn't affect them. Once they have gotten used to the interface and might consider venturing out to another wiki (most likely Commons, my guess), they might be surprised that the links are at different places but I highly doubt they will have problems operating them. Of course, empirical data would be preferable here too.
Sebastian
I'm pleased by all the comments and ideas.
On 6/26/07, Jens Frank jf@mormo.org wrote:
I'll ask some colleagues who aren't wiki editors and will tell you tonight about the results.
And I'll ask some non-wiki editors too.
Different behaviour for different wikis is a very bad idea. That would be confusing. The edit link should be placed in the same way on all WMF wikis.
That's an issue for the Foundation to decide, if it wants to. I suspect it will maintain its usual attitude of deference to the communities' wishes unless *maybe* some community decides their Wikipedia should be hot pink and loaded with animated background-images.
On 6/26/07, Andre Engels andreengels@gmail.com wrote:
If you are going to change this anyway (though I would not think it necessary), I think it would be esthetically more pleasing to use the German Wikipedia method rather than to go all the way to the left as you propose.
I actually agree, but it is kind of annoying how it jumps around, at least if you aren't used to it, and it would require a reordering of the document structure. I guess I'd narrowly prefer this option.
On 6/26/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Does this discussion include a modification of Monobook's main.css for MediaWiki distribution world-wide? or is it limited to how WMF sites operate?
There is no difference in terms of stylesheets for WMF sites and other MediaWiki sites, and I am in fact a MediaWiki developer, not anything specifically related to Wikimedia wikis. The point is to increase usability of MediaWiki out of the box. It will be applied to the CSS of all skins, if it is applied (I'd still like to specifically ask Brion to sign off on it).
On 6/26/07, Danny B. Wikipedia.Danny.B@email.cz wrote:
- The current way of inserting of editlinks to page is against semantics (it's being
inserted inside the header tag).
I know, that was my stupidity. I tried to fix it later, but that broke styles/scripts and got reverted. :( I still hope to restore it to a more sensible state at some point, maybe in a one-time general document structure cleanup (making TOCs non-tables, changing the <h5>/<h6> sidebar headers so headings nest properly, . . .).
So I've been playing with that regarding to what's been said above and got to some proposal how to deal with editlinks. The playground is on http://www.mediawiki.org/wiki/User:Danny_B./Edit_links_comparsion and the final proposal is on http://tools.wikimedia.de/~danny_b/demos/editlinks.html , since it requires some changes in MediaWiki code which renders the page (check the xhtml source).
Hmm . . . I don't know. It uses up vertical space, which isn't great. Also, I would put the edit link under the section title, not above it. It does have the advantage that it's pretty clearly related to the section, not just the section title, but overall I'm not sure I like it. I do agree with most of the rest of your points, except that I don't see anything aesthetically displeasing with the German positioning of the links. They could be made a bit smaller, perhaps, and some kind of top-section edit link would be good. The latter would be easily doable in the German style, with just [edit top] after the page name . . . but that might be too prominent and confusing to new users, plus we don't have the automatic /* summaries */, so I don't know if it would be useful overall. So overall I'd be conservative and just go with what the Germans have.
Od: Simetrical Simetrical+wikilist@gmail.com
I know, that was my stupidity. I tried to fix it later, but that broke styles/scripts and got reverted. :( I still hope to restore it to a more sensible state at some point, maybe in a one-time general document structure cleanup (making TOCs non-tables, changing the
<h5>/<h6> sidebar headers so headings nest properly, . . .).
I'd be pleased to help out with clean-up of output code.
So I've been playing with that regarding to what's been said above and got to some proposal how to deal with editlinks. The playground is on http://www.mediawiki.org/wiki/User:Danny_B./Edit_links_comparsion and the
final
proposal is on http://tools.wikimedia.de/~danny_b/demos/editlinks.html , since
it
requires some changes in MediaWiki code which renders the page (check the xhtml source).
Hmm . . . I don't know. It uses up vertical space, which isn't great. Also, I would put the edit link under the section title, not above it. It does have the advantage that it's pretty clearly related to the section, not just the section title, but overall I'm not sure I like it. I do agree with most of the rest of your points, except that I don't see anything aesthetically displeasing with the German positioning of the links. They could be made a bit smaller, perhaps, and some kind of top-section edit link would be good. The latter would be easily doable in the German style, with just [edit top] after the page name . . . but that might be too prominent and confusing to new users, plus we don't have the automatic /* summaries */, so I don't know if it would be useful overall. So overall I'd be conservative and just go with what the Germans have.
It doesn't use that much of space which would be annoying or even critical. But I agree, that's subjective.
I also played with editlink underneath the header, but: 1. it either fills the gap in between the header and paragraph -> the page isn't that "fluffy" as it used to be (that's what I, and I guess many other, wouldn't like) or 2. it takes the vertical space (that's what you just mentioned you don't see good)
Plus: What I forgot to add to advantages of my solution was that selecting of text of section for copying of course does not select the [edit] text since it is placed before such section and its header.
Kind regards
Danny B.
@Brion Vibber & Jim Wilson & Simetrical & others who will try...
My bad I haven't emphasize one important thing when I was saying that German way isn't for 99 % doable, which is:
Of course if you have order
header editlink paragraph(s)
it is doable.
But:
editlink header paragraph(s)
is the more correct order of items, because: 1. if you click [edit], you can edit the header too = it's much more logical to have editlink at the very beginning (or end) of such block to edit, not somewhere inside 2. the thing I mentioned in one of my previous posts - uncomfortable selecting & copying of text of such section (you get [edit] together with the text)
And in this order the German way is AFAIK not doable, but as I said before, I'd be happy if somebody found any hack for that.
Kind regards
Danny B.
On 6/26/07, Danny B. Wikipedia.Danny.B@email.cz wrote:
Of course if you have order
header editlink paragraph(s)
it is doable.
But:
editlink header paragraph(s)
is the more correct order of items, because:
- if you click [edit], you can edit the header too = it's much more logical to have
editlink at the very beginning (or end) of such block to edit, not somewhere inside 2. the thing I mentioned in one of my previous posts - uncomfortable selecting & copying of text of such section (you get [edit] together with the text)
And in this order the German way is AFAIK not doable, but as I said before, I'd be happy if somebody found any hack for that.
It should be possible by floating the h2 left, but I see no problem semantically with having the edit link follow the header. It makes sense when read either way.
Simetrical said:
It should be possible by floating the h2 left, but I see no problem semantically with having the edit link follow the header. It makes sense when read either way.
Correct. Putting the edit link before the header i like putting the cart before, um, the horse ... or something :)
Seriously though - having the link anywhere other than either beside or below the header text seems ghastly. Core devs, please don't allow this.
-- Jim
On 6/26/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 6/26/07, Danny B. Wikipedia.Danny.B@email.cz wrote:
Of course if you have order
header editlink paragraph(s)
it is doable.
But:
editlink header paragraph(s)
is the more correct order of items, because:
- if you click [edit], you can edit the header too = it's much more
logical to have
editlink at the very beginning (or end) of such block to edit, not
somewhere
inside 2. the thing I mentioned in one of my previous posts - uncomfortable
selecting &
copying of text of such section (you get [edit] together with the text)
And in this order the German way is AFAIK not doable, but as I said
before, I'd be
happy if somebody found any hack for that.
It should be possible by floating the h2 left, but I see no problem semantically with having the edit link follow the header. It makes sense when read either way.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Od: Simetrical Simetrical+wikilist@gmail.com It should be possible by floating the h2 left, but I see no problem semantically with having the edit link follow the header. It makes sense when read either way.
Floating of header and/or editlink is what we should avoid otherwise we'll get the same problems just on the other side of page... ;-)
Regarding the order: As I mentioned before - the order editlink-header-paragraph is better from logical and practical point of view.
Besides we're mixing two approaches a bit at the moment I think - the code and the visual rendering. What I was trying to do, was completely independent chunk of code which solved tree things (which are tightly connected) at once. Positioning is next step of course, but it definitely should not be the first one.
Lot of people were mentioning that they don't like German way because of not having the editlink always on the same place - my proposal solves that - it doesn't necessary have to put the editlink above the header, it can put it just in front of it. That's exactly the advantage of that solution - editlink is completely independent on header, therefore can be positioned almost everywhere. And without any big changes to the current CSS, since it does not change the behavior of headers etc.
Kind regards
Danny B.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Danny B. wrote:
Od: Simetrical Simetrical+wikilist@gmail.com It should be possible by floating the h2 left, but I see no problem semantically with having the edit link follow the header. It makes sense when read either way.
Floating of header and/or editlink is what we should avoid otherwise we'll get the same problems just on the other side of page... ;-)
Regarding the order: As I mentioned before - the order editlink-header-paragraph is better from logical and practical point of view.
Not particularly.
Lot of people were mentioning that they don't like German way because of not having the editlink always on the same place - my proposal solves that - it doesn't necessary have to put the editlink above the header, it can put it just in front of it.
Uuuuuugly.
- -- brion vibber (brion @ wikimedia.org)
2007/6/26, Simetrical Simetrical+wikilist@gmail.com:
On 6/26/07, Sebastian Moleski sebmol@gmail.com wrote:
As long as you implement it in a way that still allows the edit link to appear just to the right of the heading (the "German Wikipedia way"), no objections here. Ideally, this would be configurable so that each project and each user can set up their own defaults.
There should be no change at all in how the German Wikipedia way works either way we go, although I'll check that out firsthand before instituting changes. Those using the current default can preserve it with a one-line addition to MediaWiki:Common.css, and likewise for individual users.
If you are going to change this anyway (though I would not think it necessary), I think it would be esthetically more pleasing to use the German Wikipedia method rather than to go all the way to the left as you propose.
Does this discussion include a modification of Monobook's main.css for MediaWiki distribution world-wide? or is it limited to how WMF sites operate?
( If it's the latter - as I suspect - then I have no opinion )
-- Jim R. Wilson (jimbojw)
On 6/26/07, Andre Engels andreengels@gmail.com wrote:
2007/6/26, Simetrical Simetrical+wikilist@gmail.com:
On 6/26/07, Sebastian Moleski sebmol@gmail.com wrote:
As long as you implement it in a way that still allows the edit link
to
appear just to the right of the heading (the "German Wikipedia way"),
no
objections here. Ideally, this would be configurable so that each
project
and each user can set up their own defaults.
There should be no change at all in how the German Wikipedia way works either way we go, although I'll check that out firsthand before instituting changes. Those using the current default can preserve it with a one-line addition to MediaWiki:Common.css, and likewise for individual users.
If you are going to change this anyway (though I would not think it necessary), I think it would be esthetically more pleasing to use the German Wikipedia method rather than to go all the way to the left as you propose.
-- Andre Engels, andreengels@gmail.com ICQ: 6260644 -- Skype: a_engels
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hello.
I'd like to throw in my thoughts and ideas about editlinks I had some time ago. They are based on suggestions from users I'm continuously receiving:
The current style has couple disadvantages: 1. In certain cases (depending on other right floating objects on page) editlinks mingle around and sometimes stick together on one place therefore it is impossible to realize which one belongs to which header. (http://cs.wikipedia.org/wiki/Bo%C5%BEena_N%C4%9Bmcov%C3%A1#D.C3.ADlo http://cs.wikipedia.org/wiki/Nicole_Vaidi%C5%A1ov%C3%A1 http://cs.wikipedia.org/wiki/Metro#Zaj.C3.ADmavosti http://cs.wikipedia.org/wiki/Mistrovstv%C3%AD_Evropy_ve_fotbale_2004#.C4.8Ce... etc. in 1024*768) 2. When using wide displays, editlinks are pretty far away from headlines and together with the situation when paragraphs are short, it may be hard to follow the line and say which editlink belongs to which header. 3. The top-right place is the less usual place to place this kind of link, therefore people may think it belongs to previous article, since bottom-right is much more usual place for this.
Now: * The current editlink style is, that it has constant size regardless the size of header. Therefore sticking the link to header on same line causes kind of odd look. * The current way of inserting of editlinks to page is against semantics (it's being inserted inside the header tag). * Since the editlink is inserted within a header, it's harder to manipulate it, if the user wants to do some customization. * There's no editlink for intro (section 0) of page. * The editlink is pretty big (has the same size as text, while eg. tabs are smaller).
So I've been playing with that regarding to what's been said above and got to some proposal how to deal with editlinks. The playground is on http://www.mediawiki.org/wiki/User:Danny_B./Edit_links_comparsion and the final proposal is on http://tools.wikimedia.de/~danny_b/demos/editlinks.html , since it requires some changes in MediaWiki code which renders the page (check the xhtml source). Because it is just for demo purposes to illustrate the idea, it has been tested in Firefox and IE only and using Monobook. But there's no problem to do more testing and style setting if the idea will be well received.
Advantages of the proposal (in no specific order): * The editlink is now on the place where there are no doubts of what section it belongs to (the reliability of this can be yet higher when changing the label from "edit" to "edit the following section" or something like that) * The visual behavior is now much easier to customize, if you want to do so (you can place the editlink now pretty much wherever you want around the header using CSS only) since it's independent on header * It allows adding of editlink for page intro (section 0), which is pretty old request in Bugzilla btw. * Correct semantics of headers * More correct semantics of section anchors * No odd look caused by different font sizes on the same line
Questions, comments and suggestions are welcome.
Thanks.
Danny B.
Hi Danny,
I agree with most of your observations - especially regarding the semantics of putting the edit link inside the header tags. However,
and the final proposal is on
http://tools.wikimedia.de/~danny_b/demos/editlinks.htmlhttp://tools.wikimedia.de/%7Edanny_b/demos/editlinks.html
I don't like that much at all :( To me, putting the edit before the header seems even more likely to confuse people (thinking that the edit link belongs to the previous section)
Of all the suggestions I've read so far, I like the "German way" the best (putting the edit link immediately to the right of the header which it edits). This seems to be consistent in principle with the line of action tabs at the top, and wouldn't suffer from the right-floating issues which can misalign the edit links.
Just my two cents.
-- Jim
On 6/26/07, Danny B. Wikipedia.Danny.B@email.cz wrote:
Hello.
I'd like to throw in my thoughts and ideas about editlinks I had some time ago. They are based on suggestions from users I'm continuously receiving:
The current style has couple disadvantages:
- In certain cases (depending on other right floating objects on page)
editlinks mingle around and sometimes stick together on one place therefore it is impossible to realize which one belongs to which header. ( http://cs.wikipedia.org/wiki/Bo%C5%BEena_N%C4%9Bmcov%C3%A1#D.C3.ADlo http://cs.wikipedia.org/wiki/Nicole_Vaidi%C5%A1ov%C3%A1 http://cs.wikipedia.org/wiki/Metro#Zaj.C3.ADmavosti http://cs.wikipedia.org/wiki/Mistrovstv%C3%AD_Evropy_ve_fotbale_2004#.C4.8Ce.... in 1024*768) 2. When using wide displays, editlinks are pretty far away from headlines and together with the situation when paragraphs are short, it may be hard to follow the line and say which editlink belongs to which header. 3. The top-right place is the less usual place to place this kind of link, therefore people may think it belongs to previous article, since bottom-right is much more usual place for this.
Now:
- The current editlink style is, that it has constant size regardless the
size of header. Therefore sticking the link to header on same line causes kind of odd look.
- The current way of inserting of editlinks to page is against semantics
(it's being inserted inside the header tag).
- Since the editlink is inserted within a header, it's harder to
manipulate it, if the user wants to do some customization.
- There's no editlink for intro (section 0) of page.
- The editlink is pretty big (has the same size as text, while eg. tabs
are smaller).
So I've been playing with that regarding to what's been said above and got to some proposal how to deal with editlinks. The playground is on http://www.mediawiki.org/wiki/User:Danny_B./Edit_links_comparsion and the final proposal is on http://tools.wikimedia.de/~danny_b/demos/editlinks.html , since it requires some changes in MediaWiki code which renders the page (check the xhtml source). Because it is just for demo purposes to illustrate the idea, it has been tested in Firefox and IE only and using Monobook. But there's no problem to do more testing and style setting if the idea will be well received.
Advantages of the proposal (in no specific order):
- The editlink is now on the place where there are no doubts of what
section it belongs to (the reliability of this can be yet higher when changing the label from "edit" to "edit the following section" or something like that)
- The visual behavior is now much easier to customize, if you want to do
so (you can place the editlink now pretty much wherever you want around the header using CSS only) since it's independent on header
- It allows adding of editlink for page intro (section 0), which is pretty
old request in Bugzilla btw.
- Correct semantics of headers
- More correct semantics of section anchors
- No odd look caused by different font sizes on the same line
Questions, comments and suggestions are welcome.
Thanks.
Danny B.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
A small, but important notice about the "German way":
German way isn't visually bad, but it has one big disadvantage: I am 99 % sure, this rendering can't be done together with correct semantics. Which means there is no semantically correct or nearly correct combination of tags and CSS you can use for creating of this style. That's actually why I threw in my solution proposal, which I played with for pretty long time during which I faced these problems. (Some more info coming in following replies.)
Therefore I guess, we have to decide what to prefer: clean and reusable code or fancy visual rendering.
On the other hand I'd be so very pleased to see any correct solution of this, if it exist.
Kind regards
Danny B.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Danny B. wrote:
A small, but important notice about the "German way":
German way isn't visually bad, but it has one big disadvantage: I am 99 % sure, this rendering can't be done together with correct semantics. Which means there is no semantically correct or nearly correct combination of tags and CSS you can use for creating of this style. That's actually why I threw in my solution proposal, which I played with for pretty long time during which I faced these problems. (Some more info coming in following replies.)
In theory it should be possible to put something sensible together like this:
<div class="sectionheader"> <h2>Header text</h2> <div class="sectionedit">[<a>edit</a>]</div> </div>
.sectionheader h2, .sectionheader h3, .... { display: inline; }
The border for major sections could also be stuck on that outer <div>.
This should provide the look currently visible on de.wikipedia.org, while still making some kind of sense semantically. Non-CSS browsers would show the edit link on another line from the header text, but that hardly seems the end of the world to me. By keeping the link _out_ of the actual header element, it should be friendlier to screen readers and anything that extracts the header text.
In theory. ;)
- -- brion vibber (brion @ wikimedia.org)
Od: Jim Wilson wilson.jim.r@gmail.com
I don't like that much at all :( To me, putting the edit before the header seems even more likely to confuse people (thinking that the edit link belongs to the previous section)
Well, let me point out, that the gap in between the previous paragraph and editlink is pretty big (and can be done even bigger if necessary) comparing to the gap in between editlink and header, which actually almost doesn't exist, since it's sticked together. This is exactly the way which should clear all doubts about which part the editlink belongs to, if previous or following.
Kind regards
Danny B.
Danny B. wrote:
A small, but important notice about the "German way":
German way isn't visually bad, but it has one big disadvantage: I am 99 %
sure, this
rendering can't be done together with correct semantics. Which means there
is no semantically
correct or nearly correct combination of tags and CSS you can use for
creating of this style.
Never one to shy away from a challenge, I took a stab at solving this dilemma:
http://www.mediawiki.org/wiki/User:Jimbojw/Semantically_correct_right-aligne...
It uses <div> tags instead of headings with a whole bunch of inline style, but I think the principle is sound.
The final markup would look something like this:
<h2><span>Explanation section</span></h2> <div class="editsection">[<a href="/edit/url">edit</a>]</div>
And the accompanying CSS would (probably) be something like this:
h2 { font-size: 1.6em; float: left; border: none; padding: 0; } h2 span { display: block; padding-right: 0.3em; } div.editsection { border-bottom: 1px solid #aaa; line-height: 1.8em; padding-bottom:0.2em; }
One caveat to this approach is that the edit link is what's responsible for the bottom line on the section - which means if this is not present (as by __NOEDITSECTION__) then the whole thing would be broken. This would obviously have to be accounted for.
This isn't meant to be a final solution by any stretch - just a proof of concept that it _may_ be possible to create a semantically correct XHTML schema which results in German style edit link placement. I leave it to the CSS experts to come up with a better way :)
-- Jim
On 6/26/07, Danny B. Wikipedia.Danny.B@email.cz wrote:
Od: Jim Wilson wilson.jim.r@gmail.com
I don't like that much at all :( To me, putting the edit before the
header
seems even more likely to confuse people (thinking that the edit link belongs to the previous section)
Well, let me point out, that the gap in between the previous paragraph and editlink is pretty big (and can be done even bigger if necessary) comparing to the gap in between editlink and header, which actually almost doesn't exist, since it's sticked together. This is exactly the way which should clear all doubts about which part the editlink belongs to, if previous or following.
Kind regards
Danny B.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
One caveat to this approach is that the edit link is what's responsible for the bottom line on the section - which means if this is not present (as by __NOEDITSECTION__) then the whole thing would be broken. This would obviously have to be accounted for.
<div class="editsection"></div> ?
"Danny B." Wikipedia.Danny.B@email.cz wrote in message news:8974.10203-27903-941217633-1182873332@email.cz...
Advantages of the proposal (in no specific order):
- The editlink is now on the place where there are no doubts
of what section it belongs to (the reliability of this can be yet higher when changing the label from "edit" to "edit the following section" or something like that)
Actually, I had no idea whether the links in the 'final proposal' belonged to the paragraph above, or the paragraph below.
To me, it would be better if they went alongside the section head, and ideally there would be some sort of javascripting to highlight the area they apply to, to make it doubly clear.
I have posted a crude UI mock-up [1] of how I would envisage the edit links working. The icon (an 'e' in a circle) is just a crude example - in practice we would want something a lot nicer and non-language-specific. The blue highlighting in the mock-up indicates how we could highlight the section to be edited when the mouse moves over the link.
[1] http://www.mediawiki.org/wiki/Image:EditLinks_Suggestion.png
- Mark Clements (Happydog)
Mark Clements wrote:
I have posted a crude UI mock-up [1] of how I would envisage the edit links working. The icon (an 'e' in a circle) is just a crude example - in practice we would want something a lot nicer and non-language-specific. The blue highlighting in the mock-up indicates how we could highlight the section to be edited when the mouse moves over the link.
[1] http://www.mediawiki.org/wiki/Image:EditLinks_Suggestion.png
You could use icons, eg. http://es.wikipedia.org/skins-1.5/amethyst/edit.png Section-highlighting seems a good idea, i'd use it on diffs too. However, you'd need to change the way sections are dealt, as it's an isolated title. Some esoteric wikicode may break too.
On 6/26/07, Mark Clements gmane@kennel17.co.uk wrote:
To me, it would be better if they went alongside the section head, and ideally there would be some sort of javascripting to highlight the area they apply to, to make it doubly clear.
I have posted a crude UI mock-up [1] of how I would envisage the edit links working. The icon (an 'e' in a circle) is just a crude example - in practice we would want something a lot nicer and non-language-specific. The blue highlighting in the mock-up indicates how we could highlight the section to be edited when the mouse moves over the link.
[1] http://www.mediawiki.org/wiki/Image:EditLinks_Suggestion.png
The highlighting is another excellent idea. I would, however, be strongly inclined to stay away from icons, as we've done to date, when there are simple and more easily-understandable textual labels that would work just as well.
Simetrical-3 wrote:
On 6/26/07, Mark Clements gmane@kennel17.co.uk wrote:
To me, it would be better if they went alongside the section head, and ideally there would be some sort of javascripting to highlight the area they apply to, to make it doubly clear.
I have posted a crude UI mock-up [1] of how I would envisage the edit links working. The icon (an 'e' in a circle) is just a crude example - in practice we would want something a lot nicer and non-language-specific. The blue highlighting in the mock-up indicates how we could highlight the section to be edited when the mouse moves over the link.
[1] http://www.mediawiki.org/wiki/Image:EditLinks_Suggestion.png
The highlighting is another excellent idea. I would, however, be strongly inclined to stay away from icons, as we've done to date, when there are simple and more easily-understandable textual labels that would work just as well.
Actually I prefer the icons, because they provide a consistency which you simply cannot get with text. Whilst "edit" is blessedly succinct in English, I'll bet that in other languages the equivalent is much more verbose: this could be used in the alt-text just like at present.
Would it be possible to actually produce a "MySkin" which worked like this? If not, what more would be necessary to make this possible?
HTH HAND
Simetrical-3 wrote: The highlighting is another excellent idea. I would, however, be strongly inclined to stay away from icons, as we've done to date, when there are simple and more easily-understandable textual labels that would work just as well.
Please see http://www.aboutus.org/index.php?title=UniversalWikiEditButton where various wiki communities are trying to come to consensus on an edit icon which could be used on all wikis. It would be very useful to have more Wikipedians involved in this process.
On 7/2/07, Phil Boswell phil.boswell@gmail.com wrote: Actually I prefer the icons, because they provide a consistency which you simply cannot get with text. Whilst "edit" is blessedly succinct in English, I'll bet that in other languages the equivalent is much more verbose: this could be used in the alt-text just like at present.
Yes. See http://www.wikia.com/wiki/User:Angela/Edit for some examples.
Angela
On 7/2/07, Phil Boswell phil.boswell@gmail.com wrote:
Actually I prefer the icons, because they provide a consistency which you simply cannot get with text.
Also a lack of comprehensibility, especially cross-culturally. Icons are much more abstract than a word, and in particular they're more context-sensitive: a pen or eraser or anything else you can think of could just as easily be taken as "comment on this" or "make a personal note" or "write a message to the authors". Unless you're really exceptionally clever, perhaps, but with no offense to participants in making a UniversalWikiEditButton, nobody seems to have been quite that clever yet.
Of course, I'm not saying that "edit" is totally clear, but it at least rules out interpretations like "comment on this section".
Whilst "edit" is blessedly succinct in English, I'll bet that in other languages the equivalent is much more verbose
Thirteen characters as opposed to four, I counted the longest as being in Angela's link. Hardly going to mess up the display, even on a handheld, or be slow to read.
Would it be possible to actually produce a "MySkin" which worked like this? If not, what more would be necessary to make this possible?
You don't even need to use MySkin. Just change the 'editsection' message using MediaWiki:Editsection. It currently allows arbitrary HTML, such as images with alt text, to be inserted. Until r23645 just now, the brackets around [edit] were hardcoded, but I've just changed those to be removable (or localizable).
Simetrical wrote:
On 7/2/07, Phil Boswell wrote:
Actually I prefer the icons, because they provide a consistency which you simply cannot get with text.
Also a lack of comprehensibility, especially cross-culturally. Icons are much more abstract than a word, and in particular they're more context-sensitive: a pen or eraser or anything else you can think of could just as easily be taken as "comment on this" or "make a personal note" or "write a message to the authors". Unless you're really exceptionally clever, perhaps, but with no offense to participants in making a UniversalWikiEditButton, nobody seems to have been quite that clever yet.
Not if the very same icon is with the text "edit" on the upper tab (and it will also have a title="Edit this section" ).
On 7/2/07, Platonides Platonides@gmail.com wrote:
Not if the very same icon is with the text "edit" on the upper tab (and it will also have a title="Edit this section" ).
Maybe, but that requires that random users actually pay attention to the interface. It's still only obvious if you look. I remain skeptical.
Simetrical-3 wrote:
On 7/2/07, Phil Boswell phil.boswell@gmail.com wrote:
Actually I prefer the icons, because they provide a consistency which you simply cannot get with text.
Also a lack of comprehensibility, especially cross-culturally. Icons are much more abstract than a word, and in particular they're more context-sensitive: a pen or eraser or anything else you can think of could just as easily be taken as "comment on this" or "make a personal note" or "write a message to the authors". Unless you're really exceptionally clever, perhaps, but with no offense to participants in making a UniversalWikiEditButton, nobody seems to have been quite that clever yet. Of course, I'm not saying that "edit" is totally clear, but it at least rules out interpretations like "comment on this section".
Hence my suggestion to include the full textual message within the "title" attribute, which would appear as a tooltip.
Would it be possible to actually produce a "MySkin" which worked like this? If not, what more would be necessary to make this possible?
You don't even need to use MySkin. Just change the 'editsection' message using MediaWiki:Editsection. It currently allows arbitrary HTML, such as images with alt text, to be inserted. Until r23645 just now, the brackets around [edit] were hardcoded, but I've just changed those to be removable (or localizable).
Editing MediaWiki namespace is only available to admins: I'm asking for a solution which is available to anybody.
HTH HAND
On 7/2/07, Phil Boswell phil.boswell@gmail.com wrote:
Hence my suggestion to include the full textual message within the "title" attribute, which would appear as a tooltip.
Which will only appear if people actually hover over it, rather than anytime they happen to glance in that direction.
Anyway, as far as I'm concerned, unless someone provides good evidence that there's a concrete advantage to this, I'm going with my hunches and not personally implementing icons, although if specific wikis would like to they should be (and are) able to.
Editing MediaWiki namespace is only available to admins: I'm asking for a solution which is available to anybody.
Users who want to change it for themselves can use CSS, yes (.editsection a { color: transparent; background-image: ...; display: block; width: ...; height: ...; overflow: hidden; } or variants thereof), yes, and you don't need to resort to MySkin. (This happens to be possible to do with CSS, but even if it weren't it would certainly be easy with JavaScript, like virtually any other interface change. It's not even really necessary to ask whether it's possible to change the interface, the answer is virtually always yes if you're using JavaScript.)
Hi Simetrical,
Regarding your complaint about confusion of meaning - that a user will confuse the meaning of the symbol. As I understand it, that's what the universal edit button initiative is meant to solve.
There are already a large number of symbols which are understood by the general populace, making one for "edit this" seems a worthy endeavor - as the concept is appearing more and more often.
Off the top of my head, here are a few other symbols with known meaning:
* Left arrow: go back / reverse * Right arrow: go forward / advance * Circular arrow: refresh * House: Home page * Red X or white X against a solid red circle: Stop * Speech bubble (as in a cartoon): Chat * 3 1/4 Floppy disk: Save * White curves on orange background: RSS/Atom feed * Isosceles triangle facing rightwards: Play or GO
These are just a few I can see here on Gmail running in Firefox - I'm sure there are myriad others. Unfortunately, one thing for which there isn't a universal symbol yet is "edit this". Hopefully there will be soon, and we won't have to have this debate :)
-- Jim R. Wilson (jimbojw)
On 7/2/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 7/2/07, Phil Boswell phil.boswell@gmail.com wrote:
Hence my suggestion to include the full textual message within the
"title"
attribute, which would appear as a tooltip.
Which will only appear if people actually hover over it, rather than anytime they happen to glance in that direction.
Anyway, as far as I'm concerned, unless someone provides good evidence that there's a concrete advantage to this, I'm going with my hunches and not personally implementing icons, although if specific wikis would like to they should be (and are) able to.
Editing MediaWiki namespace is only available to admins: I'm asking for
a
solution which is available to anybody.
Users who want to change it for themselves can use CSS, yes (.editsection a { color: transparent; background-image: ...; display: block; width: ...; height: ...; overflow: hidden; } or variants thereof), yes, and you don't need to resort to MySkin. (This happens to be possible to do with CSS, but even if it weren't it would certainly be easy with JavaScript, like virtually any other interface change. It's not even really necessary to ask whether it's possible to change the interface, the answer is virtually always yes if you're using JavaScript.)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
"Simetrical" Simetrical+wikilist@gmail.com wrote in message news:7c2a12e20707021637w3f10a167u85fa5ab624bd58fc@mail.gmail.com...
On 7/2/07, Phil Boswell
phil.boswell@gmail.com wrote:
Hence my suggestion to include the full textual message within the
"title"
attribute, which would appear as a tooltip.
Which will only appear if people actually hover over it, rather than anytime they happen to glance in that direction.
Anyway, as far as I'm concerned, unless someone provides good evidence that there's a concrete advantage to this, I'm going with my hunches and not personally implementing icons, although if specific wikis would like to they should be (and are) able to.
By your argument, icons are always bad!
Icons are necessarily at least _slightly_ less clear than text. It is not particularly intuitive that a picture of a house means go back to the starting page, but it has become recognised as such through consistent use between many browsers and websites. A standardised 'edit' button would do the same. If you read the discussion about UniversalWikiEditButton you would see the advice that for a period of adoption, the icon and text are displayed together so that users can become familiar with the link, and that once it has been widely adopted, the text could then be removed.
The problem with just text as a link, is that it can easily get lost amongst a page that is already predominantly text with links. Particularly if it gets moved to the left-hand side, so it is more embedded in the text.
Your 'hunch' goes against pretty much every UI study ever :-)
- Mark Clements (HappyDog)
On 7/3/07, Mark Clements gmane@kennel17.co.uk wrote:
Icons are necessarily at least _slightly_ less clear than text. It is not particularly intuitive that a picture of a house means go back to the starting page, but it has become recognised as such through consistent use between many browsers and websites. A standardised 'edit' button would do the same.
Sure, if you expect everyone to start editing wikis. People recognize the house icon because 1) that's the standard icon *and* 2) everyone uses browsers, which use the standard icon. People wouldn't be familiar with the home icon if they didn't use browsers all the time, and likewise people wouldn't be familiar with a wiki edit button unless they edited wikis all the time. Which I don't think is the kind of people we should be predominantly catering to primarily just yet.
I'm viewing the ideal edit link, at present, as one that entices as many new users as possible to use it, and despite your reference to "pretty much every UI study ever", I don't see how that goal is achieved by replacing text with icons that no one will recognize (yet). An *accompanying* icon is a different question, that I don't see anything wrong with, but I'm sure not going to be the one enduring a firestorm by modifying Monobook's entrenched aesthetics.
This is all rather off the topic, anyway. I'll wait a little longer, but I do plan to do what I said, really. Not like the time I announced on this list that I would change over all the id's and classes in the software to be consistent (which would probably have been a bad idea anyway).
On 03/07/07, Simetrical Simetrical+wikilist@gmail.com wrote:
(yet). An *accompanying* icon is a different question, that I don't see anything wrong with, but I'm sure not going to be the one enduring a firestorm by modifying Monobook's entrenched aesthetics.
*cough*
Rob Church
On 7/3/07, Rob Church robchur@gmail.com wrote:
On 03/07/07, Simetrical Simetrical+wikilist@gmail.com wrote:
(yet). An *accompanying* icon is a different question, that I don't see anything wrong with, but I'm sure not going to be the one enduring a firestorm by modifying Monobook's entrenched aesthetics.
*cough*
Okay, I admit that was slightly ironic.
Aside from a firestorm, what actual recourse do concerned MW advocates have regarding this proposed (*cough* horrible *cough*) change to the UI?
-- Jim
On 7/3/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 7/3/07, Rob Church robchur@gmail.com wrote:
On 03/07/07, Simetrical Simetrical+wikilist@gmail.com wrote:
(yet). An *accompanying* icon is a different question, that I don't see anything wrong with, but I'm sure not going to be the one enduring a firestorm by modifying Monobook's entrenched aesthetics.
*cough*
Okay, I admit that was slightly ironic.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 7/4/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Aside from a firestorm, what actual recourse do concerned MW advocates have regarding this proposed (*cough* horrible *cough*) change to the UI?
For the software itself, you have to convince either me to not do it or Brion to overrule me. For any particular wiki, that's up to whoever has the ability to edit the site stylesheet. But just to clarify, the solution I intend to implement is the German style, which previous posts in this thread by you seemed to imply you were okay with, although I might have misread them.
But just to clarify, the solution I intend to implement is the German
style, which
previous posts in this thread by you seemed to imply you were okay with, although I might have misread them.
Thanks for clarifying - I mistakenly thought the decision was still to put it all the way to the left. :(
If a change must be made, the German style is the only choice I support.
-- Jim
On 7/3/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 7/4/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Aside from a firestorm, what actual recourse do concerned MW advocates
have
regarding this proposed (*cough* horrible *cough*) change to the UI?
For the software itself, you have to convince either me to not do it or Brion to overrule me. For any particular wiki, that's up to whoever has the ability to edit the site stylesheet. But just to clarify, the solution I intend to implement is the German style, which previous posts in this thread by you seemed to imply you were okay with, although I might have misread them.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
"Jim Wilson" wilson.jim.r@gmail.com wrote in message news:ac08e8d0707032209v73b878c3s7c1d31385d435cca@mail.gmail.com...
But just to clarify, the solution I intend to implement is the German
style, which
previous posts in this thread by you seemed to imply you were okay with, although I might have misread them.
Thanks for clarifying - I mistakenly thought the decision was still to put it all the way to the left. :(
If a change must be made, the German style is the only choice I support.
At the moment, my only strong feeling is that any change made right now should fix the current underlying syntax of the tags, so that 1) It is semantically valid (no link embedded in the header tag) 2) It is semantically meaningful (edit link should be between header and text, rather than in an ambiguous location) 2) It renders well with no CSS (will probably automatically follow from the above) 3) It gives us the flexibility to use CSS to create any of the suggested layouts.
The update should contain default CSS that leaves MW acting the way it did before, but with clear instructions somewhere (on MW.org?) about how to add the CSS to acheive alternative results.
If that is done then it will give us the opportunity to experiment with different edit button styles a lot more easily, in order to find a solution that will fix all our problems.
However, I would caution against jumping in and making visible changes to the wikis themselves as this is an ongoing discussion working towards a good general solution, and it is not good PR to keep changing the page layout...
- Mark Clements (HappyDog)
On 7/4/07, Mark Clements gmane@kennel17.co.uk wrote:
At the moment, my only strong feeling is that any change made right now should fix the current underlying syntax of the tags, so that
- It is semantically valid (no link embedded in the header tag)
Well, okay, but last time I tried to do that (undoing my own stupidity) I broke a bunch of scripts and Brion reverted it. Reordering two elements should have minimal impact, but adding and removing elements will have an impact. I don't know if I want to make both of these changes at once.
- It is semantically meaningful (edit link should be between header and
text, rather than in an ambiguous location)
In either case the edit link and header will undoubtedly be wrapped in a div (to, e.g., provide the lower border and appropriate padding), so I don't see a lack of semantic clarity here from a source-code level.
- It renders well with no CSS (will probably automatically follow from the
above)
Well, not so trivial if by "render well" you exclude the header and the section link from being on different lines. <h#> is a block-level element, so whether the section edit link is inline or block, it will render on a different line unless one or the other element is styled. In fact, the only way to allow it to render on one line without CSS is to not use <h#> for the header itself, and use a <span> instead, like the current (icky and not-really-semantic) header markup. If you don't mind header and link from being on different lines, sure, it'll render okay.
But this also runs back into point 2 (well, the first point 2 :P), in that depending on document structure it may render above the header link, quite ambiguously, instead of below, less ambiguously.
- It gives us the flexibility to use CSS to create any of the suggested
layouts.
Not so easy if you want to adhere to the last two points. In particular, IE and Firefox both push down any float that's not at the beginning of a line, so there's no way I know of at least to have the current behavior with the edit section link after the header in the source. That's why it comes before the header in the first place.
I *have* seen a proposed implementation of the right-floating link that doesn't use floats, and instead uses absolute positioning, with the link after the header text in the source. However, I don't know if that has sinister drawbacks that will only be noticed after a couple of weeks of usage, akin to the right floats' tendency to get shoved out of the way by other floats.
The update should contain default CSS that leaves MW acting the way it did before, but with clear instructions somewhere (on MW.org?) about how to add the CSS to acheive alternative results.
That defeats my purpose in all this, which is to make MediaWiki more usable out of the box. The idea isn't to write nice custom styles that people can use if they want. (It's not to force them to use styles they don't want to use, either, so whatever I do there *will* be clear instructions on how to reverse it.)
However, I would caution against jumping in and making visible changes to the wikis themselves as this is an ongoing discussion working towards a good general solution, and it is not good PR to keep changing the page layout...
As long as there's ongoing discussion, sure. Once everyone's had their say, and it's all properly thought out, I don't see any reason to continue to delay on the pretense that there's more that will be said. As far as I'm aware, this discussion is the only active one on the topic, so once nobody's commenting anymore it'll be time to move forward.
There are two important, separate, but related issues in all this:
1) Positioning of Edit link relative to Header in the fully rendered CSS enabled version 2) Positioning and ordering of the HTML tags used
It seems we're all in agreement that the goal of the upcoming change is to move the edit link from the far right to the near right (German style) - that takes care of #1.
Regarding the second issue - what Mark was saying (and a point to which I agree) is that the edit link tag should _follow_ the header tag (regardless of whether they're all wrapped in a div or not).
Do we all agree on that point? or is there still some desire to put the edit link before the header tag?
Also, if the edit link tag follows the header tag, I personally think this solves the "renders well" issue - except maybe in the case of high-numbered headers like h5 or h6 where the edit link text may actually be larger than the heading. Something to consider.
-- Jim
On 7/4/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 7/4/07, Mark Clements gmane@kennel17.co.uk wrote:
At the moment, my only strong feeling is that any change made right now should fix the current underlying syntax of the tags, so that
- It is semantically valid (no link embedded in the header tag)
Well, okay, but last time I tried to do that (undoing my own stupidity) I broke a bunch of scripts and Brion reverted it. Reordering two elements should have minimal impact, but adding and removing elements will have an impact. I don't know if I want to make both of these changes at once.
- It is semantically meaningful (edit link should be between header and
text, rather than in an ambiguous location)
In either case the edit link and header will undoubtedly be wrapped in a div (to, e.g., provide the lower border and appropriate padding), so I don't see a lack of semantic clarity here from a source-code level.
- It renders well with no CSS (will probably automatically follow from
the
above)
Well, not so trivial if by "render well" you exclude the header and the section link from being on different lines. <h#> is a block-level element, so whether the section edit link is inline or block, it will render on a different line unless one or the other element is styled. In fact, the only way to allow it to render on one line without CSS is to not use <h#> for the header itself, and use a <span> instead, like the current (icky and not-really-semantic) header markup. If you don't mind header and link from being on different lines, sure, it'll render okay.
But this also runs back into point 2 (well, the first point 2 :P), in that depending on document structure it may render above the header link, quite ambiguously, instead of below, less ambiguously.
- It gives us the flexibility to use CSS to create any of the suggested
layouts.
Not so easy if you want to adhere to the last two points. In particular, IE and Firefox both push down any float that's not at the beginning of a line, so there's no way I know of at least to have the current behavior with the edit section link after the header in the source. That's why it comes before the header in the first place.
I *have* seen a proposed implementation of the right-floating link that doesn't use floats, and instead uses absolute positioning, with the link after the header text in the source. However, I don't know if that has sinister drawbacks that will only be noticed after a couple of weeks of usage, akin to the right floats' tendency to get shoved out of the way by other floats.
The update should contain default CSS that leaves MW acting the way it
did
before, but with clear instructions somewhere (on MW.org?) about how to
add
the CSS to acheive alternative results.
That defeats my purpose in all this, which is to make MediaWiki more usable out of the box. The idea isn't to write nice custom styles that people can use if they want. (It's not to force them to use styles they don't want to use, either, so whatever I do there *will* be clear instructions on how to reverse it.)
However, I would caution against jumping in and making visible changes
to
the wikis themselves as this is an ongoing discussion working towards a
good
general solution, and it is not good PR to keep changing the page
layout...
As long as there's ongoing discussion, sure. Once everyone's had their say, and it's all properly thought out, I don't see any reason to continue to delay on the pretense that there's more that will be said. As far as I'm aware, this discussion is the only active one on the topic, so once nobody's commenting anymore it'll be time to move forward.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 7/5/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Regarding the second issue - what Mark was saying (and a point to which I agree) is that the edit link tag should _follow_ the header tag (regardless of whether they're all wrapped in a div or not).
Do we all agree on that point? or is there still some desire to put the edit link before the header tag?
Putting it after would be fine if someone can demonstrate that a solution using absolute positioning can replicate current behavior in major browsers (including in corner cases). That's probably doable, but it needs to be done before rejiggering the elements, since the old way still needs to be an option.
"Jim Wilson" wilson.jim.r@gmail.com wrote in message news:ac08e8d0707042142n60a6a715j801e9323541b4d90@mail.gmail.com...
There are two important, separate, but related issues in all this:
- Positioning of Edit link relative to Header in the fully rendered CSS
enabled version 2) Positioning and ordering of the HTML tags used
It seems we're all in agreement that the goal of the upcoming change is to move the edit link from the far right to the near right (German style) - that takes care of #1.
I'm not sure we are, quite. I think we're agreed that it should be moved from the right side of the page to the left side, but so far I have seen three viable solutions:
1) To the right of the header (German style) 2) Below the header (consistent position and neater, but requires an extra line.) 3) An icon in the left margin (consistent position, less intrusive, there are some objections to the use of an icon and this solution wouldn't work with a text label).
And two solutions which, in my opinion, are not viable.
4) Above the header (even more confusing than on the right) 5) To the left of the header, on the same line (consistent location, but makes headers ugly and less prominent
To be honest, my preference is for either 2 or 3, but 1 also seems to be popular and I am not dead against it.
Regarding the second issue - what Mark was saying (and a point to which I agree) is that the edit link tag should _follow_ the header tag
(regardless
of whether they're all wrapped in a div or not).
Do we all agree on that point? or is there still some desire to put the
edit
link before the header tag?
Agreed. I also think it would be _very_ useful if each section was wrapped in a section div.
Also, if the edit link tag follows the header tag, I personally think this solves the "renders well" issue - except maybe in the case of
high-numbered
headers like h5 or h6 where the edit link text may actually be larger than the heading. Something to consider.
Maybe, though you would still have the problem wherever it was placed.
- Mark Clements (HappyDog)
"Simetrical" Simetrical+wikilist@gmail.com wrote in message news:7c2a12e20707041224w520d42f3vd585ead4df93fb29@mail.gmail.com...
On 7/4/07, Mark Clements gmane@kennel17.co.uk
wrote:
- It is semantically meaningful (edit link should be between header and
text, rather than in an ambiguous location)
In either case the edit link and header will undoubtedly be wrapped in a div (to, e.g., provide the lower border and appropriate padding), so I don't see a lack of semantic clarity here from a source-code level.
If that's the case, then fine. However, currently there are no section divs (which there should be...).
- It renders well with no CSS (will probably automatically follow from
the
above)
Well, not so trivial if by "render well" you exclude the header and the section link from being on different lines. <h#> is a block-level element, so whether the section edit link is inline or block, it will render on a different line unless one or the other element is styled. In fact, the only way to allow it to render on one line without CSS is to not use <h#> for the header itself, and use a <span> instead, like the current (icky and not-really-semantic) header markup. If you don't mind header and link from being on different lines, sure, it'll render okay.
That's fine by me.
But this also runs back into point 2 (well, the first point 2 :P), in that depending on document structure it may render above the header link, quite ambiguously, instead of below, less ambiguously.
That's what we need to avoid.
- It gives us the flexibility to use CSS to create any of the suggested
layouts.
Not so easy if you want to adhere to the last two points. In particular, IE and Firefox both push down any float that's not at the beginning of a line, so there's no way I know of at least to have the current behavior with the edit section link after the header in the source. That's why it comes before the header in the first place.
I *have* seen a proposed implementation of the right-floating link that doesn't use floats, and instead uses absolute positioning, with the link after the header text in the source. However, I don't know if that has sinister drawbacks that will only be noticed after a couple of weeks of usage, akin to the right floats' tendency to get shoved out of the way by other floats.
That sounds promising. I am all too familiar with the nightmare of CSS juggling, so I am aware that such an ideal solution may not be possible, and if not then there's nothing we can do about that, but we should definitely be aiming for it.
The update should contain default CSS that leaves MW acting the way it
did
before, but with clear instructions somewhere (on MW.org?) about how to
add
the CSS to acheive alternative results.
That defeats my purpose in all this, which is to make MediaWiki more usable out of the box. The idea isn't to write nice custom styles that people can use if they want. (It's not to force them to use styles they don't want to use, either, so whatever I do there *will* be clear instructions on how to reverse it.)
However, I would caution against jumping in and making visible changes
to
the wikis themselves as this is an ongoing discussion working towards a
good
general solution, and it is not good PR to keep changing the page
layout...
As long as there's ongoing discussion, sure. Once everyone's had their say, and it's all properly thought out, I don't see any reason to continue to delay on the pretense that there's more that will be said. As far as I'm aware, this discussion is the only active one on the topic, so once nobody's commenting anymore it'll be time to move forward.
These paragraphs were a response to your previous post where you said "the solution I intend to implement is the German style". My point is that there are other alternatives, and some of them may be better, and until we've finished discussing them and settled on an optimal visual solution, then it would be rash to make visible changes such as this on live wikis, as they may well change again as the result of this discussion.
If you want to start coding anything right now, then it should be the underlying semantic/HTML changes, but these changes shouldn't alter current layout. If you plan to implement it all at once after this discussion is over, then that's fine and there should be no problems making the change. I think we are in agreement.
- Mark Clements (HappyDog)
On 7/5/07, Mark Clements gmane@kennel17.co.uk wrote:
If that's the case, then fine. However, currently there are no section divs (which there should be...).
The edit link and the header text are the only two children of a header wrapper (at present, the wrapper is <h#>; ideally, it should be a <div>). As for section divs, there really can't be, without a lot of work. It's not really on-topic here, but I'll post some more comments to http://bugzilla.wikimedia.org/show_bug.cgi?id=6104 in a second.
On 7/3/07, Simetrical Simetrical+wikilist@gmail.com wrote:
Also a lack of comprehensibility, especially cross-culturally. Icons are much more abstract than a word, and in particular they're more context-sensitive: a pen or eraser or anything else you can think of could just as easily be taken as "comment on this" or "make a personal note" or "write a message to the authors". Unless you're really exceptionally clever, perhaps, but with no offense to participants in making a UniversalWikiEditButton, nobody seems to have been quite that clever yet.
This isn't a very compelling argument against having an icon. Every pen or notepad or whatever icon *everywhere* has one of several possible interpretations. You click the button, you'll find out which one is right in this context.
There are downsides to icons, but this is a good place for one: we're short on space, we want to avoid language-specific text, and the icon will be seen thousands of times over. All of these factors weigh heavily in favour of an icon.
Steve PS In looking at MediaWiki now, it's remarkable how few icons we actually use. The only one I can see is the little "person" icon next to the username link in the menu. Oh, and the 'this page is protected' icon, and a couple of others, but they're sort of wikipedia-specific.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Steve Bennett wrote:
This isn't a very compelling argument against having an icon. Every pen or notepad or whatever icon *everywhere* has one of several possible interpretations. You click the button, you'll find out which one is right in this context.
To make a long story short, my executive decision is that we are not going to add an icon there in the near future.
It might be interesting to see some mockups and discuss them in the future, but that's a fight for another day. :)
- -- brion vibber (brion @ wikimedia.org)
"Brion Vibber" brion@wikimedia.org wrote in message news:468CF5BF.9010206@wikimedia.org...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Steve Bennett wrote:
This isn't a very compelling argument against having an icon. Every pen or notepad or whatever icon *everywhere* has one of several possible interpretations. You click the button, you'll find out which one is right in this context.
To make a long story short, my executive decision is that we are not going to add an icon there in the near future.
It might be interesting to see some mockups and discuss them in the future, but that's a fight for another day. :)
Fair enough. Can't argue with an executive decision.
Any chance of hearing the reasons behind it?
- Mark Clements (HappyDog)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Clements wrote:
To make a long story short, my executive decision is that we are not going to add an icon there in the near future.
It might be interesting to see some mockups and discuss them in the future, but that's a fight for another day. :)
Fair enough. Can't argue with an executive decision.
Any chance of hearing the reasons behind it?
1) It's unrelated to the subject already under discussion.
2) That leads to tangential, useless fighting.
3) Icons are annoying, hard to understand, and very unobvious when not already clear standards. This raises the barrier to making any kind of decision about them, and when it's already a contentious issue that's not what's on the table, I have no interest in wading through dozens of threads about it when we could, instead, actually get something productive done.
- -- brion vibber (brion @ wikimedia.org)
"Brion Vibber" brion@wikimedia.org wrote in message news:468D2A54.3010701@wikimedia.org...
Mark Clements wrote:
To make a long story short, my executive decision is that we are not going to add an icon there in the near future.
It might be interesting to see some mockups and discuss them in the future, but that's a fight for another day. :)
Fair enough. Can't argue with an executive decision.
Any chance of hearing the reasons behind it?
[SNIPPED: Some good reasons]
Thanks for taking the time to respond.
- Mark Clements (HappyDog)
On 7/5/07, Brion Vibber brion@wikimedia.org wrote:
To make a long story short, my executive decision is that we are not going to add an icon there in the near future.
I like executive decisions! They save so much time in argument :)
Steve
Okay, I did a little case study. The subject was a professor of art history, the kind of person who's not technically inclined but whose contributions to something like Wikipedia would be invaluable. I looked through articles from the English Wikipedia's "in the news" section for a suitable test, and found that Venus Williams had a good stretch to look at, three second-level headings in a row with no intervening headings. I prepared a screen with the usual edit section links:
http://img405.imageshack.us/my.php?image=mediawikiheadingstest1ccg7.png
And a modified version with edit section links like the Germans have:
http://img524.imageshack.us/my.php?image=mediawikiheadingstest2cgh0.png
I told her I wanted to use her as a guinea pig for usability, which she agreed to. I showed her the first image and asked what she thought the middle edit link (corresponding to the 2004 section) would do. She replied without hesitation that it would allow her to edit the preceding section, 2003. Then I showed her the second image and asked the same question. She expressed considerable confusion, and after some thought said she didn't know *what* it would do. When I explained the actual function of the link, she was completely astonished that anyone could make anything like the current layout without meaning for the edit link to correspond to the previous section. This appears to correspond with the German usability study's participants' confusion, which was great enough that they just deleted the unexpected existing text, and it reinforces my commitment to get it changed.
But she was also, as I said, confused about the second choice, as the Germans have it. Happily, she was an art professor, so she was able to articulate her issues well and make constructive suggestions. She remarked that having the line under the section header was unusual and confusing, and suggested it be moved above the header. (I don't think this is feasible as an aesthetic change, given that the problem will remain for third-level and deeper headings.) She thought it was much more natural for the edit link to be in the lower right of the section instead of anywhere on the top, saying something to the effect of that it made more sense to want to edit the section *after* you've read it, if I understood her correctly. I showed her the suggestion with a downward-pointing arrow, and her opinion on that was that it was inelegant and unexpected, but that at least if you *thought* about it it was unambiguous.
It might be a good idea to consider other software packages for comparison. Of forum packages, vBulletin has edit links on the bottom of posts, SMF and IPB (at least the invisionfree.com version of IPB) on the top. Those aren't terribly useful to us, because posts are more clearly marked as discrete than sections, since they are in fact discrete. They're in their own boxes and all, so there can't be much confusion. DokuWiki.com, at least, has the edit links at the right as MediaWiki does, so no help there. A couple of other packages I glanced at (Instiki, PmWiki) seem to have no section edit links at all. Overall that doesn't seem a very helpful line of inquiry.
So: I'm not sure I want to muck around with the skin's aesthetics so much. I'm a programmer, not a designer. If someone else can come up with suggestions that are both intuitive and pretty, be my guest, but for now my primary thought is 1) have the edit link immediately next to the header text, like the Germans; 2) have a downward-pointing arrow as part of the link text; and 3) add JavaScript that will, when your mouse moves over the edit link, highlight the text that will be editable by clicking. I don't think this is great, but I think it will make it very hard to be confused by the time you actually get to the edit page, which is a lot more than can be said for the current layout.
Nice to have some data, however anecdotal.
The hierarchical nature of the sections also makes putting the edit links on the bottom a poor choice, IMHO. I'm envisioning a pileup of edit links at the bottom of a page, each of which grabs a larger chunk of the text above.
I wonder if you could simulate a tab-like appearance surrounding the link if that would be clearer. Not that I know how to do that in css.
Jim
On Jul 15, 2007, at 5:38 PM, Simetrical wrote:
Okay, I did a little case study. The subject was a professor of art history, the kind of person who's not technically inclined but whose contributions to something like Wikipedia would be invaluable. I looked through articles from the English Wikipedia's "in the news" section for a suitable test, and found that Venus Williams had a good stretch to look at, three second-level headings in a row with no intervening headings. I prepared a screen with the usual edit section links:
http://img405.imageshack.us/my.php? image=mediawikiheadingstest1ccg7.png
And a modified version with edit section links like the Germans have:
http://img524.imageshack.us/my.php? image=mediawikiheadingstest2cgh0.png
I told her I wanted to use her as a guinea pig for usability, which she agreed to. I showed her the first image and asked what she thought the middle edit link (corresponding to the 2004 section) would do. She replied without hesitation that it would allow her to edit the preceding section, 2003. Then I showed her the second image and asked the same question. She expressed considerable confusion, and after some thought said she didn't know *what* it would do. When I explained the actual function of the link, she was completely astonished that anyone could make anything like the current layout without meaning for the edit link to correspond to the previous section. This appears to correspond with the German usability study's participants' confusion, which was great enough that they just deleted the unexpected existing text, and it reinforces my commitment to get it changed.
But she was also, as I said, confused about the second choice, as the Germans have it. Happily, she was an art professor, so she was able to articulate her issues well and make constructive suggestions. She remarked that having the line under the section header was unusual and confusing, and suggested it be moved above the header. (I don't think this is feasible as an aesthetic change, given that the problem will remain for third-level and deeper headings.) She thought it was much more natural for the edit link to be in the lower right of the section instead of anywhere on the top, saying something to the effect of that it made more sense to want to edit the section *after* you've read it, if I understood her correctly. I showed her the suggestion with a downward-pointing arrow, and her opinion on that was that it was inelegant and unexpected, but that at least if you *thought* about it it was unambiguous.
It might be a good idea to consider other software packages for comparison. Of forum packages, vBulletin has edit links on the bottom of posts, SMF and IPB (at least the invisionfree.com version of IPB) on the top. Those aren't terribly useful to us, because posts are more clearly marked as discrete than sections, since they are in fact discrete. They're in their own boxes and all, so there can't be much confusion. DokuWiki.com, at least, has the edit links at the right as MediaWiki does, so no help there. A couple of other packages I glanced at (Instiki, PmWiki) seem to have no section edit links at all. Overall that doesn't seem a very helpful line of inquiry.
So: I'm not sure I want to muck around with the skin's aesthetics so much. I'm a programmer, not a designer. If someone else can come up with suggestions that are both intuitive and pretty, be my guest, but for now my primary thought is 1) have the edit link immediately next to the header text, like the Germans; 2) have a downward-pointing arrow as part of the link text; and 3) add JavaScript that will, when your mouse moves over the edit link, highlight the text that will be editable by clicking. I don't think this is great, but I think it will make it very hard to be confused by the time you actually get to the edit page, which is a lot more than can be said for the current layout.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
On 7/15/07, Jim Hu jimhu@tamu.edu wrote:
The hierarchical nature of the sections also makes putting the edit links on the bottom a poor choice, IMHO. I'm envisioning a pileup of edit links at the bottom of a page, each of which grabs a larger chunk of the text above.
Good point. It's not really possible with current sectioning.
I wonder if you could simulate a tab-like appearance surrounding the link if that would be clearer. Not that I know how to do that in css.
I'm not clear what you're describing here.
On 7/16/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 7/15/07, Jim Hu jimhu@tamu.edu wrote:
I wonder if you could simulate a tab-like appearance surrounding the link if that would be clearer. Not that I know how to do that in css.
I'm not clear what you're describing here.
Like the tabs at the very top of the page (article, discussion, edit this page, history...).
That would work very nicely for the headings with underlines, but not so well for lower level headings.
Yes, exactly. I was thinking something like
Top level heading _______________| edit |__
lower level heading ..._| edit |_...
with the lines connecting over the edit link, of course. I suppose that if one was going to do an icon, it could be an icon with text in it that looks like a tab. I'm not sure this actually a good idea myself.... just thinking in public in response to the discussion. I'm building up my wiki, and the proliferation of section edit links does look like it will be confusing. I'll be doing a workshop in a couple of weeks to show people how to use it, so it will be interesting to see what my user community thinks.
Jim
On Jul 15, 2007, at 9:13 PM, Stephen Bain wrote:
On 7/16/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 7/15/07, Jim Hu jimhu@tamu.edu wrote:
I wonder if you could simulate a tab-like appearance surrounding the link if that would be clearer. Not that I know how to do that in css.
I'm not clear what you're describing here.
Like the tabs at the very top of the page (article, discussion, edit this page, history...).
That would work very nicely for the headings with underlines, but not so well for lower level headings.
-- Stephen Bain stephen.bain@gmail.com
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Hu wrote:
Yes, exactly. I was thinking something like
Top level heading _______________| edit |__
lower level heading ..._| edit |_...
with the lines connecting over the edit link, of course. I suppose that if one was going to do an icon, it could be an icon with text in it that looks like a tab. I'm not sure this actually a good idea myself.... just thinking in public in response to the discussion.
I threw together a quick test for comment:
http://test.leuksman.com/view/Venus_Williams#2003
The patch: http://test.leuksman.com/tab-test.diff
- -- brion vibber (brion @ wikimedia.org)
Brion Vibber wrote:
I threw together a quick test for comment:
I like that. Now to really complicate things, I wonder if you couldn't do both the heading and the edit as this kind of pseudo-tab?
___| Header Text |___| edit |________________________
Keeping the tabs relatively close together would be consistent with other tab usage in web pages.
Mike
On 16/07/07, Brion Vibber brion@wikimedia.org wrote:
I threw together a quick test for comment:
Oooh, looks interesting. I like the effect, but the tabs seem a bit "big", if you know what I mean...then again, making them smaller would probably mean they ended up too inconspicuous to notice at all.
Rob Church
Also, make sure the tab stays connected when you scale down the browser to 800x600 - or for exceptionally long section headings in reasonable res.
For me, they're disconnecting :(
-- Jim
On 7/16/07, Rob Church robchur@gmail.com wrote:
On 16/07/07, Brion Vibber brion@wikimedia.org wrote:
I threw together a quick test for comment:
Oooh, looks interesting. I like the effect, but the tabs seem a bit "big", if you know what I mean...then again, making them smaller would probably mean they ended up too inconspicuous to notice at all.
Rob Church
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Wilson wrote:
Also, make sure the tab stays connected when you scale down the browser to 800x600 - or for exceptionally long section headings in reasonable res.
For me, they're disconnecting :(
It's only a model.
- -- brion
"Brion Vibber" brion@wikimedia.org wrote in message news:469BAE99.90608@wikimedia.org...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Wilson wrote:
Also, make sure the tab stays connected when you scale down the browser
to
800x600 - or for exceptionally long section headings in reasonable res.
For me, they're disconnecting :(
It's only a model.
ssh!
- Mark Clements (HappyDog)
On Mon, 2007-07-16 at 20:44 +0100, Mark Clements wrote:
It's only a model.
ssh!
/me whispers "Concertina padding"
On Mon, Jul 16, 2007 at 11:09:08AM -0500, Jim Wilson wrote:
Also, make sure the tab stays connected when you scale down the browser to 800x600 - or for exceptionally long section headings in reasonable res.
For me, they're disconnecting :(
"Ctrl-+"
Cheers, -- jra
On 7/17/07, Rob Church robchur@gmail.com wrote:
Oooh, looks interesting. I like the effect, but the tabs seem a bit "big", if you know what I mean...then again, making them smaller would probably mean they ended up too inconspicuous to notice at all.
I was talking to mum about a Wikipedia article that she'd noticed an error in. I asked why she didn't correct it, she said she didn't know how. I asked "Didn't you see the links that said 'edit'?" "No, what links?"
They *are* pretty small. Should we consider making the logged-out and logged-in skins more divergent? Then we could have big friend 'edit' links for anons, and smaller more elegant ones for regulars.
Steve
Steve Bennett wrote:
On 7/17/07, Rob Church wrote:
Oooh, looks interesting. I like the effect, but the tabs seem a bit "big", if you know what I mean...then again, making them smaller would probably mean they ended up too inconspicuous to notice at all.
I was talking to mum about a Wikipedia article that she'd noticed an error in. I asked why she didn't correct it, she said she didn't know how. I asked "Didn't you see the links that said 'edit'?" "No, what links?"
They *are* pretty small. Should we consider making the logged-out and logged-in skins more divergent? Then we could have big friend 'edit' links for anons, and smaller more elegant ones for regulars.
Steve
But most anons will be interested in reading, not in editing :S
On 16/07/07, Brion Vibber brion@wikimedia.org wrote:
I threw together a quick test for comment: http://test.leuksman.com/view/Venus_Williams#2003
I like it!
http://i17.tinypic.com/68jnvo4.jpg shows a possible confusion: ==h2== followed immediately by ===h3=== gives a possibly confusing pile of tags. Perhaps this could be tweaked per skin - Monobook does the possibly-confusing horizontal line for h2 but not for other heading levels. So only do a tab for h2, and a link for the others?
- d.
On 7/17/07, Brion Vibber brion@wikimedia.org wrote:
I threw together a quick test for comment:
I actually really like that. And who said programmers were no good at graphic design...
Steve
On 7/16/07, Dschwen lists@schwen.de wrote:
Adding the javascript (if that is possible, given that we can't just wrap each section in a div tag) would imho, largely solve the problem. It may
Please check [[User:Dschwen/HighlightSection.js]]
include in monobook.js, refresh cache, etc., you know the drill
Some comments in the code would be good so it could be better reviewed. Also, I'd imagine a single box surrounding all the code (including the header itself) would look quite a bit nicer. That could maybe be accomplished by wrapping the relevant elements in divs via JS, so that the background on the div will include the elements' margins. Overall, though, it looks nice, certainly a good start, even if I'd choose a slightly different color myself. :)
On 7/16/07, Jim Hu jimhu@tamu.edu wrote:
Yes, exactly. I was thinking something like
Top level heading _______________| edit |__
lower level heading ..._| edit |_...
with the lines connecting over the edit link, of course. I suppose that if one was going to do an icon, it could be an icon with text in it that looks like a tab. I'm not sure this actually a good idea myself.... just thinking in public in response to the discussion.
Hmm. That's definitely an idea to consider, yes.
On 7/16/07, Mark Clements gmane@kennel17.co.uk wrote:
Adding the javascript (if that is possible, given that we can't just wrap each section in a div tag) would imho, largely solve the problem.
I don't think so. You don't want people to form an idea of what a button will do, and then try to use it only to be told it does something else. Ideally you want it to be clear at first glance what it does; if that's not possible, at least have it be unclear at first glance. You absolutely do not want to have it be clear at first glance that it does something it does not do, whether or not you later clarify. You'd think it would have been unambiguous for the two testers in the German study by the time they got to the edit screen and saw the actual text, wouldn't you?
On 7/16/07, Phil Boswell phil.boswell@gmail.com wrote:
Actually, is there any particularly pressing reason why this should be so impossible? We could establish a grading of lighter grey shades, or maybe use dashed/dotted lines, or a combination, for the deeper levels.
I'm having a little trouble establishing whether this can be done in personal CSS: anybody able to help me out here?
Hmm. Yes, that sounds like an interesting idea. This looks pretty good:
h3, h4, h5, h6 { margin-bottom: 0.6em; } h3 { border-bottom: 1px solid #CCC; } h4 { border-bottom: 1px solid #EEE; } h5 { border-bottom: 1px dashed #EEE; } h6 { border-bottom: 1px dotted #EEE; }
I'm thinking that we could have something looking like (will look a bit screwed up in non-monotype but hopefully you'll get the idea):
_____________________ Section title [edit]|___________________
Section text goes here ...
so the section is clearly one unit. One issue is that then it will look like the edit link for an nth-level section does not include n-1th-level subsections, but that's not a big problem, because the expected text will still be present as well.
On 7/16/07, Brion Vibber brion@wikimedia.org wrote:
I threw together a quick test for comment:
http://test.leuksman.com/view/Venus_Williams#2003
The patch: http://test.leuksman.com/tab-test.diff
Clever. I was thinking about how to hide the lower border, and that's a good method, if the measurements can be worked out properly in a universal fashion. Anyway, that looks pretty unambiguous, definitely. The section edit link can stay where it is if this method is chosen, too, which is nice.
Please check [[:en:User:Dschwen/HighlightSection.js]]
include in monobook.js, refresh cache, etc., you know the drill
Some comments in the code would be good so it could be better reviewed.
It's relly simple:
onmouseover: 1. Take the parent of the editsection span (which contains the [edit] link). 2. This parent should be some kind of heading, determine its level (H1, H2, H3, etc. ) and store it. 3. Iterate over all nextSiblings in the DOM tree, as long as the 'level' of the current element is bigger than the level of the original heading (non heading elements have level 10). 4. If the current element has nodeType 1 (HTML tag), get its style.backgroundColor and store it in a new property (oldBGcol) 5. set style.backgroundColor to babyblue
onmouseout: 1. - 3. as above 4. if the current element has an oldBGcol property, copy it to style.backgroundColor (restores the original bgcolor should it ever be set)
done
Also, I'd imagine a single box surrounding all the code (including the header itself) would look quite a bit nicer. That
Mh, this would require serious DOM tree gymnastics, but should be doable.
On 7/16/07, Dschwen lists@schwen.de wrote:
Also, I'd imagine a single box surrounding all the code (including the header itself) would look quite a bit nicer. That
Mh, this would require serious DOM tree gymnastics, but should be doable.
Hacked one (for en.wikipedia, but should work everywhere):
importScript('MediaWiki:HighlightEditSections.js');
Cheers, Magnus
On 7/17/07, Magnus Manske magnusmanske@googlemail.com wrote:
Hacked one (for en.wikipedia, but should work everywhere):
importScript('MediaWiki:HighlightEditSections.js');
Nice!
On 7/17/07, David Gerard dgerard@gmail.com wrote:
http://i17.tinypic.com/68jnvo4.jpg shows a possible confusion: ==h2== followed immediately by ===h3=== gives a possibly confusing pile of tags. Perhaps this could be tweaked per skin - Monobook does the possibly-confusing horizontal line for h2 but not for other heading levels. So only do a tab for h2, and a link for the others?
Not particularly acceptable. It will just have to be tweaked. I'm thinking a smaller box and smaller text, like at the top of the page, is the way to go.
Okay, I've posted a bug about this at http://bugzilla.wikimedia.org/show_bug.cgi?id=11270, with a patch implementing Brion's basic idea a little more robustly. I view it as nearly ready for deployment, after more extensive browser testing and a few bug fixes. If someone could install it on their public wiki for comment (maybe test-wiki?), that would be great.
For those who are newcomers to the discussion, this is a somewhat more refined variant on http://test.leuksman.com/view/Venus_Williams#2003, which seems to be largely broken, but a screenshot is available at http://i17.tinypic.com/68jnvo4.jpg. For "why do we want this" and other general discussion, see the history of this thread beginning at http://lists.wikimedia.org/pipermail/wikitech-l/2007-June/031899.html.
Okay, thanks to _Danny_B_ for pointing out that this completely breaks with right floats. Floats will be needed to work nicely with floats, but it's impossible to get floats to position precisely across browsers, that I can see. I think the German way of doing it, with the edit link on the left, has gone back to being the best choice, although it might use these tabs if people like them more than the bracketed link. (I'd sooner stick with the more traditional brackets.)
Magnus, by the way, your script doesn't seem to work properly in non-Firefox browsers. It highlights the sections, but then refuses to un-highlight them when you hover out.
"Simetrical" Simetrical+wikilist@gmail.com wrote in message news:7c2a12e20707151538u3b2f4084r6825d4932edb96e@mail.gmail.com...
So: I'm not sure I want to muck around with the skin's aesthetics so much. I'm a programmer, not a designer. If someone else can come up with suggestions that are both intuitive and pretty, be my guest, but for now my primary thought is 1) have the edit link immediately next to the header text, like the Germans; 2) have a downward-pointing arrow as part of the link text; and 3) add JavaScript that will, when your mouse moves over the edit link, highlight the text that will be editable by clicking. I don't think this is great, but I think it will make it very hard to be confused by the time you actually get to the edit page, which is a lot more than can be said for the current layout.
Adding the javascript (if that is possible, given that we can't just wrap each section in a div tag) would imho, largely solve the problem. It may not be immediately clear from looking, but moving the mouse over will immediately resolve any ambiguity. I'm not sure how much difference moving the edit link would make, if (as your tester says) it is still not clear what it refers to in the new location. The downward pointing arrow may or may not help, but I think it would look quite messy if you had the links on the left, but probably more visually acceptable if it was added to the current edit location. Of course, I guess that depends on what the arrow looks like...
- Mark Clements (HappyDog)
Adding the javascript (if that is possible, given that we can't just wrap each section in a div tag) would imho, largely solve the problem. It may
Please check [[User:Dschwen/HighlightSection.js]]
include in monobook.js, refresh cache, etc., you know the drill
Simetrical-3 wrote:
[snip] She remarked that having the line under the section header was unusual and confusing, and suggested it be moved above the header. (I don't think this is feasible as an aesthetic change, given that the problem will remain for third-level and deeper headings.)
Actually, is there any particularly pressing reason why this should be so impossible? We could establish a grading of lighter grey shades, or maybe use dashed/dotted lines, or a combination, for the deeper levels.
I'm having a little trouble establishing whether this can be done in personal CSS: anybody able to help me out here?
On Sun, Jul 15, 2007 at 06:38:17PM -0400, Simetrical wrote:
But she was also, as I said, confused about the second choice, as the Germans have it. Happily, she was an art professor, so she was able to articulate her issues well and make constructive suggestions. She remarked that having the line under the section header was unusual and confusing, and suggested it be moved above the header. (I don't think this is feasible as an aesthetic change, given that the problem will remain for third-level and deeper headings.) She thought it was much more natural for the edit link to be in the lower right of the section instead of anywhere on the top, saying something to the effect of that it made more sense to want to edit the section *after* you've read it, if I understood her correctly. I showed her the suggestion with a downward-pointing arrow, and her opinion on that was that it was inelegant and unexpected, but that at least if you *thought* about it it was unambiguous.
I've just had a blinding flash of the obvious, for a potential solution that could help, at least, people with current day desktop browsers (that's what, 95% of the audience? :-)
Could we mouseover the edit links to change the background color of the appropriate div from default to, perhaps, pink, to illustrate which section you're about to edit?
Cheers, -- jra
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jay R. Ashworth wrote:
I've just had a blinding flash of the obvious, for a potential solution that could help, at least, people with current day desktop browsers (that's what, 95% of the audience? :-)
Could we mouseover the edit links to change the background color of the appropriate div from default to, perhaps, pink, to illustrate which section you're about to edit?
That's been mentioned multiple times in this thread, so I assume like any sane person you've only been skimming it. ;)
It's a possibility insofar as it's possible to tell where the section ends at all and insofar as it's possible to wrap a div around it without breaking the HTML output.
- -- brion vibber (brion @ wikimedia.org)
On Mon, Jul 16, 2007 at 11:04:00AM -0400, Brion Vibber wrote:
Jay R. Ashworth wrote:
I've just had a blinding flash of the obvious, for a potential solution that could help, at least, people with current day desktop browsers (that's what, 95% of the audience? :-)
Could we mouseover the edit links to change the background color of the appropriate div from default to, perhaps, pink, to illustrate which section you're about to edit?
That's been mentioned multiple times in this thread, so I assume like any sane person you've only been skimming it. ;)
Very stylishly done, Brion. :-)
Yes, I'd missed it.
It's a possibility insofar as it's possible to tell where the section ends at all and insofar as it's possible to wrap a div around it without breaking the HTML output.
Hmmm. It doesn't sound like either of those should be difficult. That's probably as much indication as you need about how little I understand the parser. :-)
Cheers, -- jra
On 7/16/07, Jay R. Ashworth jra@baylink.com wrote:
It's a possibility insofar as it's possible to tell where the section ends at all and insofar as it's possible to wrap a div around it without breaking the HTML output.
Hmmm. It doesn't sound like either of those should be difficult. That's probably as much indication as you need about how little I understand the parser. :-)
See bug 6104 for a discussion of what that Doesn't Work (TM): http://bugzilla.wikimedia.org/show_bug.cgi?id=6104
That change might be a good idea to have in addition, but it's not sufficient by itself, as I said in my last post to this thread. Combined with the little tab-like box around the edit link, it should be sufficient without moving the link (with the highlighting being a probably unnecessary added perk).
What about using some down arrow on the section edit links? to mean "edit *below*".
Unicode will sure have some fitting glyphs. Now, will users' browsers support them?
Try ↓
-- Jim
On 6/26/07, Platonides Platonides@gmail.com wrote:
What about using some down arrow on the section edit links? to mean "edit *below*".
Unicode will sure have some fitting glyphs. Now, will users' browsers support them?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Od: Platonides Platonides@gmail.com What about using some down arrow on the section edit links? to mean "edit *below*".
Unicode will sure have some fitting glyphs. Now, will users' browsers support them?
↓ or ▼ should be displayable in all graphical browsers (I don't have others handy at the moment to test)
Kind regards
Danny B.
On 6/25/07, Simetrical Simetrical+wikilist@gmail.com wrote:
Why do you think that, given the usability study's result?
What the usability study found, to my understanding, was that MediaWiki was not particularly newbie-friendly; that is, its usability among new users was low. That said, MediaWiki surely has a steeper learning curve than most webware; however, it has a large group of power users who have found the various "oddities" of the software that confuse new users to be quite useful in increasing their productivity. By analogy, the modality of vim often confuses the hell out of new users to that software, yet it has become a feature that experienced users simply could not live without. Vim is never going to do away with its modal editing to become more "user-friendly"; similarly, I do not favor the idea of sacrificing the expert usability of MediaWiki to make the software more friendly to new users. Such a change, I fear, would certainly do just that--confuse expert users and hinder their productivity with the software.
Furthermore, editing should truly always be second to the content produced through that editing--that is, _readability_ should take precedence over _usability_ (in the sense of its usability to editors). I would find this to be a change that, though it may make certain elements of editing more clear to users, would cause a major aesthetic "hiccup" in the appearance and flow of pages, lending nothing more than a distraction from the content. Such a problem is avoided relatively well by the current placement of the link, and any other proposed placement would certainly have to consider and address this problem
I personally would object to such a change, and I do not feel any change to be necessary; however, I'm more than willing to discuss and experiment with this and other options. If you could perchance provide some samples of this change, preferably on complex pages with multiple images, tables, and templates intermingled with text, that could certainly help to gauge the degree of my objection. I would, however, strongly caution against making large, breaking changes on the basis of this single usability study without considering the possible repercussions of such changes outside the context of the points addressed by the study.
On Tue, Jun 26, 2007 at 12:23:02PM -0600, Daniel Cannon wrote:
What the usability study found, to my understanding, was that MediaWiki was not particularly newbie-friendly; that is, its usability among new users was low. That said, MediaWiki surely has a steeper learning curve than most webware; however, it has a large group of power users who have found the various "oddities" of the software that confuse new users to be quite useful in increasing their productivity. By analogy, the modality of vim often confuses the hell out of new users to that software, yet it has become a feature that experienced users simply could not live without. Vim is never going to do away with its modal editing to become more "user-friendly"; similarly, I do not favor the idea of sacrificing the expert usability of MediaWiki to make the software more friendly to new users. Such a change, I fear, would certainly do just that--confuse expert users and hinder their productivity with the software.
Huzzah!
What You See Is All You Get, indeed.
I personally would object to such a change, and I do not feel any change to be necessary; however, I'm more than willing to discuss and experiment with this and other options. If you could perchance provide some samples of this change, preferably on complex pages with multiple images, tables, and templates intermingled with text, that could certainly help to gauge the degree of my objection. I would, however, strongly caution against making large, breaking changes on the basis of this single usability study without considering the possible repercussions of such changes outside the context of the points addressed by the study.
On this front, my only comment is "test it on a Blackberry". :-)
Cheers, -- jra
On 6/26/07, Daniel Cannon cannon.danielc@gmail.com wrote:
What the usability study found, to my understanding, was that MediaWiki was not particularly newbie-friendly; that is, its usability among new users was low. That said, MediaWiki surely has a steeper learning curve than most webware; however, it has a large group of power users who have found the various "oddities" of the software that confuse new users to be quite useful in increasing their productivity.
There are certainly a number of features for power users that other Web software packages generally don't have, like bot interfaces, custom CSS and JS, a powerful templating system, and access to almost all HTML tags/attributes. But nobody is contemplating their removal, and in fact when it comes to interface changes those very power-user tools will allow power users to change the interface however they want (in particular with custom JS), so I fail to see how this is at all relevant.
Furthermore, editing should truly always be second to the content produced through that editing--that is, _readability_ should take precedence over _usability_ (in the sense of its usability to editors). I would find this to be a change that, though it may make certain elements of editing more clear to users, would cause a major aesthetic "hiccup" in the appearance and flow of pages, lending nothing more than a distraction from the content.
To the contrary, production of more and better content (which is to say, editing) should always take precedence over minor aesthetic quibbles with how the content is presented. Besides, I think the German style of edit links looks just as good, and apparently our second-largest wiki agrees.
If you could perchance provide some samples of this change, preferably on complex pages with multiple images, tables, and templates intermingled with text,
large, breaking changes
The change is minor, not large, and it should not break anything.
On 6/26/07, Danny B. Wikipedia.Danny.B@email.cz wrote:
German way isn't visually bad, but it has one big disadvantage: I am 99 % sure, this rendering can't be done together with correct semantics.
Works fine like this:
<div class="mw-h2"> <h2>Page title</h2> <span class="editsection">[edit]</span> </div>
You just use display: inline; for the h2, supported even by IE5 (Windows and Mac!). (Floating would also be possible, but I'd prefer to avoid that due to the tendency of floats to interfere with each other, amply demonstrated by the current edit-link-bunching bug.)
On 6/26/07, Simetrical Simetrical+wikilist@gmail.com wrote:
We've known for well over a year now that this is a problem. I would
like to finally fix it. Specifically, I intend to remove the editsection float style, so it's at the beginning of the section line, to the left. The alternative is to have it as the German Wikipedia does, with the section edit link on the right of the header; however, this a) is kind of annoying as the link jumps around, and b) requires a change to the document structure (admittedly just a reordering of elements, but it may well break some fragile stuff regardless). It does arguably look better, though, and that could be done instead (opinions?). A comparison of the three styles is available at http://www.mediawiki.org/wiki/User:Simetrical/Edit_links_comparison.
Before this goes into effect, it would be only courteous to inform existing wikis about it and the reasons for doing it. I'll prepare a little message and get someone with bots everywhere (Yurik?) to post it on all the wikis' MediaWiki talk:Common.css pages, I think, before I commit it, and so well before it goes live, along with instructions on how to reverse it preemptively if desired.
Are there any objections to this?
As long as you implement it in a way that still allows the edit link to appear just to the right of the heading (the "German Wikipedia way"), no objections here. Ideally, this would be configurable so that each project and each user can set up their own defaults.
Sebastian
On Mon, Jun 25, 2007 at 09:44:54PM -0400, Simetrical wrote:
We've known for well over a year now that this is a problem. I would like to finally fix it. Specifically, I intend to remove the editsection float style, so it's at the beginning of the section line, to the left. The alternative is to have it as the German Wikipedia does, with the section edit link on the right of the header; however, this a) is kind of annoying as the link jumps around, and b) requires a change to the document structure (admittedly just a reordering of elements, but it may well break some fragile stuff regardless). It does arguably look better, though, and that could be done instead (opinions?). A comparison of the three styles is available at http://www.mediawiki.org/wiki/User:Simetrical/Edit_links_comparison.
I came late to this, but I really *do* prefer link to right over link to left. I think that the esthetics of not indenting the header are more important than the fact that the link will "jump around".
It doesn't, actually, jump around. It's always at the right end of the header.
Cheers, -- jra
My two cents on the issue: - The edit link on the far right, as at present, is actually probably the worst of all possibilities. It's hard to see, it constantly gets mangled by infoboxes and images, and it's the least intuitively connected with the correct paragraph. It caused me a lot of problems as a newbie. - Edit link on the far left is good from every perspective except that it pushes the heading out, which is bad for reading and general visuals. If it could be placed in the margin, that would be great. - Arrows would really help with connecting the edit link to the right paragraph. I think either edit link above section heading (with down arrow) or after section text (with up arrow) could work. A fairly big change from the current situation but probably more intuitive. Placing it *after* the section would also work well for the lead section, and is very intuitive when you want to add text to the end of a section. - Of the suggestions that have been mocked up, the "German" model is my preferred one, as it has the least disadvantages. Maybe add a downarrow to make even clearer that you're editing the whole section, not just the heading?
Steve
On 6/29/07, Steve Bennett stevagewp@gmail.com wrote:
If it could be placed in the margin, that would be great.
It would, definitely, but alas, we appear to not have enough of a margin.
- Arrows would really help with connecting the edit link to the right
paragraph.
That's certainly something worth considering. The current situation could be improved immeasurably with an arrow alone, I think. But I agree that there are other issues with the present setup that would tend to militate for something more like what the Germans have, arrows or no.
wikitech-l@lists.wikimedia.org