Spin-off from #1741498-132: Add a responsive preview bar to Drupal core. There, Dries requested that continued discussion about this topic be spun off into a new issue, so this is it.

The latest patch in that issue uses specific device names as the labels for the preset sizes that can be previewed:
- iPhone 5
- iPhone 4
- iPad
- Nexus 4
- Nexus 7
- Typical desktop

In #1741498-39: Add a responsive preview bar to Drupal core, Damien proposed:
- Small phone
- Phone
- Phablet
- Tablet
- Desktop

In #1741498-130: Add a responsive preview bar to Drupal core, yoroy proposed:
- S
- M
- L
- XL

In #1741498-132: Add a responsive preview bar to Drupal core, Dries said:

Having talked to various users about this at numerous occasions, I feel pretty strong about using device names

But Bojhan responded with:

Could you provide more background on how you presented the case, and what feedback you got... I like that you are performing user research, but its a little vague on the particulars - which is important for us to understand how users perceive this.

Note that the list is stored as a configuration file, so can be customized per site through a configuration UI, per distribution, by other modules in code, etc. The discussion here is about what we want core defaults to be.

TODO: Update this issue summary with other considerations that should be considered besides user preference as revealed through user research.

Comments

klonos’s picture

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.

effulgentsia’s picture

In #1741498-149: Add a responsive preview bar to Drupal core, LewisNyman said:

The problem is that all we would be doing is telling people it's a preview of a specific device, when actually it's a million miles away from a realistic test, we'd be lying to the users. If we run this tool in Internet Explorer then what are the chances of the preview looking anything like it does on the target device?

And in #1741498-158: Add a responsive preview bar to Drupal core, Damien Tournoud said:

We are doing the rendering in whatever browser the user is using. Webkit-based renderers have slightly less then 50% market share right now (and it is going to plunge soon because of Chrome), so it is more likely then not that it is *not* going to be a Webkit

I think it would be useful to get some screenshots posted for where a preview is too inaccurate. For example, one of the things I see this preview useful for is to see what's above the fold and what's below the fold in teaser listings. Because then, as a content author, I can work on shortening my summary if I want to get it above the fold. I created some local Article nodes by copying/pasting content from https://drupal.org/news, and then played with different text trim lengths for the Body field on admin/structure/types/manage/article/display/teaser, and then created some mock devices in responsive_preview.devices.yml of different sizes. I tested various combinations on Firefox, Safari, and Chrome, and could not reproduce a condition in which these different browsers differed on what's above vs below the fold. I didn't try IE though, or comparing it to a real phone. I'll try that when I get a chance, but in the meantime, I encourage anyone who knows the differences between these rendering engines to post screenshots of unacceptable inaccuracies.

Snugug’s picture

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.

Diane Bryan’s picture

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.

Snugug’s picture

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".

laura s’s picture

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.

jgrubb’s picture

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.

waako’s picture

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.

PieterDC’s picture

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.

PieterDC’s picture

Issue summary:View changes

Updated issue summary.

jessebeach’s picture

Issue summary:View changes