Next iteration of List Reorderer in Announcements posted...

Daphne Ogle daphne at
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:

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).


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:
>> Storycards:
>> Feedback welcome and encouraged as always...
>> Daphne Ogle
>> Senior Interaction Designer
>> University of California, Berkeley
>> Educational Technology Services
>> daphne at
>> cell (510)847-0308
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at

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

More information about the fluid-work mailing list