Fwd: [Kolab-format] Visibility of incidence infos in XFB-lists, was: Client behaviour regarding "Access" or better "information sensitivity"

[Bernhard Reiter]

Am Montag, 20. September 2010 17:17:58 a long-standing Kolab-/Kontact-operator 
wrote:
> Am Mittwoch, 8. September 2010 um 14:38:40 schrieb Bernhard Reiter:
> > Am Dienstag, 7. September 2010 14:29:21 a long-standing
> >
> > Kolab-/Kontact-operator wrote:
> > > IMHO the core issue with this "prominent" setting is (and always has
> > > been) its label: There is not the slightest hint anywhere in the GUI,
> > > that it deals with the scope of visibility of XFB-/FB-information
> > > only.
> >
> > Just to be extra clear: It only has an effect now on the XFB
> > information. There is _no effect_ on the FB info.
>
> Well, first of all, this is a loosely related, but distinctively different
> topic.  Here the functionality of the setting is discussed, in contrast to
> the original topic "keep the prominent placement of that setting or not".
>
> NB: I will quickly dive into this other topic (functionality) for one
> paragraph.
> So if one sets this "Sensitivity" to "confidential" (=invisible), the time
> and date of that IMAP-folder item (incidence type) will still be visible
> via (non-extended, regular) FB-list (containing time & date only, that is),
> but not via XFB-list?

No. 
There is a second setting 
that controls if beginning and end goes into both FB and XFB. 

> If so,  
[..]

> IIRC this also was a requirement of the original Kolab customer, but it
> never worked as intended due to aforementioned usability and technical
> (scope does not include regular FB-list) issues: as a result the
> (X)FB-lists are nowadays just used as an minor source of additional
> information, rather than as a pivotal point for many calendar-based
> actions.

Freebusy lists are used successfully in many settings I know.
(For other readers: They are intended as a hint for searching a common time
between several potential participants. They need not to be representing the 
world 100% and in fact the cannot because of human behaviour. So they are 
just a helpful hint.)
There are a number of modelling choices that can affect usage significantly
and other potential issues, but once those are resolved freebusy lists are 
useful and are getting used.

Extended Free Busy lists never got into wide usage, in my personal analysis
this is because we are lacking a good viewer in the web and KDE client.

> In the following responses I assume, that the export of information to
> regular FB-lists will be also covered by this setting.
[..]

> > Improving the wording was part of my proposal.
> > Did you like the suggested words?
>
> No, IMO they are almost no improvement to what we have already, as they
> still avoid to clearly name what is happening; instead metaphors are used
> again, which will be interpreted to mean something vastly different by
> others: the same story/theme as before.
>
> IMHO the category shall be labelled "Visibility in Free/Busy lists"
> or "Relevance for Free/Busy lists" (I like the first one much better);
> the choices may be called "Full content visible" / "Only date & time
> visible" / "Invisible", alternatively, when using "Relevance" in the
> label: "All content relevant" / "Only date & time relevant" / "Hidden".
>
> An maybe even better alternative may be to use the label "Export to
> Free/Busy lists:" with the choices "Full content" / "Only date &
> time" / "Nothing".
> Actually, I believe that is the best choice I came across yet.

(Your suggestions were driven by the assumption of one combined setting. As 
explained above we do have two settings. Guess I was not explaning this clear 
enough before.)

Nevertheless thanks for the suggestions, I will consider them for my next 
proposal. (Interest in changing this has been dropping since I have come 
forward with my suggestion.)

> > Again to be extra clear: Currently "sensitivity" does affect single
> > objects so moving it to be reachable via the categories would keep this
> > focus as the selection of categories also are per objects.
>
> Oh, I never questioned the fact that this is "per object (= IMAP-folder
> item, incidence type)": it definitely is!
> My point is: it is a very special setting, which is solely specific for the
> (X)FB-list visibility of that incidence item, so it shall not be
> intermingled with other settings.
> As said, it could provide a very valuable instrument for conveniently
> controlling which data becomes published via (X)FB-lists, hence enabling
> the long overdue proper and full use of (X)FB-lists.

My suggestion kept the second setting that controls visibility prominent.

> > When there are more clients that can deal with several accounts and
> > folders fully, the need for the use of those categories and even for XFB
> > at all will vanish and then there will be only the ACL settings that
> > affect the folders.
>
> No not at all, as per account and per folder settings are way too coarse
> for many use-cases and -models: with these one will never be able to
> properly substitute per item settings.
> The discussed setting is so unique, as it controls per item what
> information is exported to the (X)FB-list: any setting which does not carry
> exactly these properties will not work as a substitute.

Again I believe you are refering to the "show time as" free/busy setting 
which my suggestion did not touch. It will stay per object.
In general:
Note that placing an object in different folders is also making a choice
per object, it is just that your choices are limited.

Best,
Bernhard


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20101013/4c0aae2e/attachment.sig>