On Apr 26, 2007, at 4:13 PM, Mimi Yin wrote:
On Apr 26, 2007, at 9:07 AM, Morgen Sagen wrote:
And can we remove the sharing filters from the Subscribe dialog
and instead have subscribers find them in the Manage share dialog?
I don't quite follow why you would want to remove the filter
checkboxes from the subscribe dialog, but yes I can take them out.
Hi Morgen, I think I'm just worried that subscribers are being
asked to make a decision, namely decide what attributes to share,
not-share, before they have the information they need to make that
decision:
+ The probably need to take a look at the contents of the shared
collection
+ In the beginning, they may not be familiar enough with Chandler
concepts to understand the significance of sharing, not-sharing
Triage status, etc.
Got it. I'll remove them from subscribe.
We could provide a button from the subscribe dialog that will take
them to the Manage share dialog.
The subscribe dialog automatically closes at the end of a successful
subscribe. Are you saying we should not do that, but instead leave
it open and have a Manage button appear? I'd say for now just have
the user use the Manage menu to get to the Manage dialog.
Ideally, the subscriber is first presented with the set of
attributes the publisher would like to share and if/when the
subscriber feels strongly about what attributes are shared...the
subscriber can go to the Manage share dialog to change the settings.
===
Is what you're describing working today in Chandler?
Everything I described is already in place.
Or is the Detail View blocking edits on read-only items? I'm
concerned about introducing this feature now.
The detail view is not blocking edits on read-only items for EIM
based shares because the detail view depends on the sharing layer to
tell it what to let the user edit or not. The sharing layer is now
telling the detail view that all fields are editable, and it doesn't
really have a way to say which specific Chandler attributes are
editable or not. At this point, if we want to block edits, it will
need to be UI code that implements that.
It seems like from a user motivation perspective, users will want
the ability to have 'local edits' or annotations on both read-only
and read-write items. I think we will also want to limit these
'local' edits to the text fields and disallow local edits for
things like: all-day-ness, event date/time, recurrence rules, etc.
Although, I could imagine different users may want to display event
date/times in different time zones without actually changing the
date/time of the event in 'absolute time'.
In other words, I think I'd like a little more time to think
through this functionality from a usage scenario and workflow
perspective.
It will require work to change the behavior from what I described.
So if we need to block edits of certain attributes on read-only
items, we could probably come up with a fixed list of attributes of
your choosing, like start time/duration, recurrence, etc. that would
be blocked, but it won't be able to take into account any filter
settings.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
