Hi Morgen,
Thx for writing this up!
Can we have all of the filters checked in the Desktop for both
publishers and subscribers, except for BCC and Needs reply? And can
we remove the sharing filters from the Subscribe dialog and instead
have subscribers find them in the Manage share dialog?
In our small workgroup usage scenarios, I think most people will want
to share Triage Status / Alarms and Event Status.
1 - A shares A's personal Work collections with B. B wants to see:
+ Whether A is confirmed to go to an appointment or not,
+ What A is working on NOW versus what has been deferred,
+ Won't be setting personal alarms on A's tasks and events.
2 - A shares a group Project collection with B,C and D.
+ Everyone wants to see if any given event is confirmed or not.
+ Everyone wants to see what the group is working on NOW versus LATER.
There are going to be cases that won't be met by our "per-item triage
status/alarm and event status" model.
Subscribers can't add shared events to their personal calendars and
set personal alarms, event status or personal triage status,
independent of the group without losing the group's TS, alarms and
event status.
Post-Preview, we should revisit this issue and see how badly users
need to have per-person values for TS, alarms, and event status.
https://bugzilla.osafoundation.org/show_bug.cgi?id=8927
Other Post-Preview issues include:
+ More robust distinction between sharing with myself (keeping
multiple machines in sync) and sharing with others (For Preview, we
should encourage users to send .ini files to themselves when sharing
with themselves.) https://bugzilla.osafoundation.org/show_bug.cgi?
id=8928
+ Presenting Subscribers with the list of sharing filters the
Publishers would *like* to share with them. https://
bugzilla.osafoundation.org/show_bug.cgi?id=8929
+ Ability to type collections? Personal collections versus Group
collections. https://bugzilla.osafoundation.org/show_bug.cgi?id=8930
A few questions about allowing subscribers to edit read-only shares...
+ Could this be viewed as an annotation feature? User makes local
edits that don't get synced to the server?
+ Does this feature apply to read-write shares as well?
+ Can all attributes can be annotated?
+ Can you make destructive annotations? ie. Change the start-time.
Mimi :o)
On Apr 23, 2007, at 5:11 PM, Morgen Sagen wrote:
I finally have had a chance to come back and revisit this issue.
The new sharing framework does much more than the old one did in
terms of dealing with differences between local and external
values. There "server wins" approach is no more. Instead, if an
external change is in conflict with a local change, the external
change is flagged as a pending conflict and will show up in the new
conflict resolution dialog. Pending conflicts can be resolved by
either accepting them, discarding them, or they can even auto-
magically go away if someone else happens to change the value to
the same thing you did. You can also ignore a pending conflict for
as long as you want, and resolve it later.
The new filtering mechanism is, in my opinion, a huge improvement
over the old one. With the old one, everyone participating in a
shared collection was required to use the exact same set of
filters. For example, if one person decided to share reminders
then everyone else got those reminders as well, even overwriting
any local reminders you had set. The new EIM-based sharing
framework allows each sharing participant control over what
individual fields they want to "opt out" of sharing. Also, if I
originally opted out of sharing reminders when I subscribed to a
collection and later change my mind, when I check the reminders
checkbox in the Collection Manage dialog, any reminders currently
on the server that differ from mine will be flagged as a pending
conflict -- no data loss caused by the old "server wins" model.
Finally, there are new capabilities for the read-only subscriber.
Since the new framework is able to maintain differences between
local and external changes, we can now actually allow the read-only
subscriber to locally modify any field on an item. The old
framework was too hard to explain: a user could not modify a given
attribute if the item was only a member of read-only shares and the
attribute in question was either not one that the sharing layer
knew about or if the attribute happened to be filtered out at the
moment. The new framework doesn't have such a limitation: if the
user wants to add a few lines to the body of a "read-only" item,
they are allowed to. If someone later makes a change to the same
body, that external change will be flagged as a pending conflict.
Or you might normally want to get reminders on a certain read-only
calendar, but be able to override them on individual items. You
can do that now. Given this functionality, we should probably have
an affordance for allowing the user to decide they want to make any
change to a read-only item -- perhaps using either the little
pencil icon at the top of the detail view, or perhaps the "never
share" lock could be repurposed. Something to let them know they
are choosing to override a value on a read-only item. As
implemented now, the user can go ahead and make the overriding change.
So given this new functionality, let's talk about the need to
transmit filter information, at least for Preview. I propose we
make it the default that all fields are shared (all checkboxes
checked) both for publish and subscribe. If you want to opt-out of
sharing a field, you uncheck the appropriate checkbox. As for read-
only subscribers, let's look at an example field like triage
status: either you are filtering it out or you are sharing it (as
you selected in the subscribe or manage dialogs). If you are
filtering it out, you are free to edit the field, and you won't see
anyone else's triage changes, nor get conflicts. If you *are*
sharing it, you will see other people's triage changes *and* you
are also able to override the field; if someone else later on makes
a change to it you will get a conflict notification. So for read-
only subscribes, we can definitely get away with not knowing what
filters other people have in place. For read-write shares, if you
are filtering out a field, you are free to edit it, your changes
won't be sent, you won't see external changes to it, and will you
get no conflicts. If you are sharing a field, you are free to edit
it, your changes will be sent, you will see external changes to it,
and you can get conflicts. The decision for what filters to have
in place is really up to each individual: if you don't want to
share a field, don't share it.
Oh, and I don't think hardcoding the filters for Preview is a good
idea. Can we really force people to share the BCC field? I doubt
one combination of filters is going to meet people's needs.
On Mar 27, 2007, at 6:10 PM, Mimi Yin wrote:
Hi Sheila,
Basically the UI blocker is the filter inconsistency between the
sharer and the sharee. I don't think we can have people not
knowing what attributes they're sharing with each other.
Can we do something like hardcode what's shared and not give users
options for Preview? I would prefer that over users not knowing
what they're sharing.
Would it be acceptable to always share:
+ Triage status and alarms
+ BCC
+ Needs reply
And never share:
+ Event status
Mimi
On Mar 27, 2007, at 5:51 PM, Sheila Mooney wrote:
Mimi,
Is this a definite blocker for Preview? I understand the workflow
and motivation but we are pretty much down to the wire with
feature freeze on Thursday and this currently isn't on Morgen's
task list. Although I understand it's not ideal, could we get
away with NOT doing this for Preview and relnote or add some
explaining in the documentation?
Just exploring whether or not this is an alternative.
Sheila
On Mar 27, 2007, at 5:04 PM, Mimi Yin wrote:
I think we need to make sure that the sharer's filter
preferences are getting to sharees. Otherwise, as a read-only
sharee, my Chandler won't know whether or not it should allow me
to do things like edit Triage status, etc. Also as a sharee, I
need to first see what the sharer's preferences were before
deciding whether I want to override any of their filters.
Logged as bug: https://bugzilla.osafoundation.org/show_bug.cgi?
id=8514
On Mar 22, 2007, at 2:53 PM, Morgen Sagen wrote:
On Mar 22, 2007, at 2:26 PM, Mimi Yin wrote:
As for "Show Sharer's options first", I wonder if that's
fairly important. Is this something we won't have on the
server for Preview? Or just temporarily as you finish up EIM?
This wasn't something I was planning for Preview, no.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
