gmane.network.jabber.psi.devel

Re: Privacy

On 4/22/05, Remko Troncon <remko@...> wrote:
> Here is what i came up so far:
>         http://www.cs.kuleuven.be/~remko/psi/forums/privacy.png

How about changing rules-edition part into something more "readable":

If [group] is [Hidden]
Then [deny] .....

The 'Custom' edit box is - for me - a bit confusing.
I guess your idea is to use combo box to choose subscriptions and
groups, but 'custom' editbox for jids.
How about making it only a combo box which would be choose-only when
selecting a subscription type and type-or-choose when it comes to jids
and groups?

One more thing: I don't know how it is on MacOS, but I'm not used to
see '+' and '-' buttons on Windows.
Honestly, it took me some time to understand what do these +/- buttons
in the bottom-left corner do.

This leads me to the last (yes, don't worry, it's the last one - I hope) point:
Most of people will probably use only one privacy list. And the list
of lists ;) on the left is a bit confusing: it takes much space, but
at the same time you don't know what does it really mean.

How about changing this UI to look more like status-presets options:

List of lists at the top, with 'Add' and 'Remove' (instead of +/-) on
the right, then rules-editor, then - at the very end - default and

(Continue reading)

headers

Remko Troncon | 22 Apr 19:14

Re: Privacy

> If [group] is [Hidden] Then [deny] .....

Yeah, that might work.

> I guess your idea is to use combo box to choose subscriptions and
> groups, but 'custom' editbox for jids.

Actually, for JID, i would also use a combo box (with all the jids from 
your roster). But, optionally, you can override the use of a combobox 
with the hidden thing.

> One more thing: I don't know how it is on MacOS, but I'm not used to
> see '+' and '-' buttons on Windows.

Proof of concept, i just wanted an 'add' button. Of course, the real 
buttons will contain icons.

> List of lists at the top, with 'Add' and 'Remove' (instead of +/-)

A combo box list is also confusing, but you're right, it uses less 
space, and most people will have only 1 list indeed.

> And what about active list? I imagine choosing the active list in the
> same way I choose my status: from a combo button in roster window.

Indeed, but that's easy to implement.

> Also, there could be a combo like this is 'Choose status' dialog. And
> more: if we get advanced status presets (like in Remko's patch), how
> about letting user to assing a privacy list to a status preset?

(Continue reading)

headers

Kevin Smith | 22 Apr 23:18

Re: Privacy


On 22 Apr 2005, at 17:40, Maciek Niedzielski wrote:
> How about changing rules-edition part into something more "readable":
This is exactly what I thought

> If [group] is [Hidden]
> Then [deny] .....
As is this.

> The 'Custom' edit box is - for me - a bit confusing.
> I guess your idea is to use combo box to choose subscriptions and
> groups, but 'custom' editbox for jids.
> How about making it only a combo box which would be choose-only when
> selecting a subscription type and type-or-choose when it comes to jids
> and groups?
I'm sorry, I'm too tired to be able to read anything longer than a 
couple of words, I just want to make sure I reply to this.

> One more thing: I don't know how it is on MacOS, but I'm not used to
> see '+' and '-' buttons on Windows.
> Honestly, it took me some time to understand what do these +/- buttons
> in the bottom-left corner do.
I understood them, fwiw.

> This leads me to the last (yes, don't worry, it's the last one - I 
> hope) point:
> Most of people will probably use only one privacy list. And the list
> of lists ;) on the left is a bit confusing: it takes much space, but
> at the same time you don't know what does it really mean.
The joy of privacy lists is that you can use multiple lists, I'm very

(Continue reading)

headers

Yves Goergen | 22 Apr 21:04

Re: Privacy

Hm, the window looks as if it could set every aspect of how Jabber
privacy lists work. But I'm a bit confused with why we need more than
one list? And a lot of less experienced users will be even more
confused. We're all used to having a single list that contains rules
about what contact or domain is allowed to do what (see me, be seen,
send messages etc). Is there any reason behind that multiple lists?

I'd say we put that active list selection into some kind of "advanced"
area (unfoldable or so) of the dialogue. And how does that "per-session
list" work at all? Can I select a list to use for this session and from
the next login on another list will be used again? Man, is this all
(needlessly) complicated. I liked it the Trillian/ICQ style. One list
for blocked contacts, one list for invisible users, one one for visible
(if this is possible with Jabber at all). The auto-authorise option and
anything related would well fit in here.

--

-- 
Yves Goergen "LonelyPixel" <nospam.list@...>

Unclassified NewsBoard Forum --> newsboard.unclassified.de
Free (GPL), easy to use and install, secure, innovative! (PHP+MySQL)

headers

Hal Rottenberg | 23 Apr 05:19

Re: Privacy

On 4/22/05, Yves Goergen <nospam.list@...> wrote:
> Hm, the window looks as if it could set every aspect of how Jabber
> privacy lists work. But I'm a bit confused with why we need more than
> one list? And a lot of less experienced users will be even more

> the next login on another list will be used again? Man, is this all
> (needlessly) complicated. I liked it the Trillian/ICQ style. One list

I strongly agree with Yves here.  No offense, but I don't want to
inflict this level of detail on our users.

--

-- 
Psi webmaster (http://psi-im.org)
im:hal@...
http://halr9000.com

headers

Kevin Smith | 23 Apr 15:35

Re: Privacy


On 23 Apr 2005, at 04:19, Hal Rottenberg wrote:

> On 4/22/05, Yves Goergen <nospam.list@...> wrote:
>> Hm, the window looks as if it could set every aspect of how Jabber
>> privacy lists work. But I'm a bit confused with why we need more than
>> one list? And a lot of less experienced users will be even more
>
> I strongly agree with Yves here.  No offense, but I don't want to
> inflict this level of detail on our users.
I strongly disagree here. This is a Very Good Thing (tm), that I think 
a lot of normal users would really like, if they understood it.
/K
--
Kevin Smith
Psi Jabber client maintainer (http://psi.affinix.com/)
Taekwon-do club captain, University of Exeter
Postgraduate Research Student, Computer Science, University Of Exeter

headers

Yves Goergen | 24 Apr 16:34

Re: Privacy

On 23.04.2005 15:35 (+0200), Kevin Smith wrote:
> I strongly disagree here. This is a Very Good Thing (tm), that I think 
> a lot of normal users would really like, if they understood it.

Well, I did understand it, but I see no use in it. A privacy list is not
something I work every day with and it's not something that would
require profiling. To me, privacy lists, access control lists, address
books etc are something I edit once to fit my needs and then only
occasionally change if the situation changes.

Why would I want to block incoming messages of my special friends only
at home? If this is a realistic use of multiple privacy lists. I
remember I touched my ICQ block list 4 or 5 times in my whole life.
Anything else goes with invisible mode and, so we have it, per-contact
or per-group presences.

--

-- 
Yves Goergen "LonelyPixel" <nospam.list@...>

Unclassified NewsBoard Forum --> newsboard.unclassified.de
Free (GPL), easy to use and install, secure, innovative! (PHP+MySQL)

headers

Hal Rottenberg | 24 Apr 16:35

Re: Privacy

> Well, I did understand it, but I see no use in it. A privacy list is not
> something I work every day with and it's not something that would
> require profiling. To me, privacy lists, access control lists, address
> books etc are something I edit once to fit my needs and then only
> occasionally change if the situation changes.
> 
> Why would I want to block incoming messages of my special friends only
> at home? If this is a realistic use of multiple privacy lists. I
> remember I touched my ICQ block list 4 or 5 times in my whole life.
> Anything else goes with invisible mode and, so we have it, per-contact
> or per-group presences.

My sentiments exactly.

--

-- 
Psi webmaster (http://psi-im.org)
im:hal@...
http://halr9000.com

headers

Kevin Smith | 24 Apr 17:09

Re: Privacy


On 24 Apr 2005, at 15:34, Yves Goergen wrote:
> On 23.04.2005 15:35 (+0200), Kevin Smith wrote:
>> I strongly disagree here. This is a Very Good Thing (tm), that I think
>> a lot of normal users would really like, if they understood it.
> Well, I did understand it, but I see no use in it.
I wasn't suggesting that you didn't understand it, but rather that 
explaining it to users, would be difficult. That said, if you don't see 
a use in it, I suspect you don't understand why I (and I suspect 
others) will want it.

> A privacy list is not
> something I work every day with and it's not something that would
> require profiling. To me, privacy lists, access control lists, address
> books etc are something I edit once to fit my needs and then only
> occasionally change if the situation changes.
Well, that's fine, and having support for multiple lists in no way 
interferes with your use of it in this manner. I don't understand your 
sentiment, which appears to be that you don't want it, so no-one else 
should either.

> Why would I want to block incoming messages of my special friends only
> at home? If this is a realistic use of multiple privacy lists.
Well, for an example: I could want to have a privacy list set up that 
blocks those people who only have me in their roster to chat about Psi 
when I'm at work, and another that blocks my work contacts when I'm at 
home. There are times when communication with some people is desirable 
and with others is a distraction. Even without the home/work 
distinction, I have friends who have a core group of contacts they'll 
always talk to if they're online, and a wider group that they only want

(Continue reading)

headers

Yves Goergen | 24 Apr 19:10

Re: Privacy

On 24.04.2005 17:09 (+0200), Kevin Smith wrote:
> Well, for an example: I could want to have a privacy list set up that 
> blocks those people who only have me in their roster to chat about Psi 
> when I'm at work, and another that blocks my work contacts when I'm at 
> home. There are times when communication with some people is desirable 
> and with others is a distraction. Even without the home/work 
> distinction, I have friends who have a core group of contacts they'll 
> always talk to if they're online, and a wider group that they only want 
> to talk to when they're not busy. This is a powerful feature and while 
> some people may choose to not use it, some people will find it very 
> useful.

Did I get that right that you can only activate a single list at a time?

> Invisibility mode uses privacy lists, so if you want per-contact of 
> per-group invisibility, this is the way to do it :)

Correct, but it's another user interface. Maybe a bit like what Bart
mentioned about the contacts list with icons. Could also be integrated
to the roster, with commands in the context menu or via hotkeys and
status icons on the right end of the row:

    | [o] LonelyPixel         [I] [B] |
    |     might be gone (auto-away)   |
    +---------------------------------+

With [o] my status icon, [I] the invisible icon, [B] a blocked icon etc.

--

-- 
Yves Goergen "LonelyPixel" <nospam.list@...>

(Continue reading)

headers

Trejkaz | 25 Apr 03:58

Re: Privacy

On Mon, 25 Apr 2005 03:10, Yves Goergen wrote:
> Did I get that right that you can only activate a single list at a time?

That is correct.  XMPP specifies that only one privacy list can be active at a 
given time.  It's unfortunate in some regards, but it keeps things simple.

Incidentally, JEP-0126 is a pretty specific description of how privacy lists 
are supposed to be used to implement invisibility, which pretty much dictates 
that almost no advanced GUI should be provided for this, that it should be 
simplified to hell. 

But what I don't get right now is, because of the single list limitation, 
merging invisibility with "normal" privacy rules, more or less requires 
constructing a new list for every combination of the two. 

TX

--

-- 
             Email: Trejkaz Xaoza <trejkaz@...>
          Web site: http://trypticon.org/
         Jabber ID: trejkaz@...
   GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F  A62C B8C7 BC8B 037E EA73

On Mon, 25 Apr 2005 03:10, Yves Goergen wrote:
> Did I get that right that you can only activate a single list at a time?

That is correct.  XMPP specifies that only one privacy list can be active at a 
given time.  It's unfortunate in some regards, but it keeps things simple.

(Continue reading)

headers

Mircea Bardac | 25 Apr 08:13

Re: Privacy

On Monday 25 April 2005 04:58, Trejkaz wrote:
> But what I don't get right now is, because of the single list limitation,
> merging invisibility with "normal" privacy rules, more or less requires
> constructing a new list for every combination of the two. 

I think this can achieved by:
1. saving the rules with their correct names on the server
2. having a ruleset named "(temp: invisibility)" - current session 
invisibility - might be dropped if the current session invisibility rules are 
storred in Psi only
3. using ruleset "(temp: timestamp)" as the current set , transparently 
merging the active ruleset with "(temp: invisibility)"
4. remove "(temp: *)" on account log-on/log-off (on log-off is not very 
secure, since you don't know how (any) Jabber client is stopped.

Mircea

P.S. hmmm.. maybe the JEP should be extended to support temporary lists. Oh, 
this is in XMPP... :/

--

-- 
Psi Forums Moderator/Bug Tracker Manager
Psi Windows Installer Maintainer/ArchLinux Package Maintainerer
http://mircea.bardac.net

On Monday 25 April 2005 04:58, Trejkaz wrote:
> But what I don't get right now is, because of the single list limitation,
> merging invisibility with "normal" privacy rules, more or less requires
> constructing a new list for every combination of the two.

(Continue reading)

headers

Remko Troncon | 24 Apr 21:50

Re: Privacy

> I strongly agree with Yves here.  No offense, but I don't want to
> inflict this level of detail on our users.

I think that, with the combobox with the different lists, this problem
is solved. Normal users will not touch the combo box, it doesn't confront
you in any way with a list of things. 
A normal user will not even go into that privacy dialog, all he does is
click 'Block this contact' in his roster.

cheers,
Remko

headers

Bart van Bragt | 24 Apr 17:07

Re: Privacy

Remko Troncon wrote:
>     http://www.cs.kuleuven.be/~remko/psi/forums/privacy.png

 From an interaction design point of view: Jikes!

It's a very elegant solution from the developers/JEP POV but do you 
really want to confront the average user with this? I think I even 
wouldn't want to use this.

I think it would be smart to think up something (much) more intuitive 
and expandable.

I had envisioned something like the list that Miranda uses. A list with 
your roster (groups + contacts) with icons after every row. You can 
switch those icons/functions on/off by just clicking on them. Instant 
feedback, you don't have to think up complicated rulesets, you don't 
have to look up individual users. It's also much more expandable because 
you can use it to set alerts etc. If I want hide my precence from 
everyone except my GF then I just click the appropriate icon on this 
list. I also click the 'online alert' icon so Psi makes a sound (or 
whatever) when she comes online.

Hmm, just installed Miranda on my Linux box and it's not the program 
that contained that nice list. It was some multi-protocol client but I 
can't remember which one.. Licq? I'll see if I can find it again and 
then I'll make a nice screenshot :)

Bart

headers

Kevin Smith | 24 Apr 17:19

Re: Privacy


On 24 Apr 2005, at 16:07, Bart van Bragt wrote:
> Remko Troncon wrote:
>>     http://www.cs.kuleuven.be/~remko/psi/forums/privacy.png
>
> From an interaction design point of view: Jikes!
> It's a very elegant solution from the developers/JEP POV but do you 
> really want to confront the average user with this? I think I even 
> wouldn't want to use this.
> I think it would be smart to think up something (much) more intuitive 
> and expandable.
Yes, this dialog as it is isn't ideal. We really need to find a usable 
configuration setup. I suspect that the X 'where' Y 'do' Z style would 
go a long way to fixing it.

/K

--
Kevin Smith
Psi Jabber client maintainer (http://psi.affinix.com/)
Taekwon-do club captain, University of Exeter
Postgraduate Research Student, Computer Science, University Of Exeter

headers

Remko Troncon | 24 Apr 21:58

Re: Privacy

> From an interaction design point of view: Jikes!

It needs work, which is why i posted it here. But i think i can make an
interface with the full power of privacy lists (yes, people want multiple
privacy lists), without confusing or irritating people who don't. Just give
it time.

And i'm still opposed to an 'Advanced' mode, and am pretty convinced we can
make a good, powerful, easy to understand client without resorting to that 
ugly stuff.

cheers,
Remko

headers

Hal Rottenberg | 25 Apr 04:21

advanced mode & options (was: Privacy)

> And i'm still opposed to an 'Advanced' mode, and am pretty convinced we can
> make a good, powerful, easy to understand client without resorting to that
> ugly stuff.

If not an actual advanced mode, what about a supplementary
configuration interface?  95% of options would be exposed to UI, the
rest will only be in this new thing.  e.g. about:config in firefox.

--

-- 
Psi webmaster (http://psi-im.org)
im:hal@...
http://halr9000.com

headers

Remko Troncon | 25 Apr 08:37

Re: advanced mode & options (was: Privacy)

> If not an actual advanced mode, what about a supplementary
> configuration interface?  95% of options would be exposed to UI, the
> rest will only be in this new thing.  e.g. about:config in firefox.

Not for privacy lists, that's for sure. These are not just 'yes' and 'no's,
this stuff needs its own dialog. So either way, we need this 'advanced'
dialog, and i'm pretty confident we can make it the _only_ dialog.

cheers,
Remko

headers

Hal Rottenberg | 25 Apr 19:25

Re: advanced mode & options (was: Privacy)

On 4/25/05, Remko Troncon <remko@...> wrote:
> > If not an actual advanced mode, what about a supplementary
> > configuration interface?  95% of options would be exposed to UI, the
> > rest will only be in this new thing.  e.g. about:config in firefox.
> 
> Not for privacy lists, that's for sure. These are not just 'yes' and 'no's,

Yeah, that's why I changed the subject.  Read my email again with that in mind?

> this stuff needs its own dialog. So either way, we need this 'advanced'
> dialog, and i'm pretty confident we can make it the _only_ dialog.

Well I've calmed down a bit from my initial bashing of your privacy
dialog.  :)  As long as everyone remembers we have these people called
"end users", that's all I need to say.

--

-- 
Psi webmaster (http://psi-im.org)
im:hal@...
http://halr9000.com

headers

Remko Troncon | 25 Apr 22:26

Re: advanced mode & options (was: Privacy)

> Yeah, that's why I changed the subject.  Read my email again with that in mind?

Well, the about:config-alike advanced options idea has been floating around
for quite a while now, hasn't it ? It has with me at least, and in my mind,
it was always the plan to have this.

> dialog.  :)  As long as everyone remembers we have these people called
> "end users", that's all I need to say.

I'm shocked the thought even crossed your mind that i forgot the end users.

cheers,
Remko

headers

Hal Rottenberg | 25 Apr 23:54

Re: advanced mode & options (was: Privacy)

> Well, the about:config-alike advanced options idea has been floating around
> for quite a while now, hasn't it ? It has with me at least, and in my mind,
> it was always the plan to have this.

Yeah, I guess I'm kinda asking if anyone has put serious thought into doing it.

> > dialog.  :)  As long as everyone remembers we have these people called
> > "end users", that's all I need to say.
> 
> I'm shocked the thought even crossed your mind that i forgot the end users.

I'm glad you are shocked, that indicates your heart is in the right
place.  Maybe you on some pain medication when you made that
privacy.ui?  :)

--

-- 
Psi webmaster (http://psi-im.org)
im:hal@...
http://halr9000.com

headers

Kevin Smith | 26 Apr 00:17

Re: Re: advanced mode & options (was: Privacy)


On 25 Apr 2005, at 22:54, Hal Rottenberg wrote:
>> Well, the about:config-alike advanced options idea has been floating 
>> around
>> for quite a while now, hasn't it ? It has with me at least, and in my 
>> mind,
>> it was always the plan to have this.
>
> Yeah, I guess I'm kinda asking if anyone has put serious thought into 
> doing it.
Yes. AFAIU, Mblsha has an alternative options system that we just don't 
use that could easily have (or even possibly has) such a dialog built 
for it.

/K
--
Kevin Smith
Psi Jabber client maintainer (http://psi.affinix.com/)
Taekwon-do club captain, University of Exeter
Postgraduate Research Student, Computer Science, University Of Exeter

headers

Justin Karneges | 26 Apr 00:58

Re: Re: advanced mode & options


On Monday 25 April 2005 03:17 pm, Kevin Smith wrote:
> Yes. AFAIU, Mblsha has an alternative options system that we just don't
> use that could easily have (or even possibly has) such a dialog built
> for it.

In the true Psi tradition. :)

-Justin

headers

Michail Pishchagin | 26 Apr 05:31

Re: Re: advanced mode & options

Justin Karneges wrote:
> On Monday 25 April 2005 03:17 pm, Kevin Smith wrote:
> > Yes. AFAIU, Mblsha has an alternative options system that we just don't
> > use that could easily have (or even possibly has) such a dialog built
> > for it.
>
> In the true Psi tradition. :)

mblsha has it all? 

Well... I have the options system, but it's only useful because you can store 
QVariants into it, and access them using the key string, and it would be 
automatically saved to and loaded from XML file. GUI for that thing is 
unavailable ATM, but could be easily created (at least in theory).

-mblsha

One Page Principle:
	A specification that will not fit on one page of 8.5x11 inch
	paper cannot be understood.
		-- Mark Ardis

headers

Justin Karneges | 26 Apr 12:16

Re: Re: advanced mode & options


On Monday 25 April 2005 08:31 pm, Michail Pishchagin wrote:
> Justin Karneges wrote:
> > On Monday 25 April 2005 03:17 pm, Kevin Smith wrote:
> > > Yes. AFAIU, Mblsha has an alternative options system that we just don't
> > > use that could easily have (or even possibly has) such a dialog built
> > > for it.
> >
> > In the true Psi tradition. :)
>
> mblsha has it all?

The tradition is that we always seem to have a bunch of code that isn't being 
used.

-Justin

headers

Hal Rottenberg | 26 Apr 15:11

Re: Re: advanced mode & options

> The tradition is that we always seem to have a bunch of code that isn't being
> used.

Along those lines, Psi is XMPP compliant since Iris is.  :)

--

-- 
Psi webmaster (http://psi-im.org)
im:hal@...
http://halr9000.com

headers

Michail Pishchagin | 26 Apr 05:40

Re: Privacy

Remko Troncon wrote:
> Since the feature is in high demand, I might be implementing privacy
> lists soon. If you thought about how the UI should look for this, or
> have other ideas wrt this topic, it's time to give your input. Here is
> what i came up so far:
> 	http://www.cs.kuleuven.be/~remko/psi/forums/privacy.png

And here's my variant of "advanced" privacy dialog configuration: 
http://maz.sf.net/tmp/psi/psi-privacy.png

The Privacy Manager list has radiobuttons in it, and the one selected, is the 
"active" privacy list. The default list could be set using "Set Default" 
button.

And in the Privacy List, the value could be edited by different controls (the 
one on the screenshot has the widget to set the value when type=subscription 
is set).

Having said all that, I think this kind of dialog is necessary for advanced 
users to tweak the things up, but there also should be a simplier way, but 
it's been discussed here already :)

-mblsha

headers

Remko Troncon | 26 Apr 09:36

Re: Privacy

> And here's my variant of "advanced" privacy dialog configuration: 
> http://maz.sf.net/tmp/psi/psi-privacy.png

Several things i don't like about this one: 
- It needs 2 dialogs. This is the same as with the account setup stuff, and i
  think this is confusing and clumsy.
- It uses some weird terminology, making it in advanced unusable for a lot
  of users.

I'll try to update my version of the dialog later today, and send another
proposal to the list.

cheers,
Remko

headers

Remko Troncon | 26 Apr 11:09

Re: Privacy

> I'll try to update my version of the dialog later today, and send another
> proposal to the list.

Ok, here's a new proposal:
	http://www.cs.kuleuven.ac.be/~remko/psi/forums/privacy2.png

Don't look at the layout details, this is just a sketch. The 'multiple
lists' aspects is only present in the top row, so i expect most users to
not touch that. The (*) should probably be changed into (Active).

The rules themselves are quite readable, and so a user should be able to
easily understand how to modify the list. Maybe, for a little bit more 
understanding, the rules should read:
	If ....
	Else If ....
	Else ....
Maybe 'New rule' should become 'add rule'.
Ideally, the comboboxes from below could be integrated in the listview,
such that the rules can be modified inline. But i'm not sure how to 
shove the multi-choice 'Messages, queries, status' checkbox in there. 
Anyone have a suggestion on this ?

The list settings are perhaps a bit lost, and maybe get too much attention,
but they have to be there somewhere 

So, keep the comments coming.

cheers,
Remko

(Continue reading)

headers

Remko Troncon | 26 Apr 11:41

Re: Privacy

> Ok, here's a new proposal:
> 	http://www.cs.kuleuven.ac.be/~remko/psi/forums/privacy2.png

I should repeat that this will probably not be the only (nor easiest)
way to set privacy settings. This is just the central point of privacy
settings, which i would first like to get as good as possible.

Later, we can start thinking about having per-contact privacy settings, and
integrating them with the privacy lists. For example, for every contact, a
right-click menu to edit the privacy settings for that contact. Of course, you
have to keep in mind that privacy lists can be 'less simple', and it can be
quite tricky to integrate this with existing rules (since a contact can be
covered by several rules). Even if Psi always uses a specific ordering in its
rules, another client might change things in the list that you don't expect, so
you cannot rely on internal representations. This also indicates that things
can go wrong, and this is a reason to have the central dialog, to be able to
interpret what's going wrong.

cheers,
Remko

headers

Przemysław Maciąg | 26 Apr 13:15

Re: Re: Privacy

Hi!

Dnia 26-04-2005, wto o godzinie 11:09 +0200, Remko Troncon napisał(a):
> > I'll try to update my version of the dialog later today, and send another
> > proposal to the list.
> 
> Ok, here's a new proposal:
> 	http://www.cs.kuleuven.ac.be/~remko/psi/forums/privacy2.png
> 
> Don't look at the layout details, this is just a sketch. The 'multiple
> lists' aspects is only present in the top row, so i expect most users to
> not touch that. The (*) should probably be changed into (Active).
> 
> The rules themselves are quite readable, and so a user should be able to
> easily understand how to modify the list. Maybe, for a little bit more 
> understanding, the rules should read:
> 	If ....
> 	Else If ....
> 	Else ....
Something like this is done in evolution mailer - it uses filters to
lunch commands for specific mails, but the idea is just like with the
privacy settings.

Anyway - evolution is using two dialogs
http://vivid.dat.pl/psi/shot_evo.png
First dialog - top left - is used to add new / edit / delete / and to
place filters in order. On second one you can see settings dialog (this
one is interesting I think).
For choosing contacts/transport/etc that belongs to list, there are easy
for users rules : contains / do not contain / is / isn't and more.

(Continue reading)

headers

Michail Pishchagin | 26 Apr 23:40

Re: Re: Privacy

Remko Troncon wrote:
> > I'll try to update my version of the dialog later today, and send another
> > proposal to the list.
>
> Ok, here's a new proposal:
> 	http://www.cs.kuleuven.ac.be/~remko/psi/forums/privacy2.png

Wow, looks really good.

My 3 cents:
1. "Active" should be checkbox.
2. "Activate by default" in this design could be set to 'true' in several 
lists.
3. "Use as fallback" -- what is it?

IF ...
ELSE IF ...
ELSE ...

seems to be a good thing too. And we might get all the config in one line (as 
Evolution does), but it'll be a really long one, so I'm not sure that we 
should do it.

-mblsha

headers

Remko Troncon | 27 Apr 09:04

Re: Re: Privacy

> 1. "Active" should be checkbox.

I made a button, because it shows that you can really 'activate' the 
list. It also fitted better in the design. Another option would be an 'activate'
button (not a toggle button), which puts '(Active)' besides the list in the
lists combo box.

> 2. "Activate by default" in this design could be set to 'true' in several 
> lists.

Actually, only 1 list can be activated by default. 

> 3. "Use as fallback" -- what is it?

If no list is active, this list is used. Actually, the fallback list is
the most important one, as it is the list that is used for all sessions. The
'active' list is just a list you use 'temporary' (i.e. for a session).

For example, you could have a fallback list, which contains the contacts you
blocked. On the other hand, you could have a 'Mobile' list, containing a
list blocking the presence-in from all your contacts, which you 'Activate
by default' on your mobile jabber client, such that you save bandwidth. This
list will be active for the current session only.

The fact that the active list is not the most important one is not very 
clear. Maybe we should name the 'Activate' differently; something with 
'Override', and 'Activate by default' 'Always override', and the 'Fallback
list' the 'Default list'. Just throwing things on the table.

> seems to be a good thing too. And we might get all the config in one line (as

(Continue reading)

headers

Remko Troncon | 30 Apr 15:32

Re: Privacy

Updated version of the privacy dialog(s):
	http://www.cs.kuleuven.ac.be/~remko/psi/forums/privacy3.png
I split off the rule editing into a separate dialog. This is both 
code-wise a lot easier to implement, and unclutters the UI more. 
Comments are welcome.

cheers,
Remko

headers

Hal Rottenberg | 30 Apr 16:19

Re: Re: Privacy

Cool.  It's getting better.  We'll definitely need some 'what's this'
help.  A lot of people are not going to understand what queries mean,
for example.

--

-- 
Psi webmaster (http://psi-im.org)
im:hal@...
http://halr9000.com

headers

Remko Troncon | 30 Apr 17:32

Re: Re: Privacy

> Cool.  It's getting better.  We'll definitely need some 'what's this'

Too bad what's this doesn't work on Mac OS X, so i prefer not relying on What's
this in any way. I didn't think the term 'queries' through, maybe there are
easier to understand terms, such that it is clear what it means.

cheers,
Remko

headers

Maciek Niedzielski | 30 Apr 23:22

Re: Re: Privacy

Remko Troncon wrote:

> Updated version of the privacy dialog(s):
>     http://www.cs.kuleuven.ac.be/~remko/psi/forums/privacy3.png 

Looks good!

A small question from not-Mac user ;) is:
What's the difference between 'Group' and 'Hidden' boxes? (one has 
up-down arrows and other down arrow)

And one more detail: The text "if JID *is* 'spammers.com'" is probably 
not the best possible, since (AFAIK) a rule like this blocks all 
contacts from spammers.com.

--

-- 
Maciek

headers

Remko Troncon | 30 Apr 23:26

Re: Re: Privacy

> A small question from not-Mac user ;) is:
> What's the difference between 'Group' and 'Hidden' boxes? (one has 
> up-down arrows and other down arrow)

The up-down combobox is uneditable, the one with the down arrow is editable.

> And one more detail: The text "if JID *is* 'spammers.com'" is probably 
> not the best possible, since (AFAIK) a rule like this blocks all 
> contacts from spammers.com.

I simply hate all people from spammers.com. You have to be evil to have
a jabber account there.

cheers,
Remko

headers

Maciek Niedzielski | 1 May 10:06

Re: Re: Re: Privacy

Remko Troncon wrote:

>>And one more detail: The text "if JID *is* 'spammers.com'" is probably 
>>not the best possible, since (AFAIK) a rule like this blocks all 
>>contacts from spammers.com.
>>    
>>
>I simply hate all people from spammers.com. You have to be evil to have
>a jabber account there.
>  
>
What I mean is: once I thought of blocking MSN's email notification 
using privacy lists. The idea was to block messages from 
msn.example.com. However, (if I understand the RFC correctly) a rule 
like this would also block messages from anything@...
This is why I say that it's not a good idea if our GUI would display it 
"JID *is* msn.example.com". "JID is from msn.example.com domain"  would 
probably be better.

--

-- 
Maciek

headers

Remko Troncon | 1 May 10:23

Re: Re: Re: Privacy

> "JID *is* msn.example.com". "JID is from msn.example.com domain"  would 
> probably be better.

Technically, msn.example.com is a JID, but you're right, it's easy to
change the displaying of the rule based on whether it's a full JID
or not.

cheers,
Remko

headers

Maciek Niedzielski | 1 May 10:59

Re: Re: Re: Re: Privacy

Remko Troncon wrote:

>>"JID *is* msn.example.com". "JID is from msn.example.com domain"  would 
>>probably be better.
>>    
>>
>Technically, msn.example.com is a JID, but you're right, it's easy to
>change the displaying of the rule based on whether it's a full JID
>or not.
>
Yes, this is a JID, but when it's full JID, then the meaning is 
different that when it's full JID. So it's better if users know the 
difference without reading RFC, or they may - for example - disable a 
transport without knowing it.

--

-- 
Maciek

headers

Maciek Niedzielski | 27 Apr 01:30

Re: Re: Privacy

On 4/26/05, Remko Troncon <remko@...> wrote:
> The list settings are perhaps a bit lost, and maybe get too much attention,
> but they have to be there somewhere 
> The list settings are perhaps a bit lost, and maybe get too much attention,
> but they have to be there somewhere 

A drawback of this solution is that:
- when I check the option, it is "secretly" unchecked for another list
- when I uncheck the option, which list becomes default/fallback one?

--

-- 
Maciek
 xmpp:machekku@...

headers

Remko Troncon | 27 Apr 08:53

Re: Re: Privacy

> A drawback of this solution is that:
> - when I check the option, it is "secretly" unchecked for another list

Indeed. Same goes with the 'Active', and 'Active by default'. For the active 
list, i tried to compensate this with a '*' besides the name, but i can't
do it with those options too. I don't really see another solution for
this, though; the dialog is pretty list-central, so there's no 'global'
section anymore 
	
> - when I uncheck the option, which list becomes default/fallback one?

None. That is no problem, this is possible.

cheers,
Remko

headers

Jeroen Vaes | 26 Apr 16:05

Re: Privacy

On Friday 22 April 2005 18:08, Remko Troncon wrote:
> http://www.cs.kuleuven.be/~remko/psi/forums/privacy.png

I think the "problem" with all of these dialogs is that the base configuration 
stays too difficult for the average user. Only advanced users will understand 
how to create a list of privacy options to fit their need, and for them it's 
quite powerful, but a regular user doesn't want to think hard when he just 
wants to block someone. Chances are he won't even understand the concept of a 
"list".

Therefore, I think Psi should have an easy GUI that masks the lists from the 
user. The "hard work" of thinking out a privacy list should be done by the 
software, not by the user.

Anyway, this is my attempt. It is based on what I remember from Miranda's 
privacy settings (which was mentioned earlier in this thread I beleive):
<http://users.telenet.be/jvaes/psi/psi-privacy.png>

To block a certain event, the user just clicks in te collumn next to the 
contact of his choice, and a little icon appears. When an icon is present, it 
means the event is blocked. when it it not, the event is allowed.

Clicking on an event on a group automatically makes the icons appear for all 
contacts in that group, which makes it easy to define exceptions to that rule 
(e.g. I want to block messages from everyone in General except Contact 2 
woiuld require 2 clicks: one in the M-column next to General to turn all 
icons on and one in the M-column next to Contact 2 to turn that one off).

You can still define "lists" or "presets" with this dialog. The default list 
should be in bold (this is not in the screenshot as I didn't know how to make

(Continue reading)

headers

Remko Troncon | 26 Apr 16:20

Re: Privacy

> To block a certain event, the user just clicks in te collumn next to the 
> contact of his choice, and a little icon appears. When an icon is present, it 
> means the event is blocked. when it it not, the event is allowed.

The problem is that you cannot map any privacy list onto this format.
This wouldn't be a problem if Psi was the only client in the world, but
other clients can make slightly different lists. And then you get into
trouble.

> I think a dialog like this is much more user-friendly as Psi does the
> hard work for you, yet still is powerful enough.

The dialog in itself, i don't think is a lot easier to use than what
i proposed. The legend thing, and the 1 column for every type looks
good though; i might integrate something like that to inline the rules in my 
proposition.

But the incompatibility with other privacy lists is a problem with this
kind of dialog, which is why IMO it should not be the central privacy list
dialog.

cheers,
Remko

headers

Jeroen Vaes | 26 Apr 16:55

Re: Re: Privacy

On Tuesday 26 April 2005 16:20, Remko Troncon wrote:
> > To block a certain event, the user just clicks in te collumn next to the
> > contact of his choice, and a little icon appears. When an icon is
> > present, it means the event is blocked. when it it not, the event is
> > allowed.
>
> The problem is that you cannot map any privacy list onto this format.
> This wouldn't be a problem if Psi was the only client in the world, but
> other clients can make slightly different lists. And then you get into
> trouble.

I can't really come up with an example that can't be mapped to this format. 
Maybe it's not easy to implement, but not that it can't be done. The server 
has to parse different privacy lists too, this is quite the same thing.

> > I think a dialog like this is much more user-friendly as Psi does the
> > hard work for you, yet still is powerful enough.
>
> The dialog in itself, i don't think is a lot easier to use than what
> i proposed. The legend thing, and the 1 column for every type looks
> good though; i might integrate something like that to inline the rules in
> my proposition.

My dialog is far from perfect, but I still think it's the most easy way for a 
user to configure his privacy settings. The other dialogs are far more 
abstract than mine, a bit too abstract for regular users I'm afraid. This is 
basic functionality, it should be made as easy as possible.

--

-- 
Jeroen Vaes

(Continue reading)

headers

Remko Troncon | 26 Apr 17:40

Re: Re: Privacy

> I can't really come up with an example that can't be mapped to this format. 
> Maybe it's not easy to implement, but not that it can't be done. The server 
> has to parse different privacy lists too, this is quite the same thing.

For starters, it misses features such as filtering based on
subscription, filtering based on resource, ... 

Something tells me that a set of if-then-else rules is more powerful
than a representation of a list with groups and jids, and that i can
make up rules which are not representable.

I also am not sure i understand correctly what the semantics of the list
is. If there is an icon, does it mean 'Allow', and if there is no icon,
does it mean 'deny' ? Or is there a third state (i sure hope so). 
What does a group with an icon mean, and a subitem
of that group with also an icon ? And a subitem with no icon ?

> My dialog is far from perfect, but I still think it's the most easy way for a 
> user to configure his privacy settings.

Sure, it has some good ideas. But i would like to stress again that we
first need a dialog with *full* power (as in anything that can occur),
and that we can then move on to easier to use methods.

cheers,
Remko

headers

Jeroen Vaes | 26 Apr 18:26

Re: Re: Re: Privacy

On Tuesday 26 April 2005 17:40, Remko Troncon wrote:
> > I can't really come up with an example that can't be mapped to this
> > format. Maybe it's not easy to implement, but not that it can't be done.
> > The server has to parse different privacy lists too, this is quite the
> > same thing.
>
> For starters, it misses features such as filtering based on
> subscription, filtering based on resource, ...

Those are all possible to implement. Like I said, it's just a start.

> Something tells me that a set of if-then-else rules is more powerful
> than a representation of a list with groups and jids, and that i can
> make up rules which are not representable.

It might be more powerful, but it won't be usable.

> I also am not sure i understand correctly what the semantics of the list
> is. If there is an icon, does it mean 'Allow', and if there is no icon,
> does it mean 'deny' ? Or is there a third state (i sure hope so).

As I said in the first mail: "When an icon is present, it 
means the event is blocked. when it it not, the event is allowed.". There is 
no third state (I assume you mean by third state that there is no rule?).

Psi should be able to figure out if it should write a rule or not. That's the 
whole point. And yes, generating a list like this probably would be 
sub-optimal, but it's a small price to pay.

> What does a group with an icon mean, and a subitem

(Continue reading)

headers

Kevin Smith | 26 Apr 18:33

Re: Re: Re: Privacy


On 26 Apr 2005, at 17:26, Jeroen Vaes wrote:
> I'm sure it can have full power. But I think we should stop thinking 
> about
> "how can I implement privacy lists" and start thinking about "how can I
> present privacy settings to the user and map them to Jabber's privacy 
> lists".
> What good it is to have a full privacy lists implementation if 90% of 
> our
> users can't use it?
We need to stop looking at guessing what our users will want to do any 
only providing that subset of privacy lists, we instead need to 
implement privacy lists and look at making the interface as usable as 
possible.

/K
--
Kevin Smith
Psi Jabber client maintainer (http://psi.affinix.com/)
Taekwon-do club captain, University of Exeter
Postgraduate Research Student, Computer Science, University Of Exeter

headers

Bart van Bragt | 26 Apr 16:55

Re: Re: Privacy

Remko Troncon wrote:
> The problem is that you cannot map any privacy list onto this format.
> This wouldn't be a problem if Psi was the only client in the world, but
> other clients can make slightly different lists. And then you get into
> trouble.
Why is that? When you load a list you can figure out what people are 
going to be blocked/allowed so you can show a privacy list from another 
client in this format. The only 'problem' that I see is that Psi might 
come up with a 'suboptimal' privacy list that is somewhat uglier than 
list of rules that a human would think up for a given set of privacy 
settings. But IMO that's a price worth paying if we can simplify things 
this much.

BTW we also end up with suboptimal lists if we allow users to 
block/allow others straight from the roster.

The whole privacy JEP is nice from a technical POV but from a usability 
POV it just sucks :) So now we have to translate the JEP into something 
that an actual human can use... Letting the user devise a list of rules 
is not something you want to do if you are not just aiming at Jabber 
developers. I even wouldn't want to do it. It's too counter intuitive, 
too much work (looking up individual users), it just requires too much 
effort.

I really like Jeroens proposal a lot. It's quick, it's intuitive, it's 
really easy to see what the effects of your settings are. The only 
problem there is the 'block/allow IQ' thingy. Heck, even I wouldn't know 
why I would want to block that for some users and not for others...

This discussion is pretty classical :) On one side we have the

(Continue reading)

headers

Remko Troncon | 26 Apr 17:55

Re: Re: Privacy

> The only 'problem' that I see is that Psi might come up with a 'suboptimal' 
> privacy list that is somewhat uglier 

And incorrect. Suppose a privacy list blocks everything from spamdomain.com.
The only thing the dialog can display is whether the contacts from your roster
in that domain are blocked or not. So far, no problem with me. But if you 
change something to one of those contacts, your list will just contain
an enumeration of all contacts on your list from spamdomain.com, and set
them to 'blocked'. This means that, users not on  your roster from that domain
will still be able to send messages to you.

And no, i'm not talking from the developers point of view. I'm talking from the
correctness point of view. I will say for the 4th time in this thread: first
concentrate on a decent dialog which actually shows the rules on the server
as they are there, then start thinking about easier methods. If you start
hiding things from users without allowing them to see what's really there,
you are bound to get in trouble. Compare it with Mac OS with Unix under the
hood. Sure, they hide things, but you can still look under the hood what's 
wrong.

cheers,
Remko

headers

Jeroen Vaes | 26 Apr 18:53

Re: Re: Re: Privacy

On Tuesday 26 April 2005 17:55, Remko Troncon wrote:
> > The only 'problem' that I see is that Psi might come up with a
> > 'suboptimal' privacy list that is somewhat uglier
>
> And incorrect. Suppose a privacy list blocks everything from
> spamdomain.com. The only thing the dialog can display is whether the
> contacts from your roster in that domain are blocked or not. So far, no
> problem with me. But if you change something to one of those contacts, your
> list will just contain an enumeration of all contacts on your list from
> spamdomain.com, and set them to 'blocked'. This means that, users not on 
> your roster from that domain will still be able to send messages to you.

I made a little update to correct this. It's a bit more cluttered, but that 
can be worked on (maybe the frames aren't such a good idea, tabs would 
probably work better):
<http://users.telenet.be/jvaes/psi/psi-privacy2.png>

Rules that don't apply to the roster can be set in the second list. The first 
three rules are designed for subscription-rules (yes, the descriptions suck 
but I couldn't come up with something better). You can also add custom items 
like spamdomain.com.

--

-- 
Jeroen Vaes
Mail: jeroen.vaes@...
Jabber: jeroenv@...

headers

Hal Rottenberg | 26 Apr 20:26

Re: Re: Re: Privacy

I don't have time at the moment to compare and contrast all of the
proposals to my example, but here 'tis, maybe you can gain some
additional insight.

http://halr9000.com/images/screenshots/olrules.png

P.S. While it is true that Outlook rules, in fact this is a picture of
Outlook's mail filtering rules, and that is how I came by this
filename.  ;)

P.P.S. this is a good thread.  :)

--

-- 
Psi webmaster (http://psi-im.org)
im:hal@...
http://halr9000.com

headers

Remko Troncon | 26 Apr 18:00

Re: Re: Privacy

> I really like Jeroens proposal a lot. It's quick, it's intuitive, it's 
> really easy to see what the effects of your settings are.

It's ambigous.

If you really want a user friendly interface: all an end user needs to be
able to do is block a contact. All the other stuff, a simple user does not
need to know about. So, all we need is an extra checkbox in the roster item
contact menu saying whether the contact is explicitly (by JID) blocked or
not. This should be all that is needed. And this is what i was planning to
do, after we have the full power dialog (which might be in some more hidden
place like the XML console, i don't care)

cheers,
Remko

headers

MRAY | 30 Apr 23:31

Re: Privacy

Jeroen Vaes wrote:

>Anyway, this is my attempt. It is based on what I remember from Miranda's 
>privacy settings (which was mentioned earlier in this thread I beleive):
><http://users.telenet.be/jvaes/psi/psi-privacy.png>
>
I'm absolutely for Jeroens proposal.
Just like Bart I do believe that a too complicated solution (all but
Jeroens) seem to be more like a "developers playground" for a nice JEP.
Once an end user tumbles across a "code-your-lists-by-hand" it will
probably mystify privacy when he expects it to be easy to handle.

Finally I prefer the big list because it _visualises_ the whole complex
thing! - an advantage that no other solution has.

(I'm also 100% of barts opinion that this seems to be a typical coder
vs. enduser discussion. I'm not a coder.)

headers

Jeroen Vaes | 1 May 12:16

Re: Privacy

On Saturday 30 April 2005 23:31, MRAY wrote:
> (I'm also 100% of barts opinion that this seems to be a typical coder
> vs. enduser discussion. I'm not a coder.)

I'm actually a coder myself (I lack good C++/Qt knowledge however, so I won't 
be hacking Psi just yet). For me, personally, the other dialogs would be good 
enough. But I don't think it would be a good idea to enforce this on all 
users. I've even seen IT-students struggle with creating good rules for a 
firewall, which is kind of the same principle, so I doubt a normal user (mom 
& dad) can master it.

--

-- 
Jeroen Vaes
Mail: jeroen.vaes@...
Jabber: jeroenv@...

headers

Remko Troncon | 1 May 12:52

Re: Privacy

> firewall, which is kind of the same principle, so I doubt a normal user (mom 
> & dad) can master it.

Then explain to me why all major e-mail clients have rulesets *exactly* like 
this ?

cheers,
Remko

headers

Jeroen Vaes | 1 May 13:13

Re: Re: Privacy

On 1 May, 2005, at 12:52, Remko Troncon wrote:

>> firewall, which is kind of the same principle, so I doubt a normal 
>> user (mom
>> & dad) can master it.
>
> Then explain to me why all major e-mail clients have rulesets 
> *exactly* like
> this ?

How many "normal" users actually *use* that functionality? E-mail 
filtering is only used by advanced users, as it is a feature you only 
have to use if you get lots of mail. But this is privacy we're talking 
about, that's a feature everyone should be able to use.

--

-- 
Jeroen Vaes
Mail: jeroen.vaes@...
Jabber: jeroenv@...

headers

Remko Troncon | 1 May 13:18

Re: Re: Privacy

> about, that's a feature everyone should be able to use.

Right-click 'Block contact'. Seems easy enough to me.

cheers,
Remko

headers

Remko Troncon | 1 May 18:00

Re: Re: Privacy

> Right-click 'Block contact'. Seems easy enough to me.

And as an extra of my dialog proposal, a shortcut 'Block contact' dialog in 
the account preferences:
	http://www.cs.kuleuven.ac.be/~remko/psi/forums/privacy4.png

What this does is: it runs over the currently used privacy list (be it 
the local or global list), and picks out
all the JID rules that block everything, and shows them in that dialog (in the
right order). Adding a rule adds a block-all JID rule to the top of the
privacy list. Deleting the rule deletes a rule from the privacy list.

Of course, this dialog does not guarantee that a contact will or will
not be blocked if you used the advanced privacy lists dialog. But since most
people will just use that interface, and the 'Block contact' context menu,
this will coincide.

cheers,
Remko

PS: I know Kev, you don't like 'Advanced' dialogs, but i think it makes
sense here. Feel free to give it another name.

headers

Jeroen Vaes | 1 May 18:27

Re: Re: Re: Privacy

On Sunday 01 May 2005 18:00, Remko Troncon wrote:
> > Right-click 'Block contact'. Seems easy enough to me.
>
> And as an extra of my dialog proposal, a shortcut 'Block contact' dialog in
> the account preferences:
>  http://www.cs.kuleuven.ac.be/~remko/psi/forums/privacy4.png
>
> What this does is: it runs over the currently used privacy list (be it
> the local or global list), and picks out
> all the JID rules that block everything, and shows them in that dialog (in
> the right order). Adding a rule adds a block-all JID rule to the top of the
> privacy list. Deleting the rule deletes a rule from the privacy list.
>
> Of course, this dialog does not guarantee that a contact will or will
> not be blocked if you used the advanced privacy lists dialog. But since
> most people will just use that interface, and the 'Block contact' context
> menu, this will coincide.

Err, if you're going to use that there, why not use my "my roster"-list there 
which allows greater flexibility? Then we're both happy(er)...

The "block this contact" shortcut would then just enable all icons. If said 
contact is blocked, the shortcut would be changed into an "unblock this 
contact" which does the opposite.

--

-- 
Jeroen Vaes
Mail: jeroen.vaes@...
Jabber: jeroenv@...

(Continue reading)

headers

Remko Troncon | 1 May 18:32

Re: Privacy

> Err, if you're going to use that there, why not use my "my roster"- 
> list there
> which allows greater flexibility? Then we're both happy(er)...

Because you either:
- Don't need anything but blocking contacts (simple user)
- Need *full* power, with crystal clear semantics, as close to the  
ground as possible such that you are absolutely certain of what is  
happening (advanced user).

Your list is the compromise between the two, which is too complicated  
for normal users, and too simple and incomplete for advanced users  
who need the power. Very annoying for both parties.

cheers,
Remko

headers

Jeroen Vaes | 1 May 19:11

Re: Re: Privacy

On Sunday 01 May 2005 18:32, Remko Troncon wrote:
> > Err, if you're going to use that there, why not use my "my roster"-
> > list there
> > which allows greater flexibility? Then we're both happy(er)...
>
> Because you either:
> - Don't need anything but blocking contacts (simple user)
> - Need *full* power, with crystal clear semantics, as close to the
> ground as possible such that you are absolutely certain of what is
> happening (advanced user).
>
> Your list is the compromise between the two, which is too complicated
> for normal users, and too simple and incomplete for advanced users
> who need the power. Very annoying for both parties.

There is nothing "advanced" in being able to distinguish what you block, 
that's core functionality, I've said it before: why deny normal users that 
functionality when you can have it another way? I think many users want to be 
able to e.g. see when someone is online whithout them knowing. Jabber has an 
advantage over the competition here, use it!

I'm going to stop the discussion here, or I'll keep on repeating myself. Using 
it like that is the best compromise I can think of. Take it or leave it. No 
hard feelings if you do the latter, but I think it would be a shame...

--

-- 
Jeroen Vaes
Mail: jeroen.vaes@...
Jabber: jeroenv@...

(Continue reading)

headers

Remko Troncon | 1 May 19:20

Re: Privacy

On 01 May 2005, at 19:11, Jeroen Vaes wrote:

> I'm going to stop the discussion here, or I'll keep on repeating  
> myself. Using
> it like that is the best compromise I can think of. Take it or  
> leave it. No
> hard feelings if you do the latter, but I think it would be a shame...

Dito. We will probably take your icons representation for indicating  
what is blocked and what is allowed (since it's the one or the other,  
this looks like a less ambiguous way to represent the rule). But the  
general dialog unfortunately is not sufficient, as it is incomplete,  
and doesn't have a clear procedural semantics, as i explained before.

As for the 'Blocking users' extra. As a power user, even I would use  
it. I would create a privacy list with a rule denying presence-in  
from my Hidden group, and would then never use the advanced privacy  
dialog anymore. I would do per-contact blocking in the shortcut  
dialog (if it ever gets accepted). I personally don't see much use of  
the finer grained rules, except for some very exceptional cases which  
are based on group or domain anyway.

cheers,
Remko

headers

Francisco Joaquín Rodríguez Prados | 5 May 01:38

Re: Re: Privacy

Sorry if my comment is somehow out to date, but I am in Spain right
now and this thread needed some time, and I wanted to read it all
carefully.

I knew nothing about Jabber privacy lists when I started reading this
thread. In fact, I knew nothing about privacy lists. In fact, the
first time I read the comments I was not able to understand what were
'privacy lists' about. Call me fool, but I find the "reverse lists" of
AMSN complicated... Usually I don't care about privacy lists, but
occasionally I would like to hide my presence from a group of people
in my roster, or I would like to appear 'offline' to a concrete user.

However, I understood what was 'privacy lists' when I saw this screenshot:

http://users.telenet.be/jvaes/psi/psi-privacy.png

Although I have some comments on the dialog, I think it shows in a
really graphical way what it does: it adds users or groups to a list,
so they see your presence, they have message capabilities, and so on.

Then I realized what Remko's dialog
(http://www.cs.kuleuven.ac.be/~remko/psi/forums/privacy2.png) meant.
But I think it is hard to figure out what this last dialog wants from
you, when you don't know what is the dialog about.

Why? Both dialogs are equivalent. It has been said here that this or
that are more powerfull or not. Actually, they make the same thing,
but Jeroen's does it in an extensive way, and Remko's one does it in a
formal way. (It happens the same with the ID3 trees and the rules you
may obtain from it. In fac, we could represent the roster as a one

(Continue reading)

headers

Francisco Joaquín Rodríguez Prados | 5 May 01:49

Re: Re: Privacy

> However, I understood what was 'privacy lists' when I saw this screenshot:
> 
> http://users.telenet.be/jvaes/psi/psi-privacy.png
> 
> Although I have some comments on the dialog, I think it shows in a
> really graphical way what it does: it adds users or groups to a list,
> so they see your presence, they have message capabilities, and so on.

Well, now the comments.

a) The icons are really nice, but an icon/no icon is not a really
clear semantic... What about a red cross (X) when blocked, and nothing
/ a green tick (\/) when allowed? The incons could go in the title
row, where now the leters S, R, M and Q go... I like the legend part;
it is a good excuse to explain what each behaviour means.

b) I would use a combo box for the diferent lists, as Remko does, with
'add' and 'delete' buttons - I think good reasons were given before
for this.

c) There are two options that don't appear: 'use as default' and 'use
as fallback'.  Thought I don't really know what is the last one for,
it seems to be important... :D

I bet on this dialog, because it is simpler. I cannot find why it is
suboptimal or less powerful as the rules one, if they are
mathematically equivalent...

Cheers,

(Continue reading)

headers

Jeroen Vaes | 5 May 10:48

Re: Re: Privacy

On Thursday 05 May 2005 01:49, Francisco Joaquín Rodríguez Prados wrote:
[...]
> a) The icons are really nice, but an icon/no icon is not a really
> clear semantic... What about a red cross (X) when blocked, and nothing
> / a green tick (\/) when allowed? The incons could go in the title
> row, where now the leters S, R, M and Q go... I like the legend part;
> it is a good excuse to explain what each behaviour means.
>
> b) I would use a combo box for the diferent lists, as Remko does, with
> 'add' and 'delete' buttons - I think good reasons were given before
> for this.

Good idea.

> c) There are two options that don't appear: 'use as default' and 'use
> as fallback'.  Thought I don't really know what is the last one for,
> it seems to be important... :D

Those were added in the later version of the dialog.

> I bet on this dialog, because it is simpler. I cannot find why it is
> suboptimal or less powerful as the rules one, if they are
> mathematically equivalent...

Yeah, well...Remko is probably right about not being able to represent all 
possible rules (I do think it's possible, but it would probably become an 
ugly hack which is certainly not quite usable). But I'm/we're probably right 
about the usability part. I think both solutions can coexist. But we'll see 
how Remko's implementation plays out. We can always change it should it be 
necessary.

(Continue reading)

headers

Remko Troncon | 5 May 10:09

Re: Privacy


> and as powerful as the formal way (this last
> thing is not my opinion, maths make it that way :D).

No it is not. Look at the example i posted  This is the risk of  
straying from the 'formal' definition too much: very subtle semantic  
differences which you don't see at first, but which come and hunt you  
in the end.

Anyway, the discussion has more or less been closed on the topic. We  
will implement it the formal way, with the graphical icons, and  
possibly with some extra shortcuts for people who do not have to/want  
to know about the powerful structure of privacy lists, such as one  
big 'block list'.

cheers,
Remko

headers

Jeroen Vaes | 1 May 12:08

Re: Privacy

I gave it some more thought, and finally came up with 2 solutions.

The first one is like the original one, only a little more advanced. It 
consists of 2 lists, one with the roster contacts and one for the rest where 
you can define more advanced rules:
<http://users.telenet.be/jvaes/psi/psi-privacy3-1.png>
<http://users.telenet.be/jvaes/psi/psi-privacy3-2.png>
You can add items to the last list, for example to make more general rules. 
The first three rules are fixed and can't be deleted.

On the other hand we have this:
<http://users.telenet.be/jvaes/psi/psi-privacy4.png>
It's kind of a hybrid between Remko's proposal and mine. It also depends on 
the concept of "rules" but is more inituitive IMO. "Add rule" brings up the 
screen on the right which you can use to add a "rule" to the list. On the 
list you define what should be blocked/allowed (icon on = blocked, icon off = 
allowed). It's easier to change existing rules this way, and it's clearer to 
present them.

On both screens I replaced the term "list" with "preset" as I think that's a 
more appropriate word to describe it, certainly in the first screen as there 
is no real "list" to define. I also removed the "make default"-button and 
replaced it with checkboxes to make the preset default for all sessions or 
only this one.

Personally I still prefer the first one. It's less work to change rules, it's 
clearer, it doesn't need an extra window to add a rule, etc. I also think 
dialogs like the second one become quite cluttered and difficult to 
understand if a user has collected a high number of rules (20+), which they 
are bound to do over the years. But maybe we can reach a compromise this way.

(Continue reading)

headers

Remko Troncon | 1 May 13:17

Re: Privacy

> On the other hand we have this:
> <http://users.telenet.be/jvaes/psi/psi-privacy4.png>

Apart from your dialog taking up a lot more space than the one i proposed,
you're not making explicit that the rules are handled from top to bottom
(which i tried to do with the if then else), and you're not providing default
cases, this indeed is not bad. Actually, the only extra value i see in this
dialog is the icons representing more compactly what is allowed an what not.
The icons look good, but they have the disadvantage that they need a legend.
You did make me realize that an allow rule is actually the inverse of a
deny rule, so checkboxes (or icons) are in principle enough to have a complete
implementation.

> Personally I still prefer the first one. It's less work to change rules, it's 
> clearer

It isn't to me. I have to guess in what order the rules are processed from both
tabs. For JIDs, i can assume that the more general the JID, the earlier it
comes in the privacy list, but for JIDs vs Subscription vs Group, this is not
specified. And when dealing with security, you don't want fuzzy semantics.
Also, if a user used another client to set a list where a more general JID
comes before a more specific JID (which doesn't make much sense, but it is
possible he did), how will you handle this ? 

Which brings me to the question: do we let Psi transform privacy lists 
automatically ? There is the rewriting of an 'allow' rule into a 'deny' rule,
which is still acceptable. But do we also remove rules if they are redundant,
or do we let the user add rules in any place he wants, even if they don't
make sense (at the moment) ? I think it would be annoying if we started
bothering users with these kind of messages.

(Continue reading)

headers

Remko Troncon | 1 May 13:28

Re: Privacy

> The icons look good, but they have the disadvantage that they need a legend.

How about this as a compromise: the rules list has (unclickable) icons as in
your proposal. The icons should be a bit better with arrows indicating incoming
and outgoing etc., and the icons should be 'deny' icons (with a read cross over
them), since this is the way these rules will be used.

The 'edit rule' dialog is more like the one i proposed, being purely textual,
and containing the complete rule. The combobox 'Allow/Deny' would go, and
the icons could appear in there too.

cheers,
Remko

headers

Jeroen Vaes | 1 May 14:00

Re: Re: Privacy

On 1 May, 2005, at 13:28, Remko Troncon wrote:

>> The icons look good, but they have the disadvantage that they need a 
>> legend.
>
> How about this as a compromise: the rules list has (unclickable) icons 
> as in
> your proposal. The icons should be a bit better with arrows indicating 
> incoming
> and outgoing etc., and the icons should be 'deny' icons (with a read 
> cross over
> them), since this is the way these rules will be used.

I like the part about the icons, because they currently suck indeed. 
Providing good icons is vital for this implementation to work. I don't 
like them not being clickable however (read on).

> The 'edit rule' dialog is more like the one i proposed, being purely 
> textual,
> and containing the complete rule. The combobox 'Allow/Deny' would go, 
> and
> the icons could appear in there too.

One of the things I like about my way is that it's realy easy to edit 
an existing rule. If you have a rule for a contact in there to block 
outgoing presence, and you want to block incoming to, it only requires 
one click to activate the icon.

A more advanced "edit" dialog might be a good idea though.

(Continue reading)

headers

Jeroen Vaes | 1 May 13:52

Re: Re: Privacy

On 1 May, 2005, at 13:17, Remko Troncon wrote:

>> On the other hand we have this:
>> <http://users.telenet.be/jvaes/psi/psi-privacy4.png>
>
> Apart from your dialog taking up a lot more space than the one i 
> proposed,
> you're not making explicit that the rules are handled from top to 
> bottom
> (which i tried to do with the if then else), and you're not providing 
> default
> cases, this indeed is not bad.

A "defaukt" case isn't necessary to show IMO. It only adds an extra 
item to the list, a "special" one a user can't edit. It will confuse 
even more.

Same with the if/else if lines. It may be ok if there are only 3 items 
in the list, but imagine a list with 20 or 30 items. It won't make it 
any more readable at all.

>> Personally I still prefer the first one. It's less work to change 
>> rules, it's
>> clearer
>
> It isn't to me. I have to guess in what order the rules are processed 
> from both
> tabs. For JIDs, i can assume that the more general the JID, the 
> earlier it
> comes in the privacy list, but for JIDs vs Subscription vs Group, this

(Continue reading)

headers

Remko Troncon | 1 May 13:57

Re: Re: Privacy

> A "defaukt" case isn't necessary to show IMO. It only adds an extra 
> item to the list, a "special" one a user can't edit. It will confuse 
> even more.

Yes it is. You either allow everything that doesn't matches, or you
deny it.

> Like you said, it doesn't make sense, so it shouldn't be shown.

Shouldn't it ?

> You can *have* a complete implementation this way. One doesn't exclude 
> the other.

No you can't.

> Now you're guessing what users want :-p

No i don't. I add an extra simple shortcut to adding a rule to the privacy
list.

> I think there is no merit in implementing something in a way not 
> everyone can use it.

Exactly. Which is why your first version is not suitable. You'll
realize this when you realize that it is not complete.

cheers,
Remko

(Continue reading)

headers

Jeroen Vaes | 1 May 16:35

Re: Re: Re: Privacy

On Sunday 01 May 2005 13:57, Remko Troncon wrote:
> > A "defaukt" case isn't necessary to show IMO. It only adds an extra
> > item to the list, a "special" one a user can't edit. It will confuse
> > even more.
>
> Yes it is. You either allow everything that doesn't matches, or you
> deny it.

A fall-through case isn't required. If none of the rules match, the packet is 
allowed. So an "Allow all"-rule is not necessary. If a user wants to change 
that to "deny all" he can define a rule of his own, off course.

> > Like you said, it doesn't make sense, so it shouldn't be shown.
>
> Shouldn't it ?

No, it shouldn't.

> > You can *have* a complete implementation this way. One doesn't exclude
> > the other.
>
> No you can't.

Then show me why. The only thing that's missing now is blocking a certain 
resource, however that can be specified on the "other"-tab (and maybe it 
should stay there, there aren't many times when someone only wants to block a 
certain resource of a user). Existing rules can perfectly be shown on the 
list when they are interpreted. I really do not see the problem.

> > Now you're guessing what users want :-p

(Continue reading)

headers

Remko Troncon | 1 May 17:10

Re: Re: Re: Privacy

> Then show me why. 

- Rule 1:
	if subscription='none' deny all
	else if jid=mydomain.com allow messages
- Rule 2:	
	if jid=mydomain.com allow messages
	else if subscription='none' deny all
	
First rule doesn't even allow messages from unsubscribed entities from 
mydomain.com. Second one does. One of both cannot be represented in such
a dialog. What's even worse, i can't tell which one.

cheers,
Remko

headers

Jeroen Vaes | 1 May 17:45

Re: Re: Re: Re: Privacy

On Sunday 01 May 2005 17:10, Remko Troncon wrote:
> > Then show me why.
>
> - Rule 1:
>  if subscription='none' deny all
>  else if jid=mydomain.com allow messages

In the "other" list, check all icons after "Contacts not in my roster". That's 
all that's needed, the second rule doesn't do anything so it shouldn't be 
shown (I'm not saying it should be deleted from the list, just that it should 
not be shown).

My dialog shows the result of the list, not the list itself. The result is 
what matters to the user, not the list itself.

> - Rule 2:
>  if jid=mydomain.com allow messages
>  else if subscription='none' deny all

In the "other" list, check all icons after "Contacts not in my roster", then 
add "mydomain.com" to that list and check all icons but messages.

> First rule doesn't even allow messages from unsubscribed entities from
> mydomain.com. Second one does. One of both cannot be represented in such
> a dialog. What's even worse, i can't tell which one.

Yes, it can. It just requires the client to be intelligent enough.

--

-- 
Jeroen Vaes

(Continue reading)

headers

Remko Troncon | 1 May 17:55

Re: Re: Re: Re: Privacy

> all that's needed, the second rule doesn't do anything 

Huh ? Yes it does, it *only* allows messages from that domain, not queries,
presence, ... 

cheers,
Remko

headers

Jeroen Vaes | 1 May 18:17

Re: Re: Re: Re: Re: Privacy

On Sunday 01 May 2005 17:55, Remko Troncon wrote:
> > all that's needed, the second rule doesn't do anything
>
> Huh ? Yes it does, it *only* allows messages from that domain, not queries,
> presence, ...

*oops* you're right, misinterpreted that one (which illustrates my point 
exactly).

It should be "In the "other" list, check all icons after "Contacts not in my 
roster", and check all icons except messages on "mydomain" contacts in the 
"my roster" list.".

--

-- 
Jeroen Vaes
Mail: jeroen.vaes@...
Jabber: jeroenv@...

headers

Remko Troncon | 1 May 18:21

Re: Privacy


On 01 May 2005, at 18:17, Jeroen Vaes wrote:

> It should be "In the "other" list, check all icons after "Contacts  
> not in my
> roster", and check all icons except messages on "mydomain" contacts  
> in the
> "my roster" list."

Which is the exact same thing as you told me to do with rule 2,  
although both rules are different.

cheers,
Remko

headers

Jeroen Vaes | 1 May 18:31

Re: Re: Privacy

On Sunday 01 May 2005 18:21, Remko Troncon wrote:
> On 01 May 2005, at 18:17, Jeroen Vaes wrote:
> > It should be "In the "other" list, check all icons after "Contacts
> > not in my
> > roster", and check all icons except messages on "mydomain" contacts
> > in the
> > "my roster" list."
>
> Which is the exact same thing as you told me to do with rule 2,
> although both rules are different.

No, I didn't. What I said about rule 2 was: "add "mydomain.com" to [the 
"others"-list] and check all icons but messages.".

The "roster"-list sets rules for your roster only, the "other"-list sets rules 
for the rest.

--

-- 
Jeroen Vaes
Mail: jeroen.vaes@...
Jabber: jeroenv@...

headers

Remko Troncon | 1 May 18:40

Re: Privacy

On 01 May 2005, at 18:31, Jeroen Vaes wrote:

> The "roster"-list sets rules for your roster only, the "other"-list  
> sets rules
> for the rest.

Not all mydomain.com contacts are in my roster, so the roster list is  
of no use in general here.

Trust me on this one, you *can't* represent all privacy lists. And  
i'm going to stop spamming the list trying to prove to you that you  
can't. Just look at the example, and think of *all* kind of use cases  
(not just the simple one where you only consider people on your  
roster, or where you assume that you will never add contacts to your  
roster again).

cheers,
Remko

headers

Maciek Niedzielski | 1 May 19:11

Re: Re: Privacy

Jeroen Vaes wrote:

> I think Psi's philosophy is to provide complete implementations *for 
> users*.

I've always thought that Psi is a client for *advanced* users.

--

-- 
Maciek

headers

Remko Troncon | 1 May 13:59

Re: Privacy

> You did make me realize that an allow rule is actually the inverse of a
> deny rule, so checkboxes (or icons) are in principle enough to have a complete
> implementation.

Of course, this depends how 'matching' is defined in the standard.
Does matching mean 'match type and value of stanza', or does it include
matching of the stanza type ? If it is the latter, we can't just have
2-state icons.

cheers,
Remko