[Design] Editing Read-only items

[Mimi Yin]

Hi,

The new sharing framework has a neat new feature which allows users  
to make local edits to read-only items. These local edits never get  
synced back up to the server...and when server edits are pulled down  
by the read-only subscriber, any conflicts with the user's local  
edits are caught and presented to the user via our new conflict  
management UI.

I'm concerned that this might cause some amount of confusion without:
+ Proper visual feedback: What are my local edit versus What's the  
definitive server version

+ Some control over what can be edited: ie. I shouldn't be allowed to  
change the date/time info on shared events, but adding private  
annotations to the Notes field is fine.

+ Finally, as a user, I would expect that if I can have local edits  
on read-only items, I should also be allowed to maintain local edits  
on read-write items as well.

Does anyone else have any opinions on this matter? Should we just try  
it out in Preview and see what happens? Or should we wait to roll  
this feature out after a little more design work has been done?

How much work would it be to add functionality to implement UI code  
to block edits on Read-only items?

Mimi

On Apr 26, 2007, at 8:18 PM, Morgen Sagen wrote:
>> 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.