Last modified: 2014-08-15 12:03:48 UTC
Several people have requested removing the prev/next arrows (and the corresponding keyboard functionality) for thumbnails in articles, and only use them for images which are part of a sequence (such as a gallery). The argument is that a reader wants to see images in the article whenever they reach to the corresponding point in reading the text; it makes little sense to jump forward to images about subjects they did not yet read about.
I'm unsure about this one: the functionality does feel useless most of the time, but sometimes it is quite handy to compare similar or related images in an article (such as the first two images of [[Retouching]]). Also, it seems quite harmless: if someone dislikes jumping within the article, they can just ignore the functionality. The arrows are not distracting and rarely overlap an image with typical dimensions. (A related consideration is that we preload the next and previous image; that is a waste of bandwidth if the reader only clicks a few of the images and never uses prev/next navigation. OTOH if they don't use prev/next navigation but do click on all the images in order, preloading is still useful.)
Prev/next gets used a lot; globally we have about 10M thumbnail clicks and 10M prev/next clicks a day: http://multimedia-metrics.wmflabs.org/dashboards/mmv We don't log whether a prev/next action happens in a gallery or on a thumbnail; it would be neat to have that data, although it would require some shuffling around of code. Also, it would be nice to log in what order / via what method a user looks at images in an article. This would require rethinking our logging scheme and use something similar to the flow events used for UploadWizard.
This was discussed e.g. here: https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer/Archive02#Remove_the_arrows_and_view_of_other_images_in_the_article
Thanks for opening this report. I'm aware of the questions raised above (mainly: why remove the function if you can just ignore it). Nonetheless, I have the impression limiting the slideshow feature will improve the overall experience for both unexperienced and experienced users. Less confusion. Less "it rips images out of context" contra arguments (here is just one of many examples for this argument: https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#The_core_problem). We know the slideshow is a great feature in galleries and categories. I don't think there is a question about this. I suggest to also enable it for all images that are in the same table (think of a table of monuments with each row showing and describing a monument). Another possibility (not sure about this; to be discussed) is to enable it for all images in the same section of the article. But apart from that the slideshow feature should be limited and not jump to images that are more and more unrelated and out of context the farther the user clicks. This will also improve the "browser back button" experience (by simply limiting it) which obviously feels weird for many users and is already discussed and reported many times.
I agree, this is an "it rips images out of context" vs "people really like to browse around". So what needs to be analyzed is: 1: Can we provide more context ? 2: Can we make it clearer where the user is in the article when browsing the image ? 3: Can we let people browse, but inform them they are going out of context 4: Do we need people to browse 'right now'. 1: I think the team is already doing this, with putting more emphasiz on the caption of the thumb in the next iteration. 2: We could show small previews of the previous and next image in the article. Another idea is showing the user when he is passing a section title or something and making that pass by ... We could provide a miniature view of the entire article on the right side, with a line indicating where the user is. We can fall back to a smaller version of the file, with a bit transparency and let the browser scroll the thumbnail that the user is right now into view.. Just a few ideas... 3: When pressing the right/left buttons in this case, inform the user that he is moving inside the article. When he presses esc, we can scroll his 'exit point' into view. 4: We know now that ppl really like to do this. So is it important to have them do this right now, if we can improve part of that flow at a later time ? I think it would be a shame to disable this, but I also think that if we have a few ideas on how to improve and reintroduce that feature later, then it isn't unsurmountable either (though would require work of course). DJ
Re: back button, I would first see which way bug 62266 goes. I think the next steps should be: * improve logging (created bug 69598 and bug 69600) and analyze how prev/next is actually used * create a prototype for this and bug 69582 as a gadget; see how popular it is on dewiki; run some user tests
