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

Kevin Smith kevin.smith at isode.com
Thu Feb 9 09:00:06 UTC 2017

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


> 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
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.


More information about the Standards mailing list