[Design] [Cosmo][Desktop] Making sure the server never ends up with a big pile of untriaged Chandler items

Mimi Yin mimi at osafoundation.org
Mon Jun 4 12:54:08 PDT 2007


BCM, Are you okay with holding off on changing the Chandler UI for now?

I think Jeffrey is proposing that we first see:
1. How many people choose to uncheck Triage Status when Publishing  
collections from Chandler.
2. How long it will take for the web UI to Triage a big pile of  
untriaged items.

Again, the big pile of un-Triaged items problem only affects the very  
1st Casual Collaborator who clicks on a ticket to view a shared  
collection where TS is not being shared. Once that 1st CC has done  
the work of triaging all the items, all subsequent CC's will benefit  
from the work done by the 1st ticket viewer.

Removing the Sharing Filter checkboxes from the Publish dialog on the  
Desktop seems like an easy change we can make if we find that the Hub  
experience is too slow. Is that true Morgen?

Just to re-iterate the plan of record so that we're on the same page:
1. The web client pulls down all NOW and LATER items and some  
reasonable set of the "most-recently-triaged-to-DONE" items.

2. If the collection is a big pile of untriaged items either because  
it's a DAV share or because the Desktop Publisher unchecked Triage  
Status when sharing...the web UI will have to pull down everything  
and things will be slow. Perhaps we could display a 'Triaging xxx  
items for the first time...' message to soothe easily agitated users.

Mimi

Begin forwarded message:

> From: "Brian Moseley" <bcm at osafoundation.org>
> Date: May 31, 2007 1:19:23 PM PDT
> To: "Chandler Design list" <design at osafoundation.org>
> Subject: Re: [Design] [Cosmo][Desktop] Making sure the server never  
> ends up with a big pile of untriaged Chandler items
>
> On 5/31/07, Morgen Sagen <morgen at osafoundation.org> wrote:
>
>> Just to be clear, we're talking about the "publish" dialog, and I am
>> more than willing to wait until later to address this in Chandler.  I
>> still contend this is going to be a problem for collections that non-
>> Chandler CalDAV clients publish, so it has to be addressed on the
>> Cosmo/WebUI end at some point anyway, unless other CalDAV clients are
>> not going to be supported by Cosmo.
>
> nobody disagrees with you, but the number of people who face this
> potential slowdown, for hub at least, is much lower if desktop always
> publishes a collection with triage status. the fewer people who feel
> this pain the better until we can come up with an improved approach.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
Begin forwarded message:

> From: Jeffrey Harris <jeffrey at osafoundation.org>
> Date: May 31, 2007 12:14:39 PM PDT
> To: Chandler Design list <design at osafoundation.org>
> Subject: Re: [Design] [Cosmo][Desktop] Making sure the server never  
> ends up with a big pile of untriaged Chandler items
>
> Hi Folks,
>
>> I think all of this depends on just how slow the web UI will be if it
>> has to load all the items, untriaged.
>>
>> Mimi
>
> Could we hold off on removing the don't-share-triage-status option  
> from
> subscribe?  Now that we've loosely decided the web UI will process
> not-yet-triaged items, it seems like there wouldn't be much harm in
> holding off on waiting and seeing what the experience is like in  
> the web UI.
>
> Sincerely,
> Jeffrey
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070604/a68b069b/attachment.html


More information about the Design mailing list