After a past Change i have to do one more click to Switch from visual Editor Interface to source code Editor. Is it necessary to put in this drop down menu for switching? I have simply this both Options i can Switch to, one of them is enabled every time. The solution before this was fine, there wasn't any Problems. The way to Switch now is so unpractical to use. Please revert this. Thanks.
Topic on VisualEditor/Feedback
Use the keyboard shortcut instead quick switching.
It is probably an idea, but I am not really a fan of Keyboard shortcuts on Websites. So I insist, that the procedure now is not really user friendly.
It is highly unlikely that they'll revert it, as it seems to have been discussed for years before this change (see ). The old process was actually worse because one could accidentally click it and end up changing to an editor they didn't want, at least now the switch must be deliberate. The dropdown also makes it possible to add an extra option to go back to the old editor instead of either the new wikitext editor or visualeditor (whenever the three are available).
Users can always change it back by using user scripts or gadgets anyway.
It's simply the same as always, this Change is effecting me as contributer and will be changed in a discussion of developers. I hate it to work or read on phab. So I can't join discussions about Topics like this. But this Change is really bad managed.
And i don't think, that someone was hitting this button by accident.
There has been a related discussion on this very page a while ago, FWIW, and the change was announced in the past Tech News. If we had had a visual editor newsletter this quarter, it would have probably been there, but there isn't exactly a good place to discuss upcoming changes beyond Phabricator (that task is actually great has there have been lots of mockups and refining ideas as they came up). The main problems are well defined in the task introduction, and of course those may not feel like "problems" to me or you, but still needed to be tackled. It's not that devs come up random changes to annoy people: in this specific case redefining the iconography for switching was, among other things, highlighted as a recommended change in last year's user testing, as it was confusing users.
Well, like i said, i'm not contributing to anything on phab and i don't get tech news. I'm just a little content contributer. But nevertheless is the change not user friendly and i don't understand why there had to be a change as well. Its completly not useful.
Generally speaking, how else do you think you could get involved in such conversations then?
this is only a thought game, but it would be nice, if you can get information about the activated beta-functions in your home wiki. Like the tech new, but only for the most important phab tasks which are effecting the user experience. Like this or changes on the interface. Something like this, posted on the discussion page on your home wiki (after you agreed to that). I can't browse to all the changes on phab, the most of them are simply little changes sometimes for background functionality or things without really hard user impact. But this one for example doubled the clicks i need to switch to source. And i have to switch often if i edit a page, because some code the visual editor is creating isn't that good to save and publish it. So i have to edit the code severeal times per section.
tl;dr: a possibility to get information on your disc.page on your home wiki for the most important cahnges with user impact. only for example.
There is no way to tell which are "the most important phab tasks which are effecting the user experience". Which is why Tech News exists and basically does what you're saying by trying to include as much as possible. Tech News ATM probably doesn't provide much insight into "changes that may be happening months from now", but this is a concept we could play with. We could for example pin the most interesting conversations on the right sidebar of this page. I'll discuss with my team next week about how to improve the existing ways and venues we already use to better flag similar things in the future.
I do want to make a more general point. I can't promise you that you will like every possible change or find it useful. In cases like this, it is usually possible for experienced users to find or request workarounds (or deal with temporary inconvenience), but this is just impossible for logged out or new editors. They wouldn't even know where to go to ask or to express their problems. So this change is important for them. We don't center the entire software development process around them of course, but we do need to look beyond our own experience. Building a good editing experience for everyone is exciting and challenging; making everyone happy is just impossible, but as someone else has already mentioned, there are almost always ways out.
Have a nice weekend.
@Elitre (WMF), please re-open the phab task and have this reverted. It fails to address the issues identified in the task description. You've got the exact same button with exact same issues, plus a pointless helping of "harder to use".
It's a rare and pointless annoyance for Visual Editor switching, but this will be rage-inducing if it's applied to Flow. The fact that Flow can't properly handle or save wikitext, and other misfeatures, are already rage-inducing enough without turning the heavily used "preview" button into an massive pain in the butt.
Sorry, I won't. Per James, "I'm sure there are better designs, but I feel that this will be better, so I'm going with it for now." Whenever someone comes with an actually better solution that's satisfying for everyone, it will be my pleasure to get things rediscussed.
The Button before was actually fine.
There are currently two ways to preview (aka switch) in flow (the second one is a link with the label "preview the result"). So this won't affect much, aside from clicking a different button. It would still be prudent to add a keyboard shortcut for "preview" in flow though (https://phabricator.wikimedia.org/T63517). Although it is likely that will naturally come up as soon as the new wikitext editor is embedded in it.
As far as visualeditor / wikitext editor is concerned, as long as the keyboard shortcut to switch from the Visualeditor <-> to Wikitext editor is fixed and is shown in the drop down menu, it shouldn't be a problem. Currently it seems to work consistently in english wikipedia (alt + shift + e or alt + shift + v), but on this wiki it doesn't seem to switch back to wikitext editor.
There is a difference in perceived efficiency and actual efficiency. Researchers found as that for novices toolbars are faster than menus but keyboard shortcuts are way more efficient for experienced users especially for repetitive actions:
http://dl.acm.org/citation.cfm?id=1978942.1979351&coll=DL&dl=GUIDE&CFID=231586142&CFTOKEN=80641087
Having only menus or just keyboard shortcuts may not the best approach but having both is certainly reasonable and backed up by usability research.
I'm guessing that the IP edit is Elitre (WMF).
There are currently two ways to preview (aka switch) in flow (the second one is a link with the label "preview the result").
That link only exists in one mode. Not to mention that the sentence looks like it has two help-links. It's very weird and unexpected that the second link functions as a mode-switch link.
It's not unusual to have to use the mode button a dozen times or more while writing a Flow post. (Six previews equals twelve usages back and forth.) The only thing worse than a dozen uses of a nonsensical one-option-dropdown menu would be having to use it six times, while having to randomly click something else six times. That's completely non-viable.
Regarding shortcut keys: It doesn't make sense to argue the interface shouldn't be fixed 'because yeah the interface is so broken that people should stop using it'. Keep the shortcut keys, and fix the interface for those who don't use shortcut keys.
There is nothing to add. Thanks.