Evaluate pros and cons of using specific device names vs. generic size names as labels for Responsive Preview

I'm in favor of having a UI to configure any desired set of label/width/height/dppx. I don't see the point in using a horizontal + vertical slider solution that gives me an arbitrary number of possibilities and I definitely don't like to see specific devices "promoted" out of the box either. I don't want to "play around" with sliders - what I want is to be able to define a set of dimensions/resolutions and also be free to label these however I like, then be able to click these predefined templates and test things out.

As a site builder, I have available stats of the screen sizes most of my visitors view the site in. If I had a way to configure a certain set of presets, then I would do so for say the top 10 (according to my site's stats) and only test my site against these presets. I personally would never bother testing screen sizes of sporadic visitors with "exotic" devices and sizes. This I believe takes care of the "cover most popular devices (per world region)" scenario too because in the end it does not matter where the site is popular and which devices are popular in that country/region - what really matters is the actual screen sizes of (most of) the people visiting a site.

Pardon my language, but are you effing kidding me tying screen sizes to device names? That is the absolute antithesis of what device agnostic design and content strategy (aka modern web development) is about. How is this even a question? Of what is proposed, The S-XL is the best, (better being a continuous slider to change sizes, or best of the available options being integration of ish) but any semblance of devices in there is absolutely ludicrous and will simply fly in the face of wider front end best practices of the past two years and piss off anyone halfway serious about responsive web design.

I'm in favor of having a UI to configure any desired set of label/width/height/dppx. I don't see the point in using a horizontal + vertical slider solution that gives me an arbitrary number of possibilities and I definitely don't like to see specific devices "promoted" out of the box either. I don't want to "play around" with sliders - what I want is to be able to define a set of dimensions/resolutions and also be free to label these however I like, then be able to click these predefined templates and test things out.

Yes, it would be very practical and time-saving to have the sort of Screenfly capability built-in, but where I can specify the sizes (breakpoints) that are significant to my design, and call them whatever I want, to make sense out of it. For instance, I might want to label it "Menu toggle 768" or "Swap sliders 640", or whatever makes sense to me.

Once I had settings that proved to be more or less universal, I'd potentially want to port those settings to other sites I'm building, using Features or whatever.

Addendum: I have appreciated the AdaptiveTheme built-in breakpoints, and use them as a point of departure. Nice to be able to customize them. I find with 4 customizable breakpoints I only have to add a few extras here or there for unique content features that have their own requirements.

To follow up on Effulgentsia's use-case about above/below the fold. I'd like to point everyone to Karen McGrane's Drupalcon keynote.

http://karenmcgrane.com/2013/05/23/drupalcon-keynote-video-and-talk-notes/

I know it's a hard pill to swallow, being told how you think about the web at its base is wrong and needs to change, but it does. Editors should not be tweaking their content to a specific view. The web view is not the canonical place where content lives, it's just a single view of it. We should be encouraging best practices in Drupal Core for others to follow, leading from the front, not (to use a phrase from the keynote) "building faster horses".

I agree with @Snugug #5. This feels like a very elegant feature for #doingitwrong. See http://alistapart.com/article/designing-for-services-beyond-the-screen and http://www.lukew.com/ff/entry.asp?1742

Does this need to be in core? Is this really the killer feature that needs to be thrown in? I've worked with major publishers for years now, and not one has asked for a variety of previews -- not when *all* of them save unpublished nodes in their workflow and thus can do all their previewing on the actual content in the actual them using actual devices they have on hand prior to taking their content live.

And how will this work for content creators who are working on mobile?

Given the choice between device vs. size, I would definitely argue against using device as any sort of definition. These things change very quickly. The past few years have taught all of us that the web is changing at an increasingly faster pace. What devices are in and what are left out? What happens when a new device becomes popular? Patch core? What about when we get a mobile device with a resizable browser window? How are retina displays handled? How does this cover television set display? Device detection has been discredited for years, so why pretend it's a good approach to emulate?

To me this seems like unnecessary complication that yields questionable benefits and a host of problems.

I also agree with Snugug's points and with Laura's point about devices. D8 is most likely going to have a much longer life than any of the screen sizes of the currently popular devices listed at the top of the thread.

This wheel has already been invented for those who are inclined to look into it (FF developer tools), and those who aren't probably don't need to be accommodated at the expense of core developer hours, but if this feature does get the green light, it should be as generic as possible.

I also completely agree with Snugug comments, it is absolutely wrong to define any dimensions by anything other than the most generic terms, especially not device names, consider the number of dimension names needing defining for Samsung devices

Also support Laura S questions about the need, usefulness and cost of implementing such a feature.

I agree with snugug, laura s, jgrubb and waako.
I hereby invite you to #2123085: Add preview options which proposes a better alternative to dimensions-only preview modes.

Updated issue summary.