Strategies for Handling Multiple Screen Resolutions and Aspect Ratios in Web Development - css

Back in the day, 800 x 600 was the screen resolution to design for - and maybe 640 x 480. Then along came 1024 x 768, etc, etc, etc.
But then it gets worse: now we have not only different resolutions but also different aspect ratios.
What strategies do people use to accommodate today's ever-expanding range of screen sizes and aspect ratios?
(BTW - I was only thinking about laptop / desktop hardware, but of course there's smart-phones and tablets to consider too.)

I know this would be a somewhat controversial opinion, but I'd say it anyway: Don't
Don't design for multiple screen sizes or aspect ratios. There are of course a few exceptions: Heavy web applications like webmail clients can definitely do with more screen real estate, and are probably flexible enough to accommodate a large range of screen sizes anyway. Mobile versions of said website, with a more flexible design to accommodate the incredible spectrum of mobile screen sizes can help too for sites with high mobile volumes. However, if you stick to the so called 'desktop web', then I think we can say that 95% of the time there are more important things to care about than screen sizes, resolution and aspect ratio.
First off, lets tackle the easy one. I don't really understand why you would care so much for aspect ratio - it isn't like we care that much for the 'below the fold' nonsense anymore, do we? The web is a vertical medium - scrolling will always have a place in websites. Having everything above the magical 600px line is just stupid.
Next, screen resolution/size: Again, I find it difficult to defend.
Users with large screens do not usually maximize their browser windows, because they find that most website do not take advantage of them. While the web adjust to the user, the user also adjust to the web. Although you could argue that this is a chicken and egg problem, the fact remains that website are usually designed for the lowest common denominator. I'm not defending this position, but rather, pointing it out as the current prevailing trend in the industry.
There are certain things that simply won't work with resolution that are too high or too low. There is, for example, a small range of widths that allow people to read comfortably on screen. Any longer and the amount of movement for the eye to the next line would be annoying. Too low and the text would appear cramped. The fact that the web was designed to be resolution neutral means that paradoxically not many provisions has been made for those who wish to build fluid layouts. min-height and max-height would help, of course, but the wider the range, the more difficulties you will face. Things like orphaned elements, displaced images, backgrounds that run out, etc. are unavoidable for truly flexible sites built with today's technology.
So my opinion is that the simplest method for dealing with multiple resolutions is to ignore it altogether - with today's technology there are not many options anyway - and design for the lowest common denominator.

Watch out for high DPI settings
I think one of the most undiscussed issues facing front-end web development today is testing on high DPI systems. Everyone has learned to test and test and test on different browsers but designers/developers have not caught on to testing on different DPI settings.
High (or even low, for that matter) DPI settings break designs when fonts are scaled but images are not (which can happen), can cause images to look fuzzy/blurry, and absolutely positioned objects may not appear in the desired location (which would be devastating for CSS menus.) If nothing else, test your images at high DPI and re-render them as necessary.
This has never really been an issue until recently with the release of Windows 7 and people buying computers with high resolution monitors. First off, Windows 7 uses 96DPI as default (which is different from the rest of the computing world that has been using 72DPI as the standard. Moreover, Windows 7 will automatically adjust DPI settings and I have seen people with DPI of 150% of normal (96 DPI in Windows).
Here's a great link discussing this issue in more details: http://webkit.org/blog/55/high-dpi-web-sites/
A great cross-browser website designed with web standards is the goal but don't forget about DPI testing.

Well, trying to keep the answer not-too-long, this is what I do.
(A) Always start from the most likely used ratio/resolution
If your average joe is going to be on a modern laptop or a desktop machine he likely has AT LEAST 1024x768 (refs: w3schools elykinnovation), that gives you roughly a usable 960px width (you might want to check the 960grid system - there are a hell lot of new framework since I first wrote this).
If you users are more likely to start with a mobile device or a tablet, thing about them first.
If it's 50%-50%, it's usually better to start from small and then grow up, eg. Rock Hammer or Foundation
(B) Layout: fluid or not?
If your website could benefit from a larger width, pick a fluid design starting from this resolution. Be careful that the human eye does not like to read text over long lines, so do not abuse of fluid design; often sticking to 960px with large margins is acceptable.
You might want to add (javascript) some additional side-menus if you really have a lot more space. But design your website to work without JS as much as possible.
(C) Other resolutions
Finally it's time to check that with least used resolutions things are still acceptable.
(D) Other devices, ratios and stuff
There are not many options for different ratios; it often means you are running on a mobile, ipad, AAA or similar device.
My advice is to ... design for those devices specifically.
While writing your HTML keep in mind what you are going to need and remember to do HTML by semantic and not for design. Use properly HTML5 semantic tags if you can.
Avoid < bold > or similar tags, and properly use tags and classes that you are going to style with CSS instead.
Use a framework!
But you still can make a few different designs for very different devices. You don't have to do everything responsive /in the same design/.
There are several ways to serve a different CSS depending on the client; you can do it:
server side, checking the browser in the HTTP heading coming from the client, either with your web server or your dynamic scripting environment - be it python/django, php, or whatever else
javascript (you can easily get the window size)
html - in particular with some specific devices such as iphone
You can easily produce a generic design for small (eg. mobile) devices by following some simple rules:
1. fluid layout capable of fitting in very small widths
2. compact header/footers not too waste too much space
3. few, clear contents per 'page'
4. avoid :over effects as they won't work on touch devices!!!
If you want to go further, you have to check individual devices customizations; an example is the iphone viewport, see the apple ref library.
This is just to get you started. Experience and specific needs will drive the rest!

Your site can't work perfectly for every display. Even if you had enough hours in the day (or should I say year/decade) to design for every possible display, you'd have to do it over every time a new device comes out.
In my development, I still religiously try to avoid horizontal scrolling, and that isn't too hard with floating divs / variable-width divs. But beyond that, we really are at the "there's an app for that" cross-roads, where you need a specially designed display for specific devices.
One strategy I use is to reduce dependence on a single display -- a customer probably doesn't need to see your entire web page to do what they came to do. You can parse-out functionality to smaller/simpler web pages that scale better on differently-sized devices.
At work, I have a little more "power", as it were -- I can develop internal web apps that are "designed to run on...some specific browser, some specific display setting, etc. -- use other configurations at your own risk". This, only after getting the managers to agree that spending an extra week in development (and even more in upgrades / future maintenance) just to placate that one vegetarian at the other end of campus who refuses to use IE really isn't worth the cost. In that case, we need another Timmy, not a more flexible web app that can look good on his favorite non-IE browser.

This is a common but complex question, which unfortunately does not have a single best solution. It all depends on the kind of content that you have. You can use a fluid layout, or design your site differently for different resolutions (see http://www.maxdesign.com.au/articles/resolution/). For an example of a fluid design, check this out - http://hicksdesign.co.uk/journal/finally-a-fluid-hicksdesign

I think that responsive web design is the answer to your question. Have a look at these examples and techniques...Responsive Web Design

Related

Why is it an issue if media queries "snap" from one set of rules to the next?

The following quote comes from here: http://www.creativebloq.com/css3/create-fluid-layouts-html5-and-css3-3142768
"Any fixed-width design, using only media queries to adapt for different viewports, will merely 'snap' from one set of CSS media query rules to the next with no linear progression between the two."
But, I can't help but wonder why this matters. Sure, the transitioning is smooth and looks pretty when a developer is playing around with browser size, but what visiting customer (on an ecommerce site or blog) is realistically going to be doing this?? In general, visitors will visit on one device at a time, click around, then leave. Even if they come back on another device, smooth transitioning isn't necessary for the UX, so, why do we care about linear progression between media queries?
This became a practical issue for us in one of our eCommerce clients, the "change" in size would occur when someone switches from landscape to portrait (especially in devices like iPhone where the width is significantly different) i.e. hoding the device vertically and then shifting to horizontal or the other way around and in fact since we used media queries there was a very minor delay (a fraction of a second) in the layout adopting to the new width.
Another realistic scenario is that people may switch between restored and maximised versions of browsers , then again as commented, wasting spaces is also an issue.

Media query workflow and standard practice?

I'm working on a responsive website, but 1 question always bother me is that should we always work from smaller screen size and move up to bigger screen or other way round?
For me I find it easier to work from bigger screen then reduce the browser screen and adjust it slowly. The reason I do this is because I can preserve my original pc screen's design much easier, if I work from smaller screen onwards, adjust it to original pc screen design would be difficult.
Is it better to work from bigger/smaller screen onwards? What is your opinion in terms of performance, loading speed, and coding difficulty?
This goes far beyond just responsive layouts or even CSS. You should optimize anything based on the way it will be used most. If I were making a site that most users would want to use from their phone, then of course, I would start development with the mobile version first! My reasoning is that there tend to be some trade-offs (albeit minor) with how things degrade as the screen size becomes smaller. To make sure the tradeoffs favor the mobile version, it may be best to start there and work toward the desktop version. However, I have always found myself in situations where starting with the desktop size is most practical, then I reduce the screen size and re-style it to my liking with media queries - reduce screen size, restyle, etc. It sounds like that's the approach you are taking and that should be fine unless a project calls for more attention to mobile from the beginning as I said.
No matter what you choose, if you are writing sensible code, the performance will be fine and the code should be understandable.
As m59 said, start with whatever device will be most used. A scenario that can benefit from the mobile to monitor workflow is when you create a new site from the ground up. This scenario leans more towards affecting design decisions because by starting mobile, you include all of the features and contents that are absolutely necessary for the user - the bare necessities . This way you filter out any filler that go into some desktop sites, making your design cleaner and the UI more user-friendly. Also, starting from mobile will allow you to explore and enhance your mobile UI development ability for the future, rather than just learning how to cram it all in.

What will load first with responsive design?

I've just finished reading yiibu's slideshow on their responsive site development for nokia, and one of the larger points of it seems to be to focus on mobile first, then desktops and other larger and faster platforms. ( http://www.slideshare.net/yiibu/pragmatic-responsive-design ) Not just in the planning phase, but literally develop your responsive design in the sense that the innitial styles, with no media queries applied, will be the design for your smallest platform, with the lowest capabilities. (older phones, depending on your audience) Which is backwards from what I've innitially thought to do (and from what I've seen, what others usually do as well).
The rationale was that this method would prevent people on mobile devices with lower bandwidth from downloading additional scripts and large images, by innitially downloading only the scripts and images needed for the minimum device, then loading more, and more, depending on the size and predicted capabilities of the device, eventually putting the most burden on the largest devices (laptops and desktop computers). --- This being contrary to what I've been doing, which is designing for the desktop, then adding media queries to optimize for mobile devices.
My question is, do I need to design for mobile first, then add media queries to optimize for larger devices with more capabilities in order to prevent the burden of downloading large images that wont be used on mobile devices?
.....Or can I just use sepparate stylesheets and call to a mobile stylesheet before calling to a stylesheet focused on larger browsers/devices?
The order of who you call first or not, shouldn't matter. The media queries by themselves are a bunch of if-else based on the criteria you place in them (device, orientation, width, etc). So by adding them first or last won't mean that a mobile phone will consider a style sheet for a desktop browser (example).
What you should do though, is to have the base stuff that is consistent across ALL devices (such as typography, font-sizes, background colors of elements, text color) on a base stylesheet that is readable to all devices.
This makes the actual reading of the file smaller as a specific stylesheet will be made for margins, paddings and widths depending on the actual size of the screen.
Last but not least, as to whether you should design the experience for mobile first or not, it's up to you, your way of working and what not. I know I don't. I design for desktop first and work my way down. I much prefer this.

Screen display for individual use/ projector viewing

I am building a learning product(in flex/flash) that will get used both by an individual on her desktop, and also by a instructor in a large room. The challenge is rooms, where this will be used, tend to be quite large- as big as 80-90 people and seating far from screen
I am not sure a single font size(12-14 font) will work for all- currently I have built it for "personal use" to use real-estate best and am hoping tweak slightly for "projector mode"- plan is to allow user to selectively pick and magnify various sections of the screen- is this a model that is done elsewhere- what are the best practices here?
Any thoughts on how to program for this?
You should keep it down to only a few short lines of text and an image/video if you're presenting this on a projector. The fact is, 12-14px fonts are much too small for that application - you should use 24px and up. Consider that projectors will typically have lower resolutions than monitors and your display will be scaled down somehow, which usually renders small / thin text unreadable. You might want to design for a 1024x768 projector, and let your interface scale so the users see the same display (same proportions and positioning) on their computer - I caution you that if you must use raster images, use high enough resolution images that they don't see a pixelated mess on their high res screens.
A useful article on slide design can be found at http://www.thinkoutsidetheslide.com/articles/select_and_use_fonts.htm and you can probably use the default templates in Powerpoint as a starting point for your layout. Don't shoehorn too much information into one screen!

Is it bad to work with pixels in CSS? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Is it bad in terms of compatibility to use pixel numbers in CSS instead of percentages? How about lower resolutions? Is it okay to work with them in ranges of 1-100?
All of the measurements have their own purposes:
Use pixels for pixel-based things, like borders. You probably don't want a border that ends up being 1.3422 pixels wide.
Use text-centric measures (em, ex) for text-based things, like content areas, labels, and input boxes. It's an easy way to make sure you have room for text of a certain length and width.
Use percents for window-based things, like columns.
There are exceptions, of course. For example, you might want to specify a minimum column width in pixels. But follow the above and your pages will scale well. ALWAYS zoom in and out on your pages to see how they work with different font sizes and browser shapes -- don't get surprised later.
This is a difficult question, because the answer mostly depends on your situation.
Pixels are not that bad, I mostly use them too. (Sometimes even for font sizes.)
I usually fix the outer block element of the layout by a given size (pixels with fixed-width layouts, and percentages with fluid layouts), and on the inside elements I usually set percentages whenever possible.
There are some elements which simply can't be styled with percentages or ems, especially the more fancy stuff coming from graphical designers who don't understand such principles.
For example: if you have a column on your site with a simple style, you can set its width to a percentage easily, but if it has a background image with a specific width that is not designed with scaling in mind, it only looks good with a fixed-width. In such cases, you'll have to ensure that the rest of the page occupies the remaining width correctly.
Note that you can use pixels with percentages together.
For example, this is a snippet from one of my latest web apps:
min-width: 800px;
width: 80%;
max-width: 1500px;
The choice also depends on what design or layout you would like to achieve.
For a fixed-width layout, pixel values are fine. If a designer gives you a Photoshop image that contains really fancy stuff which would be extremely complicated to even think about how it would resize, you should definitely go for this.
If your layout needs to be dynamic, you should use percentages to make sure that it expands as the resolution changes, and you can use the above code snippet to make it look better in scenarios where it would otherwise look insane.
Some layouts (eg. imagine if StackOverflow would take up all the space) would look pretty ugly on a width of eg. 1920 pixels - the line widths would be so insanely high that it would be extremely unconvenient to read.
This is what max-width is for. Even in some dynamic layouts, you'll have to limit the maximal width of your site to maximize usability and readability.
And also take into consideration the smaller screens.
It is true that noone uses a 800×600 desktop anymore, but many people browse the web with mobile devices which have even smaller resolution.
This is what min-width is for: to make your dynamically expanded layout look less crowded on smaller resoultions.
I hope this helps.
EDIT:
The Smashing Book has some very nice thoughts about the subject.
EDIT 2:
I don't want my post to sound like I want you to force pixel-based sizing on your visitors.
(Apparently, some people in the comments misunderstood me in such a way.)
To clear it up:
I believe that the ideal layout is one that adjusts well to any possible resolution or setting.
However, we can't always do everything perfectly. Time/resources and the target audience are the key to determine if your site requires that advanced functionality or not.
I'm suggesting that you use the right thing for the given job.
If you are developing a site which will have a significant percentage of visitors who require more advanced adjustments to the site, it may be well worth it.
(Of course, sometimes we just do it for ourselves to have the feeling of doing things the right way, but is is not always a financially sound decision.)
Still, you should do the proper research about what sort of site will be it, who will be the visitors, and such stuff, before deciding about layouts, and whether it is worth the time to make them fluid or more dynamic.
Font sizes
I think you must first understand the issues that exist with working with pixels in CSS:
Zoom in older browsers is broken. For example, IE6 and IE7 do not resize text when zooming. Line-height can be quirky too. These problems do not exist in modern browsers, but they are a reason why many shy away from using pixels for font sizes.
Everybody will see text the same size if you specify the font size in pixels. Browsers have a default size of 16px for paragraphs, so if you only use em and other relative sizes, you will respect the decision of users who change this. This is especially important on text heavy sites, especially if there are more older users. On the other hand, if the design of a site is important I think it is possible and justifiable to use px to specify font sizes without breaking usability.
In the end, you need to make the decision yourself, and it does depend on the exact circumstances, but I think that specifying font sizes in pixels is okay.
By the way, when working with em to specify font size it is a good idea to set the body to font-size: 62.5%. This means the base font size is 10px, so 1em is 10px, 1.6em is 16px and so on, making it easier to think in pixels while designing using ems. I still find it frustrating to work like this, especially when the values of ems cascade. There are some very handy sites like PXtoEM.com that help with this.
Layout issues
The screen is a pixel based layout, so pixels are an intuitive choice for many things. The main issue here is that different users have different screen sizes. As others have pointed out, using min-width and max-width in pixels along with width in percent is a helpful way to respect the size of the screen, while preventing your site to be unreasonably squished or stretched on very small and very large windows.
However, I would generally avoid this approach in favour of CSS media queries. You can then use fixed width chunks and make the layout wider (amongst other things) as the screen size increases. However, CSS media queries, like all cool web technologies, suffers from lack of browser support. Most notably, IE8 and earlier do not support them, although there are JavaScript fixes. On the other hand, the iPhone and other handheld devices do support them, and I would strongly recommend them if you want your site to look nice on these devices.
I think fixed width grids are fine. Fixed width grid systems like 960 Grid System
are popular enough in their own right, and there are so many other sites that have a fixed width, that I doubt you would hear many complaints if you did this. Handheld devices that do not have large screens are an issue, but this is where CSS media queries should be used, so it is possible to specify everything in pixels and have your site looking beautiful on the desktop and on the iPhone.
Conclusion
Ultimately, everything depends on who your users are, what you need to support, and what you want your site to look like, but there is nothing inherently wrong with using pixels in CSS.
That depends on what you are styling. For columns for example, the width should probably depend on the text size to ensure that it will look optimal on multiple resolutions/screens. If you want to divide your page in two parts, you should use percentages. But if you want a 1px border between these two parts, independent of the resolution, use pixels.
Basically it depends on who's hiring you and consequently the audience of your work.
For institutional purposes (where content should prevail over the shape, like a goverment project), you better work with .em or %, they are harder to control, but they will be really user friendly in terms of accessibility.
If we talk about corporative Websites (Where shape is the deal) pixel will be a more accurate tool to fulfill your customer expectation regarding his brand.
A liquid interface (%, .em) is always a good stuff when it is smartly done, but don't forget to check your design under extreme conditions and be sure that it will be stable.
If you work with pixels, you will have absolute control over the final look of your site, but you will have to assume the impossibility for some user's to operate with it efficiently.
Best option: rather than designing a Website compatible for all platforms (what will result in a multi-deficiency design) suggest your customers special versions of the site adapted for every demand, what is a better practice and a better business for a designer too...
I would say avoid it if possible except for in certain cases.
For instance for a thin border it's ok to just specify 1px.
Also for max- and min- style attributes it is ok. But then make the non-max/min attribute be a percentage if possible.
This really is a good question which I have asked many times before. Not being a hardcore web designer (I'm more on the development side) I've usually asked the designers I work with about their opinions, and here is what I have distilled:
Using percentages vs pixels for sizing elements and so on is really a matter of personal taste or the requirements in each specific case. If you need it to scale, or it will scale well, use percentages. If not, use pixels. People here have used the examples of major columns in a page maybe needing to be fluid but borders may well need the precision of a pixel measurement.
Obviously sizing images is pretty much tied to their resolution and pixel units, so I always use them in this case.
However, using em sizing versus pixel or even point sizing for text is a whole different kettle of fish. Most of the guys I work with have a base reset style for font sizes which brings the size of 1em down to about 12px. They then use ems everywhere else (or as near to everywhere else as is possible) to size text elements, form controls and the like. This is how I operate now too as it seems to work well across a variety of browsers, OSes and DPIs on desktops and laptops. I can't vouch for mobile devices though.
Accessibility is the key though - if you need to make something usable for people with disabilities or work on a variety of devices out the box, even things you may consider old, then scaling will be a requirement. Build it into your model for designing the site from the get-go and you may realise that absolute pixel sizing is not even needed in that case.
For example, an art-heavy design is probably going to be designed at a single scale, but the new educational website for disabled users is going to have to work in a variety of situations.
Just remember, the W3C put a variety of methods for sizing and scaling into their specifications for a reason - flexibility. Do whatever fits best and works well for your audience (as Moustard said earlier).
I'm not a css/html expert but convention I use is to use pixels for the outer containers and percentages for the inner objects.
Another rule of thumb I have with anyone reviewing my layout is a Three Pixel Rule. It is rare that everything will line up exactly within every browser out there. We've agreed the effort outweighs the benefits to move anything three pixels or less.
Do the right thing by default. If a user visits your site with javascript disabled and no preference cookies, you should serve them a web page that is as functional and accessible as possible.
Your default stylesheet should assume nothing about the browser window, and still render a functional page, however hideous, down to 320x320 resolution, and up to unbounded sizes. If photographic fidelity is so important that you can't trust browser scaling, and sometimes it is, then you should use pixel measurements (at least minimums) for elements encapsulating images of fixed size, to make sure that you don't end up with important things being covered up. Specifying minimum widths along with percentages should give you the control you need while giving your users the accessibility they need. Even if accessibility isn't an issue now, it will be later if the site is successful.
When you do know more about the browser window, then it's okay to use fixed widths in alternate stylesheets, if the importance of preserving the design justifies the added work.
If you're targeting a fixed size then pixels are fine. But if you want your layout to look good on various resolutions/screen sizes, then you should stick to more relative measures like percentages. Most folks are targeting the latter.
It is ok if that is what it takes to please your client. Most of the time, you can't balance the amount of space in diverse screen sizes with only percentages. CSS3 media queries helps here but adoption is still problematic.
I prefer pixel in most cases.
For example - default width of content ares: 960px.
In "1024" it will be ok, with small free spaces on the both side of the screen. Put some gradient or background there. In "1280" or "1440" or "1680", or whatever - there will be bigger and bigger gap, but it will look nice.
Yep, for 800 - this site will be ugly. But who cares? Every major players dropped support for 800. There are too few people with this resolution..
There are many various sites, where %% will be much better solution, though.
The building blocks of a screen are pixels. You can't go wrong with fixed pixel sizes. As other posters have mentioned, you can also use percentages or "em"s for a scalable substitute.

Resources