Re: [cosmo] Too Many Dashboard Items!

Seems like this problem will solve itself once we implement auto- 
triaging of events to DONE.

 From other users on the design/users list however, it doesn't sound  
like this is the common case.

On Nov 1, 2007, at 4:41 PM, Bobby Rullo wrote:

> There is a bug (https://bugzilla.osafoundation.org/show_bug.cgi? 
> id=10759) which says Cosmo UI takes too long to load.
>
> The reason it takes too long to load is because there are lots and  
> lots of NOW items, and we always return all NOW items in the  
> dashboard query.
>
> The reason there are lots and lots of NOW items is because people  
> don't triage their items.
>
> Those are the facts. What is less certain is WHY people don't  
> triage their items - I suspect it's for a number of reasons such as:
>
> 	a) They don't use triaging
> 	b) It takes too long to triage each item manually
>
> Esther was the impetus for filing this bug - she went to view the  
> Mitch8 calendar and it had 38 pages of NOW items. She and Mitch  
> don't use the triaging bits of Chandler right now, so she never  
> triages stuff to DONE. (For clues to _why_ she doesn't use triaging  
> see http://lists.osafoundation.org/pipermail/chandler-users/2007- 
> August/000437.html and the rest of the thread. Esther wants finer- 
> grained/customizable statuses for one thing...)
>
> Several ideas on how to fix this problem have been proposed. From  
> the bug comment:
>
>> We could limit the amount of items returned in the now query to  
>> some arbitrary
>> number.
>>
>> We could have add the ability to triage more than one item at once
>>
>> We could have a feature which turns triaging off.
>>
>> We could have a feature which makes the auto-triaging/tickliing  
>> behavior a
>> little different, so that (optionally) events tickle into DONE  
>> instead of NOW
>
>
> One other idea which might be the simplest to do is to have a  
> preference for the default view. Presumably, people who aren't  
> using the Triage features don't have much interest in the dashboard  
> view.
>
> The trick is though, where do you persist the preference? If it's  
> by user, what does that mean for people who are viewing the  
> collection via a ticket? Do we just go with the owner's preference?  
> Do we have per-collection preferences for this?
>
> Anyhow, doing this seems to be the minimal amount of work to solve  
> bug 10759, but in the long term being able to perform actions on  
> multiple events as well as controlling how triaging works is  
> important.
>
> Feedback appreciated!
>
> bobby
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design