Within the next few weeks, I'll be deploying VisualEditor for 1000+ authors here at Cimpress/Vistaprint, in a wiki with 225,000 articles.
I plan to collect feedback from our users on what works and what doesn't. What would be the best way to communicate this feedback to Wikimedia?
Here are some early, informal comments from our pilot group of 20 users:
"I am in love!"
"TemplateData integration is awesome."
"How do I insert <code> tags?" (He didn't notice the "More" link in the font menu.)
"How do I set the width of a table column?"
"How do I copy and paste table rows?"
"Editing links is fiddly" (https://phabricator.wikimedia.org/T124305)
"I didn't see the editing tools at first because they're white on a white background."
"Can we save the page without having a pop-up?"
Thanks, DanB
I think the Editing team would be interested in this! Pinging James Forrester.
I am glad to see the interest in tables. Table editing is much easier in VE than in wikitext and I'd love to see additional table editing functionality in VE, including the ability to import tables from spreadsheet applications with text and cell formatting.
Pine
On Fri, Jan 29, 2016 at 12:22 PM, Daniel Barrett danb@cimpress.com wrote:
Within the next few weeks, I'll be deploying VisualEditor for 1000+ authors here at Cimpress/Vistaprint, in a wiki with 225,000 articles.
I plan to collect feedback from our users on what works and what doesn't. What would be the best way to communicate this feedback to Wikimedia?
Here are some early, informal comments from our pilot group of 20 users:
"I am in love!"
"TemplateData integration is awesome."
"How do I insert <code> tags?" (He didn't notice the "More" link in the font menu.)
"How do I set the width of a table column?"
"How do I copy and paste table rows?"
"Editing links is fiddly" (https://phabricator.wikimedia.org/T124305)
"I didn't see the editing tools at first because they're white on a white background."
"Can we save the page without having a pop-up?"
Thanks, DanB
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 29 January 2016 at 12:22, Daniel Barrett danb@cimpress.com wrote:
Within the next few weeks, I'll be deploying VisualEditor for 1000+ authors here at Cimpress/Vistaprint, in a wiki with 225,000 articles.
Hey Daniel,
Best of luck with the deploy!
I plan to collect feedback from our users on what works and what doesn't.
What would be the best way to communicate this feedback to Wikimedia?
Broadly, feedback about the features (bugs, confusion, design suggestions, feature requests, enhancements, *etc.*) should go on https://www.mediawiki.org/wiki/VisualEditor/Feedback (though most people there are talking about Wikimedia wikis, as you might imagine).
You can also give ideas directly onto Phabricator at https://phabricator.wikimedia.org/maniphest/task/create/?projects=VisualEdit... if that's of interest.
Feedback about the software (difficulties configuring it, *etc.*) generally go on https://www.mediawiki.org/wiki/Extension_talk:VisualEditor as other sysadmins read there for advice, problem solving and recommendation sharing.
Here are some early, informal comments from our pilot group of 20 users:
"I am in love!"
Thank you. The team have done a great job, and it's great to hear people are happy. :-)
"TemplateData integration is awesome."
They'll probably like even more guided, and eventually rich DOM, editing of template parameters based on TemplateData hinting, which is something we're working on now (starting with title search-ahead).
"How do I insert <code> tags?" (He didn't notice the "More" link in the font menu.)
Yeah, this is something I'm not totally sold on how we can solve. Giving immediate access to all 20+ text styling options wouldn't be so great (overwhelming, and encouraging people to use rarely-used and indeed rarely-appropriate but valid options like <mark> or others; there's also the possibility for extensions to add to this list, so it's not trivial to make the design scale appropriately). We may re-visit this at some point. Suggestions and examples of this done well (or poorly!) elsewhere always welcome. :-)
"How do I set the width of a table column?"
This is a pretty low priority for us, and coming up with a clean design that pushes users into (a) not using it at all, and (b) if they really must, strongly encouraging them to use %age-based columnar widths would take more time than it's worth to us.
"How do I copy and paste table rows?"
This was just completed this week into master, and will roll out to Wikimedia wikis this coming week, and will be part of the REL1_27 release. You can play with it at http://en.wikipedia.beta.wmflabs.org/wiki/Table if you want a sneak preview. ;-)
"Editing links is fiddly" (https://phabricator.wikimedia.org/T124305)
On first blush this looks like the changes we've made since REL1_26 have changed this issue a bit, but I'll look at it properly when it's not 22:45 on a Friday.
"I didn't see the editing tools at first because they're white on a white background."
One of the key design objectives of the VE project has been, since the start, moving towards making editing a simple and easy and as close as possible to reading; as part of this, the visual separation between modes is intentionally light-weight and indeed we're thinking long-term about ways to initiate editing on a smaller scale than "the page" – something like an edit button against each paragraph which lets you edit and exit quickly.
"Can we save the page without having a pop-up?"
Yes, right now the "save" step is pretty heavy-weight, partially as part of our desire for Wikimedia wikis to ensure that people are consciously and intentionally publishing onto the Internet forever. I've done some thinking about moving the licence-acknowledgement step up-front into a one-time only thing, and so making saving much less heavy-weight a process. This kind of change is likely to be necessary for any future ventures into the equally exciting and concerning epic product changes related to real-time collaborative editing. In the mean time, a double-press of the keyboard shortcut will bring it up and immediately initiate save, though that doesn't exactly fix the issue raised.
Hope this helps!
Yours,
James, thank you much for your detailed response!
Regarding the <code> tag not being visible in the VE menu:
Yeah, this is something I'm not totally sold on how we can solve. Giving immediate access to all 20+ text styling options wouldn't be so great (overwhelming, and encouraging people to use rarely-used and indeed rarely-appropriate but valid options like <mark> or others...
May I suggest putting the set of visible styles into the hands of the wiki administrator, through a simple configuration variable? Some prominent wikis, like mediawiki.org, would benefit from having the <code> style visible above the "More" element, while others like Wikipedia might not need <code> much.
"I didn't see the editing tools at first because they're white on a white background."
>One of the key design objectives of the VE project has been, since the
start, moving towards making editing a simple and easy and as close as possible to reading...
Our workaround has been to set the tools' background color to #F0F0F0, very close to white but slightly contrasting. After all, you do want the reader to know that any tools appeared at all....
After the rollout of VE at my company, we'll provide feedback through the channels you suggested. Thanks again. DanB
wikitech-l@lists.wikimedia.org