UIO Design Questions
jvass at ocadu.ca
Tue Apr 9 11:17:17 EDT 2013
Thanks for the reply. I agree that the dots can be very useful as a visual cue to indicate how many preferences there are. At one point we had the dot list in the UIO panel mockups, but it became complicated by the different results between clicking and scrolling.
When a user clicks next/previous buttons through the panel, the current dot they are on is clear. But when the user scrolls through the panel, the current dot is less clear since the preference boxes would move ahead depending on how far the user has scrolled. I suppose we could round it to the closest dot, but I'm worried that that may cause extra confusion? Another option could be to change the scroll interaction to have the same effect as clicking the next/previous buttons - when the user scrolls, the preference boxes move the full width (regardless the distance scrolled). This gives a bit less control, but more consistency throughout.
Also the amount of dots would need to change depending on the browser width. I'm not sure if this would be an issue?
On 2013-04-08, at 10:33 AM, Valles, Heidi wrote:
> Joanna, your wiki page describing panel scrolling interactions is really helpful.
> I wonder if we want to incorporate an additional design element to our carousel. Most out there have an element that relays how many panels or scrolling bits there are via a list of dots, with one selected. For example, see the top of this page: http://ryrych.github.io/rcarousel/
> I like the additional information this conveys, and I think it might be beneficial from an accessibility perspective in terms of added understandability. One wouldn't have to predict/investigate the number of preference panels (or pages of panels?) by clicking through first. Not sure how it would fit exactly, but maybe something to consider.
> On 2013-04-05, at 3:44 PM, Cheetham, Anastasia wrote:
>> On 2013-04-05, at 2:50 PM, Johnny Taylor wrote:
>>> As for you're second question, as counter productive as this sounds and likely is, making said chevrons not focusable might be worth considering. Cos a keyboard user would land on each focusable element regardless of the chevrons being usable/ focusable or not. It actually might add potentially 2 redundant steps?
>>> I know, that wasn't your question, but answering that question I guess is similar to making skip links visible on focus. I say, as a keyboard user, yes, make skip links visible on focus and bring off screen panels into view. Both are confusing otherwise. My two cents.
>> Johnny, thanks for your input. Your comments *do* answer my question, which was: How would users bring off-screen panels into view? Your point is that as a keyboard user tabs through the controls, the panels would naturally scroll into focus; is that a correct paraphrasing? In that case, yes, you wouldn't want the chevrons to be focusable.
>> We weren't sure whether or not the designers had envisioned some other way of bringing panels into view without requiring tabbing through all the controls. Joanna seems to have answered that question with the wiki page she's working on, which describes exactly the interaction you describe.
>> Anastasia Cheetham Inclusive Design Research Centre
>> acheetham at ocadu.ca Inclusive Design Institute
>> OCAD University
>> fluid-work mailing list - fluid-work at fluidproject.org
>> To unsubscribe, change settings or access archives,
>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
More information about the fluid-work