[Design] Editing Read-only items
mimi at osafoundation.org
Fri Apr 27 01:17:21 PDT 2007
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
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?
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
> 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.
More information about the Design