On May 31, 2007, at 11:19 AM, Mimi Yin wrote:
Hi Morgen,
I think we need to consider the magnitude and frequency of the
inconvenience.
1. I have 4 shared collections. I'm sharing TS on 3 of them because
I work so closely with the other person sharing that collection
that we really want to be on the same page wrt what's NOW, what's
been DONE and what's deferred to LATER. (That way I can relax and
stop nagging them about open tasks ;o) The 1 collection where
shared TS doesn't make sense is the Office Calendar.
Certainly if you're sharing with yourself...you want to share TS.
Other sharees can always choose to uncheck TS when subscribing to
the share. That's the beauty of the new and improved, asymmetrical
sharing filters!...But the publisher will want to share TS so that
they can pull it down from a different machine.
2. The inconvenience for the Desktop user consists of going to the
Manage share... dialog to uncheck TS after publishing.
3. The inconvenience for the Hub user consists of waiting a long
time for data to load into the web UI. (Morgen had some questions
re: How slow will it be? How
4. OTOH, it may be fairly serious to be really slow for 1st time
Hub users. As Casual Collaborators, they're not really dedicated
Chandler users. Many CCs may not have even ever heard of OSAF or
Chandler. Instead, they're being drafted by Desktop users. If the
first time they click on a ticket, the UI is very slow to load
data, it may make for a poor first impression that turns people
away before they've had a chance to explore the UI.
That being said, once a CC has clicked on a ticket and lived
through the pain of waiting for all the data to load into the web
UI and get triaged by the web UI, other CCs will inherit the triage
status assigned by the first CC's account.
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
On May 31, 2007, at 10:53 AM, Morgen Sagen wrote:
It's coming down to a decision between inconveniencing the
Chandler user every time they publish, or inconveniencing the
first Web UI user to subscribe to a collection-without-triage.
How do we come to a decision about who loses?
Ok, I'll remove the checkboxes from the publish dialog. However,
you're really just sweeping an underlying problem under the carpet.
If I understand the problem correctly, the first time Sunbird/
Lightning/OtherCalDAVClient publishes a calendar to Cosmo, the Web UI
will be in for a bit of a wait.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
