Next iteration of List Reorderer in Announcements posted...
Daphne Ogle
daphne at media.berkeley.edu
Mon Oct 27 20:49:45 UTC 2008
Hey John,
Thanks for your feedback! I am in total agreement with you.
The use of reordering in announcements is a little fuzzy and is
targeted toward a select few. This is one of the reasons we've
required turning it on in options. My assumption is even having the
functionality available in your instance will be configurable. It
seems to be helping a few instructors with some workarounds. I hope
this is a temporary fix and more time will be spent to understand the
goals of these users and a better long term solution. The good news
is that it has allowed us to really think through list reordering from
both a design and component integration perspective. I'm really happy
with the core of the list reordering interaction. Much of what you
see in the designs will be used in other contexts in Sakai.
I should have also sent the link to this page with scenarios I heard
when I asked the community what the goals for reordering in
announcements are:
http://wiki.fluidproject.org/display/fluid/Scenarios+-+List+Reorderer
You can see the "out of scope" section lists a couple scenarios that
clearly don't require reordering and I've recommended some sort of
priority indication icon as you describe. Perhaps we really need a
set of attributes users can assign to announcements -- author can set
it to high priority and reader can also set it to important, or need
to read later, etc.? I didn't put a lot of thought into it since it's
out of scope for the current work but I again hope it's something that
gets more thought and work. It could be a model used across Sakai in
many contexts where we want to help users manage their information
(and alleviate information overload).
-Daphne
On Oct 25, 2008, at 4:27 AM, John Norman wrote:
> I have just taken a look at these and am very impressed.
>
> However, I can't help wondering if this is a case of a solution
> looking for a problem. In particular, the (only?) mentioned use
> scenario is "instructor wants to ensure an important announcement(s)
> are prominent" (paraphrased). I would like to suggest that this
> would be more simply and more intuitively achieved with a
> 'favourites' star or an 'important' flag. The nice thing about this
> is that it is familiar and requires very little development. It also
> has the benefit that a student could also decide an announcement is
> important (to them) and keep it near the top of their own list. I
> would imagine starring or flagging (we use starring to select sites
> to appear in our drop down equivalent of the site tabs) would need
> some sort of priority. Perhaps the very latest announcement first
> (to ensure it doesn't get missed entirely), followed by any
> announcements flagged by the instructor, followed by any
> announcements flagged by the student. More adventurously I imagine
> it would be OK if anything flagged could be unflagged by the student
> (perhaps with the event recorded in case they said they hadn't seen
> the announcement). In this scenario, if I have something I really
> want to keep prominent to remind me, I can do so - but I will have
> been forced to acknowledge the announcement the instructor wants to
> be sure I see. Hmnnn... now that has set me thinking about allowing
> announcements to require acknowledgement.
>
> Have we got other cases that suggest re-ordering to an arbitrary
> order is in fact what users really need?
>
> John
>
> On 25 Oct 2008, at 00:59, Daphne Ogle wrote:
>
>> Storyboard: http://wiki.fluidproject.org/x/p5s7
>>
>> Storycards: http://wiki.fluidproject.org/x/toBI
>>
>> Feedback welcome and encouraged as always...
>>
>> Daphne Ogle
>> Senior Interaction Designer
>> University of California, Berkeley
>> Educational Technology Services
>> daphne at media.berkeley.edu
>> cell (510)847-0308
>>
>>
>>
>> _______________________________________________
>> 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
More information about the fluid-work
mailing list