Going to assign this to Kevin to see if he can provide some feedback here.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webchick’s picture

Assigned: tizzo » Unassigned

Oops.

tkoleary’s picture

Assigned: Unassigned » tkoleary
attiks’s picture

Assigned: tkoleary » tizzo

FYI: The UI is still far from finished, but all help is appreciated. I created balsamiq mockups in #1734642-7: Move breakpoint module into core feel free to use them.

Gábor Hojtsy’s picture

@tkoleary made some interesting design proposals that he posted at https://projects.invisionapp.com/share/J66DW0KQ (press shift to see where to click). We tried to use the current user interface and at least I was pretty confused, needed direct handholding from attiks. The UI proposal takes some different approaches, eg. editing the breakpoint widths direct instead of media queries for embedded stuff. This is a level of detail the layout editor we are working on for Drupal 8 needs. A good question is whether this looses us significant features. The theme level breakpoints at #1775774: Allow themes to identify their breakpoints to Drupal use media queries as well.

attiks’s picture

FileSize
115.14 KB

@tkoleary thanks for the work you did, nice!

The excellent news

  1. Breakpoint sets sounds better than breakpoint groups
  2. UI looks much better: starting from a list of breakpoint sets with a dropdown button thingie

The relation between the different parts is a bit strange, so I made a quick screen how it should be from a functional standpoint:

  1. Each breakpoint set consists of multiple breakpoints (BP)
  2. Each BP has some general info: source, status, name, media query, multipliers
  3. The grid (and picture) module uses these BPs and act like plugins for breakpoints

breakpoint_edit_plugins.png

Functional problem

How are we going to change the MQ inside a BP when people start changing the width of a step?
1/ allow people to change the MQ
2/ grid module changes the MQ using javascript
3/ grid module changes the MQ on save

tkoleary’s picture

@attiks this is awesome feedback. Thanks!

Let me see if I can clarify a few things about the behavior of the UI.

If the user wants to change the position of a breakpoint they can drag the left/right arrow affordance directly above the breakpoint label in the steps widget. Doing so will do three things:

1. update the breakpoint value as the user drags.
2. On release, dirty the form with the new position of the breakpoint
3. Update the grids widget as the user drags to change the width of the visible step

One unavoidable consequence of this is that if the user drags the breakpoint to a place where the new step width is now less than the user-specified container width for that step we would need to change the container width value automatically. My inclination is that the users expectation of what should happen is that the "margin" of the container would change in proportion to the new step width. Therefore if the user has specified the container width in pixels or EMs we would need to:

1. Convert the value to %
2. Recalculate the value based on the new step width
3. Convert the value back to the original units
4. Dirty the form with the new value

As far as the question of MQs from the theme. IMHO getting the media queries from the theme violates the spirit of the direction of layouts in core is moving which is that markup and layout CSS no longer resides in the theme but is now global to the site. Obviously this is a big unresolved question but from my perspective the way this should work is:

1. There are no MQs in the .info file
2. There are default MQs in drupal that map to our understanding of the 80% use case
3. The user can specify MQs using the drag drop tools in the UI
4. All MQs are min-width to avoid ugly conflicts
5. The MQs are visible to the user but not editable outside the tools that the UI provides

As far as the rest of your mock is concerned I think it's great. I love the inlining of the multipliers into the breakpoint table. I love showing all of the options for a set on one UI, I love showing all image styles for one set together in one fieldset. I will incorporate all of this into the designs right away.

RobW’s picture

Removing breakpoints from the theme and making them only available in the ui is a horrible idea that kills any use that this module could have for professional developers. If breakpoints-the-module is going to become part of the layout builder and be used nowhere else, fine, but if it's meant to be an API to share breakpoints between themes and modules for all use cases that just won't work.

Also, there aren't "default media queries that map to the 80% use case" unfortunately. Breakpoints are design specific, not device specific, and I don't think there's any value in defining them apart from a specific visual design.

Gábor Hojtsy’s picture

@RobW: what does a theme do with its breakpoints if defining layouts is not at all in the responsibility of the theme?

webchick’s picture

Assigned: tizzo » Unassigned

That assignment to tizzo was a snafu.

tkoleary’s picture

Re: Also, there aren't "default media queries that map to the 80% use case" unfortunately. Breakpoints are design specific, not device specific, and I don't think there's any value in defining them apart from a specific visual design.

The defaults are just a starting point, if you don't like where a break point has been placed by default just grab it and move it. The advantage to the site builder of setting default breakpoints that give us steps for, say smartphone, tablet and standard (laptop/desktop), is that then we can also provide default layouts for each of those steps. Then what the site builder gets out-of-the-box is a default layout experience that approximates what 80% of the sites on the internet do. From that point the customization to a specific design you talk about is pretty painless and we've removed several hours of time the site builder would have spent re-inventing that wheel.

attiks’s picture

#6

  • "markup and layout CSS no longer resides in the theme", I hope this isn't true or that I misread/misunderstand it.
  • "All MQs are min-width to avoid ugly conflicts" grid builder can do this, if it creates their own breakpoint set and breakpoints, but themes and the picture module are going to use full MQ.

#6 and #7 the breakpoints module will be a dependency for grid builder (and picture). Themes have to be able to define breakpoints using full MQ so other modules (like picture) can react on them

#8 Themes can still define layouts the use of layout/grid builder is optional, no?

The 'problem' with grid builder is that it depends on px values, the easy solution is that grid builder define their own breakpoint set and breakpoints so they have full control. In theory they can change all other breakpoints as well, but since it's hard to tell if an other module is using them, they might break the site.

attiks’s picture

#10 gridbuilder can indeed provide some default breakpoint set(s), containing only breakpoints using min/max-width MQ's, but it should allow people to use full MQ's as well. Maybe grid builder should provide an advanced mode not using the fancy (and easy to use) drag & drop, but making it possible to use a real MQ?

Off-topic: please don't name them smartphone, tablet because it indicates a device

Gábor Hojtsy’s picture

The layout/gridbuilder IS optional, people can still hardcode whatever they want if they want to. Whether hardcoding themes is a best practice for all or the opt-out for those needing absolute precision and control is the question.

As for the gridbuilder, it can already build flexible grids, which are in no way tied to pixels, their gutters and paddings are set in ems even :) Of the 5 grids that Spark currently ships with 3 are flexible and only those are used in the default layouts (to promote non-fixed, non pixel-tied grids).

attiks’s picture

#13 but the gridbuilder still needs a px/em value for each step to display the preview unless I misunderstood the design in https://projects.invisionapp.com/share/J66DW0KQ#/3040789 and when I looked at the code at DrupalCon the px width was needed for the preview only, right? That's why I added the approximate width to my patch.

For the css output the full MQ can be used.

To be clear: I'm talking about the steps, not about gutter/padding

Gábor Hojtsy’s picture

The gridbuilder only needs widths IF the grid is fixed width. In that case it does need a concrete width, otherwise it does not matter.

attiks’s picture

@Gabor so the principle of extending breakpoint set edit page (#15) is ok for you?

RobW’s picture

If the defaults for 80% you're referring to are default breakpoints for responsive design templates provided by Spark, that makes sense. Defaults outside of a theme provide no value though -- design defines breakpoints, pure and simple. There is no "desktop" breakpoint in a site who's "tablet" layout looks good on large screens.

Every front end developer I know has no interest in the visual tools for layout being included in D8. We do want the functionality that's been laid out in breakpoints, though; I don't want to see the initial ideas behind this module be simplified in service of the layout module. If developers can't write full powered media queries that work with a Drupal API (Talking about the API here, not the GUI), they'll write them in the theme, not abandon them for min only.

  • "markup and layout CSS no longer resides in the theme", I hope this isn't true or that I misread/misunderstand it.
  • please don't name them smartphone, tablet because it indicates a device.

+1 on both.

RobW’s picture

What does a theme do with its breakpoints if defining layouts is not at all in the responsibility of the theme?

This is a huge re-definition of what a theme is, and I haven't seen any issues that directly propose this. If it's an underlying theme of Spark, it would be good to bring it to its own issue so that those of us who don't have a grasp of the whole project can understand the direction it's going.

For those of us who aren't planning on using the layout builder, breakpoints will still be the responsibility of themes.

jessebeach’s picture

The units of a media query width or height declaration must be a length. Some are relative, sure, but an absolute value can be approximated from a relative unit for the purposes of giving the user a UI for interacting with their responsive steps in relation to one another.

http://www.w3.org/TR/CSS2/syndata.html#length-units
http://www.w3.org/TR/css3-values/#lengths

The layout builder uses pixels now only because I ran out of time during the first development phase to make the unit support more robust. We'll want to support at least px and em.

I added similar comments to #1775302-30: Do a UX review of Breakpoint module, but I'll repeat one point here:

"What the proposed design does right now is it hides the complexity of media queries from users as a default. They define the min-width of a breakpoint with the slider. It makes it impossible to define two breakpoints, one at 320px and the other at 768px, and then reorder them so that the 768px breakpoint is listed before the 320px in the the group list. It also prevents a user from creating gaps in their group e.g. a breakpoint with max-width:400px and then the next with min-width: 450px."

The general consensus as I read it is that a breakpoint should be fundamentally defined by a valid media query. How we extract the boundary and step size information from that string will fall to me as build out support of breakpoint definitions in the layout builder.

webchick’s picture

"This is a huge re-definition of what a theme is, and I haven't seen any issues that directly propose this."

This is pretty much the premise of what the Blocks and Layouts initiative is. http://krisandju.e-webindustries.com/blog/drupal-8-blocks-layouts-everyw...

RobW’s picture

@Webchick: Thanks. My understanding was that the layout builder was going to be optional, but I could totally be mistaken. Hard to keep up with changes across projects when you're working on contrib and client work too.

This convo is careening off track (with no small help from me), so let's bring it back to breakpoints module UX.

attiks’s picture

#19 link should be #1734642-30: Move breakpoint module into core, I'll post a comment there since it's not related to UI

attiks’s picture

#13: "The layout/gridbuilder IS optional"
#20: "Layout builder is mandatory"? Which will make gridbuilder and breakpoints mandatory?

I'm confused :/

EDIT: layout will be mandatory, not the UI

attiks’s picture

#20 core issue at #1696302: [meta] Blocks/Layouts everywhere

Edit: wrong link

Bojhan’s picture

Reviewing tomorrow. I would definitely love to know the idea behind, how users know what to do with this UI. Because I feel although people in this thread understand the rules to follow, the site builder just starting out with making his drupal site mobile friendly is lost in the proposed UI (from lack of clarifying help text, no clear visual representation of changes). Can we somewhat define that 80% usecase? And perhaps how this fits in the overall flow, I fail to see why image style configuration is here for example.

This could really use a good issue summary, its hard to get into.

attiks’s picture

#25: "I fail to see why image style configuration is here for example"
The screen in #5 is not the default breakpoints UI, the only part that is from the breakpoints module is the table at the top.

The idea is to allow other modules to act as a plugin, but that discussion is for another threat. Keep in mind that most of the breakpoints UI will be adapted to reflect the proposal from @tkoleary in #4

Gábor Hojtsy’s picture

@attiks: where did #20 or other comments say the layout builder would be mandatory?! Our goals are definitely not to change Drupal's modular state and people should still be able to hardcode whatever they want. The express goal of the blocks and layouts initiative is to make everything a little building block on the page (vs. custom things that there were before), with those building blocks much more flexibly configurable in themselves (eg. Kris is working on blocks instances so you can place the same block multiple times on the page with different configuration).

Building in a GUI to be able to put these pieces into a layout is a logical next step vs. just keep shipping core with hard-coded PHP developed layouts that are only modifiable to people who know PHP and CSS. That does not mean people who do want to have super-precise control should not be able to ignore any layout builder and do their own stuff hardcoding the layouts using the building blocks but stitching them together in code instead of a GUI. For those people, it should be easy to ignore whatever GUI we have for breakpoints, grids or layouts, they are just not part of the audience for this tool.

Whether Drupal needs a GUI for this was proven by Panels (on 126000+ sites) and Context (on 69000+ sites) in contrib very well. Of course not everybody uses those, and whatever layout tool comes out , if it is included with core, it will not be mandatory either.

Enough background information to highlight the thinking? I agree with RobW we should go back on topic :)

attiks’s picture

#23 should read "layouts" are mandatory in Drupal 8, my mistake

I created a new issue to discuss this #1784456: [Meta] Implication of Layout & blocks everywhere, because it is off-topic

Bojhan’s picture

A full review :). Let me start of by saying, that I really love all of the work that has gone into this - I know its a though subject matter, changing rapidly and there are always to few resources to tackle something like this. It would be quite instrumental if we figure this out for Drupal core, I have not yet seen any CMS successfully tackle this.

1. Overall
I have spend a good amount of time researching this topic, and although the concepts are there - I am not sure the current form will work for our sitebuilders who are just starting out with breakpoints. Even if we where to assume they understand the rules around assigning breakpoints, the current UI gives very little feedback what the result of their settings are.

What is that 80% we are seeking to support here? What is the audience, is that a sitebuilder familiar with breakpoints or not? We have always tried building Drupal Core for a wide audience, with 700.000 users en counting it is - and if we wish to cater to a large portion that isn't too knowledgeable about making a mobile site we need to see that our tools aid them in making the right choices.

Although asking for an emulator, might be too much. I feel people need more direct visual feedback, what happens to their layout when they set breakpoints to 320px. Although the grid displayed below that tries to do that, I am not entirely sure people get that connection as its a very generic representation. This a large concern I have overall, there is too little feedback and guidance what to configure here.

2. Adding breakpoints
I like the clear visual representation that the "breakpoints" run to a certain max, until they break down into the lower one - this clearly maps a fairly difficult technical concept. Do we provide them with a default set of breakpoints? Although cloning is nice, do we expect that people mostly use this tool for minor deviations of the default or creating completely new ones?

breakpoints-adding-dragging.png

Reviewing this screen, there are a couple things I noticed:

  1. The guidance on top, does little for new users. It explains the interaction rather than the concepts, in D7 we removed most of the help text that was about explaining an interaction. We figured if the interaction needs explanation, most of the time its too complex and needs more feedback.
  2. Do you choose a pixel breakpoint, by dragging the marker? It seems like a slider is more suitable when you wish to set the range between a small set of values or large set where accuracy doesn't matter much. While here we use it to set a very specific value in a large range. Although a slider is visually fine, doesn't it make sense to add some text field to also give in a specific value? I can't really imagine dragging the marker to 768.
  3. Why do you add breakpoints, add the point of a marker? I am not sure, why you can't just add a breakpoint ioverall and drag to where you want it to be. Although I see the point of doing it like this, its going to be a surprise to users where its added. Does this have something to do with the splitting, I am not sure I get that part at all.
  4. The interaction is rather special, which obviously means a lot of custom interactions. Just editing/deleting I see a new popup interaction, that we don't have elsewhere. It would be good to get some clues on how to make this accessible, because that worries me a little.

Since this is the core of the proposal, I would love to get more thoughts on how this influences other places where this UI might end up at. I dont fully understand why you would for example configure image style responsiveness on each item, I would rather like to see us keeping those kinds of concepts more seperate. Because otherwise we might just end up with each breakpoint having a whole bunch of random responsive configurations.

3. Grid builder
From my understanding we want to allow people to configure grids depending on the breakpoint, where you would for example lessen the gutter on your super small mobile device. Similar to image style configuration, I dont fully understand why that configuration should be here. If we choose to collect all responsive configurations here, then we should choose where they are now, they are now spread across two pages.

I would personally advocate to remove the grid builder from this discussion, its not a requirement for this going in and quite a UI and technical challenge. But for the sake of centralizing any feedback, in this initial stage my review of that part:

grid-builder-responsive.png

Overall I would like to question whether the usecase of configuring the gutter per breakpoint(range) is truly a core use case. It is a use case, and I am sure it comes up but is this really a necessary basic building block to include in core? Anyway, things I noticed:

  1. How do you select this step? Do you select it in the rows above, and then it updates below? How do we signal this happens to blind people?
  2. The terminology used is clear to those who spend time with CSS (grids), but to those that don't I am not sure much of it makes sense. At the very least the description above should give more pointers, as how to configure a grid.
  3. The text "Step: Kindle fire" has to little prominence, while its one of the most important things here - it helps you pinpoint what you are configuring
  4. Why are all the grid settings placed inline? I honestly am unable to see what each one relates to visually, couldn't they be outside of the visualization, that might make it easier to see the result of changing a value?
  5. The interaction for changing the container is a little strange, you can drag it from the left and from the right but what happens when you get near the center? Also is it a common use case that people will want to have the left bigger than the right?
  6. Similar to the other proposals, how do we take accessibility into account here. Without a visual representation, I can only imagine its pretty much impossible to understand the effect of decreasing the container, or adding more padding. We will need some really great textual clues.

Besides this I see you used the Ember theme, I am wondering why there are two "Save" buttons? Is it just duplication, or do they have different purposes. Because I don't really see the necessity of to Save buttons, on a screen that can be seen within one scroll?

As mentioned in the introduction, I would really like to applaud all the effort that has gone into this - its quite complex subject matter especially in combination with the actual layout builder. I hope my comments are useful, sorry for taking so long getting to review this fully.

Gábor Hojtsy’s picture

@Bojhan: I agree the grid discussion should not happen here, that was merely a demonstration of a "plugin" and would be its own discussion later. It made sense to include it on the screens so we have a better overall feel of a more complete goal. However we should restrict the discussion to the breakpoints indeed.

tkoleary’s picture

@bojhan. Hey thanks for going in to this in such granular detail. You raise a lot of very good points. I am already revising designs for both breakpoints and gridbuilder based on feedback from attiks. I will incorporate your suggestions as well and post new designs with notes on how I addressed the issues you point out.

tkoleary’s picture

Re: "Off-topic: please don't name them smartphone, tablet because it indicates a device"

While I understand the need for clarity, "Phone, tablet, standard" do not specify a device, they specify a range of form factors. If we were to say "iPhone", iPad, Macbook", that would be specifying a device. Using a generic form factor name for these defaults (which, by the way the user can choose to overwrite) is a quick doorway in to understanding for the new user.

webchick’s picture

Yeah, I agree with #32. While as developers we might have 320px memorized as an average smartphone "portrait" width, I can guarantee you that the vast majority of site builders won't know that. Semantically named breakpoints (which I can then rename to either "320px" or "iPhone 4s" on my own site if I want) will really help with this understanding of what is still a dark art to a lot of pre-2010 web developers.

RobW’s picture

There are a couple problems with the phone-tablet-desktop naming scheme. When a mini tablet has the same pixel dimensions as a monster htc phone, a ten inch tablet the same as a Netbook/Air mini laptop, and a car dash screen and music player and television filter in across the spectrum, the names break down. Media queries don't serve style rules to devices, they serve rules to screen dimensions.

As important, it is bad practice to add breakpoints by default at device breakpoints (320, 480, 786, etc.). Breakpoints should be added when the design breaks, which preferably is not in the middle of a bunch of similar form factors. Design based breakpoints have been cited again and again as the best practice by responsive experts (Luke W, Ethan Marcotte, Brad Frost, Cloud Four, Jeremy Keith, etc., etc.), and popular device specific breakpoints (e.g., iPhone/iPad) are considered an amateur mistake. I worry that if Drupal calls its breakpoints "Phone, Tablet, Desktop", it's both encouraging bad practices and seeming amateurish itself.

Why not call them what they are: "Small screens, medium screens, larger screens"? Basically the same thing, and it doesn't encourage new/ amateur responsive site builders to build mental models that are against their best interests. If there are icons that accompany the sizes, a generic phone, tablet, and laptop would work well as common examples of the type of device that each media query might serve design to.

tkoleary’s picture

Hi all,

The design prototype has been updated here: http://invis.io/J66DW0KQ

Let me know if anything's unclear.

@attiks I tried to incorporate all your feedback. One thing that's not there is image styles. Consensus seemed to be that image styles UI itself should be updated and pull values from here for MQs.

@bojhan my answers to your questions are here

1 General

“Current UI gives very little feedback what the result of their settings are.”

That is true, the user will have to use this in conjunction with the responsive layout builder (or whatever layout plugin they are using).

“What is that 80% we are seeking to support here?”

IMHO the 80% user story is “As a sitebuilder I want my sites to display well on all devices. Responsive is the established best practice solution. Responsive assumes breakpoints, so I need sitewide configuration for breakpoints.”

“What is the audience, is that a sitebuilder familiar with breakpoints or not?”

The sitebuilder should be familiar with breakpoints but in the event that they are not we should give them smart defaults (both here and in layouts) that don’t force them to learn about breakpoints before they build.

So, for example, if we have default breakpoints for phone, tablet, and standard, and we have default grids for each of those and we have default layouts for each default content type at each breakpoint (just to be clear that would be three layouts—front page, basic page, article—with three media queries each) then you have a situation in which a site builder has a responsive website out-of-the-box without yet having to understand the responsive breakpoints.

Similarly a sitebuilder enables a theme that contains responsive media queries and default layouts. Now those media queries are added to this UI as a new set and will apply to new content created using the theme layouts, again the user has a responsive site out-of-the box without yet having to understand the responsive breakpoints.

Now say either of these sitebuilders is testing their dev site across devices and they notice that they get a one column layout on the Google Nexus 7. The action they take is “let me find out why this is happening”. The sitebuilder who understands responsive design would go looking for the “breakpoints”, find it, and know how to use it.

The sitebuilder who does not yet understand responsive design may look in layouts UI, see controls to toggle between phone, tablet etc. plus a contextual link to “edit breakpoints”, find their way into this UI and begin to try out different configurations by adding or moving the defaults. Only a small amount of configuration will be necessary for them to achieve the desired effect (add one breakpoint) and they learned a little about responsive in the process.
“we need to see that our tools aid them in making the right choices.”

Absolutely. Thus the smart defaults and the warnings for overlaps and gaps.

“I feel people need more direct visual feedback”

Preview would be nice but I think it’s out of scope for now.

“[grid is] a very generic representation.”

The grid needs to be generic to cover all use case

“Too little feedback and guidance what to configure here.”

I agree that there are complex concepts to understand here, however, the complexity is in the subject matter, not the interactions. Explaining the subject matter I think is the job of better orientation and help supplemental to this UI (and all admin UIs in Drupal).

2. Adding breakpoints

“Do we provide them with a default set of breakpoints?”

Yes.

“Do we expect that people mostly use this tool for minor deviations of the default or creating completely new ones?”

Minor deviations.

“I would like to question whether the usecase of configuring the gutter per breakpoint(range) is truly a core use case.”

All other SaaS gridbuilder tools have this.

“How do you select this step? Do you select it in the rows above, and then it updates below? How do we signal this happens to blind people?”

Moving the “add breakpoint” shuttle has three functions

As the shuttle moves the width field live updates.
As the shuttle crosses a breakpoint into a new media query (MQ), the breakpoint fields (min and max if it exists) appear. Also the grid associated with that query is displayed in the grid UI plugin below (if gridbuilder plugin is installed).
When the user clicks “add breakpoint” the breakpoint is added at the value the shuttle rests on and the user is given a modal dialog to name the media query (adding any breakpoint via the UI creates a new, min-width MQ. The user must add max width MQs manually which avoids gaps and overlaps and steers the user to best practices)

“The terminology used is clear to those who spend time with CSS (grids), but to those that don't I am not sure much of it makes sense.”

Again, I think this is an issue for orientation and help.

“The text "Step: Kindle fire" has to little prominence, while its one of the most important things here - it helps you pinpoint what you are configuring.”

Latest design addresses this.

“Why are all the grid settings placed inline?”

Latest design addresses this.

“The interaction for changing the container is a little strange.”

Latest design addresses this.

“How do we take accessibility into account here.?”

Definitely a big issue but more of an implementation question IMHO. Preston So has some good ideas about how to do this.

“I see you used the Ember theme.”

Yes, but interactions would not be different in seven

“I am wondering why there are two "Save" buttons?”

This is something we added to Ember for long pages. Rubik does it as well. When everything is above the fold it’s a bit odd but I’m not sure we can detect that.
.

tkoleary’s picture

@RobW

IMHO phone, tablet, standard are already pretty generic and small, medium, large are *too* generic for new users to peg to a real world example. Yes, there are exceptions in device sizes, but the exception proves the rule.

Also, you will notice in the prototype that the default media query breakpoints already fall between the form factor clusters, as you suggest.

RainbowArray’s picture

I would agree with RobW, using device-types as names for standard breakpoints is a mistake.

The possibilities of this are huge. We really have the possibility of Drupal being hailed as one of the best options for creating responsive websites. However, if you name the breakpoints based on device types, I guarantee that will be considered an amateur mistake and will result in responsive design gurus not recommending this as a good solution.

Obviously there needs to be a balance between "what the outside world think" and "how this works for site builders trying to figure things out."

But the problem isn't just one of outside perception. Using labels like "smartphone, tablet and standard" are going to confuse people when they work with this. There is a sliver of difference between a 10" tablet and an 11" laptop. And when somebody comes out with a 10" laptop or a 9" laptop, and a site builder tests on that, then somebody new to responsive design may well wonder why this small laptop is getting the tablet layout.

"Standard" is even less descriptive as a term. While I understand that's intended to target laptops and desktops, it's a misleading term. By the time Drupal 8 comes out, or within few years afterwards, it's highly likely that for a number of people, smartphones will become the standard way to access the web: desktops may become a special use case.

Breakpoints aren't about devices. They aren't even about screen sizes. They're about viewports. Somebody may be on a desktop but have a slew of windows open, with the browser set to what would be the equivalent of the size of a tablet.

I think you'd also be well-served to have at least four categories out of the gate. The different between a 27" Cinema Display and an 11" MacBook Air is far larger than the difference between a smartphone and the 11" screen. So I'd have at least one set of breakpoints for much larger screens.

I'd also keep an eye on what's happening with the web being accessed by TVs, which is another design challenge entirely and would require its own breakpoints.

I'd much rather see more accurate labels used like "Small," "Medium," "Large" and "Wide." Those are amorphous concepts, yes, but they're far more accurate than device types. If you wanted to further clarify, you could say "Small viewports." That's the most accurate description, but viewports is not necessarily a commonly understood concept. "Small screens," is probably better understood, but less accurate.

I get that you're trying to make this easy to grok for somebody new to responsive design. However, by using device types, it sets up a barrier to understand the next level of how responsive design really works, as well as a barrier to how this solution is perceived by the responsive design community.

I do want to emphasize that, despite my quibbling over labels, I think this is a hugely impressive development. I really like how setting breakpoints works.

RainbowArray’s picture

One last thing to add in is that I think the term "Multipliers" is pretty confusing. For somebody new to responsive design looking at that, I think most people would say multipliers of what?

This setting is really about responsive images, and high-res (or retina) images, specifically.

I think an accurate term and easy-to-understand label would be "High-resolution image styles." That's a bit long, though. "HD image styles" is a bit shorter, but less accurate. "High-res image styles" might be an option.

dasjo’s picture

Hi,

this looks very promising for serving site-builder a tool to create responsive web sites.

device-based media queries vs content-based media quieres

one big concern that i have is that we are promoting device-based media queries over content-based ones. check out the following quote, seen here:

The conventional method of determining breakpoints is to use some fairly standard widths: 320px (where the iPhone and several other mobile devices land on the spectrum), 768px (iPad), and 1024px. There’s a problem with relying on these “default” breakpoints, however.

When you start to define breakpoints entirely by the resolutions of common devices, you run the risk of developing specifically for those widths and ignoring the in-between (case in point, rotate the iPhone to landscape and you’ve just introduced a 480px width). It’s also not a particularly future-friendly approach. What’s popular today may not be popular tomorrow. When the next hot device emerges, you’ll be forced to add another breakpoint just to keep up. It’s a losing battle

while device-based media-queries might be easier to grasp, i see most responsive design experts advocate for content-based ones.

for example brad frost in his presentation beyond media queries: anatomy of an adaptive web design:

Today’s common breakpoints aren’t tomorrow’s. Create a device-agnostic flexible platform.

also lukew has noted this here:

Design grids from the smallest element up. This allows you to move away from breakpoints connected to devices and instead focus on breakpoints connected to your content.

additional questions
will this support em-based media quieres?
will this support vertical media queries?

looking forward to having future-proof tools for rwd in drupal :)

also see the media queries section of these great Responsive Web Design Resources by bradfrost.

Everett Zufelt’s picture

“How do we take accessibility into account here.?”

Definitely a big issue but more of an implementation question IMHO. Preston So has some good ideas about how to do this.

** Accessibility is a design decision. if a design cannot be implemented accessibly, then the design must change. Note, I have not reviewed the design.

attiks’s picture

#40 There's now UI for the moment, but we're working on the UI for breakpoint, I'll ping you when it ready for review and I'll try to setup a test site.

I'm waiting for #1734642: Move breakpoint module into core to be committed.

webchick’s picture

Please note that there is a functional prototype of this UI that's been posted in the gridbuilder project at #1813126: Awesome breakpoints & gridbuilder UI.

attiks’s picture

Title: Do a UX review of Breakpoints module » Do a UX review of Breakpoint module
Project: Breakpoints » Breakpoint
Version: 8.x-1.x-dev »

moving to breakpoint module