Preventing Unwanted Button Presses

I haven't received my button or performed any testing yet, but I had a thought that I'd like to ask about. It occurs to me that in some types of environments, it could become a problem if buttons are being pressed when there isn't a problem to be addressed. Maybe it's an immature office prank, or a guest is messing with a user's button, or maybe the user accidentally puts a stack of paperwork on their button. That would generate invalid tickets and waste time on both ends of the process. I expect that most of these scenarios can be prevented using training and disciplinary measures, but I'm curious whether you've considered putting anything in place to prevent invalid button presses.

I've put a little bit of thought to it, but I haven't thought of anything more practical than a keyboard shortcut to disable/enable the button (which I imagine people would forget about), and a cover or piece of hardware to "lock" the button when it's not in use, like you might see on a fire alarm or panic button or something. Neither of those sound like particularly good fixes, and I don't even know how big of a problem accidental/malicious button presses will be. Maybe it's something to treat as a paid add-on of some kind for people who know they'll need something like that. I work with a number of schools, so I tend to think of things like this in terms of whether or not it poses an opportunity for someone to anonymously cause some seemingly-harmless trouble. I just figured I'd throw it out there.

What I've seen of the service and the software so far looks really good. I'm excited to put one of these bad buys out into the field to see what it can do!


  • I have the same concerns, @LevelUpMSP, mainly because a few of my clients are home based businesses (one client even asked me about her cat stepping on the button). The way I look at it is when the button is pressed it brings up the trouble reporting dialog and waits for user input (just got my buttons and haven't tested yet, though), so this should limit the amount of false/noise tickets.

    This is one of the things I'm going to be testing for specifically. One way I'm going to test it is by sticking a button on my 10 year olds desk and see how many button presses I get, lol. Between the cats, small dogs, and the general junk that gets plopped down on his desk there's bound to be a few random presses.

    But, the need for user input before sending should be a sufficient filter for most cases and provide protection of HIPPA & PIA leakage. Together with user training should greatly limit bad tickets.

    My plan if this is a problem: 1st offense - warning, 2nd offense - increase in fees, 3rd offense - removal of the buttons. Of course my MSA will be adjusted with the appropriate language provisions. What do you all think?

  • edited August 2019

    Hi guys, I think that you won't have to worry about this and will see why once you have your buttons. But to clarify, Hitting the button alone does not generate a ticket. It merely launches the interface and data aggregation process. Until the end user fills out their problem information and hits submit no data will be transferred off of their machine and no tickets will be generated. We do have a dashboard you can pull up though that will allow you to see the actual buttons clicks and if you have that open then you will be able to know a ticket is on the way in before the client even finishes submitting it. But you won't get anything into your ticketing system accidentally unless they have a very talented cat.

  • Thanks for the responses, @TeamRampage and @admin!

    Ugh. I left the context out of my initial post in the interest of keeping it brief, but the context is actually really important in this case. (And the little context I did provide isn't even the same scenario as the one that generated my question. I apologize, guys. That was really uncool.) I knew that the software is designed to only launch the interface, and that a ticket isn't generated without additional user input by default. My first attempt to test a button with a client is going to be to solve an accessibility problem for a disabled client who is essentially in a work-at-home environment, like the clients @TeamRampage referred to. I want to configure the software to perform some number of actions automatically without the need for further input from the user. The software appears to run scripts before the user submits the form, and as flexible as it is, I've been assuming that I can add actions to that script and hopefully even disable the launch of the interface to achieve the accessibility functions that I need. For that reason, I started working on how to avoid unwanted button presses, and that's what generated the question. Bypassing a primary function of the software is an obvious detail to include, so I should have thought that through better before posting.

    I expect the default behavior, as @admin implied, eliminates the vast majority of cases where a ticket is submitted without a valid cause. If the application calls for performing functions without additional input from the user, I'm curious whether anyone had considered any ways to prevent unwanted button presses. Another way to look at it would be to find a way to prevent the activity that @admin said can be seen from the dashboard, although it makes a lot more sense with the context that I left out. If you have any thoughts on this, or if it isn't possible in the first place, please let me know.

    Also, I received my buttons yesterday, and I have to say, they look really good! The design appears to be solid (clean lines, the individual parts don't shift as though they weren't secured properly, and nothing's rattling around when you move/shake it - I'm still amazed at the number of things of all costs I have that had a loose part in the case when I opened it new). I especially like the satin black finish on the bottom half of the buttons. Cheers to the hardware designer(s)!

  • Appreciate the feedback! That is an interesting use case. My initial gut on this is incredibly low tech......maybe get some double sided tape to secure the button to the base of the monitor or bezel in some way so that it is off of the desk. Beyond that? For intentional aggressive presses? I dunno, maybe someone is being held hostage, should probably investigate.

  • Thanks for the input, @ApermenterT2T! I think something like that could work. The way the buttons are designed, you could probably secure it to a surface (desk, monitor, etc.) using any number of ways. The cable on the button I measured is about 5' long, giving the user lots of mounting options.

    My case is pretty specific, and it doesn't appear the buttons were designed with this kind of application in mind, so I don't want to lead anyone to believe that this is something the software is supposed to do, but doesn't. That said, there may be other reasons to prevent unwanted button presses. Following the line of thinking that end users are lazy, it's not too difficult to imagine some users having a messy desk and getting irritated with having to close the interface every time they move stuff around and something hits the button. The end users won't be sensitive to the branding aspect of the button, so some number of them will probably want to mount their button out of the way, like on the back of their monitor, on on the top of workstation under the desk, etc.

    I know the application I'm describing bypasses a primary function and safeguard, but I have a number of clients who are able enough that they use their computers, but have one or more disabilities preventing them from using it effectively. Hence, the accessibility angle. If you know, or can find out, whether any of the following are supported or even possible, it would be super helpful:

    • Disable the interface launch after the button is pressed, but still perform a number of actions (including submitting a ticket)
    • Add scripts/actions to be executed after the button is pressed but before the interface is launched
    • Executed by a button press: run the appropriate script(s) and then display a confirmation pop-up that auto-closes after maybe 5 seconds (this is the fundamental function I'm after for my accessibility clients)

    Thanks again!

    • Disable the interface launch after the button is pressed, but still perform a number of actions (including submitting a ticket)

    As a software dev, I can tell you this is definitely possible, but with some considerable (I assume considering the implementation) modifications to the client builds. It might be possible, from a UX standpoint, to provide this functionality as an option in the build process - but that would depend on factors such as vision for the product/UX, future planned/considered features, details of implementation, and a few other things that I can't think of right now.

    • Add scripts/actions to be executed after the button is pressed but before the interface is launched

    As far as I know, this is something that can be done currently.

    • Executed by a button press: run the appropriate script(s) and then display a confirmation pop-up that auto-closes after maybe 5 seconds (this is the fundamental function I'm after for my accessibility clients)

    Again, this depends on several factors that only the dev team can properly comment on.

    With all of that said, the functionality you're describing could be a great addition for a subset of the end users. Whether or not the work needed to implement these features is warranted, that depends on the market need to justify the business case for the resource demand of including it. Of course, I could be totally wrong and one of the devs could look at this and be like: "Hey, I totally had this in mind when I coded that module and it wouldn't too big of a deal to implement!" - though that's not very likely.

    At any rate, I like the idea you had of attaching the buttons to the back of the monitors! Definitely would need to be included in the client documentation and end user trainings, but that's a great idea to get around the problem of messy desks and false button presses! If the cable length is an issue, I can't imagine an extender would be too big of an obstacle (for the plain buttons anyway). I did give feedback on the back of the buttons being counter sunk a bit and how that could be a bit of an issue when mounting the buttons (my prefered way to mount the buttons on a vertical surface is with Command Strips, less surface damage/easy to remove when the time comes).

    I'm really glad I jumped into this thread, great discussion! Thanks all!

  • Thanks for following up, @TeamRampage!

    And thank you for your very frank answer on the interface bypass. It's not hard to imagine it being practical to add a setting (for an admin) to bypass the interface launch, and I can imagine more than a couple of scenarios where it would be useful. But like you said, whether it's a good idea or worth the development/implementation/maintenance costs it is another matter. I expect to have some time this weekend to start messing around with it in earnest, so I'm hoping to learn a lot more then. Until then, I'll leave my questions about whether it makes sense to install underwater or on a lunar rover to my notes!

    Regarding sticking the buttons on the backs of monitors, this is another of many smaller things that will take time to learn more about. I imagine users will, broadly speaking, want the button connected and at the ready at all times, but to never see it when they don't need it. That said, I'm not nuts about the "out of mind" effect of being out of sight.

    I agree with your preference for Command strips, but I can imagine several different products that should work fine, as long as the adhesive sticks to the soft-textured bottom of the button. It looks like the recess on the bottom of the button is about 1/16" deep, so something like this should work. At 3mm, it's about twice as thick as the recess is deep. If that's too close a call, and you're worried about someone cracking their monitor trying to get the button really stuck well, you could double-stack them or go with a hook and loop alternative, which should buy you another mm or so of depth. There are probably solutions that fit the buttons better or have better adhesive that can reliably be removed without leaving a mark, but I'd be comfortable using either of the two linked options tomorrow.

    The buttons barely weigh anything, so as long as the cable isn't pulled too tight, stressing the adhesive as well as the solder/connection between the cable and the board, I would think any number of options like the two I linked above would work well. I don't know what the four holes on the bottom of the simple button are for, but I suspect they're used in the assembly process. Assuming they aren't needed after manufacture, it might be cool to have an optional plate that snaps into those holes and provides a piece of 2" double-sided tape for the user to mount to whatever makes sense for their application. Just a thought.

    I'll check back in when I've made more progress. Thanks again!

  • Nice options for sticking the buttons to the monitor, @LevelUpMSP! Imma bookmark those and keep them in mind! Thanks for the links, and look forward to you findings!


    BTW, your lunar rover question might be interesting! Lol

Sign In or Register to comment.