Perhaps we're asking the wrong question here.

There are two options, and how they are presented either results in problems with clutter, or with clarity, but both options are for the same action of editing the page/section. So why present the options until the user clicks on the link for editing at all?

Now at that point it could go with a dropdown presenting the choices, but let's look at how this sort of thing, with two or more edit modes, is usually done across existing platforms: Click the link/button, and generally it opens up to the visual editor by default. From there, the source mode is a tab or option that can then be switched between as needed, with the visual editor also doubling as a preview if the user is working mostly in source.

Wordpress is a good example. Their visual editor itself makes me want to cry, but the interface is clearly navigable and such. It's basically what I expected with this when I first heard of it as well.

-K

On 21/06/13 17:40, Trevor Parscal wrote:
VisualEditor has the option to take over section edit links. We find this is probably going to be unpopular for people who want to at least sometimes edit wikitext, but don't want to loose them as VisualEditor users. After discussing a few different options, including showing both links (really cluttered and horribly long in some languages) and using icons (no icon would really convey what we want here).

We have decided that it's probably best to make the edit link show an alternative in a menu on hover. There's a prototype of this (somewhere) that MatmaRex has hacked together (screenshot attached) which is close. I mocked something up that is similar but perhaps a little better looking.

Max brings up a good point about my mockup, which is that it doesn't quite fit with other vector-isms. Given that Vector is something we want to evolve, we shouldn't get too caught up in that, but it's something worth considering since deviation from what vector is today should probably only be done if it's in the direction of what Vector should be in the future.

I'm hoping that others on the list could perhaps make suggestions, offer ideas, make simple mockups or prototypes and help make this feature as good as possible.

We need to have this solved quickly since we are releasing in a couple of weeks.

- Trevor


_______________________________________________
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design