Page MenuHomePhabricator

Closing MMV should restore history state to where it was when opened
Closed, ResolvedPublic

Description

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.


Version: master
Severity: normal

Details

Reference
bz66116

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:11 AM
bzimport added a project: MediaViewer.
bzimport set Reference to bz66116.
bzimport added a subscriber: Unknown Object (MLST).
TheDJ created this task.Jun 4 2014, 12:20 PM
Gilles added a comment.Jun 4 2014, 1:56 PM

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 ***
Gilles triaged this task as Unbreak Now! priority.Dec 4 2014, 10:11 AM
Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles lowered the priority of this task from Unbreak Now! to Needs Triage.Dec 4 2014, 11:22 AM