Closed Bug 1283445 Opened 5 years ago Closed 5 years ago

[UX] Network Throttling Control

Categories

(DevTools :: Responsive Design Mode, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED
Iteration:
50.4 - Aug 1

People

(Reporter: jryans, Assigned: hholmes)

References

(Blocks 1 open bug)

Details

(Whiteboard: [multiviewport] [mvp-rdm] [ux])

Attachments

(1 file, 1 obsolete file)

We need to work out what UX we are looking for with network throttling.  The user story (bug 1110207) describes some high level suggestions about the choices we might present.  Chrome's UI is another good reference to look at.

We also need to decide where this control belongs (RDM toolbar, RDM somewhere else, toolbox, etc.).
Priority: -- → P2
Whiteboard: [multiviewport][triage][ux] → [multiviewport] [mvp-rdm] [ux]
Flags: qe-verify-
Assignee: nobody → hholmes
Status: NEW → ASSIGNED
Iteration: --- → 50.3 - Jul 18
Priority: P2 → P1
Attached image network-throttling-spec.png (obsolete) —
Ryan, would you mind taking a look over this?
Attachment #8771418 - Flags: review?(jryans)
Comment on attachment 8771418 [details]
network-throttling-spec.png

I think it looks good overall!  It seems reasonable to expose the control from the RDM toolbar.  Perhaps we'll want to expose this elsewhere in DevTools, but we can worry about that down the road.

In the user story (bug 1110207), Bryan seemed to feel it was better to hide the specific numbers since it's not really a precise simulation and instead more just about what happens on a slow connection (for a somewhat ambiguous definition of slow).  Do you think it's better to present the numbers even if it's not precise?

The editing flow looks reasonable using the same style as device list editing.  I don't think we would build editing initially (probably we'll start with just a static list).
Flags: needinfo?(hholmes)
Attachment #8771418 - Flags: review?(jryans) → review+
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #2)
> Comment on attachment 8771418 [details]
> network-throttling-spec.png
> 
> I think it looks good overall!  It seems reasonable to expose the control
> from the RDM toolbar.  Perhaps we'll want to expose this elsewhere in
> DevTools, but we can worry about that down the road.
That's definitely Chrome's approach. I could imagine for Network Throttling you might want to be able to apply it separately from rdm, so worth continuing to think about where that might make sense.

> In the user story (bug 1110207), Bryan seemed to feel it was better to hide
> the specific numbers since it's not really a precise simulation and instead
> more just about what happens on a slow connection (for a somewhat ambiguous
> definition of slow).  Do you think it's better to present the numbers even
> if it's not precise?
The numbers /to me/ definitely don't mean much, so I'm happy to hide them. I'll update the designs.

> The editing flow looks reasonable using the same style as device list
> editing.  I don't think we would build editing initially (probably we'll
> start with just a static list).
That's definitely fine—I was just trying to anticipate next steps.
Flags: needinfo?(hholmes)
This version removes the up/down speeds, since we're only doing an emulation (not necessarily precisely what's listed).
Attachment #8771418 - Attachment is obsolete: true
Iteration: 50.3 - Jul 18 → 50.4 - Aug 1
Hey Marco (or Ryan!), 

I notice the iteration on the bug got changed—do we close out design bugs once their implementation bugs are closed out, or can this bug be marked as completed since the designs got an r+?

I'll attach the spec to bug 1283453.
Flags: needinfo?(mmucci)
Hi Helen,

If the designs are done then this bug can be marked as resolved.

Marco
Flags: needinfo?(mmucci)
Sounds like the design work is done here.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Given the UI spec, how can user edit or remove a custom profile?
Flags: needinfo?(hholmes)
(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #8)
> Given the UI spec, how can user edit or remove a custom profile?

Looking at this again, I agree it's a bit unclear how a specific profile would be chosen for editing or removal, since it's likely to be a <select> type down down.

Not too much of an issue immediately since we're starting with implementing just a static list, but we'd likely need more refinement of the spec for editing / removing if we head done that road.
I'm going to temporarily clear my ni? until we're further along in this process.
Flags: needinfo?(hholmes)
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.