jdev - 2023-04-17

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?

Each chat can have it's own window?

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

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

Guus: close it and offer "Undo" ?

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

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

so how is the tab "in the way"

we also have a tabbed interface

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

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

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

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

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

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

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

if hitting the same X for a single conversation works fine

and it pops up again on a new message

> 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

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

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

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

or are we talking about a browser client here?

https://share.hoerist.com/philipp/gJV9xDswhu5s1XhH/8c6cb360-76f5-4e9b-8673-3d735d5ba461.png

served us pretty well until now this UI

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

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

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

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

Sounds weird to me

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

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

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

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

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

my goal would be somehting like a universal search bar ✏

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

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

So maybe the issue is here not about preventing the closing

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

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

The feedback that I got was "computer illiterate users"

about what client we are talking?

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

Spark

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

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

↑ that

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.

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

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

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

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

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.

ack. Bookmarks should be roster entries.

Are you talking protocol or GUI

altough protocol wise its probably anyway out of the question

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

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

not useful for you, but may suit other users better

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

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

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

I was thinking of GUI.

yeah anyway, we talking about GUI

in what use case do i need a roster?

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

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

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

a search bar is way faster

again, faster for you with your preference for the keyboard

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

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

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

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

especially in the company setting, i often check a Department

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

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

and thats why the roster still exists in Gajim

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

its showable with one click, but hidden otherwise

all UI should stay out of your way until needed

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

also this would be an interesting XEP

something where i can query a Org Chart from the server

for a company setting, this is an essential feature

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

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

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

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

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

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

also at scale some things dont work anymore

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

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

pubsub for org chart?

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

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

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

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

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

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