XSF Discussion - 2019-11-15

  1. andy has left

  2. stpeter has left

  3. krauq has joined

  4. stpeter has joined

  5. Kev has left

  6. Kev has joined

  7. alameyo has joined

  8. alameyo has left

  9. alameyo has joined

  10. alameyo has left

  11. stpeter has left

  12. alameyo has joined

  13. Chobbes has left

  14. pdurbin has joined

  15. stpeter has joined

  16. neshtaxmpp has left

  17. neshtaxmpp has joined

  18. pdurbin has left

  19. alameyo has left

  20. alameyo has joined

  21. alameyo has left

  22. stpeter has left

  23. UṣL has left

  24. debacle has left

  25. alameyo has joined

  26. alameyo has left

  27. alameyo has joined

  28. alameyo has left

  29. alameyo has joined

  30. david has left

  31. david has joined

  32. Chobbes has joined

  33. marc_ has left

  34. adiaholic has joined

  35. pdurbin has joined

  36. neshtaxmpp has left

  37. neshtaxmpp has joined

  38. pdurbin has left

  39. Chobbes has left

  40. Yagiza has joined

  41. Nekit has joined

  42. lovetox has joined

  43. andy has joined

  44. pdurbin has joined

  45. rion has left

  46. lovetox has left

  47. rion has joined

  48. j.r has joined

  49. LNJ has joined

  50. mimi89999 has left

  51. mimi89999 has joined

  52. karoshi has joined

  53. Seve


  54. winfried has left

  55. winfried has joined

  56. alexis has left

  57. alexis has joined

  58. alexis has left

  59. wurstsalat has joined

  60. alexis has joined

  61. lorddavidiii has joined

  62. neshtaxmpp has left

  63. LNJ has left

  64. neshtaxmpp has joined

  65. waqas has left

  66. intosi has left

  67. aj has joined

  68. neshtaxmpp has left

  69. Nekit has left

  70. Nekit has joined

  71. intosi has joined

  72. winfried has left

  73. winfried has joined

  74. aj has left

  75. winfried has left

  76. winfried has joined

  77. winfried has left

  78. winfried has joined

  79. mathijs has left

  80. mathijs has joined

  81. nyco

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

  82. intosi has left

  83. UṣL has joined

  84. Nekit has left

  85. MattJ

    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

  86. nyco

    I assume Apple will join when/if forced

  87. nyco

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

  88. nyco

    how can we add pictures on the wiki?

  89. Nekit has joined

  90. kokonoe has left

  91. winfried has left

  92. winfried has joined

  93. nyco has left

  94. edhelas has left

  95. mathijs has left

  96. mathijs has joined

  97. mimi89999 has left

  98. mathijs has left

  99. edhelas has joined

  100. mathijs has joined

  101. intosi has joined

  102. marc_ has joined

  103. kokonoe has joined

  104. kokonoe has left

  105. Ge0rG

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

  106. LNJ has joined

  107. Steve Kille has left

  108. Steve Kille has joined

  109. nyco has joined

  110. goffi has joined

  111. mimi89999 has joined

  112. jonas’

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

  113. jonas’

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

  114. kokonoe has joined

  115. jonas’

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

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

  117. Guus

    jonas’: I like that

  118. larma has left

  119. larma has joined

  120. jonas’

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

  121. jonas’

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

  122. Guus

    How many multi protocol clients do we currently list?

  123. jonas’

    I don’t know, maybe only pidgin?

  124. Seve

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

  125. jonas’

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

  126. Guus


  127. pep.

    Workarounds, workarounds everywhere \o/

  128. pep.


  129. Ge0rG

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

  130. pep.

    What is considered multi-protocol?

  131. jonas’

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

  132. jonas’

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

  133. pep.

    (I was going to ask)

  134. jonas’

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

  135. adiaholic has left

  136. adiaholic has joined

  137. Guus

    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.

  138. Dele (Mobile) has joined

  139. nyco

    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

  140. pep.

    you mean IRC features do?

  141. Guus

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

  142. nyco


  143. pep.

    Because multi-protocol means lowest common denominator

  144. nyco

    still, we (XSF) do want to keep neutrality

  145. pep.

    That's not what we want to keep neutrality for

  146. pep.

    I guess

  147. Guus

    Sure: jonas’ proposal doesn't hurt neutrality

  148. Guus

    it just splits the list in two helpful lists

  149. nyco

    why not? please explain

  150. Nekit has left

  151. Nekit has joined

  152. Guus

    XMPP-native clients, and multi-protocol clients.

  153. pep.

    nyco, because it doesn't discriminate on XMPP implementations

  154. nyco

    I don't get it

  155. Seve

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

  156. Guus

    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.

  157. Guus

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

  158. nyco

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

  159. pep.

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

  160. Guus

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

  161. nyco

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

  162. pep.

    Since when is xmpp.org about users?

  163. pep.

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

  164. Guus

    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.

  165. jonas’

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

  166. Ge0rG

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

  167. Guus

    pep. many people are very happy with Pidgin.

  168. pep.

    Ge0rG, I know..

  169. Ge0rG is still mad at a certain website editor about that.

  170. pep.

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

  171. nyco

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

  172. jonas’

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

  173. jonas’

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

  174. jonas’

    nyco, do they, though?

  175. jonas’

    or do they simply not know the difference?

  176. pep.

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

  177. pep.

    Not use pidgin

  178. nyco

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

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

  180. Guus

    Which is why I like Jonas' idea.

  181. nyco

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

  182. nyco

    this customer only uses XMPP in Pidgin

  183. Ge0rG

    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

  184. Guus

    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.

  185. jonas’

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

  186. jonas’

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

  187. Ge0rG

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

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

  189. jonas’

    (I probably just forgot)

  190. Ge0rG

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

  191. nyco

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

  192. Ge0rG

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

  193. mathijs has left

  194. jonas’

    nyco, which is why pidgin is a terrible choice

  195. Ge0rG

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

  196. Guus

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

  197. jonas’

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

  198. nyco


  199. nyco

    it's on the issues on GitHub

  200. nyco

    you can read it

  201. nyco

    it may be usefull for all clients developers here

  202. Guus


  203. jubalh has joined

  204. nyco

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

  205. Guus

    ok, I'm off to do work again

  206. mathijs has joined

  207. Guus

    thanks Jonas!

  208. pep.

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

  209. nyco

    the UX offered to users MUST NOT map the protocol

  210. nyco

    the criteria of single vs multi protocol is just irrelevant

  211. nyco

    for users

  212. Nekit has left

  213. nyco

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

  214. nyco

    Pidgin is great for users, please try to understand why

  215. pep.

    I guess we'll just agree to disagree

  216. nyco

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

  217. Ge0rG

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

  218. nyco


  219. nyco


  220. Ge0rG

    otherwise they can use notepad.exe

  221. nyco

    people use it

  222. nyco

    I repeat

  223. nyco

    people use it

  224. Ge0rG

    say what?

  225. nyco


  226. nyco

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

  227. jonas’

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

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

  229. jonas’

    but it should not be the default choice

  230. nyco

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

  231. nyco

    rather fix the UX of XMPP apps

  232. Seve

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

  233. nyco

    that seems a fair hypothesis

  234. pep.

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

  235. nyco

    please consider other hypothesis :)

  236. nyco


  237. nyco

    maybe they like better Jabber for many other reasons

  238. Ge0rG

    because they don't realize how broken it is

  239. nyco


  240. nyco

    so what?

  241. nyco

    if their experience is better than not feeling the brokenness

  242. pep.

    I don't understand this last message

  243. nyco

    do we _know_? who studied that? scientific research?

  244. nyco

    I know

  245. Nekit has joined

  246. Ge0rG

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

  247. nyco

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

  248. nyco

    in order to improve the situation

  249. nyco

    empirical is cool

  250. Ge0rG

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

  251. nyco

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

  252. nyco

    Ge0rG I guess so

  253. Ge0rG

    nyco: then please go on!

  254. nyco

    be my guest

  255. nyco

    I'd rather fix the XMPP apps

  256. nyco

    but that's my opinion

  257. Ge0rG

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

  258. nyco

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

  259. nyco


  260. Ge0rG

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

  261. Zash

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

  262. nyco

    zach great idea

  263. nyco

    Zash sorry

  264. Ge0rG

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

  265. nyco


  266. nyco

    MAM for Psi as well :)

  267. Ge0rG

    the pidgin carbons ticket is in elementary school now!

  268. nyco


  269. pep.

    Ge0rG, "but there are plugins"?

  270. pep.

    Isn't everything fixed via plugins?

  271. Ge0rG

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

  272. pep.

    Or that's what I heard.

  273. pep.

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

  274. nyco

    but still, users use Pidgin... :)

  275. Ge0rG

    nyco: and then they complain about xmpp being broken

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

  277. Ge0rG

    Pidgin is actively damaging the XMPP ecosystem's popularity

  278. Ge0rG

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

  279. pep.


  280. David Cridland

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

  281. j.r has left

  282. Ge0rG

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

  283. nyco

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

  284. pdurbin has left

  285. LNJ has left

  286. LNJ has joined

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

  288. Ge0rG

    pep.: send a message on login :|

  289. pep.

    A message? How do you force anything with that

  290. Ge0rG

    you can force the user.

  291. Zash


  292. pep.

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

  293. Ge0rG

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

  294. Ge0rG

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

  295. pep.

    That is so..

  296. pep.

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

  297. Zash

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

  298. pep.

    sasl2 when?

  299. Link Mauve

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

  300. pep.

    I saw it when it appeared

  301. winfried has left

  302. winfried has joined

  303. pep.

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

  304. pep.

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

  305. karoshi has left

  306. j.r has joined

  307. debacle has joined

  308. winfried has left

  309. winfried has joined

  310. nyco-2 has joined

  311. nyco

    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

  312. nyco

    not my opinion, basic UX research fundamentals

  313. nyco-2 has left

  314. nyco

    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

  315. pep.

    "unbiased" is a bit too much

  316. pep.

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

  317. Ge0rG

    everything is full of prejudices

  318. Guus

    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?

  319. David Cridland

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

  320. David Cridland


  321. Guus

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

  322. adiaholic has left

  323. nyco

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

  324. nyco

    they don't know what that is

  325. nyco

    they don't want to read

  326. nyco

    they don't want to learn

  327. nyco

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

  328. nyco

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

  329. nyco

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

  330. adiaholic has joined

  331. Ge0rG

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

  332. nyco

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

  333. nyco

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

  334. larma has left

  335. Holger

    * WhatsApp shows almost nothing of FunXMPP ...

  336. nyco

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

  337. Ge0rG

    Nothing is fun. Everything is sad.

  338. pep.

    WhatsApp is centralized and doesn't have the same problematics

  339. Holger

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

  340. pep.

    JID issues are very well related to federation

  341. pep.

    JID UX

  342. Holger

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

  343. pep.

    You can just skip this in a centralized system

  344. pep.

    Holger: sure, not always

  345. nyco

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

  346. pep.

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

  347. larma has joined

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

  349. pep.

    nyco: your second suggestion calls for centralization

  350. nyco

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

  351. pep.

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

  352. nyco

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

  353. Ge0rG

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

  354. Ge0rG

    of course not exposed over s2s

  355. pep.

    Ge0rG: sure

  356. pep.

    I guess we all have different targets

  357. Ge0rG

    moving targets.

  358. pep.

    That's yet another issue

  359. nyco

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

  360. nyco

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

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

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

  363. nyco


  364. nyco

    that, these, them: who?

  365. pep.

    I'm not talking about "XMPP protocol fans"

  366. pep.

    Your last message

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

  368. pep.

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

  369. 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?"

  370. David Cridland

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

  371. Guus

    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?

  372. Ge0rG

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

  373. Guus

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

  374. Ge0rG

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

  375. Ge0rG

    albeit, you know, "_Jabber_ ID"

  376. Guus

    Ge0rG that's what i don't understand

  377. Ge0rG

    Everything is horrible.

  378. Guus

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

  379. Guus

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

  380. Guus

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

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

  382. Holger

    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.

  383. !XSF_Martin

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

  384. Ge0rG

    Holger: for public rooms we already have MUC Search

  385. Guus

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

  386. Ge0rG

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

  387. Seve

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

  388. kokonoe has left

  389. Nekit has left

  390. Guus

    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)

  391. mathijs has left

  392. mathijs has joined

  393. Nekit has joined

  394. Guus

    This is the current "add groupchat" option

  395. Guus


  396. Seve

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

  397. Guus

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

  398. Seve


  399. Seve

    (Based on Slack of course)

  400. Guus

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

  401. mathijs has left

  402. mathijs has joined

  403. Seve

    nyco, maybe you can give your input here.

  404. andrey.g has left

  405. pdurbin has joined

  406. winfried has left

  407. Wojtek has joined

  408. winfried has joined

  409. pdurbin has left

  410. winfried has left

  411. winfried has joined

  412. andrey.g has joined

  413. debacle has left

  414. andrey.g has left

  415. Wojtek has left

  416. kokonoe has joined

  417. winfried has left

  418. winfried has joined

  419. andrey.g has joined

  420. debacle has joined

  421. andrey.g has left

  422. andrey.g has joined

  423. edhelas has left

  424. edhelas has joined

  425. edhelas has left

  426. edhelas has joined

  427. APach has left

  428. kokonoe has left

  429. jubalh has left

  430. nyco

    again, we have only done user research on the _problems_

  431. nyco

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

  432. nyco

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

  433. nyco

    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)

  434. jubalh has joined

  435. nyco

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

  436. jonas’

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

  437. nyco

    that represents three small iterations

  438. nyco

    we have not yet implemented it

  439. pep.

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

  440. Ge0rG

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

  441. pep.


  442. nyco

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

  443. jubalh has left

  444. Ge0rG

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

  445. pep.

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

  446. nyco

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

  447. Ge0rG

    larger clouds?

  448. Zash

    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.

  449. pep.

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

  450. nyco


  451. pep.

    My statement above stands even for larger crowds

  452. Wojtek has joined

  453. nyco

    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

  454. nyco


  455. nyco

    I generally don't understand what you mean pep.

  456. pep.

    I am also confused with your statements tbh..

  457. pep.

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

  458. adiaholic has left

  459. adiaholic has joined

  460. lovetox has joined

  461. nyco


  462. pep.

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

  463. nyco


  464. pep.

    It's the second time you say this

  465. pep.

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

  466. nyco


  467. Kev

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

  468. nyco

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

  469. nyco

    thx Kev

  470. pep.

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

  471. nyco

    to whatN?

  472. pep.

    Your last message..

  473. pep.


  474. nyco

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

  475. Ge0rG

    Oh... my...

  476. pep.


  477. pep.

    I think I'm done

  478. nyco

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

  479. Ge0rG

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

  480. Ge0rG puts some cookies into the channel

  481. Chobbes has joined

  482. nyco

    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

  483. nyco

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

  484. nyco

    and you iterate the best

  485. pdurbin has joined

  486. Ge0rG

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

  487. kokonoe has joined

  488. nyco

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

  489. nyco

    hint: no need for code

  490. nyco

    well, not always

  491. nyco

    hint: start with a paper and a pencil

  492. nyco

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

  493. Ge0rG

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

  494. Ge0rG

    ..from different ethnic groups and financial backgrounds

  495. nyco

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

  496. Ge0rG

    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

  497. nyco

    right, close friends/family are greatly biaised

  498. jubalh has joined

  499. nyco

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

  500. Ge0rG

    nyco: you'd be surprised.

  501. nyco

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

  502. Ge0rG

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

  503. Nekit has left

  504. nyco

    I know

  505. Nekit has joined

  506. nyco

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

  507. Guus

    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 🙂

  508. Guus

    you / anyone that _does_ understand the context.

  509. nyco

    the pixel, here! :)

  510. Guus

    well, yes.

  511. nyco


  512. Guus

    UX is not a democracy.

  513. pep.

    What is.

  514. pep.

    You have 4 hours

  515. nyco

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

  516. j.r has left

  517. pdurbin has left

  518. Guus

    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.

  519. j.r has joined

  520. Guus

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

  521. stpeter has joined

  522. nyco

    right, I was showing the process

  523. nyco


  524. nyco


  525. Guus

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

  526. Guus

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

  527. j.r has left

  528. j.r has joined

  529. stpeter has left

  530. Steve Kille has left

  531. kokonoe has left

  532. jubalh has left

  533. Nekit has left

  534. Steve Kille has joined

  535. kokonoe has joined

  536. j.r has left

  537. UṣL has left

  538. Nekit has joined

  539. nyco

    that's often the case for devs

  540. karoshi has joined

  541. nyco

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

  542. j.r has joined

  543. stpeter has joined

  544. alexis has left

  545. krauq has left

  546. krauq has joined

  547. kokonoe has left

  548. adiaholic has left

  549. adiaholic has joined

  550. pdurbin has joined

  551. karoshi has left

  552. Chobbes has left

  553. j.r has left

  554. pdurbin has left

  555. j.r has joined

  556. nyco-2 has joined

  557. nyco-2 has left

  558. stpeter has left

  559. stpeter has joined

  560. Dele (Mobile) has left

  561. Chobbes has joined

  562. ralphm has left

  563. waqas has joined

  564. stpeter has left

  565. stpeter has joined

  566. rion has left

  567. arc has left

  568. arc has joined

  569. ralphm has joined

  570. Chobbes has left

  571. Nekit has left

  572. mathijs has left

  573. mathijs has joined

  574. Nekit has joined

  575. mathijs has left

  576. mathijs has joined

  577. Nekit has left

  578. neshtaxmpp has joined

  579. Neustradamus

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

  580. Zash

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

  581. rion has joined

  582. rion has left

  583. rion has joined

  584. jubalh has joined

  585. mathijs has left

  586. mathijs has joined

  587. mathijs has left

  588. mathijs has joined

  589. rion has left

  590. j.r has left

  591. j.r has joined

  592. mathijs has left

  593. mathijs has joined

  594. lorddavidiii has left

  595. Chobbes has joined

  596. lorddavidiii has joined

  597. karoshi has joined

  598. j.r has left

  599. intosi has left

  600. arc has left

  601. arc has joined

  602. stpeter has left

  603. arc has left

  604. arc has joined

  605. pdurbin has joined

  606. pdurbin has left

  607. rion has joined

  608. rion has left

  609. Steve Kille has left

  610. david has left

  611. david has joined

  612. ralphm has left

  613. Steve Kille has joined

  614. mathijs has left

  615. mathijs has joined

  616. arc has left

  617. arc has joined

  618. rion has joined

  619. Yagiza has left

  620. Chobbes has left

  621. debacle has left

  622. mathijs has left

  623. mathijs has joined

  624. andy has left

  625. andy has joined

  626. remko has joined

  627. remko has left

  628. Chobbes has joined

  629. winfried has left

  630. winfried has joined

  631. winfried has left

  632. winfried has joined

  633. APach has joined

  634. lorddavidiii has left

  635. arc has left

  636. arc has joined

  637. arc has left

  638. arc has joined

  639. debacle has joined

  640. Wojtek has left

  641. APach has left

  642. mathijs has left

  643. mathijs has joined

  644. winfried has left

  645. winfried has joined

  646. pdurbin has joined

  647. APach has joined

  648. pdurbin has left

  649. Chobbes has left

  650. Chobbes has joined

  651. winfried has left

  652. winfried has joined

  653. sonny has left

  654. winfried has left

  655. winfried has joined

  656. sonny has joined

  657. j.r has joined

  658. j.r has left

  659. kokonoe has joined

  660. karoshi has left

  661. mathijs has left

  662. mathijs has joined

  663. Nekit has joined

  664. winfried has left

  665. winfried has joined

  666. patrick has joined

  667. kokonoe has left

  668. winfried has left

  669. winfried has joined

  670. winfried has left

  671. winfried has joined

  672. Nekit has left

  673. Chobbes

    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 🙂

  674. winfried has left

  675. winfried has joined

  676. Ge0rG

    Chobbes: here is a good place for that

  677. Chobbes


  678. alexis has joined

  679. winfried has left

  680. winfried has joined

  681. pdurbin has joined

  682. pdurbin has left

  683. Chobbes has left

  684. LNJ has left

  685. lovetox has left

  686. winfried has left

  687. Tobias has left

  688. arc has left

  689. arc has joined

  690. arc has left

  691. arc has joined

  692. patrick has left

  693. winfried has joined

  694. Douglas Terabyte has left

  695. Douglas Terabyte has joined

  696. andy has left

  697. andy has joined

  698. goffi has left

  699. matkor has left

  700. matkor has joined

  701. j.r has joined

  702. j.r has left

  703. j.r has joined

  704. Alex has left

  705. Alex has joined

  706. pdurbin has joined

  707. j.r has left

  708. j.r has joined

  709. pdurbin has left