[Standards] Improving Usability of XMPP Clients from the Bottom - Usability Considerations

Tobias Markmann tmarkmann at googlemail.com
Mon Feb 13 21:47:27 UTC 2017

On Thu, Feb 9, 2017 at 10:00 AM, Kevin Smith <kevin.smith at isode.com> wrote:

> On 8 Feb 2017, at 22:11, Tobias M <tmarkmann at googlemail.com> wrote:
> > To improve the overall usability of XMPP software, I want authors to
> consider how the protocols they design might be implemented, and how their
> protocol influences the usability. Some examples for this are:
> >
> > * providing guidelines to what terms to use for certain things the
> protocol introduces, e.g. XEP-0319 could recommend “Idle since” or “last
> active at” as possible phrases to use when presenting the time to the user
> This is a fine example (i18n issues aside), although ‘recommend’ is
> dangerously close to normative text, which I don’t think belongs here.
> > * defining that for MIX channels, the primary name of a channel in the
> UI should be the roster item name of the bookmark, as it is user editable,
> and provide recommendations what value to use as default
> I think ‘can be’ rather than ‘should be’, again noting that 2119 text
> doesn’t belong here.
> > * providing recommendations how to handle end-to-end crypto (i.e. OMEMO)
> use cases, like key verification, trust management, or visual assurance for
> the user that the current chat is encrypted
> Sure.
> > Adding the mandatory “Security Considerations” section to RFCs/XEPs
> improved the security a lot. I suggest adding a mandatory “Usability
> Considerations” to XEPs, even if some XEPs will just say “This protocol
> provides no recommendations to usability.” or something like that.
> I think the best thing to do here Right Now is to
> 1) Add an OPTIONAL section to the XEP template

I think OPTIONAL is too light, and has little to no effect on XEP authors.
Ideally I like XEPs to have recommendations regarding usability if there
are is a need for them. At least I want to have XEP authors think about
usability issues related to their XEP, rather than just seeing the section
is OPTIONAL and just skipping it. Therefore I'd suggest to go with
RECOMMENDED or STRONGLY RECOMMENDED, similar to the current "Requirements"
and "Use Cases" sections in the XEP template.

> 2) Have some of the people pushing for this section send in PRs to add it
> to some existing XEPs
> I think requiring this without a clear *shared* picture of what it should
> look like would be a bad idea. I’m not intrinsically opposed to it being
> more strongly encouraged in the future, once it’s clear what it means and
> what the implications are for spec design, but I think right now the above
> two steps let us start making progress without boiling the ocean.

Sounds like a great idea. I think there are more of a handful of existing
XEPs that could benefit of "Usability Recommendations". Happy to provide
sections for some of them. Good usability is the main feature of client
software. While nice E2E crypto, fancy emojis and stickers, are all nice,
combine them with bad usability and your software isn't used. Good
usability is far from straightforward, otherwise all apps would have it. So
we should try our best to make it as easy as possible for developers to
provide their software with good usability.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170213/c58ac036/attachment-0001.html>

More information about the Standards mailing list