Hi,
Mimi Yin wrote:
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.
IOW, a different styling for read-only non editable attributes...
+ 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.
Yes but not on the same attribute or, how will Chandler make the
difference between a change you want to share and one you don't want to
share? This really begs for another feature (or features) : a way to
annotate an item (e.g. add a sticky "don't forget to bring a cake!" to a
read only event you subscribed to) and/or a way to link an item to
another (e.g. link a task "bring a cake" to the here above mentioned
read only event) and see this link in the DV.
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?
I'm trying to get a sense of how read-only items do behave right now.
Does anyone has a read-only ticket I could use for testing?
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
