Upfront - I am not a programmer but do work IT as a systems engineer. I have very little experience messing with code for java.
I have found a few previous posts about editing chatcontainer.java to remove or change the function of the big red “x” to close the chat window.
I’ve downloaded the spark.master from github and have changed chatcontainer.java but I have no idea how to compile this into… a new installer? Or preferably, if possible, is this something I can extract and change on an already installed instance of Spark? I want to remove the ability to close chat windows on all of the clients in my environment(about 100 workstations).
I’m not sure if this is feasible - and if it is, if it is desirable to have in the standard product. In anything but a very specific environment, this could lead to an unlimited amount of open chat windows.
As this seems to be a feature that’s specific to your organisation, I would suggest that you reach out to organisations that are listed in our directory of professional partners: Ignite Realtime: Support - Professional Partners
I think the author of this thread would have been fine with the “X” button remaining, but instead of closing the window, clicking on that button minimized that tabbed window. After all, it’s really not convenient when you just accidentally close the window with all open tabs and then start restoring them again. And in the organization, many “hamsters” do this, and then say that they missed an important message not intentionally, but simply because they “accidentally” closed the window. Very, very useful functionality.
I already asked (here, here and here), who knows how, to recompile the library in the next topic, but …
In my small organization we use Spark for several things, but my primary concern is it is our “IT Helpdesk support request” service.
We have a specific conference room that is auto-joined and everything is great with this. My problem is when the less computer literate(over half of my user base) use our workstations they close the Spark Chat(chatcontainer) because “it’s in their way”. And then they require IT support and they cannot figure out what happened to their spark chat window/they dont know how to rejoin a conference they closed out of.
In the end, I would be fine with the red “X” staying and a change of its function to minimize the chatbox instead would be perfectly acceptable.
I can definitely see how this would be a nice addition. Sadly, for my situation I need the end user to never be able to close the chat window(at least for 1 specific conference, our IT Support Request conference). On my environment, it’s all group work. I have actually disabled normal users(my students) from doing DMs, and they cannot join any other conferences other than those that I’ve dictated to them for their courses.
My problem is my non-tech savy instructors who do not know how to/cannot remember even when retaught several times how to rejoin conferences when they accidentally(or on purpose) close the chat windows and leave the conferences.
I do not believe that attempting to modify the UI in such a way that it prevents its intended purpose (close a UI element) is a good idea. It is counter-intuitive. We shouldn’t mess with the most basic of computer UI functionality: “pressing ‘x’ closes something”. That’s bad practise. It is also a solution. It is a (bad) workaround for some kind of other problem that originated elsewhere.
When clicking on a ‘close this element’ button, that is what users in that particular point in time are looking to do. Trying to prevent them from doing that will lead to end-user frustration, as they believe that this element is ‘in the way’ and want to get rid of it. Even if we anticipate that they will regret this decision in the future, it is what they are currently are trying to do. (To guard against accidental UI interaction, we could add some kind of ‘are you sure?’ prompt, perhaps augmented with an instruction on how to re-open the chat, if needed).
I am not even sure if it is possible to technically implement overriding the ‘close’ handler, given that these are pretty low-level UI events).
Perhaps we can think about ways to make it easier for users to find/reopen a particular chat?
Another suggestion would be to modify Spark in such a way that ‘bookmarks’ become part of the contact list. From a user’s perspective, there is little difference between a one-on-one chat with someone on the contact list, and a group chat. Spark’s UI is very 2006 in this respect.
You’re right, it is a bad workaround for a problem that I cannot solve. This specific problem is users don’t give a crap and click everything they can… especially when they barely know what a computer is.
Generally speaking, I agree. Changing the function of the big ol’ “RED X” normally isn’t the greatest idea.
I am not in a normal environment and do not have “general audiences” to consider. I am a completely air-gapped environment that is giga-strict on what we allow our users/instructors to do on our environment. Sometimes, users want to do stupid stuff - and in my environment when they do stupid stuff I stop them from even having the opportunity to do said stupid stuff again.
They want to close out of Spark chat and then cry for help(repeatly, several times a week) - I need to remove their power to close said window. This isn’t their computer/workstation. This is my network that they use.
I hope that makes sense on why I am ok with accepting the “bad workaround” for my situation. I just need guidance on what to do to recompile the application with my said changes - specifically in chatcontainer.java