[Design] Adding the filtering checkboxes to the subscribe dialog
mimi at osafoundation.org
Thu Apr 26 16:13:20 PDT 2007
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
+ 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?
>> A few questions about allowing subscribers to edit read-only
>> + 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
>> + 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.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Design" mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Design