[Design] [cosmo] Too Many Dashboard Items!
mimi at osafoundation.org
Mon Nov 5 11:00:36 PST 2007
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
>> 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
> 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
> Feedback appreciated!
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Design" mailing list
More information about the Design