nycoRCS is technically and "organisationally" a big mess, but at least it is a real community/consortium effort, with a real open standard process
MattJAssuming 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
nycoI assume Apple will join when/if forced
nycoI think the joiner will be the carriers rather than app makers
nycohow can we add pictures on the wiki?
Ge0rGit's a consortiom effort of Big Telco. From past experience, this is the opposite of "open"
Steve Killehas left
Steve Killehas joined
jonas’I have a sane criterium how we can demote clients like pidgin from our recommendations.
jonas’We should not recommend multi-protocol clients with the same priority as single-protocol clients.
jonas’because experience shows that multi-protocol clients are always worse than single-protocol clients.
jonas’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.
Guusjonas’: I like that
jonas’this criterium can be evaluated objectively, even though it is based on experience, which I like.
jonas’and since the clients obviously didn’t prioritize xmpp, we shouldn’t prioritize them :)
GuusHow many multi protocol clients do we currently list?
jonas’I don’t know, maybe only pidgin?
Sevethat has to be per client, in the future maybe you find a multi-protocol client that actually cares about XMPP first
jonas’Seve, we can worry about that when it happens :)
pep.Workarounds, workarounds everywhere \o/
Ge0rGso yaxim is a multi-protocol client? :((
pep.What is considered multi-protocol?
jonas’pep., a client which can directly and natively offer chat services over anything but XMPP.
jonas’(where XMPP encompasses RFCs and XEPs, so e.g. the serverless stuff would still be ok)
pep.(I was going to ask)
jonas’and being able to IRC via biboumi is obviously not multi-protocol, because the client only does XMPP
GuusI'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.
Dele (Mobile)has joined
nycojonas’ multi-protocol clients tend to offer an experience that's more user friendly, because the protocol does not matter here, but the features do
pep.you mean IRC features do?
Guusnyco but at the same time, they're often limited to the most common denominator between protocols, which leads to very basic functionality.
pep.Because multi-protocol means lowest common denominator
nycostill, we (XSF) do want to keep neutrality
pep.That's not what we want to keep neutrality for
GuusSure: jonas’ proposal doesn't hurt neutrality
Guusit just splits the list in two helpful lists
nycowhy not? please explain
GuusXMPP-native clients, and multi-protocol clients.
pep.nyco, because it doesn't discriminate on XMPP implementations
nycoI don't get it
SeveIt is just like a pre-applied filter on a search for xmpp clients, nyco
Guusnyco 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.
GuusI suppose we can keep both lists on the same website page.
nycothat's only one criteria, why this one? there's also mobile vs desktop, fat vs light, etc.
pep.because that's one way to put pidgin (sub-par XMPP implementation) at the bottom of the page.
Guuswe use this criteria, as it distinguishes between clients that have been implemented with an emphasis on XMPP, and those that have not.
nycowhen users select an app, do they care about this criteria?
pep.Since when is xmpp.org about users?
pep.If it were we wouldn't be showing pidgin at all
GuusI 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.
jonas’I think most users *don’t* care about this distinction, and that’s why they end up with pidgin.
Ge0rGpep.: there was a time when pidgin didn't appear there.
Guuspep. many people are very happy with Pidgin.
pep.Ge0rG, I know..
Ge0rGis still mad at a certain website editor about that.
pep.Guus, and many people are ranting about XMPP because of pidgin. I'm sure these two sets overlap
nycolots of users like Pidgin, so be it, let's understand that
jonas’the point being, users know what platform support means. they need a client which works on their machine (Linux, Windows, whatever)
jonas’they don’t know the importance of whether the client puts XMPP first or whether it tries to be multi-protocol
jonas’nyco, do they, though?
jonas’or do they simply not know the difference?
pep.Guus, if we cared about users we'd want them to have a good XMPP experience
pep.Not use pidgin
nycoI don't know, I wouldn't assume an answer, I'd rather do some UX research
jonas’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
GuusWhich is why I like Jonas' idea.
nycoso far, we have a customer who won't let go Pidgin, because
nycothis customer only uses XMPP in Pidgin
Ge0rGnyco: 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
Guusit allows is to explicitly define that it does support XMPP, but that your mileage for XMPP-compatibility on that type of client may vary.
jonas’that’s a pity for them, but they can make that choice consciously if they want to
jonas’but generally users don’t, and they end up with pidgin
Ge0rGjonas’: for the record: I love your idea, please make it happen.
jonas’Ge0rG, I’ll see if I can prepare a PR this weekend, but if I haven’t by sunday, feel free to ping me
jonas’(I probably just forgot)
Ge0rG"Multi-protocol clients that _also_ support XMPP but might not make a good XMPP experience a priority: ... PIDGIN ..."
nycoto 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...
Ge0rGWhat was the wording again? "Even less compatible" 😁
jonas’nyco, which is why pidgin is a terrible choice
Ge0rGnyco: pidgin is great, if you don't need any of the XEPs of the last ten years.
Guusnyco did you share that with JC? I bet he'd love to know about that.
jonas’it still (sometimes) shows the resource of your peer on every f*ing message
nycoit's on the issues on GitHub
nycoyou can read it
nycoit may be usefull for all clients developers here
nycoprotocol mapping is an illness for developers who don't consider UX
Guusok, I'm off to do work again
pep.nyco, note that it's not what we're saying
nycothe UX offered to users MUST NOT map the protocol
nycothe criteria of single vs multi protocol is just irrelevant
nycoit is our way of thinking on our community, and I do agree with the lack of XMPP support in Pidgin
nycoPidgin is great for users, please try to understand why
pep.I guess we'll just agree to disagree
nycoit's easier to use than Psi and Gajim and...
Ge0rGnyco: a client that is easy to use but doesn't deliver messages reliably is HORRIBLE for users.
Ge0rGotherwise they can use notepad.exe
nycopeople use it
nycopeople use it
nycoplease do consider Pidgin is used for reasons, other than ours
jonas’nyco, sure, and they’re free to do so
pep.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
jonas’but it should not be the default choice
nycoI don't use Pidgin, I don't recommand it, for the same reasons expressed here
nycorather fix the UX of XMPP apps
SeveI honestly think people use Pidgin for the same reason they say Jabber
nycothat seems a fair hypothesis
pep.Seve, because they're stuck in the past? :P
nycoplease consider other hypothesis :)
nycomaybe they like better Jabber for many other reasons
Ge0rGbecause they don't realize how broken it is
nycoif their experience is better than not feeling the brokenness
pep.I don't understand this last message
nycodo we _know_? who studied that? scientific research?
Ge0rGnyco: there is empirical evidence that people realize the brokenness when using pidgin, but blame Jabber/XMPP for it.
nycoPiding is here to stay, I'd like to know and understand why
nycoin order to improve the situation
nycoempirical is cool
Ge0rGnyco: what about helping Pidgin natively support the most important XEPs instead? That would be time well spent
nycomaybe that aspect of things is not the only one to consider
nycoGe0rG I guess so
Ge0rGnyco: then please go on!
nycobe my guest
nycoI'd rather fix the XMPP apps
nycobut that's my opinion
Ge0rGnyco: then please go on with that, and we'll demote pidgin on the client list
nycobecause indeed, like most here I presume, Piding belongs to the past
Ge0rGnyco: the problem isn't pidgin being broken, the problem is pidgin isn't going to get fixed
ZashI'm curious how a "Fix Pidgin" crowdfunding campain would work out
nycozach great idea
Ge0rGhttps://developer.pidgin.im/ticket/6940 (Receipts) is 11 years old, https://developer.pidgin.im/ticket/15508 (Carbons) "only" seven
nycoMAM for Psi as well :)
Ge0rGthe pidgin carbons ticket is in elementary school now!
pep.Ge0rG, "but there are plugins"?
pep.Isn't everything fixed via plugins?
Ge0rGFrom my point of view, Pidgin can be completely eradicated from xmpp.org
pep.Or that's what I heard.
pep.Somebody cared enough to make an OMEMO plugin. While basic XMPP support isn't even there
nycobut still, users use Pidgin... :)
Ge0rGnyco: and then they complain about xmpp being broken
pep.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"
Ge0rGPidgin is actively damaging the XMPP ecosystem's popularity
Ge0rGit's like poisoned milk. yes, people drink it because it's cheap, but then their babies die.
David CridlandI'd say the problem isn't Pidgin per-se - there are easy alternatives to give people - but Adium.
Ge0rGDavid Cridland: Adium is the pidgin of the rich 10%?
nyconot Pidgin is also damaging the XMPP ecosystem's popularity, because users find this app better than others
pep.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..
Ge0rGpep.: send a message on login :|
pep.A message? How do you force anything with that
Ge0rGyou can force the user.
pep.I can prevent any message to be delivered until then, I guess
Ge0rGsuspend the account, where all messages will be blocked with a "change your password" error
Ge0rGwe have such a thing in prosody's mod_firewall ;)
pep.That is so..
pep.Zash, so no password reset until sasl2 is a thing?
Zashpep.: I believe being able to do that is one of the goals of sasl2
Link Mauve“10:23:16 nyco> it's on the issues on GitHub”, do you have a link to this study?
pep.Even though it's great to have such a sample, it still is a pretty small sample imo
nycono 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
nyconot my opinion, basic UX research fundamentals
nycothat 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
pep."unbiased" is a bit too much
pep.While I might agree with your conclusion I don't agree any setup is "unbiased" :)
Ge0rGeverything is full of prejudices
Guusnyco 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?
David CridlandFWIW, people are deely confused about groupchats, in my experience.
Guushow's that? Everything is a potential group chat, nowadays?
nycoGuus create groupchats or add a contact... via a JID => people don't want to handle JIDs
nycothey don't know what that is
nycothey don't want to read
nycothey don't want to learn
nycojust describing the problem, because that is what we have researched
nycoDavid Cridland I agree, most our XMPP apps/clients map the UX to the protocol, that is a huge problem for users
nycoone of our goals as developers is to simplify and hide the complexity
Ge0rGnyco: somebody once made different "Easy XMPP" proposals to make JID handling more automatic
* browsers show almost nothing of HTTP, HTML, CSS, JS
* email apps show almost nothing of SMTP, POP, IMAP
nycoGe0rG I don't know who that guy is... :) I probably did support that initiative, still probably doing this :)
Holger* WhatsApp shows almost nothing of FunXMPP ...
nyco(which is not that fun, btw... :) )
Ge0rGNothing is fun. Everything is sad.
pep.WhatsApp is centralized and doesn't have the same problematics
HolgerI think most of the mentioned issues are unrelated to federation.
pep.JID issues are very well related to federation
HolgerFederation doesn't force the client to ask the user for a JID when creating a room.
pep.You can just skip this in a centralized system
pep.Holger: sure, not always
nycoHolger yes, Converse issue emerged by this study show internal UX/UI issues; no real focus on federated things
pep.I think there is a subset of the target that wants to be educated, just like mastodon users
nyco> 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.
pep.nyco: your second suggestion calls for centralization
nyco> JID issues are very well related to federation
centralised systems have IDs as well, but they just don't show them
pep.Which might be fine in some cases (I'm not denying it)
nycopep. > nyco: your second suggestion calls for centralization
Ge0rGpep.: user discovery on a given server should be a thing on most corporate and private / family servers
Ge0rGof course not exposed over s2s
pep.I guess we all have different targets
pep.That's yet another issue
nycoGe0rG user directories may be exposed under some conditions, like Movim social networking
nycosure, if we only target the XMPP protocol fans, we'll get protocol fans as users
I thought you might want to "reach out"
pep.I'm not talking about that no. I dont need to focus these they'll come by themselves if we don't push them away too much
pep.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
nycothat, these, them: who?
pep.I'm not talking about "XMPP protocol fans"
pep.Your last message
!XSF_Martin> 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.
pep.Email is a bad comparison though. "Nobody" likes email. It's the thing you have to use for work
Ge0rG!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?"
David CridlandYeah, people get the email-like usernames for people. They don't for groupchats.
Guusfwiw, 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?
Ge0rGGuus: I'm pretty sure we can completely get rid of JID display/input for channels and groups
Guussimilarly for adding contacts. It adds for "XMPP address". Perhaps that can be made more generic by asking for a 'username'?
Ge0rGit's not about how to name the input box, is it?
Ge0rGalbeit, you know, "_Jabber_ ID"
GuusGe0rG that's what i don't understand
Ge0rGEverything is horrible.
Guuswhat's the suggested improvement? Changes to the label of input boxes? Elaborate directory services for people to pick from?
Guus(both are probably desirable, but I'm trying to understand more of the root issue)
Guusto distinguish between absolute no-no's, and nice-to-haves
!XSF_Martin> !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.
HolgerGuus: 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.
!XSF_MartinHolger: Rely on muclumbus and only put a field to search for topics?
Ge0rGHolger: for public rooms we already have MUC Search
GuusHolger that makes sense (and I wasn't considering use-cases that included invites)
Ge0rGGuus: there should be no way to enter private rooms except by invite
SeveGuus, just check what Slack works, you just add people to a conversation and that is it.
GuusSo, 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)
SeveIn 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).
GuusSo this should drop the address input field, and add some kind of widget that allows you to add people from your roster?
Seve(Based on Slack of course)
Guus(I'm mostly trying to understand the argument here, not making actual advice)
Sevenyco, maybe you can give your input here.
nycoagain, we have only done user research on the _problems_
nycowe have addressed a few, by ideation, user tests, iterations
nycowe only addressed the most painful problems or the ones with most occurrences
nycofor 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)
this server (the domain of my JID) or another (not my JID domain)
Public or hidden
open or member-only
jonas’what is the default for both public/hidden and open/members-only?
nycothat represents three small iterations
nycowe have not yet implemented it
pep.nyco, and again, there are different targets. There is no one answer to rule them all
Ge0rGpep.: there _is_ one answer to rule them all, and it is called Gajim!
nycofor the "Join channel":
list of local server public rooms or rooms I am a member of
Ge0rG"Please choose your JID with which to create the new Multi User Chat: ..."
pep.Ge0rG, I am sure that was the original goal. I think it's slightly drifted from that since then
nycopep. you want to "reach out", so let's democratise the user of Jabber/XMPP by targeting larger crowds
ZashRiot 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.
pep.nyco, sure, but even "larger crowds"..
pep.My statement above stands even for larger crowds
nycoif 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
nycoI generally don't understand what you mean pep.
pep.I am also confused with your statements tbh..
pep.I'm not sure why you insist I want to target XMPP people
pep."if we target protocol fans, or whatever you name us, the XMPP/Jabber community..." what does that mean
pep.It's the second time you say this
pep.If you're here to troll please be more explicit, I have more interesting things to do of my time
KevI think we can safely assume nyco is not trying to troll.
nycolook, how many Jabber/XMPP users worldwide today?
do we want to expand?
pep.nyco, where did I answer "no" to this?
pep.Your last message..
nyco> thx Kev
THAT's a troll :)
pep.I think I'm done
nycoI know you want to expand, it's on your candidacy
Ge0rGI want to expand too, and Christmas season is the best time to do it.
Ge0rGputs some cookies into the channel
nycoso 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
nycothen you go on ideation, meaning you design and user-test many many possible solutions
nycoand you iterate the best
Ge0rGwe hardly manage to user-test one possible solution per project.
nycothere are plenty of low cost techniques to perform plenty of tests
nycohint: no need for code
nycowell, not always
nycohint: start with a paper and a pencil
nycoyou can get really fast, in a fair amount of time and effort
Ge0rGa paper, a pencil, and twenty users without knowledge of xmpp
Ge0rG..from different ethnic groups and financial backgrounds
nycono, 5 users, in order to spot the biggest issues
Ge0rGthere 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
nycoright, close friends/family are greatly biaised
nycoalso, a full install + use is a very large test, consuming a lot of time
Ge0rGnyco: you'd be surprised.
nycoI am always surprised by user tests, that's why I do a lot
Ge0rGinstalling an android app and getting a first contact is a matter of a few minutes
nycoif you optimised the first use journey, then very good, and congrats
Guusnyco 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 🙂
Guusyou / anyone that _does_ understand the context.
nycothe pixel, here! :)
GuusUX is not a democracy.
pep.You have 4 hours
nycosure, 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.)
Guusright. 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.
GuusI'm happy to accept suggestions, but you need to dumb it down for me 🙂
nycoright, I was showing the process
Guus(not sure if that goes for everyone here, by the way)
GuusBut I've long ago accepted that the world of UI / UX is not for me.
Steve Killehas left
Steve Killehas joined
nycothat's often the case for devs
nycothe funny thing is that old-style marketers feel like designers' user research is kind of the same as Marketing's "market research"
Dele (Mobile)has left
NeustradamusGe0rG: After a lot of efforts, Pidgin can be forgotten, no?
ZashWasn't a plan to have compliance buttons to shame Pidgin with?
Steve Killehas left
Steve Killehas joined
ChobbesIs 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 🙂