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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
