Next iteration of List Reorderer in Announcements posted...
daphne at media.berkeley.edu
Mon Oct 27 20:29:01 UTC 2008
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.
On Oct 26, 2008, at 7:58 AM, Colin Clark wrote:
> On 26-Oct-08, at 9:53 AM, Clay Fenlason wrote:
>> Is there an accessibility reason, perhaps, for why reordering in
>> 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 Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> fluid-work mailing list
> fluid-work at fluidproject.org
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
More information about the fluid-work