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