Last modified: 2014-06-04 13:56:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T68116, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 66116 - Closing MMV should restore history state to where it was when opened
Closing MMV should restore history state to where it was when opened
Status: RESOLVED DUPLICATE of bug 62266
Product: MediaWiki extensions
Classification: Unclassified
MultimediaViewer (Other open bugs)
master
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-06-04 12:20 UTC by Derk-Jan Hartman
Modified: 2014-06-04 13:56 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Derk-Jan Hartman 2014-06-04 12:20:34 UTC
I agree with the feedback quoted below. If I'm navigating, I'm expecting that my history 'pops' back to where it was when I entered the viewer, as this is an application inside the current discreet page. Now each separate view is acting as a discreet page, which is just a little bit too much.

I classify this as a bug, because it is messing with my expectations of using a website.


To quote from the feedback page:

Media Viewer functions as a discreet page making navigation awkward[edit source]
First, I'll be blunt: I don't care for this new media viewer and I don't see what purpose it serves on an encyclopedia. I use Wikipedia for a fair amount of image research for personal projects, as it's a great way to find things in the commons. As such I often click on images, read their description pages, and figure out if I can use them or not before continuing my research. Not only is the information that was readily available just last week now buried in the fine print, but the "application" apparently functions as a separate page, even though it in no means looks like one. If you close the "application", as you would visually similar applications on popular social and photo-sharing websites, and later hit the back button the navigate to your original search, you find that it takes you to the media viewer. If you've viewed and closed multiple images on a page this can lead to an unnecessarily large amount of clicking to navigate back to a page you thought was immediately previous to the one present.
Comment 1 Gilles Dubuc 2014-06-04 13:56:00 UTC
Already discussed and rejected, see duplicate ticket. Going to the file page also affects people's browsing history, yet it's not a source of complaints.

As long as Media Viewer changes the URL, it should be recorded in the history. The point of view displayed in that feedback is very editor-centric. "the article is more important than images" - the same way that Commons contributors might consider file metadata a lot more important than readers do, or might consider that images are more important than articles.

The self-centric suggestion (by that I mean that a small subset of users want *their* subjective preference to be the experience for everyone) ignores how confusing it will be for readers to have parts of their history nuked arbitrarily because we've decided that they should care more about articles than they should care about the full-window images they've seen. It would be even more infuriating for someone who cares about the images to lose the history, because they have no way of recovering it. That's a bigger annoyance than having more history that you like, which can easily be skipped.

Elsewhere on the web, when your entire page changes, it's expected that the URL changes and that the history is affected.

Anything that tries to go against the browser's standard behavior to provide a  non-standard UX is invariably a bad idea in terms of usability. In the same way that people spending a lot of time on mediawiki can influence a subset of them into such ways of seeing things (articles > images), the vast majority of our users - readers - are influenced by every other website they visit, the vast majority of which will not mess with the browser's standard history behavior. I've done a lot of research on other large websites and the only one that messed with history was Facebook, but it wasn't truly comparable as their photo view is a small popup on top of the page, it doesn't take over the entire page like Media Viewer. Thus users have different de-facto expectations. Every other large website dealing with image display either didn't update the URL or left the history alone when they did.

The only flavor of this request that would be acceptable is if Media Viewer didn't affect the URL at all. This never seemed to be a considered option, as sharing with the context preserved is seen as a very important feature. Hence why this request was rejected. Since browser history is flat and can't accommodate "subpages", we can't make images unimportant in one dimension (history) and important in the other (URL). I'm not against getting rid of the URL being updated by Media Viewer, but even people who requested that we mess with the history before didn't seem to be intereted in that idea.

*** This bug has been marked as a duplicate of bug 62266 ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links