Hi design team, Trevor, James et al.,
There are a few issues with the hybrid section link editing UI deployed with VisualEditor:
* Because it's a mouseover action, it doesn't translate to touch interfaces.
* If you prefer to edit source, you basically have to train yourself to target an invisible link in order to not be delayed by the animation.
* Because the animation triggers on mouseover, it can be distracting while scrolling/reading.
In my view, we need to consider an alternative default experience soon. I've seen the current behavior commonly cited as a reason to opt out of the the VE beta.
The team rejected static [edit] [edit source] source, I think reasonably, because of too much clutter in the section headings.
My suggestion would be to take a similar approach to the mobile site: have an icon for section editing (e.g. pencil) and maybe a different one for source editing (e.g. "<>" which is commonly used to switch into source mode in RTEs).
The one other alternative is to get rid of the animation and set the behavior via preference.
I think this problem would benefit from a few more approaches being kicked around.
Cheers :) Erik
Le 2013-07-26 08:30, Erik Moeller a écrit :
My suggestion would be to take a similar approach to the mobile site: have an icon for section editing (e.g. pencil) and maybe a different one for source editing (e.g. "<>" which is commonly used to switch into source mode in RTEs).
I completely agree, and in fact I think I already suggested this approach in a previous mail.
The one other alternative is to get rid of the animation and set the behavior via preference.
You could also provide the three option in preferences: pencil icons, full text links, or the animation.
I think this problem would benefit from a few more approaches being kicked around.
Cheers :) Erik
On 07/25/2013 11:52 PM, Mathieu Stumpf wrote:
Le 2013-07-26 08:30, Erik Moeller a écrit :
My suggestion would be to take a similar approach to the mobile site: have an icon for section editing (e.g. pencil) and maybe a different one for source editing (e.g. "<>" which is commonly used to switch into source mode in RTEs).
I completely agree, and in fact I think I already suggested this approach in a previous mail.
We need to be careful we're not de-emphasizing the edit link, when we want to increase participation. "text + icon" would probably be more noticeable than text alone, but I'm not sure an icon alone is more noticeable than text in this case.
Matt Flaschen
Le 2013-07-26 11:13, Matthew Flaschen a écrit :
We need to be careful we're not de-emphasizing the edit link, when we want to increase participation. "text + icon" would probably be more noticeable than text alone, but I'm not sure an icon alone is more noticeable than text in this case.
Then we may have an "edit toolbar" which would be fixed on the right of the page, would that be be an enough discret emphase?
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
What about having an [edit] link near the section header, and then put the [edit source] link right aligned (in the old "edit" link place), thus:
Section Name [edit] ___________________________________________________[edit source]_
Keeps the source edit link in the same place it was before.
On Jul 25, 2013, at 11:30 PM, Erik Moeller erik@wikimedia.org wrote:
Hi design team, Trevor, James et al.,
There are a few issues with the hybrid section link editing UI deployed with VisualEditor:
Because it's a mouseover action, it doesn't translate to touch interfaces.
If you prefer to edit source, you basically have to train yourself
to target an invisible link in order to not be delayed by the animation.
- Because the animation triggers on mouseover, it can be distracting
while scrolling/reading.
In my view, we need to consider an alternative default experience soon. I've seen the current behavior commonly cited as a reason to opt out of the the VE beta.
The team rejected static [edit] [edit source] source, I think reasonably, because of too much clutter in the section headings.
My suggestion would be to take a similar approach to the mobile site: have an icon for section editing (e.g. pencil) and maybe a different one for source editing (e.g. "<>" which is commonly used to switch into source mode in RTEs).
The one other alternative is to get rid of the animation and set the behavior via preference.
I think this problem would benefit from a few more approaches being kicked around.
Cheers :) Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Another option could be to use a "split button" or something along those lines where the user has access to the primary action but a clue is provided on how to get additional ones:
[image: Inline image 1] This will help to communicate that Visual Editor is the default (avoiding the initial choice for users that do not need to chose) while providing a path for advanced users. Visual style probably needs adjustment to fit properly next to the section headers.
Pau
On Fri, Jul 26, 2013 at 9:03 AM, Brandon Harris bharris@wikimedia.orgwrote:
What about having an [edit] link near the section header, and thenput the [edit source] link right aligned (in the old "edit" link place), thus:
Section Name [edit]___________________________________________________[edit source]_
Keeps the source edit link in the same place it was before.On Jul 25, 2013, at 11:30 PM, Erik Moeller erik@wikimedia.org wrote:
Hi design team, Trevor, James et al.,
There are a few issues with the hybrid section link editing UI deployed with VisualEditor:
- Because it's a mouseover action, it doesn't translate to touch
interfaces.
- If you prefer to edit source, you basically have to train yourself
to target an invisible link in order to not be delayed by the animation.
- Because the animation triggers on mouseover, it can be distracting
while scrolling/reading.
In my view, we need to consider an alternative default experience soon. I've seen the current behavior commonly cited as a reason to opt out of the the VE beta.
The team rejected static [edit] [edit source] source, I think reasonably, because of too much clutter in the section headings.
My suggestion would be to take a similar approach to the mobile site: have an icon for section editing (e.g. pencil) and maybe a different one for source editing (e.g. "<>" which is commonly used to switch into source mode in RTEs).
The one other alternative is to get rid of the animation and set the behavior via preference.
I think this problem would benefit from a few more approaches being kicked around.
Cheers :) Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 07/26/2013 12:29 AM, Pau Giner wrote:
Inline image 1 This will help to communicate that Visual Editor is the default (avoiding the initial choice for users that do not need to chose) while providing a path for advanced users. Visual style probably needs adjustment to fit properly next to the section headers.
I think this was discussed earlier, and it will be a good solution if VisualEditor becomes the dominant section editor.
However, it requires two clicks (or at least mouseover arrow, then click) for source editing, so may not go over well with power users currently.
Matt Flaschen
On Fri, Jul 26, 2013 at 12:29 AM, Pau Giner pginer@wikimedia.org wrote:
Another option could be to use a "split button" or something along those lines where the user has access to the primary action but a clue is provided on how to get additional ones:
[image: Inline image 1] This will help to communicate that Visual Editor is the default (avoiding the initial choice for users that do not need to chose) while providing a path for advanced users. Visual style probably needs adjustment to fit properly next to the section headers.
Pau
I think this split button approach by Pau is a very good compromise between simplicity, choice, and avoiding the animation in the current interaction that seems to be annoying people.
Showing both links all the time is a non-starter IMO, because the additional clutter for all users (including readers) is not worth the small gain in speed for the minority who will want to use the edit source link all the time.
On Fri, Jul 26, 2013 at 12:29 AM, Pau Giner pginer@wikimedia.org wrote:
Another option could be to use a "split button" or something along those lines where the user has access to the primary action but a clue is provided on how to get additional ones:
This will make the clickable area for the source editor tiny, which doesn't seem good.
On Fri, 26 Jul 2013 21:35:55 +0200, Steven Walling swalling@wikimedia.org wrote:
I think this split button approach by Pau is a very good compromise between simplicity, choice, and avoiding the animation in the current interaction that seems to be annoying people.
Showing both links all the time is a non-starter IMO, because the additional clutter for all users (including readers) is not worth the small gain in speed for the minority who will want to use the edit source link all the time.
The animation is annoying because it obscured the "edit source" link; Pau's proposal does that as well.
How many times have you clicked on either of these links recently? I don't mean to berate you personally, but you made four edits on your volunteer account on en.wp last week, and I really think that opinion of active editors bears more weight here, even if they are not professional designers :)
(I primarily edit on pl.wp, if anybody wants to compare my stats here ;) )
On Fri, Jul 26, 2013 at 12:56 PM, Bartosz Dziewoński matma.rex@gmail.comwrote:
How many times have you clicked on either of these links recently? I don't mean to berate you personally, but you made four edits on your volunteer account on en.wp last week, and I really think that opinion of active editors bears more weight here, even if they are not professional designers :)
Since you asked, I'll break it down for you: with my personal account I've made 259 edits this month on enwiki. With my work and personal accounts, my edit count across wikis with VE is 472. So I've used the interface quite a bit.
I may not be a grumpy Monobook devotee, who uses script-assisted editing to make thousands of edits a week, but I've used it enough to know what I'm talking about. I think the same applies to everyone who has participated in the discussion so far, including all the designers. You should generally stay away from the "you're not foo kind of person, so your opinion means less" argument, if you don't want to look like an asshole.
Early on in the design of this feature I suggested we use a drop down menu, and Matma Rex implemented a rough version of it. The UI sucked (my fault) and I moved away from it.
Here was my analysis:
*2 links side by side with reveal on hover* (what we have now)
- Pros - No change in the way the page looks - Uses lightweight controls - Cons - Hidden option - Animation is annoying - Not tablet friendly
*1 link with drop-down menu for 2nd link* (my first idea, and is now being suggested again)
- Pros - More "vector" like, for whatever that is worth - Tablet friendly - Cons - Changes the way the page looks - Hidden option - Adds heavy controls - Clicking multiple times is annoying
You can see that they both suck. I actually started a thread on this very list hoping to get ideas well before I coded this up. Instead of ideas, I got lots of people fighting about things that were off topic. Now that it's implemented and has been deployed for a month, if this is important enough for people to get serious about coming up with alternatives, than I'm still very interested in exploring them.
- Trevor
On Fri, Jul 26, 2013 at 1:14 PM, Steven Walling swalling@wikimedia.orgwrote:
On Fri, Jul 26, 2013 at 12:56 PM, Bartosz Dziewoński matma.rex@gmail.comwrote:
How many times have you clicked on either of these links recently? I don't mean to berate you personally, but you made four edits on your volunteer account on en.wp last week, and I really think that opinion of active editors bears more weight here, even if they are not professional designers :)
Since you asked, I'll break it down for you: with my personal account I've made 259 edits this month on enwiki. With my work and personal accounts, my edit count across wikis with VE is 472. So I've used the interface quite a bit.
I may not be a grumpy Monobook devotee, who uses script-assisted editing to make thousands of edits a week, but I've used it enough to know what I'm talking about. I think the same applies to everyone who has participated in the discussion so far, including all the designers. You should generally stay away from the "you're not foo kind of person, so your opinion means less" argument, if you don't want to look like an asshole.
-- Steven Walling https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Fri, 26 Jul 2013 09:03:39 +0200, Brandon Harris bharris@wikimedia.org wrote:
What about having an [edit] link near the section header, and then put the [edit source] link right aligned (in the old "edit" link place) Keeps the source edit link in the same place it was before.
The section edit links is not in that place for a few months already and I think it was agreed on that putting it there is bad usability?
On Fri, 26 Jul 2013 08:30:43 +0200, Erik Moeller erik@wikimedia.org wrote:
The team rejected static [edit] [edit source] source, I think reasonably, because of too much clutter in the section headings.
I *still* think this would be the best solution. Come on, it's not that cluttering, and it would be a known interface for more experienced editors (some gadgets do similar things).
Maybe an A/B test comparing current design to this could be run? I had previously implemented this, the abandoned patch is still sitting somewhere in gerrit and could be revived.
On Fri, Jul 26, 2013 at 12:43:38PM +0200, Bartosz Dziewoński wrote:
On Fri, 26 Jul 2013 08:30:43 +0200, Erik Moeller erik@wikimedia.org wrote:
The team rejected static [edit] [edit source] source, I think reasonably, because of too much clutter in the section headings.
I *still* think this would be the best solution.
FWIW, I agree, this seems like a good solution. The hover thing that's currently in place is annoying (apart from the touch issues), and static links is simple and easily understandable.
I am very sensitive to clutter, but I don't think two small edit links by section headings constitute clutter. Rather it emphasises *the* key thing about wikipedia, that editing is encouraged.
I don't like the use of hover in this place. I don't think, that an essential element for user interaction should be hidden from the user.
If I were an experienced user I would expect the old behavior when I click on "edit", instead of this another link popps up that sais "edit source" and disturbs me.
My solution would be moving the [ edit | edit source ] thingy to the right. That would reduce the clutter in the headings.
Lukas
On Fri, 26 Jul 2013 08:30:43 +0200, Erik Moeller erik@wikimedia.org wrote:
The team rejected static [edit] [edit source] source, I think reasonably, because of too much clutter in the section headings.
I *still* think this would be the best solution. Come on, it's not that cluttering, and it would be a known interface for more experienced editors (some gadgets do similar things).
Maybe an A/B test comparing current design to this could be run? I had previously implemented this, the abandoned patch is still sitting somewhere in gerrit and could be revived.
-- Matma Rex
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
The hover effect is easy to drop - if we are all willing to take the hit on the clutter.
It was sort of an experiment in choosing the lesser of two evils (clutter vs. hidden options), sounds like we need to reconsider.
I think that introducing icons is tricky, it should be done very cautiously.
- Trevor
On Fri, Jul 26, 2013 at 4:05 AM, Lukas Benedix benedix@zedat.fu-berlin.dewrote:
I don't like the use of hover in this place. I don't think, that an essential element for user interaction should be hidden from the user.
If I were an experienced user I would expect the old behavior when I click on "edit", instead of this another link popps up that sais "edit source" and disturbs me.
My solution would be moving the [ edit | edit source ] thingy to the right. That would reduce the clutter in the headings.
Lukas
On Fri, 26 Jul 2013 08:30:43 +0200, Erik Moeller erik@wikimedia.org wrote:
The team rejected static [edit] [edit source] source, I think reasonably, because of too much clutter in the section headings.
I *still* think this would be the best solution. Come on, it's not that cluttering, and it would be a known interface for more experienced
editors
(some gadgets do similar things).
Maybe an A/B test comparing current design to this could be run? I had previously implemented this, the abandoned patch is still sitting somewhere in gerrit and could be revived.
-- Matma Rex
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Fri, Jul 26, 2013 at 11:11 AM, Trevor Parscal tparscal@wikimedia.org wrote:
The hover effect is easy to drop - if we are all willing to take the hit on the clutter.
That's probably the best short term option.
The problem with a dropdown is that, while VE is in beta and experienced users may prefer not to use it for many reasons (performance, missing functionality, etc.), adding a higher cognitive penalty for not using it will likely just lead to users turning it off completely. If we want experienced users to test it every once in a while, give feedback on how it can be made better, and have them see the improvements, finding a solution that poses the least burden on them will give us the biggest win.
That's why I'd argue for icons in the mid-term, but I hear the argument about those potentially reducing the visibility of section editing overall and therefore having a negative effect. Any new alternative approach likely needs to be tested. Until then, accepting a bit of additional clutter (perhaps that could be mitigated by losing the second "edit" and going with "edit | source") may be best if we don't want to go into preferences-land.
Erik
On Fri, Jul 26, 2013 at 6:19 PM, Erik Moeller erik@wikimedia.org wrote:
On Fri, Jul 26, 2013 at 11:11 AM, Trevor Parscal tparscal@wikimedia.org wrote:
The hover effect is easy to drop - if we are all willing to take the hit on the clutter.
That's probably the best short term option.
This is now done on enwiki, with the addition of a "beta" label. We'll now see increased complaints and concerns about clutter, of course. :P
We do need to kick into gear thinking on the mid to long term options. A couple of constraints I would formulate:
* primacy of one mode or another should be determined by the user as much as possible (i.e. wikitext users should have a happy experience that doesn't nudge them too much to use VE; VE users should have a happy experience that doesn't nudge them too much to use wikitext);
* let's avoid animations or hover effects that don't work with touch.
My take is that beautiful icons would work well in the mid term, while refactoring the edit UI altogether to make the mode of operation a secondary choice on the edit screen itself (a mode-switch on the edit screen) might be viable in the long run, but would be especially difficult for section editing. But I think we need to explore some bold ideas here both for the mid and long term.
Erik
While I support the new direction, I was surprised to receive some in-person feedback from friends and family telling me that the animated links actually brought to their attention for the first time that they could actually edit.
Which led me to believe 2 things:
1. I think they don't listen when I talk. 2. The animated links provided value in the increased visibility, that even without animation we should seek to retain.
- Trevor
On Fri, Aug 2, 2013 at 12:45 AM, Erik Moeller erik@wikimedia.org wrote:
On Fri, Jul 26, 2013 at 6:19 PM, Erik Moeller erik@wikimedia.org wrote:
On Fri, Jul 26, 2013 at 11:11 AM, Trevor Parscal tparscal@wikimedia.org
wrote:
The hover effect is easy to drop - if we are all willing to take the
hit on
the clutter.
That's probably the best short term option.
This is now done on enwiki, with the addition of a "beta" label. We'll now see increased complaints and concerns about clutter, of course. :P
We do need to kick into gear thinking on the mid to long term options. A couple of constraints I would formulate:
- primacy of one mode or another should be determined by the user as
much as possible (i.e. wikitext users should have a happy experience that doesn't nudge them too much to use VE; VE users should have a happy experience that doesn't nudge them too much to use wikitext);
- let's avoid animations or hover effects that don't work with touch.
My take is that beautiful icons would work well in the mid term, while refactoring the edit UI altogether to make the mode of operation a secondary choice on the edit screen itself (a mode-switch on the edit screen) might be viable in the long run, but would be especially difficult for section editing. But I think we need to explore some bold ideas here both for the mid and long term.
Erik
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Aug 5, 2013 9:46 AM, "Trevor Parscal" tparscal@wikimedia.org wrote:
While I support the new direction, I was surprised to receive some
in-person feedback from friends and family telling me that the animated links actually brought to their attention for the first time that they could actually edit.
Which led me to believe 2 things:
- I think they don't listen when I talk.
- The animated links provided value in the increased visibility, that
even without animation we should seek to retain.
- Trevor
Well said.
On Fri, Aug 2, 2013 at 12:45 AM, Erik Moeller erik@wikimedia.org wrote:
On Fri, Jul 26, 2013 at 6:19 PM, Erik Moeller erik@wikimedia.org wrote:
On Fri, Jul 26, 2013 at 11:11 AM, Trevor Parscal <
tparscal@wikimedia.org> wrote:
The hover effect is easy to drop - if we are all willing to take the
hit on
the clutter.
That's probably the best short term option.
This is now done on enwiki, with the addition of a "beta" label. We'll now see increased complaints and concerns about clutter, of course. :P
We do need to kick into gear thinking on the mid to long term options. A couple of constraints I would formulate:
- primacy of one mode or another should be determined by the user as
much as possible (i.e. wikitext users should have a happy experience that doesn't nudge them too much to use VE; VE users should have a happy experience that doesn't nudge them too much to use wikitext);
- let's avoid animations or hover effects that don't work with touch.
My take is that beautiful icons would work well in the mid term, while refactoring the edit UI altogether to make the mode of operation a secondary choice on the edit screen itself (a mode-switch on the edit screen) might be viable in the long run, but would be especially difficult for section editing. But I think we need to explore some bold ideas here both for the mid and long term.
Erik
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
