Bug 11213 - Spinning Widget in selection bar
: Spinning Widget in selection bar
Status: NEW
Product: SqueezePlay
Classification: Unclassified
Component: UI
: unspecified
: All All
: -- normal (vote)
: Future
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-26 18:08 UTC by ndijulio
Modified: 2011-11-06 23:24 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ndijulio 2009-02-26 18:08:40 UTC
The spinning widget should only appear in the selection bar after a set about of lag time (~2 secs) has occurred between when a button has been pressed and the screen does NOT advance.  

During the course of normal navigation the widget should not been seen by the user.  A good example is when the device is trying to establish a connection to SqueezeCenter.
Comment 1 Jim McAtee 2009-02-26 18:52:34 UTC
I agree.  I would also suggest that the check mark that appears is equally unnecessary when you already have the visual feedback of changing the background color/image when a selection is made.
Comment 2 Blackketter Dean 2009-02-27 06:51:53 UTC
Tom, is this an input thing, or should Ben be looking at it?
Comment 3 Richard Titmuss 2009-03-26 04:15:32 UTC
Tom should look at this. I think two seconds is far too long, the user needs feedback that the action was successful, otherwise they'll start prodding the screen/IR lots. Maybe half a second?
Comment 4 ndijulio 2009-03-26 10:52:22 UTC
The comment of 2secs was the actual feedback experience on screen and not a recommendation.  I would agree with the statement that unless the there is indeed a lag from the server, etc. the spinning widget should NOT be seen at all.
Comment 5 Wadzinski Tom 2009-07-14 11:01:45 UTC
Will there always be a visual indicator (a pressed state) on all skins and input types? On fab4 there appears to always be a visually apparent pressed style, on the QVGAbaseSkinApplet-based skins, there is no pressed style, so, unless we change that, the user would be left not knowing for a few moments if they pressed the button or not, if a delayed spinny is the only visual indicator.
Comment 6 ndijulio 2009-07-14 11:13:30 UTC
Tom-if i understand your question correctly, the pressed state for QVGAskins is either:

1. Transition slide (left/right) of the screen into selected menu. Transition = confirmation

or

2. A thinking widget (spinny) would be present only if there is a lag or time necessary to connect to source, followed by a transition.

We tried adding a literal visual press state (similar to the touch skin) early on and it was determined to be too noisy.
Comment 7 Wadzinski Tom 2009-07-14 11:54:20 UTC
Noah, I was hoping to confirm a concern I have. On the QVGAskins with a new "wait two seconds before showing item spinny", if there is no literal visial pressed state, then the following is likely to occur, which I think is troubling.

1) I select rhapsody (or anything that might have a delay) with an ir or button press. Nothing visual happens. I think "did I really press the button", so I quickly tap again, which a) is is an uncomfortable experience and b) might cause the next menu's first item to be inadvertently selected, if the menu fills in before I have a chance to stop my "did I really press it the first time" second press.


From an engineering perspective, doing the delayed item spinny code should be pretty straightforward.
Comment 8 Wadzinski Tom 2009-07-16 11:04:01 UTC
After a call from Noah, I'll try a 1 second delay before the item spinny occurs

The spinny also shouldn't appear while the transition is occuring.
Comment 9 ndijulio 2009-07-16 19:07:07 UTC
Tom - reassigning to you.  Let me know if any further graphical development is needed...
Comment 10 Richard Titmuss 2009-07-27 01:13:37 UTC
Reset priority before triage.
Comment 11 Chris Owens 2010-03-15 18:05:20 UTC
7.4.x milestone is in the past
Comment 12 Chris Owens 2010-05-06 15:38:09 UTC
Tom is no longer available to us
Comment 13 Alan Young 2011-11-06 23:24:18 UTC
Unassigned bugs cannot have a priority.