[Standards] pubsub/pep auto-creation
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
> I agree. Let's say that I want to start publishing my geolocation info.
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
> 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
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.
More information about the Standards