jdev - 2023-04-17

  1. Guus

    I am getting a feature request to modify our chat client to avoid a window from being closed when the corresponding UI action is performed (typically: hit a X button in a top corner of a dialog). The rationale for the request is that while MUCs are joined automatically (auto-join bookmark), users aren't computer-literate enough to re-open the chat room when they accidentally close a window, or after they closed it because "it was in the way". I desperately do not want to override default window behavior (apart from maybe an 'are you sure' prompt). I'm not sure if we can make reopening a bookmarked MUC easier, as we have a first-level menu named 'bookmarks' that ... lists all bookmarks. Thoughts?

  2. lovetox

    Each chat can have it's own window?

  3. Guus

    No, they're tabs. I'm assuming that they are auto-joining one MUC.

  4. Guus

    or is your suggestion: allow them to be separate windows?

  5. wurstsalat

    Guus: close it and offer "Undo" ?

  6. lovetox

    Guus, User says, "The Window is in the way"

  7. lovetox

    but you say its not a window, its one tab in a single window application?

  8. lovetox

    so how is the tab "in the way"

  9. lovetox

    we also have a tabbed interface

  10. lovetox

    and we offer the user a config option, that if he closes a MUC tab it shows a warning "If you close this you will leave the MUC, are you sure?"

  11. lovetox

    But as said i think i dont understand the problem, because a Tab is never in the way of anything

  12. lovetox

    there is zero reason to close a tab, other than "im not interested anymore in this conversation"

  13. Guus

    That is part of my unease: preventing a user from doing something that they intend to do will be counterproductive.

  14. lovetox

    thats the problem, you dont know what the user intends, he is not aware of the consequence

  15. Kev

    Make leaving the MUC an explicit step, not triggered by closing the window.

  16. lovetox

    How would a user come to the conclusion that hitting X does mean that he never gets notified about new messages anymore

  17. lovetox

    if hitting the same X for a single conversation works fine

  18. lovetox

    and it pops up again on a new message

  19. lovetox

    > Make leaving the MUC an explicit step, not triggered by closing the window. Thats the second solution, you dont leave the muc, just hide the window

  20. lovetox

    and pop it up on next message, the same as in single conversations

  21. lovetox

    but i can tell you now, that then you will get a feature request that says, i want to leave a muc on hitting X :D

  22. lovetox

    But i dont understand why you talk about "Window behavior", a tab is not a Window, usually a Tab is a UI element from your GUI Framework, and it has a button, like other UI elements

  23. lovetox

    or are we talking about a browser client here?

  24. lovetox


  25. lovetox

    served us pretty well until now this UI

  26. Kev

    > But i dont understand why you talk about "Window behavior", a tab is not a Window, usually a Tab is a UI element from your GUI Framework, and it has a button, like other UI elements Historically, chats were windows. Then they were openable in tabs or windows, but the term 'chat window' has somewhat persisted amongst the old farts like me.

  27. Guus

    I'm not even sure that these particular users would care about receiving messages or not (leaving or not leaving the MUC when closing the chat UI element. I'm being told that some point in the future, when they _do_ need to use the (now closed) chat to send a message, they're unable to do so (because they do not know how to re-open the chat).

  28. Guus

    This smells like "we want users to keep open a UI element in case they will ever need it somewhere during the day"

  29. lovetox

    Why does the user not know how to start a conversation?

  30. lovetox

    Sounds weird to me

  31. lovetox

    A MUC, is just a conversation like any other, just with more people

  32. lovetox

    it should be same UI element button: "Start a Conversation"

  33. lovetox

    and when clicked he should be able to search for some keyword or name, or contact

  34. lovetox

    but yeah these are the same pains we have gone through with the old Gajim design

  35. lovetox

    strict separation of MUC and Single conversation, different ui buttons, different workflows

  36. lovetox

    my goal would be somehting like a universal search br

  37. lovetox

    my goal would be somehting like a universal search bar

  38. lovetox

    simply a field where the user types something and i show him all the possible stuff

  39. lovetox

    so he just have to remember the name of the groupchat and can open it whenever he wants

  40. lovetox

    So maybe the issue is here not about preventing the closing

  41. lovetox

    its probably a hint, that its not easily clear from the UI how to open groupchats

  42. lovetox

    maybe the user needs to understand the concept of a groupchat before he can understand the UI to open one

  43. guus.der.kinderen

    The feedback that I got was "computer illiterate users"

  44. lovetox

    about what client we are talking?

  45. lovetox

    maybe i give it a testrun to see if i can find what they mean

  46. Guus


  47. lovetox

    hm, somethings wrong, i installed the .deb on ubuntu, but it doesnt matter which server i put in it always says "CertPath validation failed"

  48. singpolyma

    I'm using gajim 0.13.x and it has a nice feature for this case where MUC does not leave when I close window but appears as an entry in roster. Really, IMO, bookmarks are roster entries from a UX PoV so this makes sense

  49. flow

    ↑ that

  50. Ge0rG

    reminds me of that feature of Gajim where it would _actually_ add MUCs to your roster, and then you auto-join with GC1.0 on connect and the room UI is replaced with a direct chat UI and you can't join the room because it's in your roster.

  51. singpolyma

    Ge0rG: that sounds like what happens when someone adds to roster by mistake. We've finally made that impossible in latest Cheogram Android

  52. Ge0rG

    singpolyma: yeah, it's quite a nuisance for xmpp newbies

  53. singpolyma

    Yeah. I'm not sure if there will be any strange side effects to our approach but so far it is working

  54. singpolyma

    I just unified join MUC with add contact so there is only one place to put a jid, then DTRT

  55. theTedd

    Guus, I suspect from these users' point of view, the way to open a chat is to click on a contact from the list; anything that's hidden behind a menu doesn't exist. So, I would show a "Groupchats" or "Rooms" group in the contacts list and insert all bookmarks into it, maybe with some indication of which are currently joined. Additionally, a confirmation dialog on closing a muc window, with options: close tab, leave room, cancel.

  56. Guus

    ack. Bookmarks should be roster entries.

  57. lovetox

    Are you talking protocol or GUI

  58. lovetox

    altough protocol wise its probably anyway out of the question

  59. theTedd

    gui, which is why avoided using the term 'roster'

  60. lovetox

    and GUI wise, i have the opinion that something like a "roster" is not that useful

  61. theTedd

    not useful for you, but may suit other users better

  62. lovetox

    that implied, i dont speak for all humanity if you got that impression

  63. MSavoritias (fae,ve)

    > altough protocol wise its probably anyway out of the question why? is it compatibility reasons?

  64. lovetox

    if you write a new roster spec, i guess you would leave many clients behind

  65. guus.der.kinderen

    I was thinking of GUI.

  66. lovetox

    yeah anyway, we talking about GUI

  67. lovetox

    in what use case do i need a roster?

  68. lovetox

    the most i hear is, "i want to see who is available, before i start chatting "

  69. lovetox

    basically like, i dont know who i want to write, im just checking who is available and choose afterwards

  70. lovetox

    because in every case where i *know* who i want to talk to, a roster is useless

  71. lovetox

    a search bar is way faster

  72. theTedd

    again, faster for you with your preference for the keyboard

  73. guus.der.kinderen

    > basically like, i dont know who i want to write, im just checking who is available and choose afterwards > This was the dominant usage model when xmpp was conceived, but probably not any more.

  74. guus.der.kinderen

    "see who of your friends is online" was useful when people were not online 24/7.

  75. theTedd

    it depends on the purpose of the chat at the time - some hats have a specific purpose/query, others are for the sole purpose of chatting to whoever

  76. theTedd

    and if it's a non-emergency query then you don't necessarily need an immediate response, while chatting to someone who isn't present isn't much use

  77. lovetox

    especially in the company setting, i often check a Department

  78. lovetox

    and check who is online, because i need *someone* from that department

  79. lovetox

    thats the only use case which i hear often which i agree with

  80. lovetox

    and thats why the roster still exists in Gajim

  81. lovetox

    But its not a prominent UI element which you have *all the time* on the screen

  82. lovetox

    its showable with one click, but hidden otherwise

  83. theTedd

    all UI should stay out of your way until needed

  84. lovetox

    because i think its a valid use case, but one you dont need 20 times a day

  85. lovetox

    also this would be an interesting XEP

  86. lovetox

    something where i can query a Org Chart from the server

  87. lovetox

    for a company setting, this is an essential feature

  88. lovetox

    you can mimic it with roster groups, though in company settings, roster comes from AD and i dont think that any company can or does build there Org chart in AD

  89. lovetox

    though i guess xmpp has anyway no big chances in company settings

  90. theTedd

    maybe this is the One Thing™ XMPP needs to be launched into mainstream usage

  91. Guus

    hah. Spark's usage is 99% company setting.

  92. Guus

    exactly like that: tied to some directory service, having roster entries grouped by departments, etc.

  93. lovetox

    yeah, i would like some XEPs targeting that use case, if a server sends me a org chart i can provide way better UI than roster groups

  94. lovetox

    also at scale some things dont work anymore

  95. lovetox

    if a company has a roster of 3000 people, a scrollable list ist not good UI anymore

  96. Guus

    True. People tend to use rosters restricted to the same deparment, augmented with some 'general purpose' groups - but that could be improved on.

  97. theTedd

    pubsub for org chart?

  98. lovetox

    the problem is probably less the how the org chart is sent, more how does someone maintain it.

  99. lovetox

    actually i have no idea how my company does it with MS Teams

  100. theTedd

    they can use whatever format, then a component publishes it to pubsub

  101. lovetox

    i guess AD has fields for department and parent-department?

  102. lovetox

    in reality you probably want to connect to some service where companys maintain there org chart

  103. lovetox

    and simply convert this to xml and send it to the client