Next iteration of List Reorderer in Announcements posted...

[Daphne Ogle]

Some thoughts below...

And I just want to emphasize that this is a particularly tricky  
context since we assume a very, very small % of users will actually  
use reordering in announcements.  However, as you point out, we set  
user's expectations in one tool for how things will work in all tools.

Thanks to everyone for all the great feedback on this!  Please keep it  
coming.  I'll be working on a storyboard for reordering in resources  
starting this iteration and I'm sure that will bring up more  
interesting challenges, trade-offs, etc.

-Daphne

On Oct 27, 2008, at 4:04 PM, Clay Fenlason wrote:

> Thanks, Daphne.  There are clearly aspects to this I haven't thought
> about.  But I'd still like to push on a couple points.
>
> I'm not sure, for example, what clutter is introduced by allowing
> reordering - it doesn't seem like there needs to be anything to
> display until the dragging-and-dropping commences.  I was in fact
> thinking that the clutter argument went entirely the other way (why
> have "Reorder" appear on the screen when that could be assumed, if
> there were a consistent approach for all tabular listings in the
> application?).  Consistency across all tabular listings (currently
> rather too many) in Sakai in particular would seem to have both
> technical and UX benefits in terms of consistency.
The clutter I was referring to is:  1) the info message at the top of  
the page, 2) the column of number-reordering and 3) the rollover text  
users see as they rollover the row.  This may not seem like a lot but  
every piece of information on the page competes with every other piece  
of information and I think this just complicates a very simple tool  
for the 98% (guesstimate)  of users who will never use it.   There's a  
also a bit of hiding the functionality from the core of users to  
protect them from making it complicated/confusing for students/site  
participants.
>
>
> In fact, a lack of consistency here *across* tools might be its own
> issue.  The tables for assignments, announcements, resources, etc.
> really look very similar.  If some of them can be reordered on the fly
> and others require a special reordering mode, some confusion might
> emerge to which it doesn't seem especially helpful to respond, "Ah,
> but in some of those tools you'll realize that you don't end up
> reordering *very often.*"  I'm tempted to say that the issue should
> not be pegged to the announcements tool vs. the resources tool, or
> what-have-you. The UX issue should be pegged to the experience of
> dealing with a *table of stuff*, wherever you encounter it.  This
> feels like one more area where Sakai's tool silos are getting in the
> way, even in how they force us to contextualize the UX - sometimes
> unnaturally.
Absolutely!  I have gone back and forth on this quite a bit.  And when  
consistency really matters is to allow us to set user's expectations  
and *teach* them how to do something once that can reuse across the  
application.  Which of course applies here.  That said, the reordering  
itself will happen the same way (eventually) across the tools which is  
the more tricky interaction.   I feel like the limited use of this  
functionality (response above) is reason enough to require the extra  
step to be able to reorder in announcements.  I'm really interested in  
others thoughts on this...

I don't think this is a matter of tool silos.  Perhaps tool silos are  
what forces us to think about how this works in various tools but  
context is king in UX.  Announcements and resources are both "tables  
of stuff" but they are different contexts.   The important difference  
between these 2 contexts is the frequency of reordering and the  
typical user organizational models (announcements time based model is  
requiring interaction that won't be required in non-time based  
contexts).  Another example of how context matters is looking at  
Netflix.  Netflix uses the up arrows to allow users to move movies up  
their cue because they can assume that most of the time a user's  
intention is to move movies up so they get them quicker.  Of course  
sometimes they may want to delay a movie and move it down the list but  
much less of the time.  Having both directional arrows is a more  
complex interaction.  So the tradeoff was to simplify the interaction  
for the bulk of use while perhaps making it a little less intuitive  
for moving items down.   In resources however, we can't make that  
assumption so if we were to have directional arrow interaction we'd  
likely have both.  This is so key to how we think about design in  
Fluid.  Although we are developing reusable chunks of interface/ 
interaction they will look and work differently according to the  
context.  We think through a variety of contexts and then make them  
easily configurable in ways that make sense for the primary contexts  
of use.
>
>
> I had thought about the tricky aspects of clicking on different areas
> of the rows, too, since they can have their own interactions, and once
> again turned to Netflix to see how they handled this.  There I find
> that a click-and-release on the title link works as expected (as
> though I were just clicking on a link), but if I click on the link and
> don't release the button I'm able to drag the row around.  Far from
> being tricky, this ended up adapting to my intent more readily than I
> had predicted (I might even use the phrase "user delight").  More
> precisely, if I click, hold the button, and move the row *at all*, it
> doesn't behave as a link, even if I move it back to where it was
> originally.  But if I click and hold down the button for a long time
> without budging the row, then let go, it still behaves as though I had
> just clicked on the link.  This seems like an elegant answer.
Yes, I think the Netflix interaction is very elegant and I think we  
should follow their lead here.    We also have the number-reordering  
to fall back on which is good.  Although this is an elegant solution,  
exact mouse clicking can be difficult for a significant number of  
people for reasons (e.g. less mouse experience, arthritis, motor skill  
challenges, a mouse that doesn't work well, etc.).
>
>
> ~Clay
>
> On Mon, Oct 27, 2008 at 4:29 PM, Daphne Ogle <daphne at media.berkeley.edu 
> > wrote:
>> Clay et al,
>>
>> There are a few main reasons for forcing the user to go into  
>> reorder mode in
>> this context rather than just have the reordering in place as you  
>> say.  For
>> the most part this is context specific to announcements.
>>
>> 1)  From what I've been able to find out, this isn't functionality  
>> that
>> falls into the 80% use rule.  It seems to be a work around that some
>> instructors have requested at Michigan.  So, rather than have it  
>> clutter the
>> main page, we've moved it to its own mode.  Even for those that use  
>> the
>> functionality, reordering is not a frequently completed task so  
>> adding a
>> click to get to it is better than having the functionality there  
>> competing
>> with readability (the #1 activity in this tool) all the time.  This  
>> is also
>> the reason I've recommended reordering is only available in this  
>> tool once
>> it's been turned on in options.  It would be off by default.  The  
>> netflix
>> context (which I also use as a benchmark) is different in that a  
>> common
>> activity is rearranging your list of movies.
>>
>> 2)  An interaction that is included in list reordering but not in the
>> previous reorderers (layout reorderer and image reorderer) is the  
>> ability to
>> reorderer with numbers.   There's user testing data that drag and  
>> drop is
>> easiest and preferred when a list is fairly short.  Once the list  
>> gets long,
>> particularly when it requires lots of scrolling, the easiest and  
>> preferred
>> interaction is using the numbers.  By itself this isn't a reason to  
>> have a
>> reorder mode but the added column coupled with infrequent use of  
>> reordering
>> is.
>>
>> 3)  Another input is thinking about the other interactions on the  
>> page.  The
>> title of the announcement is clickable for instance, so as a user,  
>> making
>> sure you "grab" the item rather than open it (by clicking the  
>> title) can be
>> a bit tricky.   That said, I kept the title clickable in the  
>> reorder mode
>> anyway so users could see the details of the announcement while  
>> reordering
>> (it's a tradeoff but seemed more important to be able the see the
>> announcement content in the reorder context).   The bigger  
>> challenge is that
>> the whole row is what is being moved but it really isn't an  
>> "object" in the
>> main interface.  So as a keyboard user moves the main page in  
>> announcements
>> they would first focus on the announcement title, then the authors  
>> name,
>> then the access and so on.  In the reorder mode the entire row  
>> becomes an
>> object so the keyboard movement would be from the 1st row to the  
>> 2nd to the
>> 3rd and so on.   This is another difference between the list in a  
>> table and
>> our previous types of reordering where there are objects users move  
>> through
>> (thumbnails and portlets).  This challenge by itself really isn't  
>> reason
>> enough to force a reorder mode (we could just define the keyboard
>> interaction to select the entire row before selecting individual  
>> items in
>> the row).
>>
>> I believe the next place we'll be integrating reordering is in  
>> resources
>> where reordering is a much more common activity.  I'd like to avoid  
>> another
>> mode for it.
>>
>> -Daphne
>>
>> On Oct 26, 2008, at 7:58 AM, Colin Clark wrote:
>>
>>> Clay,
>>>
>>> On 26-Oct-08, at 9:53 AM, Clay Fenlason wrote:
>>>>
>>>> Is there an accessibility reason, perhaps, for why reordering in  
>>>> place
>>>> is the wrong way to go?
>>>
>>>
>>> I'll let Daphne or others respond to the overall interaction  
>>> question,
>>> but I don't see any specific accessibility reasons for avoiding
>>> "reorder in place." Indeed, in other implementations of the  
>>> Reorderer,
>>> such as uPortal 3.1's use of the layout reorderer, we don't use a
>>> separate mode at all. Reorderering is just there when you need it.
>>>
>>> Colin
>>>
>>> ---
>>> Colin Clark
>>> Technical Lead, Fluid Project
>>> Adaptive Technology Resource Centre, University of Toronto
>>> http://fluidproject.org
>>>
>>> _______________________________________________
>>> fluid-work mailing list
>>> fluid-work at fluidproject.org
>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>
>> Daphne Ogle
>> Senior Interaction Designer
>> University of California, Berkeley
>> Educational Technology Services
>> daphne at media.berkeley.edu
>> cell (510)847-0308
>>
>>
>>
>>
>
>
>
> -- 
> Clay Fenlason
> Director, Educational Technology
> Georgia Institute of Technology
> (404) 385-6644
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (510)847-0308