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.
We could provide a button from the subscribe dialog that will take
them to the Manage share 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? Or is the Detail
View blocking edits on read-only items? I'm concerned about
introducing this feature now.
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.
Does that make sense to you?
Mimi
A few questions about allowing subscribers to edit read-only
shares...
+ Could this be viewed as an annotation feature? User makes local
edits that don't get synced to the server?
Well, to be precise, this is not annotating but rather overriding.
You are replacing an "external" value with your own -- one that
doesn't get sent to the server. You could imagine the read-only
subscriber adding notes to an event's body and think of that as
annotation, but really the subscriber is modifying their private
copy of the body. If someone else later changes the body, the read-
only subscriber will see a conflict; they can discard the conflict,
but at least they are made aware whenever someone else changes that
body.
+ Does this feature apply to read-write shares as well?
Well, in read-write shares, local changes that aren't being
filtered out *are* synced to the server, so it's not really the
same. The only conditions in which a local change is not sent to
the server is if the field is being filtered out or if the local
change is in conflict with what's on the server.
+ Can all attributes can be annotated?
The sharing framework puts no restrictions on which fields can be
overridden by a read-only subscriber. Note I am using the term
"fields" instead of "attributes". The EIM-based framework doesn't
know about Chandler "attributes" per se. If you want to restrict
what UI-visible values the user can modify, that needs to be
handled at a level "above" the sharing framework, in the UI itself.
+ Can you make destructive annotations? ie. Change the start-time.
The sharing framework allows the read-only subscriber to override
any field. Again, if we want to put restrictions on which ones the
user is allowed to modify, that needs to now happen in UI code.
~morgen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
