XSF logo 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 https://liliputing.com/2019/11/google-enables-rcs-messaging-for-us-smartphones-without-any-carrier-help.html
  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 Yeah
  127. pep. Workarounds, workarounds everywhere \o/
  128. pep. :P
  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 agree
  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 yes
  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 cool
  219. nyco so?
  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 wat
  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 also
  237. nyco maybe they like better Jabber for many other reasons
  238. Ge0rG because they don't realize how broken it is
  239. nyco maybe
  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 wat
  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 hehehe
  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. :D
  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 SASL2?
  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 "deeply".
  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 wat
  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 https://igniterealtime.org:443/httpfileupload/908ca3e5-059f-43bb-8299-a312ab0529fd/image.png
  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 yes
  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. :D
  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 wat
  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 wat
  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 wat
  462. pep. "if we target protocol fans, or whatever you name us, the XMPP/Jabber community..." what does that mean
  463. nyco wat
  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 What???
  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. #contextishard
  474. nyco > thx Kev ? :) THAT's a troll :)
  475. Ge0rG Oh... my...
  476. pep. whatever..
  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 hehehe
  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 ok
  524. nyco clear
  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