Page MenuHomePhabricator

[collapsibleTabs] Vector: Tab "Move" should be visible by default (to discourage copy/paste moves)
Closed, DuplicatePublic

Description

Author: danny.leinad

Description:
After a few weeks of existence Vector as default skin, I see a bad thing...

A lot of newbies do not know about option "Move (page)" (because it is hidden) and they moving pages using method copy/paste.

As Wikimedia community we should pay very much attention to respect copyright and I would like to request to set option "Move" as visible tab.


See Also:
T46594: Vector: Page-specific items should not be in sidebar toolbox but in actions dropdown
T55728: 'View history' link disappears in small browser window
T70774: If "More" menu contains only one item (usually "Move"), display the item instead of "More"

Details

Reference
bz24481

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:02 PM
bzimport added projects: Vector, Design.
bzimport set Reference to bz24481.
bzimport added a subscriber: Unknown Object (MLST).

(In reply to comment #0)

After a few weeks of existence Vector as default skin, I see a bad thing...

A lot of newbies do not know about option "Move (page)" (because it is hidden)
and they moving pages using method copy/paste.

As Wikimedia community we should pay very much attention to respect copyright
and I would like to request to set option "Move" as visible tab.

Some users have been doing this wrong even when the move tab was visible (or when they're not autoconfirmed yet and hence cannot move pages). For years on end this has been happening and for an equal number of years more experienced members of the community have been cleaning up after them.

Is there any indication that this phenomenon (copypaste moves) has been getting worse since the Vector deployment?

danny.leinad wrote:

Is there any indication that this phenomenon (copypaste moves) has been getting
worse since the Vector deployment?

In my opinion, yes. Now people do not see this tab and they even do not know that they can drop-down menu, where exist proper option.

(In reply to comment #2)

Is there any indication that this phenomenon (copypaste moves) has been getting
worse since the Vector deployment?

In my opinion, yes. Now people do not see this tab and they even do not know
that they can drop-down menu, where exist proper option.

What I meant was: is there any data that supports this notion?

I think it's hardly empirically measurable, but I can also subjectively say, that the number of c&p "moves" increased.

I would actually suggest to swap history and move links, if there is any reason (which?) for having only limited number of tabs visible. Have the "History" hidden, since it is for newbies less useful than "Move". "Move" is _direct_action_ to the page, while "History" is just obtaining of some kind of metadata. So in general "Move" is more related to "Edit" than the "History" is.

danny.leinad wrote:

What I meant was: is there any data that supports this notion?

Sorry, but I'm not a data analyst, I'm admin of Polish Wikipedia, who regularly patrolling RC and I see what's going on.

Wouldn't it be better if we had a way to check if the contents of a new page are actually the contents of an existing or recently blanked page? We could do this with a hash on the contents and a quick query in a table. Then, if the user appears to be moving a page by copy pasting we can say "it looks like you are trying to move [[this]] to [[that]], would you like to leave behind a redirect? Tip: Moving pages can be done by clicking the move action [[Image:Screenshot of move link in menu bar]]" and then *magically* move it for them.

Bottom line, making things more visible always boils down to helping a particular use case at the eventual cost of most others. If we are seeing a detectable, recoverable misbehavior on the site, we should detect and recover from it. This is also going to ensure we have a far more robust solution that actually prevents the misbehavior rather than just hinting the user into behaving correctly.

I don't think such detection would be a substitute right now, although it may be subject for a different "propose for removal" after a move interface has been restored.

Note that the right isn't necessarily a new tab. Having an edit link near the title, or in the edit tab could also be an appropiate UI (similar to what we have now at bugzilla).

What to do with users which are not allowed to move pages? Perform moves on copypaste only sometimes would be a horrible usability.

What about partial moves (eg. move + fix a typo)?

That detection idea also has its benefits, like users creating a page in two namespaces at the same time, with a difference in case, or recreating a just-deleted page.

I stand in my position though that the move link is important and the removal of move link from the visible tab bar actually harms usability. I don't have real data to back up my arguments, but since the usability study didn't take that into account, there wasn't a real reason for removing either ;)

I have a dejà vu on this about a different bug, which ended up discussing about collapsibletabs (which would be a workaround for hidden menu options, and still don't work).

Just to clarify, I'm not saying that move detection is preferable to having a move link, I'm saying it could help solve for the case where someone is moving by copy-pasting. Also, it would be great if we could get something more than anecdotal evidence that this is occurring more or less based on the skin choice.

A gadget exists to offer users the choice to show the Move tab in Vector: [[MediaWiki:Gadget-MenuToTabs.js]]

Hmmm... there's a bug being discussed about adding checksums to revisions. If we had checksums checking for C&P page moves might be an interesting possibility.

(In reply to comment #11)

Hmmm... there's a bug being discussed about adding checksums to revisions. If
we had checksums checking for C&P page moves might be an interesting
possibility.

Bug 21860 is that bug.

That doesn't look efficient without creating a large index covering the whole revision table.

Just saying, I still lack of use of the Move feature by wiki users that are totally unaware of it. The enhancement request feels still relevant.

This has been brought up at pl.wp's Village Pump again when an experienced user couldn't find the 'Move' link after changing his skin from Standard/Classic to Vector (after the recent skin removal event): https://pl.wikipedia.org/w/index.php?title=Wikipedia:Kawiarenka/Kwestie_techniczne&oldid=36433876#Przenoszenie_pod_sk.C3.B3rk.C4.85_Wektor.3F..

Design input, anyone?

swalling wrote:

(In reply to comment #15)

This has been brought up at pl.wp's Village Pump again when an experienced
user
couldn't find the 'Move' link after changing his skin from Standard/Classic
to
Vector (after the recent skin removal event):
https://pl.wikipedia.org/w/index.php?title=Wikipedia:Kawiarenka/
Kwestie_techniczne&oldid=36433876#Przenoszenie_pod_sk.C3.B3rk.C4.85_Wektor.
3F..

Design input, anyone?

In addition to making the Move tab more visible, a possible enhancement could be generating an alert of some kind if the user selects/copies the entire contents of page.