Thanks for reviving this discussion. :) This issue has been brought up a number of times before, and it seems worth reconsidering, if we can find a practical solution that could be implemented quickly, before we switch our focus beyond Media Viewer in coming weeks. For example, we could revisit the ‘metadata panel’ metaphor and think more of a ‘page section’ concept instead. Medium.com (1) offers wonderful design examples of how a page can start with a fullscreen cover photo on top, and contain more information below — and Flickr (2) also used a similar approach, as shown in the links below. I recommend that Pau look into an alternative design along those lines, create a quick prototype and discuss it with users — and if the response if favorable, review it with the team at our next planning meeting, to see if that idea could be implemented in our timeframe. For now, I have started a ticket on Mingle to track this request: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/697 Thanks for keeping us honest, you guys :) Fabrice (1) Medium page: https://medium.com/book-excerpts/secrets-of-the-stacks-4ca8405f1e11 (2) Flickr screenshot: https://docs.google.com/a/wikimedia.org/presentation/d/1wZvLx_Q-bpCCMBjz2Y6… On Jun 5, 2014, at 1:29 PM, Rob Lanphier <robla(a)wikimedia.org> wrote: On Jun 5, 2014, at 12:54 PM, Gergo Tisza <gtisza(a)wikimedia.org> wrote: On Jun 5, 2014, at 12:42 PM, Erik Moeller <erik(a)wikimedia.org> wrote: On Jun 5, 2014, at 12:37 PM, Quiddity <pandiculation(a)gmail.com> wrote: _______________________________ Fabrice Florin Product Manager Wikimedia Foundation http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)

Which is more intuitive depends on your mental model. If you think of the metadata panel as something that opens and closes, pressing up to bring it up and pressing down to bring it down makes a lot of sense. If you think of it as part of the page, that is currently out of view, it's the opposite. The current layout of MediaViewer reinforces the first model, IMO, with the image not scrolling when the metadata panel moves. Either way, it's important to support both models. We currently do that by flashing the panel controls if you press the wrong direction - I think that's a good approach but the implementation is basically unnoticeable and should be made much more prominent. On Thu, Jun 5, 2014 at 12:42 PM, Erik Moeller <erik(a)wikimedia.org> wrote:

On Thu, Jun 5, 2014 at 1:29 PM, Rob Lanphier <robla(a)wikimedia.org> wrote: the rest of the web, and that we may need to make more of a change than providing a more prominent hint. I think we need a more prominent hint either way, and even more so if we change existing behavior. The lack of that hint is the bigger problem; what behavior we assign to up/down is the smaller one. (Also, we are not talking about normal scrolling behavior either way, are we? We are animating the panel on up/down, and we are talking about keeping that animation, but reversing the directions. Not animating at all would certainly be more consistent with the wider web, but also somewhat inconvenient IMO, as there is little practical use in opening the panel partially, and standard up/down key behavior is slow. I agree with Fabrice here: if we want to change directions, we should reconsider the whole metaphor. E.g. the chevron initially pointing up and then changing direction doesn't really make sense in a scrolling model.)

I think there are different aspects discussed here: *Overriding key behaviour* I think it is legitimate to override the browser behaviour if it aligns with user goals and keeps consistency with default behaviours. For example, in the Gmail list of emails the up/down keys are overridden to select individual messages instead of scrolling (while the rest of scrolling possibilities are kept as default). Similarly, many carrousels allow to access sequences of images by both right/left arrows and touch gestures as if the user was scrolling. However right/left keys provide access to the next images not producing an increment in horizontal scroll, and that feels natural. Relying on scroll to support the current behaviour is just an implementation choice. I think it is a good choice since the behaviours align well, but that should not mean that the UI should expose verbatim all the exact behaviour of its underlying components. The fact that it does not feel natural for some users, highlights a different problem (more on this later). *Our current metaphor* Our current metaphor brings us good things such as minimising the moving parts: when you access the metadata the whole screen is not moving, just the metadata info you are interested in. That keeps the image (and controls such as close or fullscreen) anchored and easy to go back to them. An alternative approach where the whole page moves (as the Medium and old Flickr examples Fabrice commented) will make the whole thing feel as a heavier single page. *Up or down* with user expectations? This bring us back to the question of which is the right direction to scroll, or what are you acting on (the viewport or the content). There are many advantages in following a direct manipulation model, but it is true that both scrolling directions (and thus both ways to understand scroll) still exists nowadays. I think that if we reverse the directions, that will become confusing for other users. So what I initially proposed was to make the panel open by clicking either up or down. In that way, users with different mental models will just get the expected outcome. I still think it is worth a try to check how it feels (we may want to try it with a common.js override). I'm open to explore other affordances for opening the panel, but I think the problem is not the whole general metaphor. Pau On Thu, Jun 5, 2014 at 2:56 PM, Brian Wolff <bawolff(a)gmail.com> wrote: -- Pau Giner Interaction Designer Wikimedia Foundation

I've just created a very basic CSS override. I added instructions on how to try it on the mingle card comments <https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/697> with an existing test account, but you can also add the following CSS to your common.css: .mw-mmv-image-wrapper, .mw-mmv-post-image{ position:initial; } Even though there are details to polish to be called a prototype, my initial impression is that it does not feel as good as our current approach, but feel free to provide any feedback. This seems like the kind of thing to throw a few quick hallway tests at. Yes. If someone provides me with the JS snippet to be added to common.js, setting this up and testing should be really fast. If this the JS is more complex than it seems, I can also create a quick prototype. Pau On Thu, Jun 5, 2014 at 6:03 PM, Erik Moeller &lt;erik(a)wikimedia.org&gt; wrote: -- Pau Giner Interaction Designer Wikimedia Foundation

When the panel is closed and the user presses either "up" or "down" keys, open the panel. On Thu, Jun 5, 2014 at 6:40 PM, Gergo Tisza &lt;gtisza(a)wikimedia.org&gt; wrote: > On Thu, Jun 5, 2014 at 6:19 PM, Pau Giner &lt;pginer(a)wikimedia.org&gt; wrote: >> >> This seems like the kind of thing to throw a few quick hallway tests at. >> >> >> Yes. If someone provides me with the JS snippet to be added to common.js, >> setting this up and testing should be really fast. If this the JS is more >> complex than it seems, I can also create a quick prototype. >> > > _______________________________________________ > Multimedia mailing list > Multimedia(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/multimedia > > -- Pau Giner Interaction Designer Wikimedia Foundation

I think that picking isolated websites (gmail or medium) isn't enough to get a sense of what the average user's expectation is. These two particular examples aren't necessarily the best for other reasons: Google products and Gmail in particular have always had very engineer-minded keyboard shortcuts because engineers rule the culture at Google. That's not necessarily the best thing for accessibility if you don't have that culture. As for Medium, it's too new to have proven itself as something with good accessibility. Maybe a lot of people are getting confused by medium's interface, we wouldn't know. I suspect that the reason why this keep coming up is that we're overriding a key that normally provides core browser functionality. Also, anyone who happens to have the opposite mental model than the one we cater for, either through their experience of the web, of their use of tablets, etc. will have a very hard time training themselves to remember to "do it right" in Media Viewer. It goes against their intuition and even if we visually inform them that they're "doing it wrong", they have to learn to use the tool, which is bad. Something like Media Viewer should be intuitive for everyone. Even if we pick the option that works for the majority, there will still be a non-trivial amount of users for whom the up/down arrow behavior will feel counter-intuitive. And every time it doesn't do what they expect, they get a little more annoyed at the product. In my opinion, we should stick to only creating keyboard shortcuts that use keys that aren't overriding browser mechanics. We can keep right and left arrow because we know that Media Viewer never has horizontal scrollbars, but for opening/closing the metadata panel I think we should use something else like "M" that would both open and close the panel. And keyboard shortcuts can be documented on Media Viewer's help page, and could also be displayed in the UI (when hovering the clickable equivalent, for example). We can even add a bunch, for example a shortcut to download the original file (D?), to view the full size (V?), go to the file page (F?), etc. We can internationalize them as well if we want to. That might actually help with the power users complaints that some things now require multiple clicks in Media Viewer that didn't use to on the file page. Give them keyboard shortcuts to save clicks and it might make a subset of them happy. And if we stick to plain letters with no modifiers for those shortcuts, we shouldn't run into any browser functionality conflict (since plain letter presses are normally left undisturbed so that html inputs can receive them). On Fri, Jun 6, 2014 at 8:12 AM, Gergo Tisza &lt;gtisza(a)wikimedia.org&gt; wrote:

I created versions of the different options we are discussing (to try, access beta wiki <http://en.wikipedia.beta.wmflabs.org/wiki/Lightbox_demo> with the test users indicated below): - A: Panel opens with both up and down arrows (user: mv-both, password: 123) - B: Up and down keys act as default for scroll (user: mv-none, password: 123) - C: Provide image and data on a continuous page (user: mv-page, password: 123) I'm ok with A or B. I think A provides a better solution to the user intent (view the metadata), while avoiding diverging from the standard scrolling direction too much. If A still generates confusion, I'm ok to default to the browser defaults, but I think the line-by-line increment will led most people to unnecessary additional key presses. I think that changing completely the metaphor we are using (as in C), will bring more problems than benefits (e.g., what to do with the controls over the image). I'll do some quick tests with some users, but feel free to provide your impressions when trying the above. Pau On Fri, Jun 6, 2014 at 8:32 AM, Quiddity &lt;pandiculation(a)gmail.com&gt; wrote: -- Pau Giner Interaction Designer Wikimedia Foundation

Thanks, Pau, really appreciate your quick turnaround with this prototype. I just tried it and the user experience worked for me. I didn’t miss the sliding panel approach we had before — which was nice, but not worth the confusion caused by counterintuitive arrow keys. Before you show the prototype to casual users, it would be great to change the direction of the arrows, so they get the whole experience as it is intended to work. Maybe that’s something that Mark could help you with, when he returns from his one-day vacation on Monday. Thanks again for your willingness to try this alternative. I know it’s not your first choice, but I think it’s worth exploring, since quite a few people have expressed confusion about this issue. :) Fabrice On Jun 5, 2014, at 6:19 PM, Pau Giner &lt;pginer(a)wikimedia.org&gt; wrote: _______________________________ Fabrice Florin Product Manager Wikimedia Foundation http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)