Bug 12921 - Diagnostics addition: Add option to provide persistent on-screen network errors
: Diagnostics addition: Add option to provide persistent on-screen network errors
Status: NEW
Product: SqueezePlay
Classification: Unclassified
Component: --
: unspecified
: PC Other
: -- normal (vote)
: 8.0.0
Assigned To: Unassigned bug - please assign me!
: Support-Important
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-17 17:08 UTC by Dan Evans
Modified: 2011-11-06 23:25 UTC (History)
7 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Evans 2009-07-17 17:08:00 UTC
(This is a corollary to bug 12920.) 

When dealing with wireless signal issues, it's very difficult to get reliable
feedback from the user.  Often after the wireless event has happened and the user hears their music stutter or cut out, if they go to their player the diagnostics will show everything is fine.  Why?  Because they were too slow and missed the important information.

So, I propose the following:

 * Create a new option at the bottom of Diagnostics called "Persistent Errors".

When this mode is ON it enables error messages that describe what's happening with the WiFi.  Furthermore, these messages are persistent-- that is, they *must* be clicked on to go away.  That way whatever the important event that happened was, it will be visible to the user after the fact and they can report it.

This will be helpful to Support in gathering behavior data from customers.  This will be helpful to QA in testing.

One thing to consider will be how to manage multiple messages that get triggered.  Do they queue up?  Or is there a "count" at the top of the one message?  This may require some design cycles.

This should be implemented for all SqueezePlay-based devices, and if feasible
backported to older players as well.
Comment 1 Ross Levine 2009-07-17 17:12:08 UTC
What inspired this request is the crash message that baby and fab4 both display, it is very obvious to the user what happened after a crash. 

A suggestion for the case of multiple messages: send an email to the user with clear 1 line error messages and time stamp. Cute examples:

Date/Time: Wireless signal below 25%
Date/Time: Internet connection down
Comment 2 Dan Evans 2009-07-17 17:14:44 UTC
Ross makes a good point.  I described this as related to WiFi, but it really should be network errors inclusive. (changing summary.)
Comment 3 James Richardson 2009-07-30 10:12:22 UTC
Targeting for next release
Comment 4 Ben Klaas 2009-08-26 07:46:52 UTC
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
Comment 5 Chris Owens 2010-05-07 10:28:48 UTC
Richard is no longer available to us.
Comment 6 Alan Young 2011-11-06 23:25:12 UTC
Unassigned bugs cannot have a priority.