Bugzilla – Bug 12848
New Diagnostic: Play a test tone when wireless signal low
Last modified: 2009-09-08 09:28:28 UTC
When dealing with wireless signal issues, it's very difficult to get solid feedback from the user. Firstly, they frequently just don't believe us. (their wifi works with their laptop, so it can't _possibly_ be the problem, right?) Second, we dealing with something not only invisible it's hard to measure even if you know what you're doing. So, I propose the following: * Create a new option at the bottom of Diagnostics called "Audio Feedback" (or simply "debugging" if you prefer.) * When Audio Feedback is ON, two things can trigger the playing of an audio cue over the speakers or audio outs. That cue could either be a generated tone or a canned waveform. It just needs to be audible and distinct. The triggers are: 1. When the WiFi signal is lost entirely 2. When the WiFi signal drops below a defined threshold This will allow us to easily test and prove that a user is dealing with wireless issues, rather than some other unknown. Plus it can inform the user specifically when and how frequently these events are happening, so they may correlate it to something in their environment. This should be implemented for all SqueezePlay-based devices, and if feasible backported to older players as well.
(In reply to comment #0) > * When Audio Feedback is ON, two things can trigger the playing of an audio > cue over the speakers or audio outs. That cue could either be a generated tone > or a canned waveform. It just needs to be audible and distinct. The triggers > are: > > 1. When the WiFi signal is lost entirely > 2. When the WiFi signal drops below a defined threshold Could you quantify that threshold? Is the primary purpose of this to prove to a customer that they are out of range? If so, how is that different than telling the customer to simply move the player within range and compare audio dropouts? Do we really need a debug mode for this, wouldn't proper error messaging be a better fix? I like the concept of this bug, I feel your pain about the "it couldn't possibly be my wireless network you're crazy" sentiment, but I'm not sure a test tone will help the situation. I think I would prefer to see some sort of showbriefly message saying something like "WARNING: wireless signal is below recommended streaming requirement, this could result in your music not streaming consistently." You probably have a better idea for the specific error message(s); I just like the idea of a message the user can read that is on the screen when problems occur so the user doesn't need to call your team, but simply read, to have a clear idea of the problem.
The problem with an error message on the screen is it presumes you're looking at the screen. Most users won't be when these dropouts occur-- they'll be in the kitchen listening to music or elsewhere. Granted, I'm all for appropriate error messages. (see bug 11314) This will be a solid proof that we're dealing with wifi issues to both the customer and to us. Also, it will help narrow down the cause. For example, a user is listening to music and hears issues, they call Support and as a result turn ON Audio Feedback. (or they read a FAQ or forums and do this.) * If the music stops or becomes choppy and they hear the tone then *Aha!* we know for sure we're dealing with wireless signal issues. (range or interference.) * If instead the music stops or becomes choppy and there's no tone, then we're dealing with something else-- a firewall, ISP weirdness, router flakiness, etc. This gives us another tool to narrow down what exactly we're dealing with, removing some of the guesswork. As far as what the threshold should be for "low signal" that's something we'd need to discuss and agree on.
(In reply to comment #2) > The problem with an error message on the screen is it presumes you're looking > at the screen. Most users won't be when these dropouts occur-- they'll be in > the kitchen listening to music or elsewhere. Granted, I'm all for appropriate > error messages. (see bug 11314) > > This will be a solid proof that we're dealing with wifi issues to both the > customer and to us. Also, it will help narrow down the cause. For example, a > user is listening to music and hears issues, they call Support and as a result > turn ON Audio Feedback. (or they read a FAQ or forums and do this.) Really? When music stops playing people don't look at the music player? Call me crazy but the first thing I do when a music playing gizmo stops playing music is look at it. I'll change this to an enhancement and ask that you attach a tone you'd like and some specifics. Could you use Controller and quantify an SNR or wireless signal strength percentage, as well as other details you'd like to see in your debug mode like does it interrupt music and what sort of on screen messages you'd like. > * If the music stops or becomes choppy and they hear the tone then *Aha!* we > know for sure we're dealing with wireless signal issues. (range or > interference.) > > * If instead the music stops or becomes choppy and there's no tone, then we're > dealing with something else-- a firewall, ISP weirdness, router flakiness, etc. > > This gives us another tool to narrow down what exactly we're dealing with, > removing some of the guesswork. Aside from wireless signal strength not working, doesn't the diagnostic screen already cover this completely? Granted wireless signal doesn't have feedback there at the moment but it should for MP. It already shows if it can't reach DNS / SN, as well as TCP ports. This covers the difference between wifi range issues, Internet access and DNS issues, as well as firewall.
Dan, I think this is an excellent, perhaps brilliant (depending on how well it works), recommendation. Ross, a couple things to keep in mind: - unless I'm mistaken, this would be used almost exclusively after a customer care call, where the user has already experienced enough problems (even with a signal strength indicator etc) to pick up the phone and contact support. Wireless signal strength indicators, and the assumption that users would go check their device etc if music stops, are all fine and good (and let's keep exploring solutions that let users fix problems on their own), but the tone solution would only be used after all these remedies have FAILED for that user in terms of helping determine/fix the problem, and after they've called customer support. So this solution, and the solution(s) Ross is recommending, are not mutually exclusive, I don't think. - the tone does more than just tell the user there's a problem. It tells them in context and in a timely fashion (as Dan mentioned, they don't have to be near the device for this to be useful, just within earshot); and it might also convince stubborn users who refuse to believe that a home network connectivity issue might be the source of their problem (this is just a human nature issue)... ---------- Finally, I would caution that a constant tone of any kind might be incredibly annoying. Some sort of soft beep or pinging sound that repeats every few seconds might be more tolerable.
Thanks Weldon, we had a pow-wow and came to the conclusion that Dan will be filing a few more diagnostic enhancement requests. Regarding audible feedback the only cases I can see this being useful is for a blind user or in the case that someone is trying to specifically track down an intermittent issue like interference. In the case that someone is having a difficult time understanding when exactly a connection issue was occurring, audible feedback would be excellent. In any other case I would prefer to see a message on the screen that tells me in plain English what the problem is. Dan is filing a few bugs to outline some better error messages, which more clearly convey in layman's terms (and colors) what the problem is. Also there will be some timeout suggestions to help make sure these customers get the message, something like the persistent message you get during a crash, rather than a showbriefly. One great way to do this would be to have a switch to enable debug mode in diagnostics which would enable more persistent messages to users experiencing these problems. And if users don't understand what they see on the diagnostic screen lets make that more understandable. I still fail to see how tones will help any more than the diagnostic screen already helps. From the diagnostic screen I can see if I have a wireless issue, a DNS / Internet connection issue, and firewall issues. Keep in mind we already have an audible indication of any problem, the music stops! From the Receiver front led experience I'm hesitant to rely on very simple queues like beeps and colors when we have a screen that can display text.
(In reply to comment #5) > Thanks Weldon, we had a pow-wow and came to the conclusion that Dan will be > filing a few more diagnostic enhancement requests. > > Regarding audible feedback the only cases I can see this being useful is for a > blind user or in the case that someone is trying to specifically track down an > intermittent issue like interference. In the case that someone is having a > difficult time understanding when exactly a connection issue was occurring, > audible feedback would be excellent. > > In any other case I would prefer to see a message on the screen that tells me > in plain English what the problem is. Dan is filing a few bugs to outline some > better error messages, which more clearly convey in layman's terms (and colors) > what the problem is. Also there will be some timeout suggestions to help make > sure these customers get the message, something like the persistent message you > get during a crash, rather than a showbriefly. One great way to do this would > be to have a switch to enable debug mode in diagnostics which would enable more > persistent messages to users experiencing these problems. And if users don't > understand what they see on the diagnostic screen lets make that more > understandable. Sounds great. And I pretty much agree with all of this. > I still fail to see how tones will help any more than the diagnostic screen > already helps. From the diagnostic screen I can see if I have a wireless issue, > a DNS / Internet connection issue, and firewall issues. Keep in mind we already > have an audible indication of any problem, the music stops! You're assuming that people are always smart, logical, and calm when troubleshooting a device that they paid hundreds of dollars for :-) . I'm guessing this isn't always the case. And hey, if you're right, great, no harm no foul - I'd rather have two indicators that work correctly (making one redundant) than risk the chance that nothing we provide is resolving the problem. > > From the Receiver front led experience I'm hesitant to rely on very simple > queues like beeps and colors when we have a screen that can display text. No one is suggesting ONLY using audio, unless I'm missing something. As I just said, your approach and Dan's suggestion are NOT mutually exclusive solutions, we can do both, right?
Don't ever accuse me of assuming people are smart! ;) I think you're still not getting part of what I'm explaining. Lets try exploring a scenario, lets say a customer is beyond the range of their wireless network, too far to consistently stream their music. Currently the music will sound choppy, no error message, and no tone. They'll probably not think to check diagnostic, instead they'll call support. This bug proposes at this point tech support would have them look at the diagnostic and there they would see poor wireless signal, currently displayed in all white in SNR (should be a percentage like legacy players, see bug 11044). At this point support would have the customer enable diagnostic audio mode, and the customer would hear the tones (I suggest ambulance or rooster from Sounds & Effects) and they would be reminded via annoying noise that 'something is wrong' right? It sounds to me like this bug is about helping the customer believe the support agent when they say wireless range / reception is the problem. If this is the case I don't believe tones will help any more than an improved diagnostic screen or better error message handling. In the out-of-wireless-range-case I believe we should have an error message show up persistently after the 3rd rebuffer saying "Your Squeezebox isn't able to stream consistently, it looks like the problem is [SNR / signal strength]" If the signal strength is very bad then it should be displayed in red, not so bad maybe yellow. The diagnostic page needs some more improvement, but not a whole lot. We need to dumb down the wireless signal, and implement some sort of easy to understand colors, or maybe a meter, something that anyone can look at and understand that wireless signal is too low if that is the problem. If we know what the problem is we should display it on the screen in such a way that the user can understand it. In Dan's first comment he says part of the problem is users don't believe us in the case of wireless signal issues because their laptops seem to work in the same area. If support believes audible feedback will help them to believe us, then go for it. Personally I think basic clear feedback on our beautiful color screen makes more sense, but there I go with that logical thing again, sorry Matt!
(In reply to comment #7) > Don't ever accuse me of assuming people are smart! ;) > > I think you're still not getting part of what I'm explaining. Lets try > exploring a scenario, lets say a customer is beyond the range of their wireless > network, too far to consistently stream their music. Currently the music will > sound choppy, no error message, and no tone. They'll probably not think to > check diagnostic, instead they'll call support. > > This bug proposes at this point tech support would have them look at the > diagnostic and there they would see poor wireless signal, currently displayed > in all white in SNR (should be a percentage like legacy players, see bug > 11044). At this point support would have the customer enable diagnostic audio > mode, and the customer would hear the tones (I suggest ambulance or rooster > from Sounds & Effects) and they would be reminded via annoying noise that > 'something is wrong' right? I wouldn't propose using something as terribly annoying as the rooster or ambulance sound. That would be awful IMO - who the heck would want to hear that, even if it was an error message? Why not a baby crying or nails being scratched on a chalkboard ;-)? It would/should be some sort of "system"-type sound. Give me a little credit :-) (also see the end of comment 4). > > It sounds to me like this bug is about helping the customer believe the support > agent when they say wireless range / reception is the problem. Yes, that is also my understanding. If this is the > case I don't believe tones will help any more than an improved diagnostic > screen or better error message handling. In the out-of-wireless-range-case I > believe we should have an error message show up persistently after the 3rd > rebuffer saying "Your Squeezebox isn't able to stream consistently, it looks > like the problem is [SNR / signal strength]" If the signal strength is very bad > then it should be displayed in red, not so bad maybe yellow. I'm ok with this, I think... > > The diagnostic page needs some more improvement, but not a whole lot. We need > to dumb down the wireless signal, and implement some sort of easy to understand > colors, or maybe a meter, something that anyone can look at and understand that > wireless signal is too low if that is the problem. If we know what the problem > is we should display it on the screen in such a way that the user can > understand it. > > In Dan's first comment he says part of the problem is users don't believe us in > the case of wireless signal issues because their laptops seem to work in the > same area. If support believes audible feedback will help them to believe us, > then go for it. Personally I think basic clear feedback on our beautiful color > screen makes more sense, but there I go with that logical thing again, sorry > Matt! Again, totally fine with messaging. But I'm not on the customer care calls, and I'll defer to customer care in terms of the best way to deal with stubborn customers (just from prior life experience, I've been on both ends of those types of frustrated calls).
(In reply to comment #8) Ambulance was a joke; audible feedback for error messages is a fantastic opportunity for some Sean/Dean style humor. :p Dan has a great error-message voice, maybe he can do some recordings? Let me know if you need a hand with the script. Dan to open specific support important diagnostic enhancement bugs. This one is a mess, sorry!