[Standards] pubsub/pep auto-creation

Ian Paterson ian.paterson at clientside.co.uk
Sat Mar 24 03:36:21 UTC 2007


Peter Saint-Andre wrote:
> Ian Paterson wrote:
>> The user may simply be logged in with another client that may change 
>> the configuration. Such changes may be legitimate since when 
>> specifying a well-known node, a XEP may make the value of a 
>> configuartion field optional, or it may not specify a value for the 
>> field at all (perhaps because that configuration field wasn't even 
>> defined when the XEP was written).
>>
>> I think we need to consider the likely user interface for a real life 
>> example.
>
> I agree. Let's say that I want to start publishing my geolocation info.
[snip]

We agree about geolocation nodes. In fact, I specifically stated in my 
post that the probable user interface for a geolocation node would work 
fine without publish+configure (because it is published without user 
interaction). My whole point was that the user interface for some other 
types of nodes would be different (e.g. those nodes that are published 
only rarely, and only upon user input via a dialog, e.g. a "Home 
Address" node).

> And storing the preference in iq:private seems really silly to me.

Yes, I'm not suggesting that.

>> The example being used on this list has been of a node that may be 
>> legitimately configured to be "public" or "private". For example, 
>> imagine a "Home Address" node. The client will probably present the 
>> user interface for the node in a dialog box with the address fields, 
>> and with a checkbox "Publish my Home Address publicly".
>
> Why? You don't need to configure the node every time you publish and 
> you don't need to request the config every time. Just assume that the 
> user set it up according to their preferences the first time around. I 
> told the PEP service that I wanted my geolocation info to go to my 
> Friends group, so don't please bother me about it again -- that 
> decision was made and I'm quite happy about it, thank you. If this is 
> the first time, you get an error flow and prompt the user to answer 
> the question "who should be able to see your geolocation information"? 
> The user answers that question once and never fiddles with it again 
> (unless they really want to)

With a node that almost never changes (e.g. a "Home Address" node), the 
first time will often be the only time, so we should care about the 
first time.

We should make user interfaces as easy as possible - even if they are 
rarely used. The flow you describe forces the user to provide input in a 
second dialog that they probably weren't expecting to pop-up on their 
screen after the round trip to the server. This is more irritating and 
less efficient for the user than if a "Publish Publicly" checkbox had 
been included on the first dialog (completely eliminating the need for 
the second dialog).

We should enable simple client development - even features that are 
rarely used still have to be implemented. The flow you described forces 
the client developer to implement the error flow handling, including the 
display of another dialog. A "Publish Publicly" checkbox on the first 
dialog is easier to implement.

Different types of nodes will need different user interfaces, some of 
which (e.g. a "Home Address" but not a geolocation) will benefit from 
allowing *optional* publish+configure.

- Ian




More information about the Standards mailing list