Well, this is underwhelming.

I had many doubts about this design when I first saw it, but hoped that tweaks along the way would improve it. Doesn’t look like it.

Core design issues:

1. On one hand it wastes a lot of space. On a 13″ laptop with everything maximized I have roughly 700px available vertically; yet the only device size that fits in the screen (counting the padding, top bar, viewport, *and* the size control below) is the iPhone 5. That’s frustrating when, with a design made for efficiency, sizes like the iPhone 6 and the Nexus 5 could fit alright. I find it worrying that the planned solution for this is “well, let’s zoom out the whole thing automatically”, and not “hmm, maybe 3 toolbars that each have some white space around is not a great use of space”. E.g. moving the width/height dimensions to one of the toolbars could help, and maybe making the white space around the top toolbar depend on the window height: tight on small windows, comfortable on larger ones — CSS Media Queries to the rescue!

2. On the other hand everything is very small and buttons are awfully close together and implemented with tiny hitboxes. Why make such liberal use of empty space but not actually make a UI you can only click without 100% motor skills *and* frustrating strain?

3. Why the strange-looking combo-boxes? More importantly:
– Why is the first one clickable on the full text and the second one split between the “DPR” label and the tiny number value (another ridiculously small hitbox)?
– Why is the DPR combo-box still looking like a combo-box but does not react to clicks when a device size was picked? That’s very confusing.

I also have a few concerns about the implementation:

4. Abysmal performance when toggling the RDM on (not sure if I’m waiting a full second or more, there’s some flashing and it seems that the tools are anchored to the left first and center themselves with one reflow or several).

5. Performance is not great when resizing the viewport from the sides or corner either. Obviously that’s going to depend on the web page inside, but it’s still noticeably slower and jankier than in the old RDM.

6. Zoom is funky, and probably not what users expect.

7. The select and buttons implementation has a few issues, especially when it comes to keyboard use. Haven’t tried it with a screen reader yet.

It’s great that some good features have been implemented and others are on the way, but that UI has So. Many. Issues.

1. fvsch

   My apologies for the first three sentences in that comment, though. They sound condescending and are unhelpful.

   November 22nd, 2016 at 12:41

2. J. Ryan Stinnett

   Thanks for the feedback! Keep in mind that this is a work in progress, we still have a lot planned for the future, and it exposes many features that were unavailable before.

   In general, the RDM tool was rewritten in HTML (from Mozilla’s internal XUL) to help us grow the tool more readily in the future, which was a large effort, but there are still some areas that need a bit more polish.

   1. You’re probably right that margins could be tightened up, especially on smaller screens. I’ve filed https://bugzilla.mozilla.org/show_bug.cgi?id=1319593 for this.

   2. We’ll keep the small hit boxes in mind for future updates. There are more elements we plan to expose, so it may be tough to fit everything if they grow to be much larger.

   3. For the DPR selector, the text is not part of the menu, so that makes it differ from throttling. However, it seems like we could easily trigger then menu when clicking the DPR text. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1319597. At the moment, we lock the DPR value when a device is selected, but we could allow it to be changed in that case. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1319599.

   4. I agree it can be a bit slow to enable. I haven’t noticed it being too bothersome, but we should try to polish it up where possible! We have https://bugzilla.mozilla.org/show_bug.cgi?id=1278757 to track this.

   5. You’re right, it can be a bit more jittery than before. I believe this partly connected to the viewport being centered now. In any case, let’s track this with https://bugzilla.mozilla.org/show_bug.cgi?id=1318340.

   6. Yes, I agree most people probably expect zoom to target the web content instead of the RDM UI. We have https://bugzilla.mozilla.org/show_bug.cgi?id=1278758 for this.

   7. I am not sure what you mean here, but please file a bug with more details so we can investigate it.

   Feel free to file additional bugs for issues or enhancements so we can track them along with other work.

   November 22nd, 2016 at 15:57

Hello,

How do I setup a custom user-agent with the new RDM?

Cheers!

1. J. Ryan Stinnett

   Choosing a device from the device selector will apply the user agent for that device. At the moment, there is no way to set a completely custom user agent.

   We’ll be adding support for custom devices with their own size, user agent, and other properties (https://bugzilla.mozilla.org/show_bug.cgi?id=1173142), so that seems to match what you’re looking for.

   If you have a commonly used device that’s missing from the device list, feel free to contribute it at https://github.com/mozilla/simulated-devices, and we’ll publish an updated list in the DevTools using that data.

   November 22nd, 2016 at 16:22

I would like to reinforce the comments about the UI implementation.

1. Usability
The controls are non-standard – I’m seeing a Mac styled drop-down on Windows. There is little user support in identifying what drop-downs represent (tooltips). The control hit areas are too small (drop-downs, pointer, camera, close, rotate). The ‘Responsive Design Mode’ label is presented the same as options (‘No throttling’) for no apparent reason. Related settings are displayed in different locations (‘DPR’, device profile, pixel size).

2. Fit and finish
The fit and finish is poor (alignment, spacing, consistency). There are unnecessary glows and transitions. The pixel size field bizzarely adopts Android styling which is confusing and out of place for Windows users. The edit device list UI is an odd modal overlay with non-standard controls. Centring the responsive viewport has resulted in poor performance when resizing the viewport.

3. Functionality
The basic pixel size selection list has changed for something more encompassing, but where is the migration of user settings and previous functionality? How can I save a custom device size/DPR? What do entries on the device list represent (size/DPR)?

1. J. Ryan Stinnett

   Thanks for the feedback!

   1. We’ll continue to the tune the appearance of the controls. They aren’t meant to match any OS in particular. I agree the hit boxes are a bit small at the moment, hopefully we can improve that.

   2. I believe other replies covered these issues. Please file bugs if you have more specific issues that don’t appear to be tracked already.

   3. We’ll be adding support for custom devices with their own size and other properties (https://bugzilla.mozilla.org/show_bug.cgi?id=1173142). The devices in the list are taken from https://github.com/mozilla/simulated-devices. Feel free to contribute additional devices, and we’ll publish an updated list in the DevTools using that data.

   November 22nd, 2016 at 17:16

Yay, throttling tools! I like this.

Well if i could save my own window sizes again to test my breakpoints i would give it a thumb up – right now I had to downgrade my version to get this feature back.