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?
lovetox
Each chat can have it's own window?
Beherithas joined
Schimon_has left
Schimon_has joined
Guus
No, they're tabs. I'm assuming that they are auto-joining one MUC.
Guus
or is your suggestion: allow them to be separate windows?
Kevhas joined
Dele Olajidehas joined
wurstsalat
Guus: close it and offer "Undo" ?
antranigvhas joined
lovetox
Guus, User says, "The Window is in the way"
lovetox
but you say its not a window, its one tab in a single window application?
lovetox
so how is the tab "in the way"
lovetox
we also have a tabbed interface
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?"
lovetox
But as said i think i dont understand the problem, because a Tab is never in the way of anything
lovetox
there is zero reason to close a tab, other than "im not interested anymore in this conversation"
Guus
That is part of my unease: preventing a user from doing something that they intend to do will be counterproductive.
lovetox
thats the problem, you dont know what the user intends, he is not aware of the consequence
Kev
Make leaving the MUC an explicit step, not triggered by closing the window.
lovetox
How would a user come to the conclusion that hitting X does mean that he never gets notified about new messages anymore
lovetox
if hitting the same X for a single conversation works fine
lovetox
and it pops up again on a new message
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
lovetox
and pop it up on next message, the same as in single conversations
SouLhas left
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
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
> 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.
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).
marc0shas left
marc0shas joined
Guus
This smells like "we want users to keep open a UI element in case they will ever need it somewhere during the day"
SouLhas joined
atomicwatchhas joined
lovetox
Why does the user not know how to start a conversation?
atomicwatchhas left
lovetox
Sounds weird to me
atomicwatchhas joined
lovetox
A MUC, is just a conversation like any other, just with more people
atomicwatchhas left
lovetox
it should be same UI element button: "Start a Conversation"
atomicwatchhas joined
atomicwatchhas left
lovetox
and when clicked he should be able to search for some keyword or name, or contact
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
lovetox
but yeah these are the same pains we have gone through with the old Gajim design
atomicwatchhas left
lovetox
strict separation of MUC and Single conversation, different ui buttons, different workflows
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
lovetox
my goal would be somehting like a universal search br✎
lovetox
my goal would be somehting like a universal search bar ✏
atomicwatchhas joined
atomicwatchhas left
lovetox
simply a field where the user types something and i show him all the possible stuff
lovetox
so he just have to remember the name of the groupchat and can open it whenever he wants
atomicwatchhas joined
atomicwatchhas left
lovetox
So maybe the issue is here not about preventing the closing
atomicwatchhas joined
atomicwatchhas left
lovetox
its probably a hint, that its not easily clear from the UI how to open groupchats
lovetox
maybe the user needs to understand the concept of a groupchat before he can understand the UI to open one
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
SouLhas left
Vaulorhas left
Vaulorhas joined
SouLhas joined
marc0shas left
marc0shas joined
archiwistkaapokalipsyhas left
archiwistkaapokalipsyhas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
guus.der.kinderen
The feedback that I got was "computer illiterate users"
lovetox
about what client we are talking?
lovetox
maybe i give it a testrun to see if i can find what they mean
Laurahas left
Guus
Spark
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"
marc0shas left
marc0shas joined
norayrhas joined
Mx2has left
Schimon_has left
Yagizаhas left
paulhas joined
Maranda[x]has left
Ingolf[m]has left
Marandahas left
Mjolnir Archonhas left
techmetx11has left
PapaTutuWawahas joined
ralphmhas joined
Yagizаhas joined
Laurahas joined
Yagizаhas left
Yagizаhas joined
Yagizаhas left
Yagizаhas joined
Maranda[x]has joined
marc0shas left
marc0shas joined
sonnyhas left
sonnyhas joined
Mx2has joined
wurstsalathas left
wurstsalathas joined
techmetx11has joined
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
singpolymahas left
singpolymahas joined
techmetx11has left
techmetx11has joined
singpolymahas left
flow
↑ that
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.
singpolymahas joined
Vaulorhas left
SouLhas left
SouLhas joined
Vaulorhas joined
homebeachhas left
Matrix Traveler (bot)has left
homebeachhas joined
Matrix Traveler (bot)has joined
singpolyma
Ge0rG: that sounds like what happens when someone adds to roster by mistake. We've finally made that impossible in latest Cheogram Android
Ge0rG
singpolyma: yeah, it's quite a nuisance for xmpp newbies
Vaulorhas left
SouLhas left
SouLhas joined
singpolyma
Yeah. I'm not sure if there will be any strange side effects to our approach but so far it is working
Vaulorhas joined
singpolyma
I just unified join MUC with add contact so there is only one place to put a jid, then DTRT
nicocohas left
nicocohas joined
PapaTutuWawahas left
rubihas left
rubihas joined
singpolymahas left
marc0shas left
marc0shas joined
singpolymahas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
sonnyhas left
sonnyhas joined
heartyhas left
heartyhas joined
theTeddhas joined
heartyhas left
heartyhas joined
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.
snowhas joined
Schimon_has joined
Guus
ack. Bookmarks should be roster entries.
Schimon_has left
Schimon_has joined
edwinmhas joined
PapaTutuWawahas joined
Schimon_has left
Schimon_has joined
jgarthas joined
lovetox
Are you talking protocol or GUI
_roothas left
theTeddhas left
theTeddhas joined
lovetox
altough protocol wise its probably anyway out of the question
theTedd
gui, which is why avoided using the term 'roster'
_roothas joined
lovetox
and GUI wise, i have the opinion that something like a "roster" is not that useful
theTedd
not useful for you, but may suit other users better
lovetox
that implied, i dont speak for all humanity if you got that impression
MSavoritias (fae,ve)
> altough protocol wise its probably anyway out of the question
why? is it compatibility reasons? ↺
lovetox
if you write a new roster spec, i guess you would leave many clients behind
guus.der.kinderen
I was thinking of GUI.
lovetox
yeah anyway, we talking about GUI
lovetox
in what use case do i need a roster?
lovetox
the most i hear is, "i want to see who is available, before i start chatting "
lovetox
basically like, i dont know who i want to write, im just checking who is available and choose afterwards
lovetox
because in every case where i *know* who i want to talk to, a roster is useless
lovetox
a search bar is way faster
edwinmhas left
theTedd
again, faster for you with your preference for the keyboard
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.
guus.der.kinderen
"see who of your friends is online" was useful when people were not online 24/7.
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
theTeddhas left
theTeddhas joined
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
lovetox
especially in the company setting, i often check a Department
lovetox
and check who is online, because i need *someone* from that department
lovetox
thats the only use case which i hear often which i agree with
lovetox
and thats why the roster still exists in Gajim
lovetox
But its not a prominent UI element which you have *all the time* on the screen
lovetox
its showable with one click, but hidden otherwise
theTedd
all UI should stay out of your way until needed
lovetox
because i think its a valid use case, but one you dont need 20 times a day
lovetox
also this would be an interesting XEP
lovetox
something where i can query a Org Chart from the server
lovetox
for a company setting, this is an essential feature
theTeddhas left
theTeddhas joined
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
jgarthas left
lovetox
though i guess xmpp has anyway no big chances in company settings
PapaTutuWawahas left
theTedd
maybe this is the One Thing™ XMPP needs to be launched into mainstream usage
PapaTutuWawahas joined
stuart.j.mackintoshhas left
Guus
hah. Spark's usage is 99% company setting.
theTeddhas left
theTeddhas joined
Guus
exactly like that: tied to some directory service, having roster entries grouped by departments, etc.
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
lovetox
also at scale some things dont work anymore
lovetox
if a company has a roster of 3000 people, a scrollable list ist not good UI anymore
Guus
True. People tend to use rosters restricted to the same deparment, augmented with some 'general purpose' groups - but that could be improved on.
guus.der.kinderenhas left
theTedd
pubsub for org chart?
lovetox
the problem is probably less the how the org chart is sent, more how does someone maintain it.
lovetox
actually i have no idea how my company does it with MS Teams
theTedd
they can use whatever format, then a component publishes it to pubsub
lovetox
i guess AD has fields for department and parent-department?
marc0shas left
lovetox
in reality you probably want to connect to some service where companys maintain there org chart
marc0shas joined
lovetox
and simply convert this to xml and send it to the client