Resolution and build of responsive web sites

HTML & CSS
1

Hello everyone.

I’m a graphic designer who wants to understand more about responsive web design (as not to waste to much of the time of the guys who are going to implement the design).

I see that some sites content is made to fit within a few specified resolutions, while others are even more dynamic, and change. This site http://foodsense.is/ seems to have five resolutions, this one seems to have three http://www.cacaotour.com/index.php/en/cacaotours, and this one seems to have only two http://2011.dconstruct.org/

So what resolutions should I work within, and is it better to make a design completely fluid, or to make it work within some specific resolutions?

Thanks for helping!

2

Hi,

It does depend on the site in question and what type of content you have.

In the first example there are lots of images of a fixed width in containers of a fixed width so the only way to accommodate smaller devices is to set breakpoints with media queries and adjust the layout at each screen size. This of course means you need to cater for all device sizes (and landscape/portait orientation). The site works pretty well and looks good as it adjusts but you do get a different layout each time (which I find disconcerting as I’m a continual “window shuffler” and open and close the browser window to various degrees thousands of times a day and I’d rather see a scrollbar - but I’m the only one who thinks that way :). It also means you have to design multiple versions of the page which is also a pain.

The other sites you linked to are fluid/elastic sites with min and max widths which allow the page to shrink and grow within limits and means that they don’t have to accommodate every specific device size but only need to change when the layout no longer works at a certain width (whatever that may be). This is the option I would prefer as to some extent you can forget about devices and what size they are as you create a layout that shrinks and grows and you only need to set the media query for the size when the layout needs to change (and not the device).

Obviously some designs are more suited to fluid and some need to be fixed and some are elastic so there is no real “one size fits all” approach.

If you are creating designs from scratch then I would go for fluid/elastic so that you cater for as many people as possible from the start and then you would only need to create different versions at the points where your layout no longer scales nicely. On some designs that may mean you need to do nothing (e.g. for a site of mainly text it could grow and shrink at will).

What you do need to think about though is as you create your designs you keep saying “what if” at every stage. What if the menu doesn’t fit all the way across on smaller screens? What if some browsers break a phrase into two lines and some only one. What if there’s twice as much text content as shown in the design… and so on.

3

As Paul said, you have to decide that for yourself, but as a general rule, I’d look more at sites that are fluid by nature and are continually expanding and contracting. That doesn’t mean that everything has to move all the time, though. You could have a fixed width sidebar while the content area expands and contracts. Generally on a really small screen, though, it’s probably better to have a sidebar drop below the content, as it just becomes too tight a squeeze otherwise.

The tough bit for graphic designers is to get away from the idea of a sheet of paper that they are designing for. Designing for a fluid medium like the web is a bit like painting on water. You have to be more flexible and openminded about the design, because it can be expanded and contracted in all sorts of ways. The end user can mess with your layout in all sorts of ways, like having their fonts set to a size bigger than you anticipated. Your design—to be fit for the web—needs to account for all these variables. This isn’t as difficult as it sounds, though. The key is not to try to be so in control of the layout, and use design to enhance content rather than to constrain it.

4

This is one of the type of questions that cannot bring about absolute answers because how a design is optimally presented depends on your content and how you structure that content. A well-designed site can be done in relative units (em/%) or pixels.

Personally, I don’t like using fixed metrics (px) for layout and fonts anymore, simply because I no longer subscribe to the idea that a design, as a whole, needs a fixed canvas, unlike in print.

To address the examples you posted, I’d say that if you have a design with, say, five columns, then I’d say a 100% fluid layout is good for larger screen sizes but not so ideal for smaller ones, unless you use media-queries or min-widths, the latter being nearly impossible to make usable on narrow viewports, otherwise you’ll end up with having one-word-per-line columns.

For a one-column layout, I’d say that a 100% fluid design can also constitute a problem because the text lines will likely be too long unless you account for it aptly by making sure the width is narrow (not set to 100% but something more appropriate and apply min/max-widths).

How many different resolutions and viewport sizes you support depends on whether your design is fluid, semi-fluid, elastic, fixed, or a combination of these and that decision will also determine how many media-queries you’d optimally be using to accomodate as many devices as possible.

Some reading resources:

http://www.w3.org/TR/css3-mediaqueries/

http://css-tricks.com/css-media-queries/

5

A completely fluid layout won’t happen very often.

In fact a completely static or flexible design won’t happen very often either. (Yeah, I know, static shouldn’t ! :slight_smile: )

What happens in real life is a responsive design (media queries help transition to and from bigger “resolutions”, widths really) with a hybrid layout: fixed or relative values with any combinations of the fixed (px), fluid/liquid (%) and elastic (em) elements and with min and max constraints.

One such design should take care of widths from 320px up to 1900px. We could discuss bigger or smaller widths, but it’s not realistic.

Another thing to consider separately are the higher pixel density devices, like you can see in foodsense.is:


/*	RETINA OVERRIDES 
----------------------------------------------- */

@media 
only screen and (-webkit-min-device-pixel-ratio: 2),
only screen and (min-device-pixel-ratio: 2) {

All in all, we’re not talking about 2, 3 or 5 “resolutions”, we’re talking how each individual design would go from mobile first: start from a base layout, and then take care of widths from 320px, and then properly handle the extra widths up the screen sizes. Which is the approach I employ.

You could take a look at this responsive boilerplate that has taught me lots: http://stuffandnonsense.co.uk/projects/320andup/.

It’s based on H5RP and MH5BP, some more stuff to learn from: http://html5boilerplate.com/

Others would do things differently. They’d start from a 960px or 1140px flexible design and then adjust up and down the (flagrantly different) screen sizes.

But no matter the starting point, responsive design is the key. Flexible design (fluid layouts, …) alone won’t be able to properly handle big differences in screen sizes.

6

As a side note, dconstruct.org, which you say has “only two resolutions”. It’s not.

  • it’s a hybrid layout, it mixes px and em
  • it has 3 breakpoints, that are not about px, are about em
7

From what I understand there are a couple of main break-out points.

320px (iPhone landscape)
480 px (iPhone portrait)
600px (Android Tablets)
768px (iPad + ~Galaxy Tabs) and 1024px

As far as creating a responsive design I feel it’s easier to use those breakout points and design a wire-frame. From this wire-frame create your overall design. Responsive Web Design is still in it’s infancy, and as such, you’re likely to see many adopting the wire-frame technique.

8

Breaking points are informative not mandatory. If your design is a flexible one, you don’t have to “respect” each and all of them. You just have to id the points where the design breaks.

In a normal responsive design, the bulk of the code is located in the base style. The breaking points styles combined should not be more then, largely, 25% of that base style.

I’m not sure where you’re getting at with wireframing… it’s used regardless.

And I’ll also argue that RWD is well past infancy.

9

@itmitică;

I think you’re completely correct!

There are likely to be new trends in RWD, I am just getting my teach dirty now. I never used a wireframe prior, never had to, just got the design without coding this. Maybe this is why I am finding RWD much more different to the traditional way I did things.

10

I’m still not sure where you’re getting at seamlessly connecting wireframing with RWD…

Wireframing is a mockup of a layout. You don’t “code” a mockup, you’re pretending, you’re playing make believe layout. It exists since long before web design, and long before RWD.

RWD, for the most part, is very traditional designing actually. The only other extra thing are the occasional media queries.

11

You code this mock-up and make it work as a wire-frame, without the detail. So basically you would code our all your DIV’s without content, and from this make your containers/content holders responsive. If that makes sense.

Then you’d fill the detail out. It’s the only way you can properly do things when coding a wireframe. I tried everything and I wish I had build better building blocks.

12

Not really. Sorry. :slight_smile:

Personally, I prefer to start from the content in the design, even Lorem ipsum and similar pretend content stuff when there’s not enough content. I also like to use HTML5 semantics, so it’s not all divs.

And we don’t seem to understand the same thing with wireframing. For me, there’s no code in wireframing. Wireframe = mockup.

13

@itmitică;

You draw our your DIV’s, then you make them flexible, from here you make them responsive. Wireframe has no code traditionally, but with responsive web design I think you have to code your wireframe and make it responsive first, otherwise things would get tricky, as I am finding out.

14

Everybody has its way, I guess. If it works for you… And I believe you mean to say basic layout.

For me, RWD is mainly the same thing as before:

  • get content coded in page (semantic, preferably)

  • use the dedicated graphic design to apply the main/common/basic style to the page (75% or more from the total CSS code)

  • find breaking points/quirks/platform specifics in the design and address the issues with MQs (25% or less from the total CSS code)

The one thing I’m not clear on, is how do you manage to make the design responsive without content. There a good chance that adding the content after would go against the content.

15

[QUOTE=itmitică;5160006]

  • find breaking points/quirks/platform specifics in the design and address the issues with MQs (25% or less from the total CSS code)[/QUOTE]

Yes that’s the approach I like as its not device specific and you only need to cater for the points where the design needs to change rather than worrying about what width the device is.

16

Me too, Mobile first is an interesting concept but I find starting with a high res version first fine and is easier to manage.
You just need to be a little creative with how to change things at lower res.

Here’s a short 7 minute video on some techniques that might be helpful to some.

Paul, I know you’re holding out on pre-compilers. You’ll come around eventually :wink:

17

Thanks a lot for all the help! I really appreciate it.

I have some thoughts and questions though on size/complexity of responsive sites.
Most of the responsive sites I’ve seen are not overly complex, on the other hand there are pages like the Boston Globe

Q1: If I want to make a page with a lot of products, and I want the owner of the site to be able to update it himself, would that be possible/recommended? I’m afraid that a big project like that would be a lot more expensive with RWD than with traditional design.

Q2: I’ve read that if the site is browsed via a mobile phone, the phone will download a big picture and scale it down itself. This sounds like a huge waste of bandwidth/processor power. Is it possible to have an image in two or more sises so that the device can download the most appropriate one?

I’m finding RWD very intriguing, but I worry a bit about how expensive it might get, especially with bigger sites, and also bandwidth on smaller devices.

18

It depends on the tool the client is using, to some extent, but a good CMS will allow you to create content areas for a client to insert content into, and as long as you plan what they can upload and where, it should still work.

Is it possible to have an image in two or more sises so that the device can download the most appropriate one?

There are lots of people working on this very issue, and though there’s no perfect solution yet, there are some pretty good ones:

http://filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing/
http://css-tricks.com/which-responsive-images-solution-should-you-use/
http://adactio.com/journal/4997/
http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/

19
Off Topic:

I’m too thick to use that :slight_smile: Don’t even understand how to install it lol.

20
Off Topic:

Open up Terminal, enter “gem install compass” and you’re done.
It’s packaged as an app for $10 too.
http://compass.handlino.com/

I cannot express how much I love compass / sass, give it a try, I’m sure you’d find it handy.