[Design] Adding the filtering checkboxes to the subscribe dialog

[Morgen Sagen]

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.