Next iteration of List Reorderer in Announcements posted...

[Michael S Elledge]

Hi All--

Being able to flag announcements as "important" or "high priority" makes 
sense to me, too, and is much simpler, as well as allows students to 
retain control over their UI. Have students been asked their opinion of 
this? Aren't we putting too much control in the hands of faculty?

Mike

John Leasia wrote:
> Here at UMich we've had requests for general reordering in 
> Announcements. We thought that getting the Fluid reorder in there 
> would be the simple case, then move it to other tools that reorder 
> lists so as to have a consistent way of doing it throughout Sakai 
> (what we also want to do with the datepicker by the way). Some of our 
> faculty want to present a sequential path through content. They use 
> Schedule tool for assignments for example (the assignment instructions 
> are in the event description). Some want to use announcements as the 
> main tool and want more control than just date over the order (they 
> change things, or maybe name the announcements Week 1, Week 2, etc. 
> with additional announcements in between on occasion. They want to set 
> some of them up ahead of time, some not, etc.  The ability to stake 
> one at the first position is part of that in some cases.
>
> John L
>
>
> 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
>>>     
>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elledge.vcf
Type: text/x-vcard
Size: 313 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20081027/b96bd7d4/attachment.vcf>