My suggestion : Keep it simple for Preview. Either leave the feature
as it and get user feedback or block the UI code to not make any
changes to read-only items. This scenario not part of our standard CC
worflows so we could wait on it and see how users feel about it.
On Apr 27, 2007, at 1:17 AM, Mimi Yin wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
