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

Tobias M tmarkmann at googlemail.com
Wed Feb 8 22:11:12 UTC 2017

Hi all,

Usability of most, if not all, XMPP clients has been subpar compared to similar commercial software in the area of instant messaging and real-time communication. At FOSDEM there were some nice talks about the general topic of usability and design in the Open Source Design devroom [0]. One talk in particular, highlighted the issue of good usability design when it comes to open source software projects and provided suggestions how this could be improved [1] in open source communities.

I think, what we call can agree here, is that we ideally want usable [2] implementations of the XMPP protocol and its extensions. All RFCs must contain security considerations near the end [3]. A similar rule for XEPs can be found can be found in XEP-0001 [4]. This requirement raises the awareness of security as one main issue in protocol design and their implementation, and causes authors to consider these issues early in the progress. This leads to more secure protocols, and more secure implementations of these protocols.

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

While I certainly don’t want all implementations ending up looking the same, using the same colour scheme, or visual design, a common user experience across XMPP software sounds like a laudable goal. It should be easy to switch between clients for a user.

We shortly discussed this in today’s Council meeting [5], but due to limited time it was recommended to bring this to the list for wider discussion. So, here we are.


[0] https://fosdem.org/2017/schedule/track/open_source_design/ <https://fosdem.org/2017/schedule/track/open_source_design/>
[1] https://fosdem.org/2017/schedule/event/osd_when_cultures_clash/ <https://fosdem.org/2017/schedule/event/osd_when_cultures_clash/>
[2] https://www.w3.org/WAI/intro/usable <https://www.w3.org/WAI/intro/usable>
[3] https://tools.ietf.org/html/rfc7322#section-4.8.5 <https://tools.ietf.org/html/rfc7322#section-4.8.5>
[4] http://xmpp.org/extensions/xep-0001.html#security <http://xmpp.org/extensions/xep-0001.html#security>
[5] http://logs.xmpp.org/council/2017-02-08#16:33:36 <http://logs.xmpp.org/council/2017-02-08#16:33:36>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170208/312146cb/attachment-0001.html>

More information about the Standards mailing list