[Design] Adding the filtering checkboxes to the subscribe dialog
morgen at osafoundation.org
Thu Apr 26 20:18:10 PDT 2007
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
> + 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.
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
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
More information about the Design