Last modified: 2014-10-09 15:16:11 UTC
Right now, when paging through the images on a page via prev/next, every step creates a new history entry. When the user tries to navigate back to the previous page, they have to step through all the images in reverse before being able to leave the page. This is very annoying behavior when someone is browsing between articles. HTML5 provides a limited ability to manipulate the history (specifically one cannot delete history entries, only replace them), and fallbacks for old browsers provide even less, so it is not clear what would be a good alternative that is possible to implement.
I'm copying here the results of the investigation Gilles did in commit https://gerrit.wikimedia.org/r/#/c/97919/ : * Facebook nukes the lightbox-related history when exiting the lightbox * Flickr leaves the history alone when exiting the lightbox * I tried a couple of common Wordpress lightbox plugins and they didn't affect the URL * Dropbox's lightbox doesn't affect the URL * Amazon's lightbox doesn't affect the URL * EBay's lightbox doesn't affect the URL * Bing Image search leaves the history alone when exiting the lightbox Irrelevant ones (just putting them here so that someone else doesn't waste time researching them): * 500px doesn't have a lightbox, they use pushState and replace history, but navigating is always the full-blown photo page with comments, etc. so can't really be compared * deviantART is the same as 500px, the "lightbox" is the entire full-blown page, so can't really be compared * Twitter, Yahho Image Search, Google Images, HuffPost, Linkedin, BuzzFeed don't have a lightbox that I could find * Pinterest's lightbox doesn't have prev/next
I'd recommend nuking the lightbox history entries when you exit the lightbox, that would be most like going 'back all the way' to the article.
This also applies when closing out the Media Viewer using the "X" instead of going back in the browser. Close the image with X, returns to article. Press back on the browser, and you're back on the media image, /not/ the previous webpage you were visiting. This isn't desirable. I don't think it merits a new bug report since solving how histories are handled might take care of the issue. If not, I'll file a new bug for that specifically.
(In reply to Brion Vibber from comment #2) > I'd recommend nuking the lightbox history entries when you exit the > lightbox, that would be most like going 'back all the way' to the article. If applied to the "X" in the lightbox and the back button for the browser, this could kill two birds with one stone. If practical. I'm willing to test it out.
I still don't see what justifies the nuking, because we're dealing with a fullscreen experience, not a modal like Facebook. Moreover, unlike Facebook (I have to keep referring to them because they were the only example I could find that does something similar to what is suggested here) the navigating experience can start with media viewer. For example, someone shares a media viewer link with me: http://en.wikipedia.beta.wmflabs.org/wiki/Lightbox_demo#mediaviewer/File:Swallow%20flying%20drinking.jpg Clearly, this is about the image. I navigate the gallery a bit, which has similar images that I enjoy. Then I close the lightbox and end up on an article. That's not where my navigation started. Yet at this point, the history gets nuked. I want to get back to these images I was looking at, and I can't. It's a terrible experience. Now, of course, if you guys want to stay stubborn about the nuking idea, you'll start introducing rules like "well, we won't nuke the history if the person starts navigating from a media viewer link". This assumes that you can guess intent, i.e. what people are visiting either the article of the image for. We can't read people's minds, there's no way of knowing if they're more interested in the article-centric history or the image-centric history. Plus, it introduces inconsistency. Users have to literally guess something about our implementation to understand why sometimes the history gets nuked and sometimes it doesn't. I think the mediawiki bias of "the articles are everything" is affecting your judgement. Forget mediawiki for a second: if the URL changes and the entire screen changes, isn't the de-facto web standard that this should be a permanent entry in your browsing history? Another argument is that the alternative to media viewer (which it's trying to replace) is going straight to the file page. That affects your browser history. With backwards UX compatibilty in mind, media viewer should affect browser history permanently.
(In reply to Gilles Dubuc from comment #5) > I still don't see what justifies the nuking, because we're dealing with a > fullscreen experience, not a modal like Facebook. Moreover, unlike Facebook > (I have to keep referring to them because they were the only example I could > find that does something similar to what is suggested here) the navigating > experience can start with media viewer. > > For example, someone shares a media viewer link with me: > http://en.wikipedia.beta.wmflabs.org/wiki/Lightbox_demo#mediaviewer/File: > Swallow%20flying%20drinking.jpg > > Clearly, this is about the image. I navigate the gallery a bit, which has > similar images that I enjoy. Then I close the lightbox and end up on an > article. That's not where my navigation started. Yet at this point, the > history gets nuked. I want to get back to these images I was looking at, and > I can't. It's a terrible experience. The thing is that this is not likely where the start of the experience will begin... > Now, of course, if you guys want to stay stubborn about the nuking idea... <snip> > I think the mediawiki bias of "the articles are everything" is affecting > your judgement. Well, yes. We're writing for MediaWiki use :) The purpose of a wiki, and the purpose of our wikis, is text-oriented, so that's my focus. When I view the files and I click the X, I want to exit out of the viewer experience. I don't think this is colored by my Wikimedia time. Back should go back, X should clear out. If I have just scrolled though 10 images in a gallery, I don't think I want to revisit all the images using the back button.
> The thing is that this is not likely where the start of the experience will begin... We're building a sharing feature that will link to those URLs: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/147 It's very much going to be where the browsing starts in many cases from now on, for anyone who shares an interesting image they find on an article. So no, you can't dismiss that use as being unlikely. > The purpose of a wiki, and the purpose of our wikis, is text-oriented That's a very outdated view. By that standard, the Multimedia project shouldn't exist, if text is all that matters. My understanding is that all this work is done precisely because Mediawiki has been too focused on text and negligent of the possibilities of the media it's being delivered on. > When I view the files and I click the X[...] So the argument brought to the table is that it's your personal preference. I went out and researched the issue, seeing what the web at large is doing in similar situations. I'm not easily convinced by self-centric preference arguments when it comes to designing UX. Particularly when they come from an echo chamber of people who have been similarly influenced by a product to the point of forgetting what the rest of the web does. The question is not why 3 people on this ticket who share a bias by having spent too much time on a product that's always focused too much on text would prefer it to be that way. It's whether the majority of web users would find it to be a better/more logical experience. So far nobody here seems to have made any effort to justify the "pro" view using tangible arguments or real-world examples. It seems to be only driven by mediawiki distortion field where fullscreen images are so secondary that they don't deserve a place in the permanent browser history. Never mind the fact that the user could have spent more time looking at each image than they spent on the article. Also, the "looking at 10 images" argument is blown out of proportion, because it's unlikely to happen. On average people won't look at that many images (we could even gather stats to confirm, but really, it's a simple as seeing that very few articles actually have 10 images, most of them probably have between 0 and 5), unless it's a gallery page. So the "inconvenience" of having to go back as many virtual pages as they actually visited is low on average.
What the rest of the web seems to be doing, though, based on your research, is not having deep links for images at all, with the exception of Flickr and Bing, where images are the only type of content so it makes more sense to center navigation around them. More importantly, I think Wikipedia is different from most other websites in how much need there is for the history when navigating. Websites like Facebook or Flickr or EBay present you with some sort of top-down hierarchy (categories, friends and their event feeds etc), and the actual content isn't really involved in the navigation, apart from providing some prev/next option. In Wikipedia, the content itself is the navigation system [1], so an image history gets much more in the way. (That is my impression, anyway; it would be nice to get less subjective data, like user tests, but I wouldn't rely on best practices from other sites too much in issues concerning navigation, their structure is just too different. E-commerce sites might be a step closer in that search is the primary means of finding comment, but still not quite the same.) Also, some wikis have large image galleries at the end of their articles. MediaViewer could actually make that practice more common, because the user experience of looking through a gallery is pretty horrible now (you either look at the images in something like 100x150px, or load every single one on a separate page, which still looks like crap), but with MV it would become quite nice. Obstructing the navigation gets in the way of that. All that said, I agree that reopening the lightbox via back button is an important use case (although that's partially because the viewer is a bit too eager to exit). Also, nuking the history doesn't seem that easy to implement, given that the History API does not provide a way to learn whether stepping back would navigate you away from the current page or not (not to mention the horrible IE fallback which has a completely different logic). [1] obligatory XKCD comic: http://www.xkcd.com/214/
Filed bug 62578 and bug 62580 about the too eager to exit issue.
(In reply to Tisza Gergő from comment #8) > In Wikipedia, the content itself is the navigation system [1], so an > image history gets much more in the way. > [1] obligatory XKCD comic: http://www.xkcd.com/214/ <grin> Thanks, Gergő, that is the crux of the issue that we have here. I'm going to mark this as RESOLVED->WONTFIX for now. Gilles, I appreciate your feedback. I don't agree with you, but that's fine :) We'll work this out through full development and see where the other exit bugs lead us.
Strike that change state, I'll leave it to y'all.
> More importantly, I think Wikipedia is different from most other websites in > how much need there is for the history when navigating. Mediawiki/Wikipedia is not special from a browser history perspective because it's addictive. It's not special from a browser history perspective because it has an xkcd comic about it. It's just a website, and one that is critically behind the times in many respects. It definitely isn't special enough in any way that it needs its own browser history standard, different from the rest of the web. People visit a lot of pages? Big deal, same thing goes for google and many other high pageview sites and you don't see them messing with the browser history based on an assumption of what people care about the most. If you want to clean people's browser history automatically based on their taste, make a browser extension. Regardless of how you slice it, the back button is linear and the browser history isn't hierarchical. You want something more out of the browser history, and it doesn't exist.
*** Bug 66116 has been marked as a duplicate of this bug. ***
I'll try to explain why this is desired... https://www.google.com https://en.wikipedia.org/wiki/STS-118 Click one image. Hit esc/close viewer You are back in the article Click another image Hit esc/close viewer You are back in the article Click a third image Hit esc/close viewer You are back in the article Now choose: "Back" in your article I expect to navigate to google now, but it is taking me trough 3 images and 3 of the same copies of the STS-118 article and it's annoying.
This personal preference is perfectly understood. Yet it's incompatible with updating the URL, i.e. treating the image as its own page. Since pressing escape updates the browser's URL to restore the article's address, it behaves like visiting a new page history-wise. That's just what the browser does. My point still stands: the only way to do cater for this request is to not treat the image like a page of its own, i.e. not update the URL. Any attempt to mess with the history is misguided, particularly since older browsers are incapable of manipulating their own history. I'll update this ticket's description to be the only possible technical change, but I doubt that the product and UX teams will be interested in losing the ability for people to share the image using the browser's URL.
"I'll update this ticket's description to be the only possible technical change, but I doubt that the product and UX teams will be interested in losing the ability for people to share the image using the browser's URL." That is an entirely different bug/feature request. I moved it to bug 66217. Changing the URL without creating history entries, or removing some of the existing history entries, is entirely possible technically (modern browsers have replaceState; old browsers have location.replace - as long as you limit URL changes to the hash part, the two behave pretty much identically). Facebook does it, as you just said. Whether it is a good idea from a usability point of view is a different issue - one where flinging untested assumptions about user expectations at each other is not going to be productive. Facebook nukes the history; Bing and Flickr keeps it, so obviously neither approach can be a catastrophic failure. (Also, we haven't received many complaints about this so far, which suggests this is not a big problem for most users.)
(In reply to Tisza Gergő from comment #16) >(Also, we haven't received many complaints about this so far, which > suggests this is not a big problem for most users.) new complain: https://de.wikipedia.org/wiki/Hilfe_Diskussion:Medienbetrachter#Umst.C3.A4ndliches_wieder-.C3.B6ffnen_des_Viewers_beim_zur.C3.BCck_gehen
(In reply to Gilles Dubuc from comment #15) > This personal preference is perfectly understood. Yet it's incompatible with > updating the URL, i.e. treating the image as its own page. Since pressing > escape updates the browser's URL to restore the article's address ..... you seem to ignore the facts that both updating the URL when clicking an image, and restoring it when hitting escape is developer's choice, not some objective, unavoidable fact. the solution is super simple: do not update the browser's URL when clicking an image. it's not only easy to avoid doing so, it's the right thing to do. imageviewer does not use natural browser's navigation (this is what we had *before* imageviewer, and then, nobody complained about the way history is handled), it uses javascript to display the image, and it's entirely your decision whether or not to modify the browser's URL when displaying the image through JS. please think about it as a request for consistency: when clicking an image that represents a movie (.ogg) in mediawiki, we open an overlay with "X" in the upper-right corner that plays the movie (see here: [[fr:1907_en_aéronautique]]). ogg viewer does this without updating the URL, so if you visit a page with 5 movies, view them one after the other, hitting the "X" after each one ends, and after the last one you hit "Back", MW does not drag you through all 5 movies you just watched. for sanity and consistency, mediaviewer should behave the same way. peace.
(In reply to kipod from comment #18) > the solution is super simple: do not update the browser's URL when clicking > an image. it's not only easy to avoid doing so, it's the right thing to do. That's bug 66217, as mentioned above. If you find it preferable, you should probably comment there (ideally with stronger arguments than it being "the right thing to do").
(In reply to Tisza Gergő from comment #19) > (In reply to kipod from comment #18) > > the solution is super simple: do not update the browser's URL when clicking > > an image. it's not only easy to avoid doing so, it's the right thing to do. > > That's bug 66217, as mentioned above. If you find it preferable, you should > probably comment there (ideally with stronger arguments than it being "the > right thing to do"). my responses tend to be (too) long, so i assume you just did not read all of it. the comment you replied to already contains a stronger argument than "it's the right thing to do", and if you'll take a minute (or five) and read it, i'm sure you'll be able to find this argument (hint: "consistency"). peace.
I think that it is desirable to achieve both: (a) Keep image specific URLs, and (b) avoid users to go through a long sequence of all the images they have visited. If we don't want to completely wipe the browser history (Gilles provides reasons for that above), what we can do is to limit the image exploration through next/prev to just one back state. In that way, once you exit Media Viewer, the first "back" action brings you back to Media Viewer (preferably in the last image you viewed) and a second one brings you back to where you were before (e.g., an article). With that solution, a use can reach "Kiwi" from the "New Zealand" article, explore 25 images of Kiwis from the gallery and after closing the gallery, the "back" button will bring him to the "gallery" (where MediaViewer controls allow to explore other images, but you are not forced to), then "Kiwi", and then "New Zealand", saving 24 "back" button clicks compared to our current approach.
And what if you want to use your browser's back button to get back to the 20th Kiwi image you viewed, after closing Media Viewer? If, for example you came to the article for images and you just wanted to glance at the article in the middle of your image hunt. 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.
> 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?
