Dietrich Ayala (:dietrich) Reporter
	Description • 12 years ago

Settings still doesn't feel good on Unagi. I think it's a combination of all things below:

1. some jankyness while scrolling still, especially right after a cold load.

2. scrolling lag: open Settings, press on Bluetooth and scroll up and down. Bluetooth is almost never under your finger. it eventually catches up to your finger once you stop scrolling.

3. the color doesn't change on press takes WAY too long. with a simple press-and-hold, you can *visibly* see the color change some time *after* you press. it's not instant.

4. color change on press often never occurs at all. STR: open Settings, scroll down to Device information and immediately press and release it once it comes into view. it will open the DI pane, but the menu item never changes color.

5. some panes take up to 3 whole seconds to open. it seems to vary. we really need telemetry to measure this in the wild on an ongoing basis.

	Dietrich Ayala (:dietrich) Reporter
	Comment 1 • 12 years ago

Josh, can you comment on the expectations wrt background color changing on press, and scrolling behavior?

If the above concerns are valid I'll file separate bugs on each.

	Josh Carpenter [:jcarpenter]
	Comment 2 • 12 years ago

Thanks for filing this, Dietrich. 

Generally, line by line, we want:

1. 60fps scrolling performance

2. 100ms max lag time for scrolling. From our Responsiveness doc:

> 100ms: Maximum UI response time to user hand-eye coordination events. 
> “If an object the user is dragging or resizing lags more than 0.1 
> second behind the user’s pointer movements, users will have trouble 
> placing or resizing the object as desired” and the experience feels 
> unpleasant and inaccurate as a result.

3-4. Button :active state to be visible within 140ms on touch start event.

5. Task completion (opening a subsection) as soon as possible after touch end. 

...Or to add a bit more nuance: Task completion asap after touch end, ALBEIT after a N ms wait for the button :active state to clear. We want to establish a rhythm to the FFOS interface. Usually it means making a response happen _faster_. But in some cases we want to throttle the response slightly so we can make sure a button :active state can play out it's cycle (to pick one example). iOS does this nicely, defining a disciplined timing consistency across the OS, even when it seems likely their HW could load content a few ms faster than they actually are. UX has not yet defined these timing thresholds within FFOS (our focus has been on responsiveness) but we'll add it to the docket. 

I hope that helps? I'm in London this week w/ the UX team and then in Madrid next, if you want to discuss then. If you do file bugs against these, can you please mark them as follows:

Whiteboard: u=user c=settings s=ux-most-wanted

That ensures they're pulled up into http://scrumbu.gs/t/fxos-ux/ux-most-wanted/

	Josh Carpenter [:jcarpenter]
	Comment 3 • 12 years ago

Made this the meta and added the ux-most-wanted tag.

	Dave Huseby [:huseby]
	Comment 4 • 11 years ago

So we're tracking these goal in our user stories: https://wiki.mozilla.org/B2G/Performance/UserStories

Kevin: what's the status on this?  is there another meta bug for this?

	Kevin Grandon :kgrandon
	Comment 5 • 11 years ago

(In reply to Dave Huseby [:huseby] from comment #4)
> Kevin: what's the status on this?  is there another meta bug for this?

It looks like this is a meta bug, and with solving the dependent bugs we can close this out. I'm also looking at bug 922658 for point 5, but I'd prefer to not block this one so we can come to some closure here.

My recommendation would be to follow-up on the two dependent bugs, then get this closed out.

	Bobby Chien
	Comment 6 • 9 years ago

[Tracking Requested - why for this release]:

	BMO Automation
	Comment 7 • 7 years ago

Firefox OS is not being worked on