I agree that presenting this amount of choice to everyone is unwanted and
almost definitely unneeded.
If we do have a choice presented to users, it should only be more advanced
users, as a concession since they are likely going to need to continue
using Wikitext for some time while VE matures and supports more tasks.
These are the same users we made the preference to use the source editor
for section edit links, and we are hoping to keep the VisualEditor close at
hand for these people so they will use it more and more over time.
It's also possible that the best solution is to leave it alone as it is.
On the point of switching between visual and source modes, this is already
on our roadmap, but won't make it into the July release.
I've attached some mockups. I made them several months ago, but they show
the general idea. The mockups show 2 edit tabs, but really there would be a
single edit tab in this design since source is integrated.
You will also notice something we call outline mode. This has to do with
the issue of how difficult floated content is to work with and organize in
the current "layout" mode - as well as how much the extra gaps we put
between some elements to allow text insertion throw the layout off. We are
still exploring this concept, please don't get to distracted by it - I just
wanted to show that we imagine editors being able to switch between
multiple modes easily.
On Fri, Jun 21, 2013 at 10:46 AM, Jon Robson <jrobson(a)wikimedia.org> wrote:
I actually completely agree with Steven from the bug
report when he
says "The dropdown arrow or cog is too much unnecessary choice. The
point of section edit links is to enable speedy editing of single
sections, so introducing a dropdown is overloading things. Most new
editors will appreciate defaulting to VE, and for power users who need
edit source, this is where having a preference to change your default
to edit source would come in handy"
I also worry putting the word 'source' near 'edit' actually would have
a detrimental effect on editing as it suggests you will be editing
Also +1 to "By deemphasizing wikitext editor we both send the clear
message about our intentions to have VE be the default edit
Out of interest is there any data here to describe why having an edit
source link in sections is needed? I think any decision here should be
more data driven. I worry that this issue is given more importance
then it needs.
Is this several community members asking for this feature or is there
a real problem here?
Here are some questions I'd suggest get answered via data first
1) What percentage of users actually hit edit source when in Visual Editor
2) Are people switching to edit source on certain types of pages e.g.
(if so maybe the preference might be set for different namespaces)
3) Are people switching to edit source from Visual Editor primarily on
sections or is it the same on full page edits?
4) What is the average edit count of an editor switching to source?
On Fri, Jun 21, 2013 at 9:52 AM, Bartosz Dziewoński <matma.rex(a)gmail.com>
On Fri, 21 Jun 2013 18:40:58 +0200, Trevor
discussing a few different options, including showing both links (really
cluttered and horribly long in some languages)
There's a mockup of this, too, linking for completeness:
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.
The code for this is here: CSS + JS: http://pastebin.com/pvtAw1ZT
- these links will probably expire
please copy the code if anybody cares
I have also been considering a horizontal expando - something like
- but I don't really like it myself.
Design mailing list
On Fri, Jun 21, 2013 at 10:32 AM, Jared Zimmerman
If we strongly feel that VE is the future of
wikipedia and are making it
default editor than we should be consistent at an
article or section
The thing that I feel is paralysis of choice, we already have enough
that don't understand the concept of editing
much less the confidence to
edit. I think that Visual Editor goes a long way
to help reduce the fear
associated with editing. We will be taking a step back if we make the
decide between two methods of editing, increasing
the steps and cognitive
barrier to editing.
I've quickly mocked up 3 options based on a conversation we had in the UX
group for placement of a single edit action, that would point to the
editor environment for the user. The last one
would be better if the left
margin on the body copy was a bit wider.
To address the issue of users wanting choice, I would postpone that
rather than making it a barrier into the edit
A quick sketch of access point for opening the wikitext editor from
the visual editor environment.
By deemphasizing wikitext editor we both send the clear message about our
intentions to have VE be the default edit environment.
Again, in this particular instance I think choice, even though requested
some users is antithetical to our overall goals
of a seamless experience
getting users, especially new users between read
and edit environments.
Jared Zimmerman \\ Director of User Experience \\ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmerman
On Fri, Jun 21, 2013 at 9:40 AM, Trevor Parscal <tparscal(a)wikimedia.org>
> VisualEditor has the option to take over section edit links. We find
> is probably going to be unpopular for people
who want to at least
> 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)
> MatmaRex has hacked together (screenshot
attached) which is close. I
> 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
> 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
> 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
> as possible.
> We need to have this solved quickly since we are releasing in a couple
Design mailing list
Design mailing list
Design mailing list