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-bpCCMBjz2Y64...

On Jun 5, 2014, at 1:29 PM, Rob Lanphier robla@wikimedia.org wrote:

On Thu, Jun 5, 2014 at 12:54 PM, Gergo Tisza gtisza@wikimedia.org wrote:

...

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.

It would seem to me that this approach assumes the user is wrong to press "down", and needs re-education. Mark is making the case that we're fighting expectations set by pretty much the rest of the web, and that we may need to make more of a change than providing a more prominent hint. My personal experience concurs with this. The Snow Fall example[1] (and many others like it) show how fixed-image-position scrolling like we do is compatible with the traditional expectation of up-arrow/down-arrow behavior.

Of course, I'm going to allow for the possibility that I'm cranky and old school, and that I just need to learn to hit the correct arrow key. :-)

Rob [1] http://www.nytimes.com/projects/2012/snow-fall/

On Jun 5, 2014, at 12:54 PM, Gergo Tisza gtisza@wikimedia.org wrote:

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 Jun 5, 2014, at 12:42 PM, Erik Moeller erik@wikimedia.org wrote:

I have to agree with Mark here - it took me a while to discover the up-arrow behavior, and I suspect users miss the metadata panel because of this reversal of default direction.

I understand that it doesn't exactly behave as an incremental scroll right now, but it's still confusing.

-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

On Jun 5, 2014, at 12:37 PM, Quiddity pandiculation@gmail.com wrote:

On 14-06-05 11:17 AM, Mark Holmquist wrote:

...

So.

When I go to a web page, and I'm browsing it, and I want to read *more content*, I accomplish this in one of four ways:

• Scroll down with my scroll wheel or trackpad
• Scroll down with page down
• Scroll down with the spacebar
• Scroll down with the down arrow key

All of these work in Media Viewer, except for the last. You have to use the *up* arrow key to accomplish a scroll-down movement. This makes NO SENSE.

+1 from me.

...

Someone on the talk page has complained about this same thing [0] and frankly that's enough reason for me to make more noise about it again.

Can we *please* rejoin the entire rest of the web in not screwing with native browser scrolling controls, and letting people just scroll normally? Do people actually like the up-arrow control for expanding the metadata panel? Other comments about scrolling?

[0] https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Can.27t_co...

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

_______________________________

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@wikimedia.org wrote:

I have to agree with Mark here - it took me a while to discover the up-arrow behavior, and I suspect users miss the metadata panel because of this reversal of default direction.

I understand that it doesn't exactly behave as an incremental scroll right now, but it's still confusing.

-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

On Thu, Jun 5, 2014 at 1:29 PM, Rob Lanphier robla@wikimedia.org wrote:

Mark is making the case that we're fighting expectations set by pretty much

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*

From my point of view, the big question is: does the up/down arrows align

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@gmail.com wrote:

On 6/5/14, Gergo Tisza gtisza@wikimedia.org wrote:

...

On Thu, Jun 5, 2014 at 1:29 PM, Rob Lanphier robla@wikimedia.org

wrote:

...

...

Mark is making the case that we're fighting expectations set by pretty much

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.)

FWIW, my mental model would be to press a down arrow. If there's a metaphor here suggesting an up arrow, its not coming across to me.

But I may also just be old (young?) and cranky.

--bawolff

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

I recommend that Pau look into an alternative design along those lines, create a quick prototype and discuss it with users

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 erik@wikimedia.org wrote:

One additional point: Right now I can press Page-_Down_, or Scroll-_Down_, but have to press Arrow-_Up_. I fail to see how this is logically consistent with a single mental model.

Making both work might make sense, though honestly I'd be surprised if users actually try to press Arrow-Up to see the panel.

This seems like the kind of thing to throw a few quick hallway tests at.

-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

What exactly should that snippet do?

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 gtisza@wikimedia.org wrote:

On Thu, Jun 5, 2014 at 6:19 PM, Pau Giner pginer@wikimedia.org 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.

What exactly should that snippet do?

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

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 gtisza@wikimedia.org wrote:

On Thu, Jun 5, 2014 at 7:55 PM, Pau Giner pginer@wikimedia.org wrote:

...

What exactly should that snippet do?

When the panel is closed and the user presses either "up" or "down" keys, open the panel.

var oldLoadViewer = mw.mmv.bootstrap.loadViewer; mw.mmv.bootstrap.loadViewer = function() { return oldLoadViewer.apply( this, arguments ).done( function() { mw.mmv.bootstrap.viewer.ui.panel.scroller.keydown = function() { mw.mmv.bootstrap.viewer.ui.panel.scroller.toggle(); }; } ); };

This makes both the up and down keys toggle open/closed state.

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

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 pandiculation@gmail.com wrote:

On 14-06-06 02:34 AM, Gilles Dubuc wrote:

...

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.

Possibly, it would help to re-word the way we're understanding these 2 examples, into the abstracts that they represent:-

In line- or list-item-highlights, like email programs (Thunderbird, etc), or file managers, or spreadsheets, or drop-down menus:

• Clicking the keyboard down-arrow will move the highlight downwards by

exactly one (1).

In full-window-highlights, like a PDF-viewer, or image-viewer, or webpage:

• Clicking the keyboard down-arrow will make the content scroll-upwards.

(by a variable amount, depending on OS, program, and user-settings. Sometimes 1 line, sometimes 3 lines, sometimes x pixels.)

(and similar results for left/right arrow-keys)

HTH.

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

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 pginer@wikimedia.org wrote:

I recommend that Pau look into an alternative design along those lines, create a quick prototype and discuss it with users

I've just created a very basic CSS override. I added instructions on how to try it on the mingle card comments 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 erik@wikimedia.org wrote: One additional point: Right now I can press Page-_Down_, or Scroll-_Down_, but have to press Arrow-_Up_. I fail to see how this is logically consistent with a single mental model.

Making both work might make sense, though honestly I'd be surprised if users actually try to press Arrow-Up to see the panel.

This seems like the kind of thing to throw a few quick hallway tests at.

-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

---

Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

-- Pau Giner Interaction Designer Wikimedia Foundation _______________________________________________ Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia

_______________________________

Fabrice Florin Product Manager Wikimedia Foundation

http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)