And what if you want to use your browser's back button to get back to the 20th Kiwi image

You will click the "back" button, and then use Media Viewer "prev" arrow to go back to the image you were before.

I think that the behaviour can be intuitive for the user, but in the case it is not, you still have the possibility to recover: Imagine you click the "back" button one time (going to Media Viewer) and then again (exiting Media Viewer), you only need to click the browser "Forward" button to return to the Media viewer and use the next/prev controls to locate the desired image.

The argument of browsing 25/50/100 images is blown out of proportions.

That depends on the article ("Kiwi" has 7 pictures, but "New Zealand" has about 30) and the specific user interaction. The number of times you have to click the "back" button, depends on the movements you made through images. Thus, a user going back and forth with prev/next through 5 images will require more than 5 back button clicks to undo his path.

It is not only a problem of volume, but the user mental model about what constitutes an activity. Articles are also composed by sections, but creating history steps for each section the users go through would be problematic. Even for fewer sections, the user would not recognise those as relevant steps. Similarly, we provide users with a collection of images and each individual step seems to be perceived more as part of a single activity (exploring the collection) than as many individual tasks. Obviously the divisions in this case are more blurry than the article/section example, but I think that the volume is just a manifestation of the underlying problem.

So your suggestion is to have an experience where people have to get lost by following their natural instinct (pressing back twice), then have to learn that they've lost their history in that context and need to use next/prev? And given how far apart in time people will run into that trap, they'll have to re-learn through failure several times before they've finally assimilated "the right way" to use the product.

If you're in favor of considering that browsing images isn't an activity on the same level of importance as browsing from one article to the next, then the URL shouldn't be updated, and then the history just follows that logic. You can even have the one-level approach using this, if the URL is updated to only include MediaViewer when you enter Media Viewer. The back/forward buttons would still let you get in or out of Media Viewer if you do that.

(In reply to Pau Giner from comment #21)

what we can do is to limit the image exploration through next/prev to just one back state

This is fairly close to how Google+ Photos works (with the exception that they do nuke the history when you exit the lightbox).

As said above, I am highly skeptical of the claim that something done by Facebook and Google could be a horrible usability blunder. They have the manpower for detailed usability tests, and the image viewer is a central, highly visible feature both in Facebook and in Google+.

If Pau is interested in doing some user tests to get more reliable information on what users feel natural, I can write some JS snippets which modify the history behavior from user JS.

Otherwise, I would still be comfortable with assuming that whatever Google or Facebook does is probably well tested, and going with that. (Assuming that we can do the history nuking thing for browsers without History API. I am not sure how exactly they achieve that, but the History API has conceptually the same operations as the old window.location API, so I expect it will be possible to do the same.)

As for the current behavior, bug 67008 would make it somewhat more comfortable. I have a patch mostly ready for that, I'll finish it this weekend.

(In reply to Gilles Dubuc from comment #22)

The argument of browsing 25/50/100 images is blown out of proportions. Most
articles don't have anything close to 20 images on them.

I think what relevant for us is how many images a reader usually sees in an article; in other words, articles should be weighed by their pageview count. I expect frequently viewed articles are better written and have many images. We don't have the right stats to calculate an average, but as a quick experiment, the top 10 enwiki pages (per stats.grok.se) have 20, 18, 4, 30, 3, 1, 8, 30, 9 and 0 images in them, respectively (not counting portal icons etc), so articles with ~20 images are not that infrequent.

This change cannot go through without thorough user testing. And not just experienced users, readers need to be represented as well.

"Google and Facebook must have done the homework, so we don't have to" is a ridiculous idea. It's very surprising to see you mention that they must be following a perfect process to design their products, following the amount of doubt you've displayed about the decision-making process in your own organization. If there are companies that are likely to design their products without caring about users' direct feedback, it's Google and Facebook. The millions of "likes" on petitions to bring back their older UIs should be an indication that they're not always acting with usability or their users in mind. As for deliberately making confusing UIs, I think they've proven to do just that repeatedly in order to increase their ad clicks. Inexperienced web users confuse sponsored links and the real deal, in Google results and Facebook feeds alike and that's entirely by design. It's dangerous to assume that each of their products has the best possible usability in mind. And not just because they have to consider the effect on revenues, they're very large organizations and those history-modifying features we've found aren't very prominent. We're not talking about their front page here. They're very likely to have been built by small teams, interns, etc. and not necessarily doing proper user testing.

As for nuking the history without the history API, where have you seen that happen? I consider that such support for older browsers is impossible until proven otherwise. That's another large weakness of this idea, which I've brought up before. People switching between browsers will have a drastically different experience. And basic navigation falls into "grade A" features, imho.

I agree that we need to do our testing (and those snippets will be extremely useful, Gergo. So thanks for the offer).

I also think that when we refer to a widely used product as an example, we should not just assume they are doing the right thing (since our context may be quite different), but use those examples to remember how was our experience using them and whether (and why) the problems we are anticipating in theory occurred in practice or not.

So your suggestion is to have an experience where people have to get lost by following their natural instinct (pressing back twice)

No. What I'm saying is that presenting the whole image sequence as a step in the history may align well with the mental model of our users, and for those that it does not, they can still achieve their goal. If the second group is significant, it will mean that my assumption was wrong.

There has been considerable debate over this, so I'll try to summarize the options, and then we can pick which are good candidates for in-depth testing. I'll try to list the benefits and disadvantages of each approach, please fix where you feel it's biased.

A: keep current behavior

• pro: follows standard web logic of one URL - one history entry
• con: gets in the way when browsing several articles in the same tab

B: don't change URL at all, don't add history entries

• pro: decreases complexity of code
• con: sharing image-over-article becomes less intuitive, breaks sharing via devices/tools which use URL directly

C: change URL but do not add history entries

• pro: easy to implement (now that IE7 is grade C)
• con: mispredicting browser behavior is costly (clicking on back to go back to previous image will instead cause you to leave the page, and probably lose scroll position), no one seems to be doing this

D: add a history entry when you enter the lightbox, but don't add new ones for next/prev navigation

• pro: easy to implement (now that IE7 is grade C)
• con: can still get in the way when going back to previous article (although much less so than the current behavior), no one seems to be doing this

E: Facebook-style: nuke all MediaViewer-related history entries once the user exits MediaViewer

• pro: Facebook does it, fits an "app" mental model well
• con: unusual, cross-browser implementation might be problematic

F: Google Photos style: like D but nuke the history when exiting the lightbox

• pro: Google does it
• con: unusual, cross-browser implementation might be problematic

G: do E or F but use History API, drop older browser support

• pro: consistent browser behavior, easy to implement, better URL i18n
• con: need to drop IE 8-9, makes HTML caching problematic

An example to make the differences clear: users visits article -> clicks on image 1 -> clicks on next, sees image 2 -> clicks on close -> clicks on image 4 -> clicks on next, sees image 5 -> clicks on close

The history stack will look like this:
A: a -> a,1 -> a,1,2 -> a,1,2,a -> a,1,2,a,4 -> a,1,2,a,4,5 -> a,1,2,a,4,5,a
B: a -> a -> a -> a -> a -> a -> a
C: a -> 1 -> 2 -> a -> 4 -> 5 -> a
D: a -> a,1 -> a,2 -> a,2,a -> a,2,a,4 -> a,2,a,5 -> a,2,a,5,a
E: a -> a,1 -> a,1,2 -> a -> a,4 -> a,4,5 -> a
F: a -> a,1 -> a,2 -> a -> a,4 -> a,5 -> a

Implementation sketch: modern browsers support the history.pushState() and history.replaceState(), with the popstate event to detect changes. Older browsers support history.location.go() and history.location.replace(), with the hashchange event to detect changes. (Really old browsers, namely IE7 and below, don't support hashchange and have weird bugs with the rest, but they are now Grade C and do not get any Javascript at all. Yay!) So old and modern browsers have the exact same set of operations (which does not preclude the possibility that bugs in some version of some browser cause inconsistent behavior).

So for C, we just need to replace instead of push; and for D, we need to replace instead of push if the viewer is already open.

E and F add another kind of step, where the last few history entries are removed. There is no direct way to do this; we could check how Facebook & Google do it (they both rely on the History API with a HTTP fallback, though). Probably they use history.back() to walk back until the first state that needs to be kept, then replace it with itself. We could do that (it's still the same set of operations on old and new browsers), but the logic is complex (e.g. we would need to special-case the situation where the page is loaded with a MediaViewer hash already in place), and there is a much larger surface for browser bugs/inconsistencies.

Which versions are good candidates for a user test? I would go with C - very easy to implement, and should at least tell us whether the whole problem of history pollution can be captured in a user test at all. Pau, any thoughts?

Interestingly, the mobile lightbox doesn't exhibit this behavior - does it purge the history entries? I still see it as one of the most frequently reported annoyances with MV as it is today. It would be very nice to play with an alternative behavior, perhaps initially as a pref to see if it causes any problems.

@Tgr I would like to try D.

I think that the main question is on which sets of events the user perceives as an atomic unit. In those terms, D means viewing an individual image as a unit, and viewing a collection of images also as a single unit.
It will also allow to differentiate the impact of two different scenarios: a user undoing his path through individual clicks on images in an article (which will still occur) vs. a user undoing each step when navigating images inside Media Viewer (which is expected to be solved). We need to make sure testing for both behaviours, to consider whether a "nuke history when exiting" approach (E,F,G) is worth the effort.

It also makes the behaviour of the back button inside Media viewer to change from going to the previous image to exit the viewer (something worth observing to decide later between E and F which behave differently regarding that aspect).

GCI task: https://www.google-melange.com/gci/task/view/google/gci2014/5808506137477120

In T64266#968820, @Tgr wrote:

GCI task: https://www.google-melange.com/gci/task/view/google/gci2014/5808506137477120

broken link

Works for me.

The task hasn't been approved/published by an org admin, so not everyone can see it yet.

GCI task available now. Sorry for the lag.

I've created a prototype for approach D. To try it out, on mediawiki.org edit User:[your_username]/common.js and add the following line:

importScript('User:Unicodesnowman/T64266Prototype.js');

(also available on enwiki, same name)

This monkey-patches MMV using a variety of hacks, so only Firefox / Chrome is supported. A new 'mmv-open' event is created - it's necessary to detect when the viewer is opened/closed, as the naive approach of letting the first hash change add, and all others replace, is buggy when the user uses 'Forward'.

Updated: Now done with hash parsing, much simpler and correctly manages closing MW.

In T64266#973239, @Unicodesnowman wrote:

I've created a prototype for approach D. To try it out, on mediawiki.org edit User:[your_username]/common.js and add the following line:

importScript('User:Unicodesnowman/T64266Prototype.js');

User: uxtest-mmvhistory-d, pass: 123 (on mw.org)

I tried this and seems to work well.
I tried going to a page, following a link, exploring several images, and trying to go back to the initial page. I think that while images are represented in the back sequence, the main issue of going through the individual steps of a sequence is avoided.

This can be some small test worth considering for upcoming testing sessions by @aripstra.

Mass-removing the Multimedia tag from MediaViewer tasks, as this is now being worked on by the Reading department, not Editing's Multimedia team.

Why not add an option in the media viewer itself? In that way every user can opt-in (or opt-out) and decide how they want the media viewer to work. Also, you could gauge how many people prefer the "nuke history" type of behavior and how many prefer the current behavior instead.

For what it's worth: I am so annoyed by the current behavior that sometimes I avoid clicking on a picture (even though I wanted to zoom it) because I don't want to open it in a new tab and also because I want to be able to go back with ALT+LEFT. So consider that some users are deterred to click pictures, because of this.

I think nobody wants to close the image, hit "back" and see that image again. This isn't the expected or intuitive behavior.

So what's holding this?

There is a very simple solution by using the HTML location.replace method for displaying the previous ("<") and next (">") images (see: https://www.w3schools.com/jsref/met_loc_replace.asp )

So, it's almost 2019 and this is still an issue. It seems this would not get resolved, even when it's such a annoying and undesirable behavior of the site.
Right now I just avoid to view images because I will have to press back button like twice as needed.

Related: T189173 will hopefully find a standard way inside mediawiki core of doing this.

As an affected user, I'd like to resolve this issue at the Hackathon in Prague. I might need some help.

My first question is whether this issue can be resolved without getting T77258 done, i.e., by building upon T64266#973239.

The mobile web site has solved this problem so multimedia viewer just needs to follow the example given by it's code. We use mediawiki.router - making use of it is really not hard. The library needs to be imported and used. The fix is really simple.

My understanding is there was debate about what the behaviour should be in https://phabricator.wikimedia.org/T64266#2901210 - or can we just fix this?

Let's just fix it and then, if really there was some consensus to be reached, we will revert (it won't happen).

Sometimes things are stuck only because there is little interest. It's clear here that most people who are interested in the matter want the behavior to change; others just aren't too interested so it's not critical to formally reach a consensus.

@simon04 I'll be wearing an internet archive hoodie and wikipedia t-shirt to help me be more findable if you want to look at this together. :)

@simon04 @wil93 @Jdlrobson were y'all able to make progress on this at the hackathon? I find the updates to the mobile site a huge usability improvement and am enthusiastic about making similar changes on desktop as well.

There's a big patch in development in the context of T77258. Once merged, also this issue will be resolved. :)