Problem/Motivation

While previewing layouts at various screen and device dimension sizes is familiar to most front end developers and themers, the mechanics of this efforts may still be unknown or cumbersome to content creators and editors. For many of them, the goal of their efforts is to create great content. Anything that helps them quickly determine what this content might look like across the media that will deliver it to consumers is an improvement.

Summary of Pros and Cons raised during the debate of this issue

Pros
  1. Drupal 8 lacks a robust content previewing mechanism. The RP module gets us closer to that goal.
    • Comments: #98, #87, #306, #355
    • #87, Creating and previewing content is a core function of a CMS.
    • #306, This feature is mostly for content-editors, core really lacks a sane content preview (what we have with Preview button - the old school style) So once core 8 focused on editor's experience out of box so it makes sense to include.
    • #355, I think this provides a useful feature for content editors, even if it's going to be a pain to maintain.
  2. Shiny Drupal 8 features give us something to taut on release
    • Comments: #107, #268, #298
    • #268, Providing rich, user friendly, quick responsive(in speed) editorial interfaces is the way to ensure they get hooked to our Drupal platform.
    • #298, The content creators or editors are invariably the decision makers when it comes to the tools they have to use.
  3. Many direct competitor CMSs have a similar feature. Drupal keeps parity with the RP module.
    • Comments: #87
  4. Specific device names are easily recognized by non-techie content authors
Cons
  1. The device definitions that ship with Drupal 8 will be old in 6 months; using specific device names.
    • Comments: #108, #109, #129, #130, #135, #158
    • Remediation: #109, Use labels like Phone, Phablet and Tablet instead of specific device names.
    • Remediation: Devices are configurable in the UI. New devices can be added. Devices can be deleted.
    • Remediation: #155, We will add new device definitions with minor Drupal 8 core updates.
  2. It is has the potential of being deceptive i.e. that the previews will not match the rendering of the device indicated by the label
    • Comments: #88
    • It is true that the rendering engine used to produce the preview may not be the same as the one on the intended device.
    • This feature is meant to give a content author a quick test of how a page might be presented on numerous devices.
    • Remediation: #39, #40, The preview window is not simply sized to match the device's published pixel dimensions, it also takes resolution into account as well.
  3. We should not be introducing features to core at such a late stage in the development cycle.
    • Comments: #85, #89
    • Remediation: The RP module is a self-contained feature with no impact on other core modules.
    • Remediation: Jesse Beach has volunteered to be the maintainer of the module.
    • Remediation: A policy to allow late-stage feature commits is in place.
  4. Site builders and content creators need to stop thinking about how the site looks on a short list of specific devices because its folly
    • Comments: #141
  5. Native browse tools exist and are getting better for responsive previewing
    • Comments: #178, #282
    • #282, Most major browsers ship with this facility built-in. Their solutions will not only evolve and improve much faster, they will also be much more accurate.
    • Rebuttal: #286 Content authors will most likely not know about or be able to use the tools provided by browsers. These are advanced features.
  6. The only sure way to preview content on a specific device is to use that device.
    • Comments: #285
    • Rebuttal: Even the few devices represented by the RP module would cost a couple thousands dollars to purchase. Must all content authors purchase every device in order to preview their content?

CMS Competition

Many content management and creation tools are stepping up to aid content creators in this process.

Instant preview by Magnolia CMS: http://www.magnolia-cms.com/magnolia-cms/features/mobile-cms.html

Mobile optimization by Sitecore: http://www.sitecore.net/Products/Web-Content-Management/Mobile-Web/Mobil...

Adobe CQ5 optimization: http://www.adobe.com/it/special/eseminar-enterprise/pdf/CQ5_Mobile.pdf

CQ5 Mobile provides an easy-to-use, browser-based, in-context content authoring environment that eliminates the need for custom client software or separate sites for device types.

Drupal needs to assist in improving the content creation workflow from data model up to the point of end-user consumption.

Proposed resolution

The responsive preview module proposed here is a light-weight tool for content creators to quickly determine how their pages will appear on smaller devices.

It provides preview options for several popular devices. This device list will be kept current through periodic minor releases of Drupal.

Remaining tasks

Follow up issues are tagged responsive preview. Once this is in, they'll be moved to the responsive_preview.module component.

Known bugs

The responsive preview icon still shows up even on the iPhone sim which is obviously not wide enough to preview in anything. Clicking the icon causes it to disappear. (https://drupal.org/comment/8261301#comment-8261301)

User interface changes

A toolbar icon is added. It shows a device drop-down selection menu (devices are configurable from an admin UI) that launches a preview of the current page in a pop-up on the selected device dimensions and default orientation. Users can switch orientation from a dedicated button on the preview UI or select a different device from the toolbar device drop-down.

API changes

None.

Files: 
CommentFileSizeAuthor
#424 mobilepreviewbar_extendpage.JPG47.66 KBShyamala
#424 mobilepreviewbar_addarticle.JPG46.86 KBShyamala
#423 interdiff.txt5.3 KBjessebeach
#423 responsive-preview-1741498-422.patch90.75 KBjessebeach
PASSED: [[SimpleTest]]: [MySQL] 59,445 pass(es).
[ View ]
#338 preview-menu.png18.94 KBrteijeiro
#338 device-list.png114.77 KBrteijeiro
#338 new-device.png41.33 KBrteijeiro
#338 iphone4-no-scroll.png173.74 KBrteijeiro
#278 Screen Shot 2013-09-10 at 11.03.22 AM.png55.66 KBwebchick
#275 chromenative.jpg173.6 KBRobLoach
#275 firefoxnative.jpg268.94 KBRobLoach
#238 Odio_Quidne___Drupal_D8_Dev.png25.02 KBjessebeach
#238 Odio_Quidne___Drupal_D8_Dev.png28.32 KBjessebeach
#234 Odio_Quidne___Drupal_D8_Dev.png23.65 KBjessebeach
#215 Drupal_D8_Dev.png35.78 KBjessebeach
#213 device-label.jpg38.46 KByoroy
#213 device-list.png15.31 KByoroy
#204 Responsive_preview___spark8.localhost.png84.6 KBGábor Hojtsy
#204 Responsive_preview___spark8.localhost 2.png52.33 KBGábor Hojtsy
#203 Edit_device___d8.drupal.dev-2.png4.42 KBjessebeach
#201 1741498-edit-device.png138.34 KByoroy
#180 Chrome - Override Device Width.png142.61 KBRobLoach
#175 Screen Shot 2013-06-14 at 6.25.29 AM.png37.22 KBlarowlan
#173 Screen_Shot_2013-06-13_at_2.52.36_PM.png25.91 KBjessebeach
#172 Screenshot_6_13_13_4_14_PM.png98.94 KBGábor Hojtsy
#172 Screenshot_6_13_13_4_15_PM.png36.33 KBGábor Hojtsy
#172 Screenshot_6_13_13_4_16_PM.png94.16 KBGábor Hojtsy
#172 Screenshot_6_13_13_4_16_PM 2.png48.21 KBGábor Hojtsy
#165 responsive_preview-other_website_example.png60.28 KBWim Leers
#142 slider-preview.png57.3 KBDavid_Rothstein
#67 mobile-preview.png44.02 KBjessebeach
#52 mobile-preview.png81.73 KBjessebeach
#41 scaling mobile preview — iPhone.png296.18 KBWim Leers
#41 scaling mobile preview — iPad.png779.56 KBWim Leers
#41 no scaling when device-width — iPhone.png251.04 KBWim Leers
#17 close-ipad-landscape.jpg114.62 KBWim Leers
#11 Screenshot_2_7_13_12_00_AM-2.png9.46 KBjessebeach
#7 layout-toolbar-tab-expanded.png27.56 KBjessebeach

Comments

Though this is a great piece of work from a technical POV, I think this should be in contrib; I just don't see how it can be justified in core. In my opinion, RWD is not about catering to specific devices (quite the opposite), and this feature (as core functionality) may seem outdated and odd in a couple of years.

As has been mentioned in this issue before, Drupal can add/remove/edit devices during a release cycle. The argument that the device list can go stale holds no water, IMO. SItes can easily edit their own device list too, for that matter.

There are of course other reasons to object to this. My objection is that we are months past feature freeze and this could add some criticals to our backlog once it gets battle tested.

This issue (more accurately, the responsive preview feature) is a mixed bag. On the one hand, in a multi-device world the ability to preview how things look in other contexts is important. However, a couple of acquaintances asked me to weigh in on any concerns since I've been speaking about and working on multi-device and multi-channel issues recently.

The most obvious (but also least pressing) issue is the hard-coding of specific devices instead of specific sizes in the preview itself. #2013166: Evaluate pros and cons of using specific device names vs. generic size names as labels for Responsive Preview covers it in more depth, and since it can be remedied with pure configuration updates I won't rehash the issue here.

The one that's more troubling to me is the assumption that varying screen size is the heart of the previewing problem. Increasingly, responsive web design is called on to adjust itself in subtle ways to a variety of cues: screen size, window size, device orientation, input type, device signature, and audience targeting are all important considerations on sites whose designs are complex enough to demand a multi-format preview.

Tackling this issue in a way that serves users beyond kick-the-tires demos is hard -- very hard. The Typo Neue team is an example of the kind of fundamental rethinking that well-executed preview requires, and they aren't entering into it lightly.

I understand that an important consideration for many D8 features is the perceived need to win head-to-head demo shootouts with prorietary CMSs like CQ5 and SiteCore. Having talked with integration specialists and customers using both of those systems, what I hear is that neither of those systems does this in a way that serves customers well, either. While it's important to remain competitive by serving the needs of Drupal's users, we should not rush to spend scarce development and maintenance resources on a feature-war checkbox fight -- especially when the competing systems aren't doing a great job of it themselves.

I don't have a strong opinion on the core-or-contrib-for-8 issue, but as someone who'll be working with and advising clients about D8 for years to come -- long after the demos are finished -- I believe this purely window-sized approach to previewing runs the risk of quickly becoming as dated as puffy, candy-colored icons in the admin section. In situations where preview fidelity *matters,* I believe it will be disabled and replaced by more capable implementations -- either ones from contrib, or one custom-coded to meet the needs of complex projects.

Screen sizes can be updated over the D8 cycle, but the approach used by the feature will not, unless I've misunderstood, be flexible enough to deal with the reality of responsive design over the next 3-4 years. Whether its near-term curb appeal it is worth the work is a question for the developers whose time has and will go into creating, testing, and supporting it over the D8 lifecycle.

Double Post

Death to Bullshit

I find it astounding, although I really shouldn't at this point, that suggestions from non-backend experts are all but ignored. Have we learned nothing from Luke W's keynote at Denver? What about Karen's in Portland? What about our own front-end stance of "mobile first"? To paraphrase Karen, this is another one of those features that seems "ginned up by some marketing department". It is utter bullshit. Let me explain.

First, let's talk device names. As discussed in a thread specifically created to discuss naming, the overwhelming consensus is that device names are absolutely pointless but, worse than that, totally and absolutely misleading. There are so many factors that go into a design from progressive enhancement of display from available features to orientation to any number of other things that arbitrarily deciding that some given width (and not height) is somehow a device is pure crap. It is almost the definition of an anti-pattern.

To that extent, second is the fact that the display they're getting is categorically not what they'd see for any given device. Has the back end world forgotten about the different rendering engines in existence? Claiming that a resized IE preview is what their site will look like on mobile Safari for iOS7, or for that matter IE Mobile, is just blatantly not true. Are you really suggesting that a know wrong model provides a good user experience? Bullshit.

Even if you were to rename them from device sizes to relative sizes and have those relative sizes be ranges and not set sizes, you're still missing the largest issue with this feature: it's Desktop Web centric. Let's start with Desktop. Even if we're only discussing publishing for the web, this feature inherently assumes someone is sitting at a Desktop publishing content making this feature worthless for any content creation happening on anything but that type of environment.
Now what about web? The same issue exists with this that does with the inline editing; it puts users into the terrible mental model that the web is the canonical view of their content. THIS IS NOT TRUE. The Services initiative makes widely distributing content to platforms other than the web something inherent to Core, and constantly pushing this mental model for Core is absolutely infuriating. Drupal 8 is going to be around for a long time. Next year when smart watches are everywhere, not only will this feature be worthless, but the idea that your content only exists on the web, if it weren't dead already, will be gone and forgotten. This feature respects neither the content creator, the front end developer, the designer, nor the reality of the multi-channel, multi-device world we live in.

If this module must exist, it doesn't belong anywhere near Core. While attempting to turn Drupal into CQ5 may be good for those trying to sell Drupal from a marketing/investment perspective, that doesn't mean it's a good thing.

Also, as an aside, I find it totally fucking disingenuous to suggest that just because those participating in this conversation aren't the core user for this module means our opinions don't matter. We are your damn experts on the matter and if we suggest a car when you want a faster horse, take heed as to why we're suggesting that and don't blow it the fuck off. It shows a total lack of respect.

StatusFileSize
new1.59 KB
new91.51 KB
FAILED: [[SimpleTest]]: [MySQL] 58,589 pass(es), 729 fail(s), and 36 exception(s).
[ View ]

Patch updated according to https://drupal.org/node/2089727 Changelog.

EDIT: It seems I have created the interdiff.txt in the oposite direction :'(

Status:Needs work» Needs review

There is really no need to throw out words "bullshit," Snugug. You can still make your points (and honestly, they'd be much better received) without resorting to attacking people. http://drupal.org/dcoc <-- read it.

I don't feel like this huge pile of comments is really helping. We have a BDFL, and sometimes his job is to D. If you want to affect his decision-making process, though, the best thing to do is get the concerns raised in recent comments put in the issue summary in neutral language like a pro/con list.

@webchick, your post in #296 would also have been better received, and might have been responded to with a more neutral tone, had it not included an ad-hominem.

I look forward to someone pushing for this feature updating the issue summary to reflect the current status of the discussion.

@snugug

Tossing aside the profanity because I know that's just you being you :), I want to challenge you to propose an alternative approach that addresses this very real and often-heard user story:

"As a site administrator managing a large site that an excellent development team has already themed to be fully responsive, I want a relatively painless way to get an approximate preview of my new content (Is Miley's head big enough to see her expression?, Does the headline break in the middle of the punch line?). Pixels and Ems mean nothing to me, but I know for a fact from my statistics department, that two thirds of my users view my site on a Nexus 7 and that's what I want to see."

Issue tags:-Usability, -sprint

@tkoleary, it's not up to snugnug to provide an alternative, it's up to this issue to justify solving that very specific user story, in this way, in core. Browsers and contrib modules have plenty of opportunity to provide alternatives during the full length of 8.x's lifecycle.

I'd be more interested in a measured response to eaton and snugnug's posts that actually deals with the points they made, rather than just trying to turn the conversation around.

Does "Buy a Nexus 7" qualify as relatively painless? :/

I'd be more interested in a measured response to eaton and snugnug's posts that actually deals with the points they made

Here's my take on it.

First, responding to snugug's points (#321):

Have we learned nothing from Luke W's keynote at Denver? What about Karen's in Portland?

Karen specifically mentioned in her talk the need for CMSes to provide the functionality of previewing multiple presentation modes, to get content authors to make the mental transition from a world of Microsoft Word style editing, where what you write always appears in that one way from screen to paper, to a world of content appearing in a multitude of ways. She also mentioned that this is a very difficult thing to accomplish, since invariably, you end up providing for preview some presentation options and leaving out others. The feature in this issue is a step in that direction. One could argue that it's an insufficient step, since the presentation options we're offering (sizes) and the ones we're leaving out (everything else mentioned in #319) fails to help content authors realize there are other variable at play than just size. But I think there's no way the web community is going to help content authors make this mental leap in one shot. It's going to be an iterative process, and I think starting with the one axis, as this issue is doing, and then figuring out UIs for all the other axes, is a reasonable way to approach things. As for Luke, I'm not clear what in his talk is relevant to this, except perhaps this next point.

Even if we're only discussing publishing for the web, this feature inherently assumes someone is sitting at a Desktop publishing content making this feature worthless for any content creation happening on anything but that type of environment.

Huh? AFAICT, this feature works equally well on a tablet or any other device. Its only limitation is you can only preview in a size smaller than the one you're on. So, on a tabletish device, you can preview a phonish size. Maybe it makes sense to also allow previewing larger sizes than the one you're on, despite the corresponding need for horizontal and vertical scrolling?

[This feature] puts users into the terrible mental model that the web is the canonical view of their content. THIS IS NOT TRUE. The Services initiative makes widely distributing content to platforms other than the web something inherent to Core, and constantly pushing this mental model for Core is absolutely infuriating.

Are you suggesting we therefore get rid of all Preview functionality everywhere, since the Preview button of the node edit form also only shows you a web representation of your content?

And, to eaton's (#319):

The one that's more troubling to me is the assumption that varying screen size is the heart of the previewing problem. Increasingly, responsive web design is called on to adjust itself in subtle ways to a variety of cues: screen size, window size, device orientation, input type, device signature, and audience targeting are all important considerations on sites whose designs are complex enough to demand a multi-format preview.

I agree that all those other axes are important. But does that make screen size unimportant? As an analogy, consider our comment module. For over a decade, it's been limited to only commenting on nodes (and still is, though hopefully we'll get that fixed for D8). Of course there are use cases to also comment on user profiles, products, orders, files, etc. Does that mean we should have removed comment module from D7 (or any prior version), and only allowed it into core once it's been generalized to all entity types? Or was it ok for it to exist in core despite its limitation of nodes only? My opinion is the latter, and similarly, I think the majority of Drupal 8 sites out there will be well served to have content authors quickly previewing different sizes, even if they're not also quickly previewing every other conceivable axis.

In situations where preview fidelity *matters,* I believe it will be disabled and replaced by more capable implementations -- either ones from contrib, or one custom-coded to meet the needs of complex projects.

That's fine. Likewise, in places where a full-fledged editorial workflow matters, people can replace core's simple "Save as Draft" vs. "Publish" button with something more sophisticated. And people can turn off all of Drupal's core UIs and replace the entire CMS experience with a native app. I don't see what's wrong with core offering something that fits the needs of the current mainstream, even if leading edge use cases, or what will be mainstream in 5 years, eventually make the current solution obsolete. I think perhaps there's debate on whether this feature solves the needs of the current content authoring mainstream (or will continue to do so for sufficiently long after D8's release). I don't know the answer to that, but would be very curious about how to determine that. While I do not at all want to dismiss the opinions of front-end experts, I share webchick's concerns that these experts are so far on the leading edge that they're undervaluing something that might be "good enough" as an interim improvement to "nothing".

And by "good enough", I don't mean anything disparaging at all. I think content authors being able to easily preview content in different sizes is totally awesome and core worthy. If someone proposed a working, well coded, well tested, patch that also allowed previewing other important metrics, like different view modes or different Views or whatever else, I would also consider that appropriate for core inclusion.

@Effulgentsia:

Let me start by thanking you for actually responding to the issues brought up and let me respond:

While my contributions inside the Drupal community aren't as vast as others, I wind up contributing a great deal to open source projects outside of Drupal, many of which intersect with the same types of problems that Drupal is trying to solve, in this case being able to provide a preview of your site at multiple screen widths. You know what I've found after years of working on responsive things, discussing with other experts in the field, creating my own tools, and using and working with tools other experts have created? Toolbars that resize your screen width, and nothing more, are fantastic for demos when sitting in front of computers, but are pretty terrible everywhere else. They are made 1000% worse when screen widths (and only widths) claim to be devices. You know what I've found works much better? What Luke W advocates for, and we've all seemed to miss? Opening up my site on various devices. That works like a damn charm, every single time.

Take a look at the following tool by Brad Frost, one of the leading thinkers in the Future Friendly/Responsive Web Design "movement", his Pattern Library. Hey look! At the top! A responsive preview toolbar! This one, though, was designed for people who know what they're doing, doesn't use devices, has em and px measurements, and the S/M/L are random sizes in a general range. It even has disco mode. I love Disco Mode. Now go open that up on a mobile device, those have gone away because having large previews are messy on mobile (and honestly not particularly helpful because you're going to need to zoom all over the place). That being said, this is a responsive preview tool, again built by a leading thinker in the field, and ya know what? After the Disco presentation, that toolbar becomes totally useless to me. It's not something that's helping me on a physical mobile device, and what it's doing on Desktop can easily, and with absolutely 0 effort on our part, be replicated by simply resizing my browser window. It helps if I want to see a smaller width on a larger handheld device where I cannot resize my browser window, but that's it.

But that kind of gets to Eaton's point, suggesting that width alone is "good enough" is not, in and of itself, good enough. Let us ignore all other variables that go into good design and let's just laser focus on width. If we're making the assumption (and putting out users into the mental model of) width corresponds to device size, then we're leaving out one of the most critical parts of the devices we're talking about: they're handheld! Meaning they have different viewing distances! Meaning, again, that sitting in front of a computer (or a tablet) and idly resizing the display isn't even good enough to tell us what our content is actually going to look like at those widths across devices! What happens when we add in just screen resolution into the mix? If the point of the exercise is to see if our content looks good, there hasn't been a 1x resolution iPhone in 3 years, and the new Galaxy Note has a DPR of 3. We're doing a terrible disservice suggesting that width is the only factor a user should care about; it's not good enough, it's demoable enough.

What I find so silly about this all is we're talking about live sites. You know the absolute best way to demo what content is going to look like on a live site across multiple devices? Well, amateescu said it best:

Does "Buy a Nexus 7" qualify as relatively painless? :/

Here's the thing that those not working on the front end every day, with content strategy every day, I find tend to miss about Responsive Web Design: It's not about current devices and known unknowns, it's about future devices and unknown unknowns. Yes, previewing multiple presentation modes is important, but IMO "small web" and "large web" aren't different presentation modes, they are different sizes of the same presentation mode: web. When Karen says presentation modes, I do believe she means different presentation modes. RSS Feed, JSON Object, Mobile App, Smart Watch app, Electronic Signage. The point of different presentation modes is to show that your content doesn't just live on the Web, and the Web's presentation isn't the only one you need to care about. Having different sizes of the Web are simply different sized Word documents. Having a system where these different sizes are hardcoded to a single size each time, or worse than than named after devices, means that you're giving people let's call it 5 different sized Word documents to look at. That's not particularly helpful; no one is actually going to change their content for that. That way of displaying a size, at a half a handful's screen sizes instead of a fluid continuum (which they can get from resizing their browser) is called adaptive design, and is something that hasn't been a best practice, none the less a good practice, since before this issue went up a year ago.

Responsive Web Design is designing for the cracks. If all we're doing is providing a button to resize someone's viewable area from one fixed size to another fixed size instead of having them change their browser window's size by hand, what we've done is turn cracks into gorges. Sure it may be demoable enough, but that's not good enough.

Now for the straw men brought up (I do love burning straw men, especially now that it's getting cool).

The Preview Button

Yes. I do believe that for any non-trivial website or publishing workflow beyond a single-user blog that the Preview functionality in its current state is useless, especially if you've got an admin theme. Hell, I'll go one step further and say that for any site where content is built in chunks instead of blobs the current Preview functionality is useless. It's fantastic for WYSIWYG blobs (ya know, assuming you don't do much in the way of theming your front end), but terrible for Web displays that make use of Drupal's fantastic chunking capabilities and mixes field display with block content display. It's also kind of terrible when wanting to work with faceted related content. Or any of the other million things it's bad at. What it's really good at is providing an out-of-context preview of the body field and the title field. You know what the first thing that gets asked of me by the editors I work with? Why doesn't the Preview button actually show me a preview of what I've created, to the point we've disabled it in favor of publishing to Draft and then allowing a user to change the publish state. Is a preview of what they're getting in their Web presentation as good as true cross-presentation-mode previews? Absolutely not. Is it better than an in-line preview of the body field? Without question.

The Comment Module

This one is fun because this one starts with a false analogy. Before we burn this straw man, let's have him dance a little. If, when Comment module was being created, every browser ever made had a native, cross-browser way to leave a comment on a specific page of a website, have that comment persist across different users accessing that website, in short did literally everything the Comment module sets out to do, and all an end user had to do to show those comments was press a button, let's say next to the back/forward/refresh buttons in each browser's native UI, would Comment module have been made? Would Comment module have made it in to Core? If the entirety of the functionality of Comment module was handled natively by browsers, would we even be having this conversation? Would we even be discussing creating our own, if other commenting systems had been built by experts in the field, doing the same things we're proposing to do, and their experiences ultimately didn't improve enough upon the native experience to be worth the hassle? I think the answer is probably not.

Now, to burn said Straw Man. Pre Drupal 7 and entities, there was no real good way to attach a piece of functionality to any "entity" on the site (hell, there was no concept of entities, just nodes) so it made sense for Comment module to focus exclusively on nodes. Yes, products and profiles and orders all those other things could have comments attached to them, but before entities, the only way to really create these was through Nodes. When Drupal 7 shipped, Comment module still only supported Nodes. Should it have been pulled out? No, it provided an, and here's the key difference, existing working solution to the problem of commenting. Should it have shipped with full Entity support though? Without question. Why didn't it? There were much larger fish to fry for D7's release, and as the existence of a million modules prove (some of which still haven't been upgraded to entities), the entity system in Drupal 7 was only half baked when it launched (no disrespect to those working on it) so I'm honestly not entirely surprised it didn't. Should JavaScript aggregation have been pulled out even though it wasn't upgraded to entities like CSS aggregation was? No, for the same reason. The Comment module (and JS aggregation, and others) are oversights in existing working solutions to problems with no native browser solution. What's being proposed here is a new, controversial, and untested solution to a problem with a native browser solution.

The feature in this issue is a step in that direction. One could argue that it's an insufficient step, since the presentation options we're offering (sizes) and the ones we're leaving out (everything else mentioned in #319) fails to help content authors realize there are other variable at play than just size. But I think there's no way the web community is going to help content authors make this mental leap in one shot. It

I would be a lot less against this feature if it was being honest about the only variable it is modifying. Pretending to be a device implies a lot of other variables are under control of the preview. As it happens the naming convention in Pattern Lab was suggested about 200 comments ago.

I think the faster horses analogy by Snugug is pretty accurate. Responsive design is not about a handful of devices. In my experience the organisations that think that are the ones that are too large to shift their way of thinking and approach to the web in just a few years. If we look at the organisations that have a bleeding edge approach to responsive web design, you'll see that they have addressed the fact that their site is being accessed by many devices of different shapes and flavours. Here's a good example from the BBC called cutting the mustard.

Looking at mobile devices that are accessing our service in the early stages of our project highlighted the challenge. We have ~80 significant browsers / operating system combinations regularly using our application across the globe and a long tail of hundreds more. In the four months since we first gathered the statistics there’s been many more releases and updates - Amazon’s Fire, Apple’s new iPad, Ice Cream Sandwich, Microsoft’s Mango.

I'll provide a longer, more on-topic reply later but I wanted to point out that the discussion is getting too emotional. Hence, I feel inclined to leave a "meta thought".

As we get bigger, consensus-driven decision making gets more difficult. I believe this "Mobile preview" issue is a good example. One group of people believe this is a good idea, another group of people believe it is a bad idea, and yet other people think something differently. Long story short, we don't seem to arrive to a consensus. When that happens, we can't fall back on shouting louder and louder, nor should we bring emotional arguments to the table. Instead, when the consensus-driven decision making "fails", a tie-breaker comes in and makes a decision. I did that months ago.

Having said that, I'm happy to continue the conversation and have changed my mind on many occasions. However, this particular issue aside, I see a lot of people that hold a grudge when something is decided that they don't like -- even when that happens rarely and in areas that don't truly affect their own work. More and more, I observe that failure to accept decisions causes bitterness and a negative attitude well beyond the issue they disagreed with.

I'm happy to make more tough decision and hope to make many more (we have to!) but we can only succeed in an environment where (i) we all do a good job listening (including myself) *and* (ii) decisions are accepted without holding a grudge. We have to create a culture where people can accept decisions they don't like. Not easy given how much passion we have in the community but fundamental to the way we operate. It takes two to tango.

Thank you!

@effulgentsia:

As an analogy, consider our comment module. For over a decade, it's been limited to only commenting on nodes (and still is, though hopefully we'll get that fixed for D8). Of course there are use cases to also comment on user profiles, products, orders, files, etc. Does that mean we should have removed comment module from D7 (or any prior version), and only allowed it into core once it's been generalized to all entity types? Or was it ok for it to exist in core despite its limitation of nodes only?

If someone was proposing adding comment module to core now, and the patch only worked with nodes, then it would not get committed until it worked with entities. People have spend hundreds of hours of their own time trying to bring it up to date with the entity API (and caching best practices) this release, which hopefully gets committed very soon. As Snugnug pointed out, the entity API went into 7.x too late to get it anywhere close to complete or bring things up to date, but that's mostly been fixed this time around (obviously with lots of work to go, part of why we have around 80 critical tasks open - to ensure core gets up to date with its own APIs). There are no contrib alternatives to comment module (except for one proprietary alternative), and it's in use on lots and lots of sites as a visitor facing feature. So from both a technical and feature standpoint, I don't think the analogy holds.

On the other hand would tracker or forum module be added to 8.x if they were proposed from scratch? Certainly not without being brought a lot further up to date than they have been, and possibly not at all in anything resembling their current form. The feature set they provide is very specific and things are moving on around them both technically and in terms of how the web gets used. Removing those, while it's been proposed, is a bit harder than some other modules, not least because they're used on Drupal.org and other sites.

@Dries while ideally these discussions wouldn't get heated , I personally get very frustrated when decisions are made with no justification given. For example from this year, or 2007 or 2008. In both those cases the issues eventually got committed, but only because various stubborn people (including me), continued to argue on the issues long after the decision was made, in one case for almost seven years.

Maintaining something years after it's obsolete or turned out to be not such a good idea is not enjoyable. Especially when that happens as part of a project to which you donate hundred if not thousands of hours per year. Despite trying to avoid ever looking at Poll module, I have ten commits against it as a result of trying to get other things done. So decisions on feature addition or retention do have an impact which lasts well after the initial decision gets made, and I don't think it's fair to characterise this as 'holding a grudge'.

I'm also not sure that this issue really counts as a 'hard decision' as such. The consequences of adding the feature would be that a feature gets added to core that several people have objected to. The consequence of not adding the feature would be that it gets provided as a contrib module, and Drupal won't have a feature out of the box which some other CMSes apparently do (albeit not executed well anyway).

So it is fundamentally a different choice than deep technical (or developer experience, or usability, or accessibility) issues, where a choice has to be made to unblock other patches or the release as a whole, but there are two or more sides deadlocked over the approach. Even in those cases it's OK for people to continue to argue against the decision long after it's been made - the likely change from PSR-0 to PSR-4 is an example of people doing that very constructively.

(ii) decisions are accepted without holding a grudge. We have to create a culture where people can accept decisions they don't like.

speaking as an (opinionated) spectator on this issue, i find this statement troublesome. it strikes me as having the following implications:

  • the individuals who continue to raise objections here are doing so out of spite, not expertise. this undermines their positions via a subtle ad hominem argument.
  • once a "decision has been made," differing opinions should no longer even be voiced.

tbh, i think there is a valid reading of @eaton and @Snugug's comments that IS them "accepting a decision." i'm not saying they think they accept it, nor am i expecting or encouraging them to. but the act of stating one's objections in the public space, clearly and openly, is an essential part of consensus (esp. the "Degrees of Conflict" section). letting concerns be voiced can undermine a specific process, but keeping concerns from being voiced damages group integrity, undermining ALL processes.

if the decision's been made, then ignore the concerns. we don't actually operate by consensus, so the stated concerns can stand and be on the record, which is where they belong. acknowledge them and continue forward as dictated.

all this said, from my perspective, this seems like a particularly odd case to be so hard-line on the "a decision has been made" front, for the exact reasons @catch gives:

I'm also not sure that this issue really counts as a 'hard decision' as such. The consequences of adding the feature would be that a feature gets added to core that several people have objected to. The consequence of not adding the feature would be that it gets provided as a contrib module, and Drupal won't have a feature out of the box which some other CMSes apparently do (albeit not executed well anyway).

bravo. we're not between a rock and a hard place for an existing system. we're choosing whether or not to introduce a new core component. no consensus? put it in contrib. unless i've missed something?

tbh, i think there is a valid reading of @eaton and @Snugug's comments that IS them "accepting a decision." i'm not saying they think they accept it, nor am i expecting or encouraging them to. but the act of stating one's objections in the public space, clearly and openly, is an essential part of consensus (esp. the "Degrees of Conflict" section). letting concerns be voiced can undermine a specific process, but keeping concerns from being voiced permanently damages the integrity of the group across all processes.

Indeed. I tried to make clear in my post that I don't have strong feelings on this going into core, or not going into core. I'd been asked to weigh in on the issue and provide some perspective on whether or not it was a good approach. I agree with effulgentsia's post: the perfect can't be the enemy of the good. It's just important for us to keep in mind that this feature is a solution to a near-term problem, and does not address the much more challenging explosion of responsive and RESS variations that forward-looking designs will increasingly rely on. (Someone, please tell that to the marketing people before D8 ships!) As long as we keep our heads on straight and don't oversell it, the feature does bring valuable functionality to users, many of whom aren't even thinking about mobile issues yet.

A larger issue, and one that's more interesting, is the change that has occurred over time in selecting functionality for inclusion in core. Increasingly, major features are decided on by Dries, and the equivalent of a ticket is opened by an Acquia employee here in the issue queue. The ticket outlines what is required, what must be done, and why it must be done. In many cases, the "Why" boils down to feature-parity with another enterprise-class CMS like SiteCore or Adobe CQ, and the need to win the hearts of CxO level stakeholders in head-to-head demos.

There's nothing wrong with using those pressures to allocate resources, and webchick is absolutely correct that the BDFL position gives Dries unequivocal right to make those decisions. I think it's just a major transition for the community, who for nearly a decade regarded core as a sort of "communally owned resource," where any party's ideas required buy-in from a critical mass of other participants. During those days, Dries' influence was largely a matter of encouraging people to work on key issues in his Drupalcon keynote, and "blocking" features he felt were a bad match for core. Dries taking a more active role in the direction of core is a good thing, as it will give users and developers more confidence about the direction of Drupal's future. The downside is that some people will not like that direction, and will either protest or leave for other projects. That's preferable to endless drifting.

Several years ago, I tried to hammer out a set of proposed heuristics for deciding whether functionality should be added to core or not. In an earlier discussion in #drupla-contribute,, webchick expressed disappointment that I had let that drop off. I think it's worth pointing out that high-level decisions about Drupal functionality are no longer inherently consensus-based community decisions. Rather, some decisions are left to the community. What individuals can and should do is decide for themselves what issues and projects they are passionate about, and work on them. I think there's a lot of anger and frustration that stems from confusion around this transition, and it often bubbles up in issues where the distinction is unclear.

Status:Needs work» Needs review
StatusFileSize
new2.14 KB
new91.54 KB
PASSED: [[SimpleTest]]: [MySQL] 59,637 pass(es).
[ View ]

Rerolled the patch so it passes on head again. I think this is useful regardless of whether this goes to core or not. People can still try it out then and provide feedback based on that understanding.

Issues identified:
- delete controller now needs a cancel route provided not a cancel path
- the tab .yml file had plain wrong syntax
- the form title should use #title and not _title the later is for the .yml (confusing, yeah)

This passes and works manually fine for me.

Status:Needs review» Needs work
StatusFileSize
new173.74 KB
new41.33 KB
new114.77 KB
new18.94 KB

Patch applies well. Thanks Gábor!!

Everything seems to work like a charm but I have found a weird thing and I am not sure if it's a bug or not. All devices can be scrolled down, I mean the window browser scroll, not the device scroll. But with iPhone 4 it seems not working.

Added new device and tested that works well too.

I have attached some screenshots to show that it working well except this little issue:

Menu is working well
preview-menu.png

New device created
device-list.png

New device working well
new-device.png

iPhone4 scroll issue
iphone4-no-scroll.png

Marked the issue as "needs work" to fix the small bug. If I'm wrong just tell me :)

I think you're probably right @rteijeiro. I'm going to guess that the edge collision detection isn't taking the border height sufficiently into consideration here such that scrolling would be triggered. I'll just need to adjust the line of code that does that calculation. Great catch!

I would like to fix it but I'm afraid it's really hard to me :'(

rteijeiro, you can definitely get this. Here's the code that's doing the scroll calculation in responsive_preview.js around line 733.

// Resize the scroll pane.
var paneHeight = height + (this.bleed * 2);
// If the height of the pane that contains the preview frame is higher
// than the available viewport area, then make it scroll.
if (paneHeight > (document.documentElement.clientHeight - offsets.top - offsets.bottom)) {
  $scrollPane
    .css({
      height: paneHeight
    })
    // Select the parent container that constrains the overflow.
    .parent()
    .css({
      overflow: 'scroll'
    });
}
// If the height of the viewport area is sufficient to display the preview
// frame, remove the scroll styling.
else {
  $scrollPane.css({
      height: 'auto'
    })
    // Select the parent container that constrains the overflow.
    .parent()
    .css({
      overflow: 'visible'
    });
}

I think the solution lies in how paneHeight is being calculated. Maybe there's another UI element that needs its height taken into account so that the available area is less and thus triggers scrolling sooner, so we don't get pieces of the preview frame outside the viewport without a scrollbar.

// Resize the scroll pane.
var paneHeight = height + (this.bleed * 2);
// If the height of the pane that contains the preview frame is higher
// than the available viewport area, then make it scroll.
if (paneHeight > (document.documentElement.clientHeight - offsets.top - offsets.bottom)) {
...

Are we accounting for a fully expanded toolbar? Also, if someone is using Panels In-Place Editor, it'd be ideal to take that into account too, if possible. Those are the main UI elements I can see eating up a lot of space.

Status:Needs work» Needs review
StatusFileSize
new1.28 KB
new91.62 KB
PASSED: [[SimpleTest]]: [MySQL] 58,767 pass(es).
[ View ]

Just fixed adding the toolbar submenu (toolbar-lining) height that was the problematic element :)

Not sure if my code is pretty enough but it works.

Status:Needs review» Needs work

ah! that's what was causing the problem. We should be able to get that value from Drupal.displace rather than making the Responsive Preview module know about the Toolbar module so intimately. If we're already taking the top displacement value into account and the horizontal toolbar isn't part of that value, then this is a problem with Drupal.displace.

You can see the displacement values at any time by running Drupal.displace() in the browser Console.

Status:Needs work» Needs review
StatusFileSize
new1.3 KB
new91.56 KB
PASSED: [[SimpleTest]]: [MySQL] 59,318 pass(es).
[ View ]

Great! Thanks @jessebeach. Didn't know about Drupal.displace() :)

I guess now it is better.

if you're just getting the value don't call the function displace only use it as an object.

@nod_: Just tried with Drupal.displace.top and it doesn't work. I have found the same use Drupal.displace().top in core/modules/comment/js/comment-new-indicator.js file so that's because I used that. Is it correct?

Drupal.displace.offsets.top should work.

StatusFileSize
new1.31 KB
new91.57 KB
PASSED: [[SimpleTest]]: [MySQL] 59,048 pass(es).
[ View ]

Thanks @nod_!!

Maybe we should fix that also in core/modules/comment/js/comment-new-indicator.js file ;)

Attached an interdiff with #343

#349: yes, please! But do that in a separate issue — I'll RTBC it :)

Hm ... simplytest.me doesn't show the responsive-preview icon after applying responsive-preview-1741498-349.patch (#349). No matter whether I choose Drupal 8.x-dev, Drupal 8.0-alpha4 or Drupal 8.0-alpha3.

@the_phi: Did you tried to enable the responsive_preview module first?

No, I didn't. Sorry, wrong alert/alarm, @rteijeiro! In Spark the module is enabled by default -- I must have gotten used to that. With Drupal 8.x-dev it works just fine (superficially judging, obviously)!

There's been a lot of discussion on this, so I'm reluctant to add anything. It's clear that Dries has decided that A) this feature should go in, and B) this feature should have device names rather than size labels, despite all the advice to the contrary.

Dries has the right to do that, of course. And I can understand that perspective.

For a content editor who wants to preview content before it is published, and who likely is not familiar with all the concepts that go into responsive design, an option to preview how the content would look on an iPhone is probably easy to grasp.

I think that's better than a "Preview" button that just shows how the content looks on whatever device the content editor is currently using. Even if device names don't paint the full picture, at least it's one opportunity to get content editors to understand their content is going to look different depending on where it appears.

This preview option is not a replacement for more full-featured tools that help themers and front-end developers to change the layout of a site and adjust breakpoints. I still hope we can get the Responsive Layout Builder functioning, as that's going to make a big impact on making it easier to develop responsive sites in Drupal.

I think the best that you can hope for with this preview option is that the content editor can spot some broad issues that could pop up at small or large screen sizes. Maybe a content editor puts a table on a page and realizes that it doesn't work very well at a small screen size. Or maybe that image that looks great on a phone looks really small on a desktop, and the content editor realizes that the wrong option was picked when inserting the image, then goes back and picks the format that flexes with screen size (even if the content editor doesn't know the details of what is happening with the picture module).

I saw this picture today, of a device testing lab: https://twitter.com/kylebarrow/status/392970944957788160/photo/1

That's a lot of devices. 900 or so in fact. On the site I manage, we had 350 different mobile devices access our last month. There were about 200 or so different screen resolutions.

So I get nervous about putting three or four device names into core.

Yes, those can be updated with point releases of Drupal, and if we're lucky, site owners will make those updates and see the new device names. And yes, a proactive site developer can manually update device names and specs to give a content editor new options.

Maintaining that list of device names that gets updated in point releases is one more thing that has to be monitored over the next few years. And each time an update gets made, that's another opportunity to bikeshed whether there are too many iPhone options listed, or not enough Samsung options, or Windows Phone, or whatever. I'd expect we'll get to have a lot more 300+ comment threads over the next few years with plenty more fun debates on devices.

Whatever we do, though, it's really important to keep in mind that this tool is not the same thing as a content editor dropping by a device testing lab with a wide range of devices each and every time a page is posted. And frankly, that would seem like a crazy thing to do. You use a device lab when you're creating a site, not when you're maintaining the content on that site.

What we want is for content editors to consider that their content will appear on different devices, and maybe catch some major issues that might not be apparent otherwise.

Putting in device names might make it easier for content editors to "get it" faster. Device names also might make those content editors focus on just the default devices and not realize that there are a lot of other devices out there with in-between screen sizes.

Device names are also going to be a much bigger maintenance hassle.

There are a few generic labels that might work: Phone, tablet, laptop, desktop. But the definitions of what means in terms of screen size could also change over time. Is a phone 4 inches? A tablet 7 or 10 inches? Is a laptop 11 inches, 13 inches, 15 inches? Desktop 20 inches or 27 inches? How do those physical sizes translate to pixels?

The same is true with labels like small, medium, large, extra large. What does that mean in terms of pixel? Is what we think of as small today going to be the same thing that we think of as small in a few years?

I'm not really sure. I love Brad Frost's Pattern Lab, and his Ish tool is great. Showing content editors Disco mode would probably freak them out but get the point across.

As I think about this more, I don't know that we can pick any one set of labels that is going to mean the same thing in terms of pixels over the next five years. So if device names are easier for content editors to grasp conceptually out of the box, maybe that will work.

But I agree with what others have said that it's important to keep in mind that by putting this into core, we are committing to maintain that list of device names over time and to deal with changes in browsers that could foul this up (as the Firefox glitch demonstrated).

The fact that many of the people most interested in front-end development and mobile disagree with the device name approach is concerning, because if there isn't buy-in, then we're likely going to continue to have this debate every time a device name update is suggested over the next half-decade of Drupal 8's maintenance life, and beyond if this stays in Drupal 9.

I've yammered on far too long. Short version: probably best if we fix the last outstanding issues and get this committed, device names and all. I think this provides a useful feature for content editors, even if it's going to be a pain to maintain.

According to your existing entry, the iPad (4/5-Air) has a resolution of 1536×2048 pixel in combination with 2 dppx.
Now, how does this correspond to its publicly propagated pixel density of 264 ppi?

Why am I asking this superficial question (I am, admittedly, completely new to dppx!). The reason is quoted just below and stems from http://www.w3.org/TR/css3-values/#resolution:

Note that due to the 1:96 fixed ratio of CSS ‘in’ to CSS ‘px’, ‘1dppx’ is equivalent to ‘96dpi’.

Well:

  • Isn't it either 2dppx, which then should correspond to 192ppi (2 x 96ppi)?
  • Or rather 264ppi, but then 2.75dppx (264ppi / 96ppi)?

I also checked http://dpi.lv from Lea Verou. In her list I seem to be able to discover lots of inconsistencies/discrepancies. Could someone briefly explain this to me, please?

@the_phi: Also, what about the new iPad Mini with Retina Display? It has the same resolution as the larger ones only a physically smaller display.

@DamienMcKenna: This results, very clearly, in an increase of the pixel density, expressed in ppi. Some mistakenly use dpi instead.
However, I don't seem to fully understand the relation between ppi and dppx (dots per 'px' unit)! In addition to this, I just cannot see any dots on any of my screens. For me, dots are something printed on paper.

I haven't read all comments. But I have the impression no-one, saying the device- or screensize-specific preview functionality isn't sufficient, already has started an issue proposing a better alternative.

I hereby invite you to #2123085: Add preview options

Issue summary:View changes

...fixed minor typo and added more detailed description of UI changes while at it.

Testing comments.

Issue summary:View changes
StatusFileSize
new96.83 KB
FAILED: [[SimpleTest]]: [MySQL] 59,818 pass(es), 1 fail(s), and 4 exception(s).
[ View ]
new7.75 KB

The scrolling issue in #338 ended up being a miscalculation of the preview frame positioning. In this case, the top position of the frame was not taken into account. This had nothing to do with Drupal.displace.

-      if (paneHeight > (document.documentElement.clientHeight - offsets.top - offsets.bottom)) {
+      if ((paneHeight + $container.position().top) > (document.documentElement.clientHeight - offsets.top - offsets.bottom)) {

I've also ported a few fixes from the Responsive Preview project 7.x branch. I found these issues while backporting the 8.x code and working with the non-responsive themes in 7.

All of the changes are represented in the attached interdiff.

There are no known outstanding issues as of this patch.

Issue summary:View changes

I can confirm those errors about MENU_CONTEXT_INLINE on localhost. There are no matching change notices, but #2084463: Convert contextual links to a plugin system similar to local tasks/actions is the most likely culprit.

Issue summary:View changes

StatusFileSize
new5.63 KB
new90.71 KB
FAILED: [[SimpleTest]]: [MySQL] 59,920 pass(es), 2 fail(s), and 2 exception(s).
[ View ]

It is a little bit astonishing that noone spotted the usage of the old local tasks API yet, but well 3 months seems not to be that much time given the age of this patch.

Here is a patch which adds contextual_links, local_tasks as well as some minor changes here and there.

StatusFileSize
new1.59 KB
new90.86 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch responsive-preview-1741498-370.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Awesome, thanks dawehner!

One small thing. You deleted

</code>, which is necessary to determine a unique machine name. I see this pattern in other modules, like custom_block.
<code>
- * Fetches a responsive preview device by ID.
- *
- * @param string $id
- *   A string representing the device ID (machine name).
- *
- * @return
- *   A fully-loaded device object if a device with the given ID exists,
- *   or FALSE otherwise.
- */
-function responsive_preview_device_load($id) {
-  return entity_load('responsive_preview_device', $id);
-}

I'm putting this function back as I don't see an alternative to callback pattern to load an entity without a wrapper function (unless we do something fun like Closure::bind()!).

There was also some dead code in DeviceFormController.php

/**
* {@inheritdoc}
*/
public function delete(array $form, array &$form_state) {
  $form_state['redirect'] = 'admin/config/content/responsive-preview/manage/' . $this->entity->id() . '/delete';
}

The tests that failed are passing locally now, so here we go!

Status:Needs work» Needs review

Status:Needs work» Needs review

And testbot is happy now.

And testbot is happy now.

It's sad to read this thread. It's more sad to see this feature treated like it's some kind of gift to users (ostensibly because someone said they'd like it). I agree with the arguments against this kind of feature -- and especially against the naming of presets according to device names. I see a lot of voices of people who work with clients every day raising valid objections, and maybe it's just me, but I'm not seeing a lot of arguments why this is such a killer feature. In the end, I see this feature as something that sounds nice on paper, but ends up being a club for clients to use on their developers. "Why doesn't the site on my Nexus 5 look like it does in my preview?"

Also, btw, it's especially misleading to use pixel width on anything labeled "HDTV" (which I saw in one of the screenshots). Everything is different there.

The rest of my thoughts are in the meta thread.

@mdrummond makes a very good point in #355 (lengthy but worth a read):

By exposing device names, you presume that I'd know what these names stand for.

(In fact, even I have no idea, 'cos I'm a software geek, not a hardware geek.)

Since the preview won't be accurate anyway, it might make more sense to select by technology (desktop → laptop → mobile → tablet → ...) and applicable variations (dimensions → widescreen/portrait → retina → HD[TV] → ...), which might be easier to understand by users.

Standard browser bg is white, this makes its #212121, I suggest setting #fff on .responsive-preview-frame-container iframe {}.

Also I tend to think the .responsive-preview-frame-container would look sharper with less border radius, perhaps just 8px? Right now the 20px looks really rugged on my monitors, reducing this softens it quite a bit.

StatusFileSize
new90.69 KB
PASSED: [[SimpleTest]]: [MySQL] 59,361 pass(es).
[ View ]

No longer applies due to this hunk, since Overlay was removed:

***************
*** 31,43 ****
    new contextualToolbar.VisualView(viewOptions);
    new contextualToolbar.AuralView(viewOptions);
-   // Update the model based on overlay events.
    $(document).on({
      'drupalOverlayOpen.contextualToolbar': function () {
        model.set('overlayIsOpen', true);
      },
      'drupalOverlayClose.contextualToolbar': function () {
        model.set('overlayIsOpen', false);
      }
    });
--- 31,51 ----
    new contextualToolbar.VisualView(viewOptions);
    new contextualToolbar.AuralView(viewOptions);
    $(document).on({
+     // Update the model based on overlay events.
      'drupalOverlayOpen.contextualToolbar': function () {
        model.set('overlayIsOpen', true);
      },
      'drupalOverlayClose.contextualToolbar': function () {
        model.set('overlayIsOpen', false);
+       model.set('isVisible', true);
+     },
+     // Update the model based on Responsive Preview events.
+     'drupalResponsivePreviewStarted.contextualToolbar': function () {
+       model.set('isVisible', false);
+     },
+     'drupalResponsivePreviewStopped.contextualToolbar': function () {
+       model.set('isVisible', true);
      }
    });

So here's a re-roll for that; however, it seems odd that Contextual module's JS has code in it for either Overlay or Edit or Responsive Preview. Contrib definitely can't get away with that. So it seems these events should be added through some sort of "alter" equivalent within their respective modules. Might be a separate issue to add such a capability to contextual module (or I might also not understand how JS works :P~).

Didn't address Jeff's comments, since I was just going for getting this patch to apply to HEAD again.

StatusFileSize
new91.03 KB
PASSED: [[SimpleTest]]: [MySQL] 59,387 pass(es).
[ View ]

And, honestly? If we're going to do this, it should really be enabled by default in the Standard profile. The big benefit of this feature is informing content authors of the fact that previewing on whatever device they're authoring on is not remotely sufficient, and giving them a well-integrated CMS tool with which to attempt this without spending $10,000 in hardware. But if the tool is not on OOTB, then we are not really achieving this.

So here's a re-roll again that just adds the module in standard.info.yml. (Sorry, I don't know how you fancy kids nowadays do interdiffs. Get off my lawn. :P)

Enabling the module in Standard profile is a huge change, and I think it is not really fair to make this change in comment #382 of an issue. This detail was not at all discussed so far, as far as I'm aware.

It might be that everyone just assumed that it would be enabled by default, but that's neither here nor there if no one found it important enough to discuss. I for one regularly looked at the patches to make sure that that was in fact not the case.

This issue is incredibly loaded with a huge arsenal of opinions already so I think it would be best to leave yet another debate out of this issue and discuss that in a follow-up.

Well we all knew that was part of the agenda anyway :). I agree that its more fair to the community, if we don't push it to standard at #382. The only reason I didn't spend more time on this issue, is because I knew it wouldn't be on by default.

I still find this issue strange, that despite the significant amount of valid concerns against the current implementation of device names the Spark team does not concede to implement the community its wishes. An RTBC here, would from my point of view not be that of the community, but a small subset that is (most of whom) are directly involved with the development.

Sorry for the bluntness, but I see so many valid constructive comments against it, and such few constructive comments for it. We are not at a stalemate, which is what Dries makes it sound like in #333 - we are at a clear point where loads of people disagree with the decision to put devices names in, and a small subset is for it. I think its OK, for this feature to go in - but I'd like it to go in without the major flaw in its design.

I hope to still see the long on topic reply from Dries to explain his position. Because right now, I have no idea why we can't just postpone the discussion about putting specific devices in the list is a followup.

I was not following this for a good 150 comments, but really hoping this gets resolved by constructive leadership.

Sure, #381 is fine, too. I was playing with the feature some more yesterday and it seemed like it made more sense given the goals, but I'm happy to push that to a follow-up, assuming this makes it into core.

The Spark team is coding Dries's wishes, because Dries is the Drupal project lead, and he specifically asked for it to be done this way. When he once again has time to review this (it's not a priority atm with all the actual beta-blocking stuff going on), the issue summary's been updated with the arguments pro/con for him to take a look at.

Status:Needs work» Needs review

Maybe we need some testbot feedback?

The way I see this there is a #7th con not included in the issue summary - that device names impede usability, not increase it as is contended in the summary. I can see others have argued something similar, but that has generally taken the line of users being misinformed, or mislead regarding the accuracy.

#4 Specific device names are easily recognized by non-techie content authors.

I'd like to examine that more closely because it doesn't really sound like something we can presume.

Practically everyone knows about device groups, either explicitly or implicitly. Explicit knowledge means they understand device groups exactly, without any doubt. Implicit means they know about them, or have heard of them, or just have a general idea of what Tablets and Smartphones are.

Expecting users to learn actual device names is a more demanding task than leveraging this pre-existing, near universal implicit knowledge of Smartphone, Tablet and Desktop. The issue summary appears to take it at face value that everyone has explicit knowledge of what the devices listed are - I strongly suspect it's not that simple.

Included are two Google Nexus devices. These are marginal, low sales devices in many countries, including my own. The point being that most users lack even tacit knowledge about the vast majority of mobile devices. A default list of devices will always be wrong on some level.

Including multiple device named options such as iPhone 5 and Nexus 4 may well increase the time it takes to complete the task (task performance load), simply because you have more options than is functionally necessary to complete the task, i.e. "a quick preview". Users should not be particularly interested in the difference between iPhone 5 and Nexus 4. All they need to care about is that it looks OK in a Smartphone.

It's a plausible argument that as soon as you go beyond groups you're into specialist territory. I mean if you really need iPad Air, because you're on a corporate network and everyone is issued with that particular device, then you have the option to add that device by name.

If front end developers can build entire sites and themes with device group previews (they can), then surely it stands to reason that including device names to facilitate basic content previewing is clearly unnecessary - device groups are easier to understand than actual device names. You don't need to know if this preview is for iPhone 4/5/6/7, all you need to know is that you're previewing for Smartphone.

The maintenance issue has been raised as pertaining to cores ability to keep up - but that is only half the equation. What you also ask is that all content authors also keep up with the latest and greatest devices. Smartphone, Tablet etc are not likely to change in the next five years IMO, although we may get new classes/groups of devices (glasses, watches etc), it's possible of course that a new groups could become broadly popular. Watches I think might be a space to watch :)

My conclusion is that using real device names (brand and model names) actually make the preview harder to use, not easier. Maybe not very much harder, but I do believe it's a misnomer to put that in the "pro" column. Afaict very little has been presented to support that assertion, it appears to be presumed.

I have been using device groups for more than two years in contrib, the relevant version has 40 000+ users and I am yet to have an issue about this. Granted it's not for a preview, however the user base is very diverse from low skilled non-technical people right up to very experienced web developers. It clear to me that right across the board people understand the concept of device groups.

I know there are holes in my argument, there will be in every stance on this issue and you may not agree with me, I can only express my professional experiences with this issue. At the end of the day I am not that personally invested in this to be frank, however I do think this is a pretty big mistake to ship with device names, and that device names have not been well argued for.

If you want to rebut then go right ahead, I will probably not reply, these days my ability to be involved with core is very much curtailed. I will try but lets face it, a lot has been said and even I am not entirely sure I have said that much that is new, I think some of this is embedded in comments already, at least to an extent.

Personally I like the preview feature. I think it's important even, and from what I can tell there is considerable buy in on this feature, save for this one very important and divisive issue, and in that I very much agree with #384.

I agree with #387. Maybe we should use small phone, medium phone, large phone, small tablet, medium tablet, large tablet and leave it at that? As stated, users can add specific resolutions and name them as desired if the need arrises.

Tested #382 patch and seems to work fine.

Regarding #387 and #388 discussion:

- Did you tried the module?
- Did you noticed that you can delete those device names and create new ones?
- IMHO, I think those elements are only sample names and they are only for demonstration purposes not for branding or something similar. I don't see the problem in having these or different device names as soon as you can delete them and create your own devices with your custom names and sizes.

We should focus on test the module and make it RTBC as soon as possible ;)

One other small bug that came up in the demo today was the responsive preview icon still shows up even on the iPhone sim which is obviously not wide enough to preview in anything. Clicking the icon causes it to disappear.

#389 I have been using and evaluating the patches on and off for some months. Perhaps tl:dr or maybe the usability argument I am making is not clear enough?

In the issue summary using device brand names is under "pros", but without any solid evidence or argument to support that presumption.

I say that using device brand names is not easier to use, in fact it's highly likely they're harder to use, for all the reasons I already stated in #387.

I've called into question the maintenance argument, because that's not been fully debated, again, well outlined in #387.

I am testing the module - I am raising a UX issue, and while there is an issue open for that already, I see very few reasons why this issue cannot be postponed/blocked by the naming convention issue, given the majority here disagree with the current approach, and it's clearly a divisive issue.

That does not preclude you continuing to test and perfect the module while that goes on.

Issue summary:View changes
Status:Needs review» Needs work

Totally agree @Jeff but I think this discussion should be addressed in #1920554: "Finalize" the device list shipped with Drupal core's responsive preview module that IMHO is the correct issue for that. This issue has almost 400 comments that makes hard to follow the conversation.

Updated summary with error reported by @webchick in #390.

Status:Needs work» Needs review
StatusFileSize
new91.02 KB
PASSED: [[SimpleTest]]: [MySQL] 59,742 pass(es).
[ View ]

Rerolled, changes to MAINTAINERS.txt no longer applied.

I also made a small change to responsive-preview.js. I discovered a race condition issue in the Drupal.behaviors.responsivePreview.attach method that would cause the Toolbar tab to not fully initialize if the context was not correct on the first pass. The changes are shown in the interdiff.

StatusFileSize
new1.09 KB

Annnnd the interdiff for #393.

Status:Needs review» Reviewed & tested by the community

#393 works, for me! Changing status to RTBC.

Status:Reviewed & tested by the community» Needs work

Sorry, that one was rolled from #382, which adds this module standard profile. We need to remove that hunk and discuss it separately.

Oh, I've lost the overview! Which patch should get tested, actually?

No, that's the right patch, just it needs a re-roll to remove that hunk. :)

Status:Needs work» Needs review
StatusFileSize
new0 bytes
PASSED: [[SimpleTest]]: [MySQL] 59,932 pass(es).
[ View ]

Responsive Preview removed from Standard Profile :)

Ui, 0 bytes!

StatusFileSize
new91.66 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch responsive-preview-1741498-401.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Fixed 0-byte-#399!

Status:Needs review» Needs work

The last submitted patch, 401: responsive-preview-1741498-401.patch, failed testing.

StatusFileSize
new90.68 KB
PASSED: [[SimpleTest]]: [MySQL] 59,879 pass(es).
[ View ]

Something with the editor, sorry.

StatusFileSize
new90.68 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch responsive-preview-1741498-404.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Why did it not do the testing? Again!

Status:Needs work» Needs review

Oh, you need to set the issue status back to "needs review" when you upload a new patch. Testbot ignores "needs work" issues.

Status:Needs review» Reviewed & tested by the community

Back to RTBC.

Status:Reviewed & tested by the community» Needs work

The last submitted patch, 404: responsive-preview-1741498-404.patch, failed testing.

Status:Needs work» Needs review

Status:Needs review» Needs work

The last submitted patch, 404: responsive-preview-1741498-404.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new90.68 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch responsive-preview-1741498-411.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Again: same patch, new number!

Status:Needs review» Needs work

The last submitted patch, 411: responsive-preview-1741498-411.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new90.49 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch responsive-preview-1741498-413.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

NULL comment, current system patch!

Status:Needs review» Needs work

The last submitted patch, 413: responsive-preview-1741498-413.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new90.52 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch responsive-preview-1741498-415.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

#403 was a pass, #404 not. Same patch! WTF?

Status:Needs review» Needs work

The last submitted patch, 415: responsive-preview-1741498-415.patch, failed testing.

Status:Needs work» Needs review

Status:Needs review» Needs work

The last submitted patch, 415: responsive-preview-1741498-415.patch, failed testing.

The patch in #415 is corrupted and doesn't apply. I'm rerolling it now.

Status:Needs work» Needs review
StatusFileSize
new90.57 KB
FAILED: [[SimpleTest]]: [MySQL] 59,425 pass(es), 10 fail(s), and 3 exception(s).
[ View ]
new3.48 KB

I made this patch from #393 and removed responsive preview from the standard profile.

There was a conflict in contextual.toolbar.js.

I also had to make changes because of #1800022: Update Backbone and Underscore. In Backbone 1.0+, options are no longer included on the instance when the initialize is invoked. Options are passed as an argument to initialize.

The last submitted patch, 420: responsive-preview-1741498-419.patch, failed testing.

Status:Needs review» Needs work

Testbot, please stop being lazy. :\

Status:Needs work» Needs review
StatusFileSize
new90.75 KB
PASSED: [[SimpleTest]]: [MySQL] 59,445 pass(es).
[ View ]
new5.3 KB

Testbot is not to blame this time :) There were legit test failures. entityInfo changed from an array to an object, so we needed to change entityInfo['label'] to entityInfo->getLabel().

Also, the API for tabledrag options seems to have changed as well.

I also changed all the Backbone.Event.on/off invocations to Backbone.Event.listenTo/stopListening invocations. I neglected to do this in #420.

Tests are passing locally. Let's see what the bot thinks.

Status:Needs review» Needs work
StatusFileSize
new46.86 KB
new47.66 KB

Works perfectly on Home page & Article pages.
Breaks on Admin pages...

Add Article PageExtend Page

hmmm, it shouldn't be rendering on admin pages at all. Something has changed in the Matrix.

Just remembered I hadn't seen any activity on this in a while. Would still really like to see this get in.

...keeping only latest patch visible might help ;)

Pages