On 10 September 2014 04:58, David Gerard <dgerard(a)gmail.com> wrote:
On 10 September 2014 12:54, Andrew Gray
<andrew.gray(a)dunelm.org.uk> wrote:
* inter-wiki or intra-wiki integration of
multiple-venue discussions
rather than several parallel pages and potentially parallel
discussions (not a very frequent issue, but a messy one when needed;
Pine notes this below)
Yeah, that's getting into the "solves a problem I have" area I was
thinking of.
A few more of these and experienced users will be demanding Flow.
[Talking well into the future, and free-lancing a little in Danny's area;
please do not expect this soon.]
One of the pain points about our treatment of content vs. discussion right
now is how to expose to casual editors of a page that discussion is
on-going about a particular aspect of an article, or that there has been a
lot of argument about an aspect of the page and that this is now 'settled'
– not that it can't be changed, but that editors may wish to consider
before blindly changing something.
These discussions can range from the very specific (what exact term /
wording should we use here?) to the very general (we should take care to
use photos of the concept from all 'sides' of the debate). Most often
they're about a small chunk of content and proposals to alter, expand or
remove it. Indeed, the need to comment on these is flagged quite often when
talking about Flow – generally in terms of "we need to copy content into
the discussion and back out again", which I think is a solution rather than
the core problem we're trying to address, framed by our current way of
treating discussions.
Normally these discussions, and their total lack of visibility to all but a
handful of editors who read the talk page and all its archives before they
make each edit, aren't a problem. It's rare that a page has issues, after
all, and very often "common sense" gets you most of the way there, so even
without knowing about prior discussion your edits can be uncontroversial.
Sometimes we make edits against these agreed points, and someone previously
involved in the discussion notices and undoes the change (or "fixes" it or
whatever), and might drop a note on their talk page to that effect. This is
effective for very highly-watched pages, but adds a lot of burden to people
to monitor their watchlists' articles for changes against their hazy
memories of what has and hasn't been discussed. Certainly, editor working
on recent changes patrolling won't know the particulars of each article and
the local discussions that have been had.
Occasionally, we use HTML comments to shout at potential editors ("Do NOT
change his race!" on Barack Obama's article on the English Wikipedia, for
instance). These are confusing to newbies (it's a magic fragile syntax
that's uncommon), don't always 'work' (lots of people tune out whacky
syntax they don't know), and very rarely give an indication as to /why/
some user posted that instruction, when this dates from and whether it's
still current, or if it actually has consensus.
To make it easier for editors, we could provide a way to attach discussions
not just to an article (Talk:Foo is stuff about "Foo") but as well to a
particular item inside Foo – a section, a paragraph, a template, a
reference, an image. When you edit, we could show somehow discussions
attached to that item.
There have been proposals to use a right-hand bar to show information
relevant to the content in view ("see related Wikidata item"; "articles on
this subject in other languages use these images"; etc.); that could be a
neat place to put relevant discussions' subjects/titles (or even the whole
discussion). Alternatively, we could put little markers in a tray/gutter
that users can click on to see more of, or put a highlighted ring around
content subject to recent discussion when editors change it. There are lots
of ways we could consider making a more powerful, more visible way to
discuss content.
Making these kind of tool available through VisualEditor would be pretty
easy (though getting the design right for all our workflows would need some
care, and as always the challenges of getting a reasonable, consistent
design for phone, tablet and desktop platforms will need some thought).
Doing it in the wikitext editor in a way that makes sense for users might
be harder. However, "hard" is not a good enough excuse for us not tackling
these kinds of big issues around making editing a simpler, more obvious
experience that doesn't need people to have read the talk page and all its
archives before making an edit.
Does that sound like a useful change for experience editors? :-)
J.
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester