XSF Discussion - 2019-11-15

https://liliputing.com/2019/11/google-enables-rcs-messaging-for-us-smartphones-without-any-carrier-help.html

RCS is technically and "organisationally" a big mess, but at least it is a real community/consortium effort, with a real open standard process

Assuming the non-Google messaging apps adopt it (most commercial Android distributions don't use it by default, such as Samsung's), the only other thing that remains to be seen is whether Apple will join in

I assume Apple will join when/if forced

I think the joiner will be the carriers rather than app makers

how can we add pictures on the wiki?

it's a consortiom effort of Big Telco. From past experience, this is the opposite of "open"

I have a sane criterium how we can demote clients like pidgin from our recommendations.

We should not recommend multi-protocol clients with the same priority as single-protocol clients.

because experience shows that multi-protocol clients are always worse than single-protocol clients.

we should still *list* them, but in a separate table and with a note above that those clients only make sense if and only if you also need to connect to other networks *and* you want to use only one tool *and* you can live with a degraded user experience of all involved protocols.

jonas’: I like that

this criterium can be evaluated objectively, even though it is based on experience, which I like.

and since the clients obviously didn’t prioritize xmpp, we shouldn’t prioritize them :)

How many multi protocol clients do we currently list?

I don’t know, maybe only pidgin?

that has to be per client, in the future maybe you find a multi-protocol client that actually cares about XMPP first

Seve, we can worry about that when it happens :)

Yeah

Workarounds, workarounds everywhere \o/

:P

so yaxim is a multi-protocol client? :((

What is considered multi-protocol?

pep., a client which can directly and natively offer chat services over anything but XMPP.

(where XMPP encompasses RFCs and XEPs, so e.g. the serverless stuff would still be ok)

(I was going to ask)

and being able to IRC via biboumi is obviously not multi-protocol, because the client only does XMPP

I'd consider 'multi-protocol clients' to be the likes of Trillian and Pidgin. Unsure how to exactly define that other than what jonas’ already wrote.

jonas’ multi-protocol clients tend to offer an experience that's more user friendly, because the protocol does not matter here, but the features do

you mean IRC features do?

nyco but at the same time, they're often limited to the most common denominator between protocols, which leads to very basic functionality.

agree

Because multi-protocol means lowest common denominator

still, we (XSF) do want to keep neutrality

That's not what we want to keep neutrality for

I guess

Sure: jonas’ proposal doesn't hurt neutrality

it just splits the list in two helpful lists

why not? please explain

XMPP-native clients, and multi-protocol clients.

nyco, because it doesn't discriminate on XMPP implementations

I don't get it

It is just like a pre-applied filter on a search for xmpp clients, nyco

nyco we now have one list that contains all clients. jonas’ suggests to split that list into two list: one that contains only clients that do XMPP natively, and another one that only has multi-protocol clients.

I suppose we can keep both lists on the same website page.

that's only one criteria, why this one? there's also mobile vs desktop, fat vs light, etc.

because that's one way to put pidgin (sub-par XMPP implementation) at the bottom of the page.

we use this criteria, as it distinguishes between clients that have been implemented with an emphasis on XMPP, and those that have not.

when users select an app, do they care about this criteria?

Since when is xmpp.org about users?

If it were we wouldn't be showing pidgin at all

I think so. It allows the user, apart from the platform selection, to also select a client that either gives them broad, but limited features for many protocols, or a more specific solution.

I think most users *don’t* care about this distinction, and that’s why they end up with pidgin.

pep.: there was a time when pidgin didn't appear there.

pep. many people are very happy with Pidgin.

Ge0rG, I know..

Guus, and many people are ranting about XMPP because of pidgin. I'm sure these two sets overlap

lots of users like Pidgin, so be it, let's understand that

the point being, users know what platform support means. they need a client which works on their machine (Linux, Windows, whatever)

they don’t know the importance of whether the client puts XMPP first or whether it tries to be multi-protocol

nyco, do they, though?

or do they simply not know the difference?

Guus, if we cared about users we'd want them to have a good XMPP experience

Not use pidgin

I don't know, I wouldn't assume an answer, I'd rather do some UX research

or do they like pidgin because of its multi-protocol features, which is a very valid reason, but a reason one really should have to use pidgin

Which is why I like Jonas' idea.

so far, we have a customer who won't let go Pidgin, because

this customer only uses XMPP in Pidgin

nyco: maybe people like pidgin because they don't realize how everything will break down when they use it together with another client. Or when they realize it, they blame xmpp

it allows is to explicitly define that it does support XMPP, but that your mileage for XMPP-compatibility on that type of client may vary.

that’s a pity for them, but they can make that choice consciously if they want to

but generally users don’t, and they end up with pidgin

jonas’: for the record: I love your idea, please make it happen.

Ge0rG, I’ll see if I can prepare a PR this weekend, but if I haven’t by sunday, feel free to ping me

(I probably just forgot)

"Multi-protocol clients that _also_ support XMPP but might not make a good XMPP experience a priority: ... PIDGIN ..."

to me, Pidgin feels more relaxed than other desktop/fat XMPP clients Pidgin is much less "mapped" to the XMPP protocol, which is definitely a thing to do to coroborate this, we have done user research on Converse, and the fact is regular users/people just don't like and don't want to "see" the procotol, that includes IDs, vocabulary, UX...

What was the wording again? "Even less compatible" 😁

nyco, which is why pidgin is a terrible choice

nyco: pidgin is great, if you don't need any of the XEPs of the last ten years.

nyco did you share that with JC? I bet he'd love to know about that.

it still (sometimes) shows the resource of your peer on every f*ing message

yes

it's on the issues on GitHub

you can read it

it may be usefull for all clients developers here

👍

protocol mapping is an illness for developers who don't consider UX

ok, I'm off to do work again

thanks Jonas!

nyco, note that it's not what we're saying

the UX offered to users MUST NOT map the protocol

the criteria of single vs multi protocol is just irrelevant

for users

it is our way of thinking on our community, and I do agree with the lack of XMPP support in Pidgin

Pidgin is great for users, please try to understand why

I guess we'll just agree to disagree

it's easier to use than Psi and Gajim and...

nyco: a client that is easy to use but doesn't deliver messages reliably is HORRIBLE for users.

cool

so?

otherwise they can use notepad.exe

people use it

I repeat

people use it

say what?

wat

please do consider Pidgin is used for reasons, other than ours

nyco, sure, and they’re free to do so

nyco, if you want to go the way of fixing pidgin, be my guest. That would be a great gift to the community. In the meantime, it is a horrible experience for users

but it should not be the default choice

I don't use Pidgin, I don't recommand it, for the same reasons expressed here

rather fix the UX of XMPP apps

I honestly think people use Pidgin for the same reason they say Jabber

that seems a fair hypothesis

Seve, because they're stuck in the past? :P

please consider other hypothesis :)

also

maybe they like better Jabber for many other reasons

because they don't realize how broken it is

maybe

so what?

if their experience is better than not feeling the brokenness

I don't understand this last message

do we _know_? who studied that? scientific research?

I know

nyco: there is empirical evidence that people realize the brokenness when using pidgin, but blame Jabber/XMPP for it.

Piding is here to stay, I'd like to know and understand why

in order to improve the situation

empirical is cool

nyco: what about helping Pidgin natively support the most important XEPs instead? That would be time well spent

maybe that aspect of things is not the only one to consider

Ge0rG I guess so

nyco: then please go on!

be my guest

I'd rather fix the XMPP apps

but that's my opinion

nyco: then please go on with that, and we'll demote pidgin on the client list

because indeed, like most here I presume, Piding belongs to the past

wat

nyco: the problem isn't pidgin being broken, the problem is pidgin isn't going to get fixed

I'm curious how a "Fix Pidgin" crowdfunding campain would work out

zach great idea

Zash sorry

https://developer.pidgin.im/ticket/6940 (Receipts) is 11 years old, https://developer.pidgin.im/ticket/15508 (Carbons) "only" seven

:)

MAM for Psi as well :)

the pidgin carbons ticket is in elementary school now!

hehehe

Ge0rG, "but there are plugins"?

Isn't everything fixed via plugins?

From my point of view, Pidgin can be completely eradicated from xmpp.org

Or that's what I heard.

Somebody cared enough to make an OMEMO plugin. While basic XMPP support isn't even there

but still, users use Pidgin... :)

nyco: and then they complain about xmpp being broken

If you want to figure out why, great. In the meantime I vote on not recommending it to avoid us the "XMPP is bad because $pidgin"

Pidgin is actively damaging the XMPP ecosystem's popularity

it's like poisoned milk. yes, people drink it because it's cheap, but then their babies die.

:D

I'd say the problem isn't Pidgin per-se - there are easy alternatives to give people - but Adium.

David Cridland: Adium is the pidgin of the rich 10%?

not Pidgin is also damaging the XMPP ecosystem's popularity, because users find this app better than others

Is there a way to define a force-password-reset in a backwards compatible way? I'm thinking about <required/> stream feature (after <bind/>), but that won't be backwards compatible..

pep.: send a message on login :|

A message? How do you force anything with that

you can force the user.

SASL2?

I can prevent any message to be delivered until then, I guess

suspend the account, where all messages will be blocked with a "change your password" error

we have such a thing in prosody's mod_firewall ;)

That is so..

Zash, so no password reset until sasl2 is a thing?

pep.: I believe being able to do that is one of the goals of sasl2

sasl2 when?

“10:23:16 nyco> it's on the issues on GitHub”, do you have a link to this study?

I saw it when it appeared

for example: https://github.com/conversejs/converse.js/issues/1580

Even though it's great to have such a sample, it still is a pretty small sample imo

no it is not small: it is a research on problems, and research sciences show that 5 persons is enough to make like 2/3 of the main problems emerge

not my opinion, basic UX research fundamentals

that study was conducted a while ago, with real, unbiaised testing conditions when we show Converse to enterprise prospects, in 5 or 10 min they just basically say the same things over and over again: these main problems are confirmed by a much larger sample

"unbiased" is a bit too much

While I might agree with your conclusion I don't agree any setup is "unbiased" :)

everything is full of prejudices

nyco I'm to lazy to read the entire thing. Can you give an explicit example of what should change in Converse's UI based off that. I'm fully aware that given my background, I'm completely blind to this all. To me, it seems like a very generic chat client. It lists 'groupchats' and 'contacts', and a list of 'participants' in a groupchat. Doesn't that translate well to Average Joe?

FWIW, people are deely confused about groupchats, in my experience.

"deeply".

how's that? Everything is a potential group chat, nowadays?

Guus create groupchats or add a contact... via a JID => people don't want to handle JIDs

they don't know what that is

they don't want to read

they don't want to learn

just describing the problem, because that is what we have researched

David Cridland I agree, most our XMPP apps/clients map the UX to the protocol, that is a huge problem for users

one of our goals as developers is to simplify and hide the complexity

nyco: somebody once made different "Easy XMPP" proposals to make JID handling more automatic

risky comparisons: * browsers show almost nothing of HTTP, HTML, CSS, JS * email apps show almost nothing of SMTP, POP, IMAP

Ge0rG I don't know who that guy is... :) I probably did support that initiative, still probably doing this :)

* WhatsApp shows almost nothing of FunXMPP ...

(which is not that fun, btw... :) )

Nothing is fun. Everything is sad.

WhatsApp is centralized and doesn't have the same problematics

I think most of the mentioned issues are unrelated to federation.

JID issues are very well related to federation

JID UX

Federation doesn't force the client to ask the user for a JID when creating a room.

You can just skip this in a centralized system

Holger: sure, not always

Holger yes, Converse issue emerged by this study show internal UX/UI issues; no real focus on federated things

I think there is a subset of the target that wants to be educated, just like mastodon users

> JID issues are very well related to federation can be related to people not easy with ID handling can be related to people not having better, like lists, suggestions, etc.

nyco: your second suggestion calls for centralization

> JID issues are very well related to federation centralised systems have IDs as well, but they just don't show them

Which might be fine in some cases (I'm not denying it)

pep. > nyco: your second suggestion calls for centralization what suggestion?

pep.: user discovery on a given server should be a thing on most corporate and private / family servers

of course not exposed over s2s

Ge0rG: sure

I guess we all have different targets

moving targets.

That's yet another issue

Ge0rG user directories may be exposed under some conditions, like Movim social networking

sure, if we only target the XMPP protocol fans, we'll get protocol fans as users I thought you might want to "reach out"

I'm not talking about that no. I don't need to focus on these they'll come by themselves if we don't push them away too much ✏

wat

that, these, them: who?

I'm not talking about "XMPP protocol fans"

Your last message

> risky comparisons: > * browsers show almost nothing of HTTP, HTML, CSS, JS > * email apps show almost nothing of SMTP, POP, IMAP Email also requires to enter an email address, that's the same as entering a jid. So users should be used to this. Also when adding someone on facebook they must know their 'funny facebook name' which is also like an id.

Email is a bad comparison though. "Nobody" likes email. It's the thing you have to use for work

!XSF_Martin: when adding somebody on facebook you'll never enter an ID, you'll just surf your friends, and then their friends, and then add 'em. Or, you know, see a big fat banner of "Are those your friends?"

Yeah, people get the email-like usernames for people. They don't for groupchats.

fwiw, Converse asks for the address (not 'JID') for a group chat. Do I understand you correctly nyco that the issue not the term ("JID" vs "Address") but the fact that we're asking for something specifically?

Guus: I'm pretty sure we can completely get rid of JID display/input for channels and groups

similarly for adding contacts. It adds for "XMPP address". Perhaps that can be made more generic by asking for a 'username'?

it's not about how to name the input box, is it?

albeit, you know, "_Jabber_ ID"

Ge0rG that's what i don't understand

Everything is horrible.

what's the suggested improvement? Changes to the label of input boxes? Elaborate directory services for people to pick from?

(both are probably desirable, but I'm trying to understand more of the root issue)

to distinguish between absolute no-no's, and nice-to-haves

> !XSF_Martin: when adding somebody on facebook you'll never enter an ID, you'll just surf your friends, and then their friends, and then add 'em. Or, you know, see a big fat banner of "Are those your friends?" I often hear people 'I'll add you on facebook' than the reply 'yeah, but don't search for my name as my name is Hans Hanssen there' Seems funny sounding fake names are common there so it's also like an ID. I don't know how many find others by searching friends friend lists.

Guus: Just auto-generate a room JID and hide it both from the user creating the room and from those invited into the room. Obviously won't work for public rooms that are supposed to be joined by JID, but should be done that way for private groups and 'team chat' IMO.

Holger: Rely on muclumbus and only put a field to search for topics?

Holger: for public rooms we already have MUC Search

Holger that makes sense (and I wasn't considering use-cases that included invites)

Guus: there should be no way to enter private rooms except by invite

Guus, just check what Slack works, you just add people to a conversation and that is it.

So, to come up with a real-world advise, Converse should: a) Have an option to create a new "group chat" without any settings except for maybe a name and an avatar (that should create a private MUC on the home server of the user?) b) Allow people to be invited in that new room by picking people from the roster (I think Converse already does that)

This is the current "add groupchat" option

https://igniterealtime.org:443/httpfileupload/908ca3e5-059f-43bb-8299-a312ab0529fd/image.png

In Slack, a) cannot be done without providing at least one participant. So when you create a conversation is always selecting the participants (you can invite more people later on).

So this should drop the address input field, and add some kind of widget that allows you to add people from your roster?

yes

(Based on Slack of course)

(I'm mostly trying to understand the argument here, not making actual advice)

nyco, maybe you can give your input here.

again, we have only done user research on the _problems_

we have addressed a few, by ideation, user tests, iterations

we only addressed the most painful problems or the ones with most occurrences

for the "Create channel" UX, we narrowed down on a very simple form: name, members via search, and avatar plus the "advanced" options (hidden by default)

advanced options: this server (the domain of my JID) or another (not my JID domain) Public or hidden open or member-only

what is the default for both public/hidden and open/members-only?

that represents three small iterations

we have not yet implemented it

nyco, and again, there are different targets. There is no one answer to rule them all

pep.: there _is_ one answer to rule them all, and it is called Gajim!

:D

for the "Join channel": search list of local server public rooms or rooms I am a member of

"Please choose your JID with which to create the new Multi User Chat: ..."

Ge0rG, I am sure that was the original goal. I think it's slightly drifted from that since then

pep. you want to "reach out", so let's democratise the user of Jabber/XMPP by targeting larger crowds

larger clouds?

Riot has an "Add room" button which opens a room search thing, which has a "Create room" button, which opens another dialog where you can (optionally) name the new room.

nyco, sure, but even "larger crowds"..

wat

My statement above stands even for larger crowds

if we target protocol fans, or whatever you name us, the XMPP/Jabber community... ...then we'll top at a few thousands users worldwide, maybe tens of thousands

wat

I generally don't understand what you mean pep.

I am also confused with your statements tbh..

I'm not sure why you insist I want to target XMPP people

wat

"if we target protocol fans, or whatever you name us, the XMPP/Jabber community..." what does that mean

wat

It's the second time you say this

If you're here to troll please be more explicit, I have more interesting things to do of my time

What???

I think we can safely assume nyco is not trying to troll.

look, how many Jabber/XMPP users worldwide today? do we want to expand?

thx Kev

nyco, where did I answer "no" to this?

to whatN?

Your last message..

#contextishard

> thx Kev ? :) THAT's a troll :)

Oh... my...

whatever..

I think I'm done

I know you want to expand, it's on your candidacy

I want to expand too, and Christmas season is the best time to do it.

so what would be your projects/products next target groups? what do they see? live? hear? what problems do they have with IM in general? what problems do they have with your IM? that's a start

then you go on ideation, meaning you design and user-test many many possible solutions

and you iterate the best

we hardly manage to user-test one possible solution per project.

there are plenty of low cost techniques to perform plenty of tests

hint: no need for code

well, not always

hint: start with a paper and a pencil

you can get really fast, in a fair amount of time and effort

a paper, a pencil, and twenty users without knowledge of xmpp

..from different ethnic groups and financial backgrounds

no, 5 users, in order to spot the biggest issues

there used to be a time when I asked unexperienced people to install and configure yaxim. Unfortunately, those were either family members or coworkers, the opposite of a diverse group

right, close friends/family are greatly biaised

also, a full install + use is a very large test, consuming a lot of time

nyco: you'd be surprised.

I am always surprised by user tests, that's why I do a lot

installing an android app and getting a first contact is a matter of a few minutes

I know

if you optimised the first use journey, then very good, and congrats

nyco My issue is largely that I (personally) don't want to understand all of the larger context - I just want you to tell me what to change in the UI / UX 🙂

you / anyone that _does_ understand the context.

the pixel, here! :)

well, yes.

hehehe

UX is not a democracy.

What is.

You have 4 hours

sure, that's why there are devs on one side (backend, frontend, etc.) and designers (UI, UX, information architecture, etc.) and marketers and user researchers (spot and evaluate market issues, segment target groups, test core message, etc.)

right. So all of the context that you're posting to this page is waaaay TMI for me. You're loosing me in the general terms that you're using.

I'm happy to accept suggestions, but you need to dumb it down for me 🙂

right, I was showing the process

ok

clear

(not sure if that goes for everyone here, by the way)

But I've long ago accepted that the world of UI / UX is not for me.

that's often the case for devs

the funny thing is that old-style marketers feel like designers' user research is kind of the same as Marketing's "market research"

Ge0rG: After a lot of efforts, Pidgin can be forgotten, no?

Wasn't a plan to have compliance buttons to shame Pidgin with?

Is there a channel that would be appropriate for asking questions about the XMPP protocol? I am currently developing an XMPP server in Haskell, and it would be mighty nice if I had a place to ask clarifying questions 🙂

Chobbes: here is a good place for that

👍️