Next iteration of List Reorderer in Announcements posted...

Mon Oct 27 23:04:05 UTC 2008

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.

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.

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.

~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