DevTools: clarify network timing visualization in details overlay

DevTools: clarify network timing visualization in details overlay

BUG=447200
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=188159

[pfeldman, 2015-01-08 19:37:59]

pfeldman@chromium.org changed reviewers:
+ eustas@chromium.org, maxwalker@chromium.org, paulirish@chromium.org

[maxwalker, 2015-01-09 15:10:41]

On 2015/01/08 at 19:37:59, pfeldman wrote:
> 

Wow, that was quick! :)

Follow up after the feedback from our last sync meeting:

1) Added “Started at” and “Total” label, renamed "Explanation" to "Resource
timing (info)":
https://cl.ly/image/1w1A1N3e1g24?_ga=1.95077084.156968028.1420207259

2) Scaling: Paul mentioned the problem that the details overlay currently scales
each request to the same width, so a 5ms request looks just like a 400ms
request. Idea: we could show these differences more clearly by adapting the
width of the overlay's middle part to some degree (e.g. scale between a min.
width of 50px for short requests and a max. width of 150px for long requests):
https://cl.ly/image/3j1Z1o3a090x?_ga=1.125939405.156968028.1420207259

3) Added specs in case the changes look good to you:
https://cl.ly/image/06080r2B2k3C?_ga=1.267969230.156968028.1420207259
Info icon: https://cl.ly/3y2B152E0z3h?_ga=1.267969230.156968028.1420207259

[pfeldman, 2015-01-09 15:28:23]

1) Do you think we need started at?

2) I'd rather land it as is and follow up with the scale. The problem is that in
the network space, 10ms, 100ms, 1s and 10s for long polls are all valid. So some
degree might be insufficient to clearly differentiate them.

[eustas, 2015-01-09 16:02:14]

The CQ bit was checked by eustas@chromium.org

[eustas, 2015-01-09 16:02:15]

lgtm

[commit-bot: I haz the power, 2015-01-09 16:03:05]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/837553007/1

[maxwalker, 2015-01-09 16:59:35]

On 2015/01/09 15:28:23, pfeldman wrote:
> 1) Do you think we need started at?
I would say that being able to read the approximate start time from the time
legend is sufficient.
However, Paul mentioned that it was just recently added, so I assumed there were
many requests for this.

> 2) I'd rather land it as is and follow up with the scale. The problem is that
in
> the network space, 10ms, 100ms, 1s and 10s for long polls are all valid. So
some
> degree might be insufficient to clearly differentiate them.

lgtm

[commit-bot: I haz the power, 2015-01-09 17:15:17]

Committed patchset #1 (id:1) as
https://src.chromium.org/viewvc/blink?view=rev&revision=188159