Folks voting to close as not constructive, read the whole thing please. Specific questions at the end. Looking for real world examples and approaches.
Context
With numerous devices like smart-phones, tablets being used increasingly to access the web its important to plan, design (responsively) and develop (esp. your front end) to give the devices a fast and tailored user experience.
There's some amazing sites being built. Have a look at mediaqueri.es (resize your browser)
We see approaches such as
big screen first, then target smaller devices.
mobile first then media queries to spice things up for bigger screens.
device detection with different techniques (including server side)
and serving completely different markup and content to devices.
Question(s)
What are you folks doing out there today? Why did you choose your approach and most importantly if it isn't the most efficient approach to tackle this, then what is?
Things I'm looking for:
Is it a pure CSS / JS / HTML approach, or server side, or a combination - why?
Each device gets only the resources (images etc.) that it needs so it performs well
Maintenance of the site is easier, i.e. adding / changing features is not a huge pain
Some code samples are always useful
lets leave out old shitty browsers like ie7 and below
I think what you are looking for is Responsive Web Design.
See:
http://www.alistapart.com/articles/responsive-web-design/
http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web-design/
Responsive Web Design (using CSS) does not necessarily address performance issues but is a good starting point. Keeping in mind that premature optimization is the root of all evil, you can profile your users and bandwidth and determine where you need to optimize once you have a working design in place.
For a discussion of some of the downsides, e.g., image resizing in the browser (you can work around this with CSS and/or AJAX, though), see:
http://www.webdesignshock.com/responsive-design-problems/
You will want to use a framework like PhoneGap. HTML evolves slowly but every day, about 10 new devices with new bugs "features" hit the market and you innocent app - there simply is no way for a small group of people to handle the necessary work.
As for different devices, there are two trouble areas:
Screen sizes
Render bugs
For screen sizes, there are pretty cool solutions today. For example, some frameworks add the CSS style "640x400" or "480x800" to the body element. That makes it dead simple to style elements depending on the screen size. Or you can use JavaScript pull in the matching style sheets.
For render bugs, you'll need workarounds. As I said above, this is nothing a single person or a small group can handle. Every few months, there is a new version of Android with a new render engine and new "features". You fix problems for one of them and break ten others at the same time. Select a framework which plays well with many devices and which is open to changes (read: avoid anything proprietary).
That way, you get solutions for the common problems and you can fix small issues yourself.
I would definately recomment RedFilters Answer (+1).
I just wanted to add some libraries which you might find interesting relating to this topic. They involve Browser feature detection & conditional resource loading.
check them out:
http://www.modernizr.com/
http://yepnopejs.com/
When designing my homepage, I feel like the common knowledge is that it is bad to just have one big picture in the center that gives all of the content. The "right" way to do it would be to chop up the large layed out image into several small backgrounds and make the text use standard html with css background images for layout.
Is the only reason one big image is bad SEO reasons?
A search engine can't make sense of it.
A blind or otherwise visually-impaired person can't make sense of it.
Someone blocking images because he's on a mobile phone with expensive internet can't make sense of it.
There are a few reasons :-)
Also important:
Changes are not easily made to whole, pre-composited images, unless you still have access to the original layered variants. And hopefully they contain text as well, not just pixel data. (Mentioned by others before already. Credits go to pierre and Kendrick)
If you're using background images don't forget to set a text and background color too. Otherwise people not seeing any images might have a hard time deciphering your text (black on black isn't nice to read :-))
You can still use one large image as background. How the text is layed out above that is another matter entirely. In fact, chopping up the image and piecing the pieces together is painful using CSS too. In my experience it's best and easiest to leave background images unchopped and instead composite the rest of the layout above them, using other images or backgrounds if needed. This gives you a little more flexibility when changing a layout again, too.
SEO is one. Handicapped accessibility is another big one -- a screen reader can't read text within an image, typically. Page load time is another one; a user with a slow connection won't see anything useful while the image loads. Lastly, many browsers will use multiple connections to request resources such as images, so they can be loaded simultaneously. If there's just one image, only one connection can be used.
Updating will be tedious; you can also no longer rely on many benefits of CSS.
It's also bad for accessibility (screen readers, text-resizing, different monitor sizes)
It also removes your ability to easily edit text content.
I certainly wouldn't do it if you're looking for a web-developer job, but if you really don't care about the above, you won't be the first person to do it...
I see no reason at all in using imagea to represent something what can easily be achieved with HTML and CSS.
You're putting up a web site to enable communication between you and your visitors. Images and Flash prevent that.
Generally, you design a site with HTML/CSS and text. Only when you wish to add some design that cannot be expressed with standard means, then you use images. But have your site degrade gracefully for those who cannot or does not wish to see images. Let images be an addition, like an advanced version, in no case a replacement for text.
So I was looking at the facebook HTML with firebug, and I chanced upon this image
and came to the conclusion that facebook uses this large image (with tricky image positioning code) rather than many small ones for its graphical elements. Is this more efficient than storing many small images?
Can anybody give any clues as to why facebook would do this.
These are called CSS sprites, and yes, they're more efficient - the user only has to download one file, which reduces the number of HTTP requests to load the page. See this page for more info.
The problem with the pro-performance viewpoint is that it always seems to present the "Why" (performance), often without the "How", and never "Why Not".
CSS Sprites do have a positive impact on performance, for reasons that other posters here have gone into in detail. However, they do have a downside: maintainability; removing, changing, and particularly resizing images becomes more difficult - mostly because of the alterations that need to be made to the background-position-riddled stylesheet along with every change to the size of a sprite, or to the shape of the map.
I think it's a minority view, but I firmly believe that maintainability concerns should outweigh performance concerns in the vast majority of cases. If the performance is necessary, then go ahead, but be aware of the cost.
That said, the performance impact is massive - particularly when you're using rollovers and want to avoid that effect you get when you mouseover an image then the browser goes away to request the rollover. It's appropriate to refactor your images into a sprite map once your requirements have settled down - particularly if your site is going to be under heavy traffic (and certainly the big examples people have been pulling out - facebook, amazon, yahoo - all fit that profile).
There are a few cases where you can use them with basically no cost. Any time you're slicing an image, using a single image and background-position tags is probably cheaper. Any time you've got a standard set of icons - especially if they're of uniform size and unlikely to change. Plus, of course, any time when the performance really matters, and you've got the budget to cover the maintenance.
If at all possible, use a tool and document your use of it so that whoever has to maintain your sprites knows about it. http://csssprites.org/ is the only tool I've looked into in any detail, but http://spriteme.org/ looks seriously awesome.
The technique is dubbed "css sprites".
See:
What are the advantages of using CSS
Sprites in web applications?
Performance of css sprites
How do CSS sprites speed up a web
site?
Since other users have answered this already, here's how to do it, and another way is here.
Opening connections is more costly than simply continuing a transfer. Similarly, the browser only needs to cache one file instead of hundreds.
yet another resource: http://www.smashingmagazine.com/2009/04/27/the-mystery-of-css-sprites-techniques-tools-and-tutorials/
One of the major benefits of CSS sprites is that it add virtually 0 server overhead and is all calculated client side. A huge gain for no server side performance hit.
Simple answer, you only have to 'fetch' one image file and it is 'cut' for different views, if you used multiple images that would be multiple files you would need to download, which simply would equate into additional time to download everything.
Cutting up the large image into 'sprites' makes one HTTP request and provides a no flicker approach as well to 'onmouseover' elements (if you reuse the same large image for a mouse over effect).
Css Sprites tecnique is a method for reducing the number of image requests using background position.
Best Practices for Speeding Up Your Web Site
CSS Sprites: Image Slicing’s Kiss of Death
Google also does it - I've written a blog post on it here: http://www.stevefenton.co.uk/Content/Blog/Date/200905/Blog/Google-Uses-Image-Sprites/
But the essence of it is that you make a single http request for one big image, rather than 20 small http requests.
If you watch a http request, they spend more time waiting to start downloading than actually downloading, so it's much faster to do it in one hit - chunky, not chatty!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm making a website now and I am trying to decide if I should make it fluid or not. Fixed width websites are much easier to make and also much easier to make them appear consistent.
To be honest though, I personally prefer looking at fluid websites that stretch to the full width of my monitor. My question comes from the fact that in most modern browsers you can hold control and scroll your mouse wheel to basically resize any website.
So is creating a fluid website worth the trouble?
It depends on your audience and your content.
The following are sites I respect and I think are example to imitate.
Fluid Examples:
Amazon
Wikipedia
Static Examples:
Apple
eBay
MSN
StackOverflow
MSDN
Some Mix it Up!
CNN
I think I prefer static most of the time. It is easier to make it look good in more browsers. It is also easier to read.
Making a website fluid, but adding a min/max-width attribute seems to be the best of both worlds, for me. You support fluidity, but you limit it at a certain width (say, 800px and 1200px).
It is up to you - here are some things to consider:
Text is hard(er) to read when lines are very long.
Your audience may have larger or smaller resolutions than normal, and picking an 'incorrect' static width will annoy them.
Maintaining a fluid site can be, but doesn't have to be much more difficult than its static counterpart.
Absolutely. It is a big inconvenience to people with huge monitors to have to resize the page. It can also be a bit dodgy with some layouts. Little inconveniences, no matter how trivial, can actually affect people's opinions of your site.
Also, netbooks have odd resolutions which make it hard to design sites for. For example, I'm writing this at 1024x600.
It's not particularly hard nowadays either (in modern browsers), especially with min- and max-height in CSS, and the new gradients, etc in CSS3, so image scaling won't be as big a problem in the near future.
In response to the comment below, I think that the pros outweigh the cons in this particular case - IE6 is a problem everywhere. We just have to deal with it.
You have to realize most computer users don't even KNOW HOW to zoom in the browser! Most users are so far from the understanding of computers that we have. We always have to remember that fact.
Text based apps: No. Table based apps: Yes.
Pros of fluid layouts
People with big monitors gets to use their screen real estate.
Easier for users with big monitors when you have a lot of information on your page.
Cons of fluid layouts:
A fluid width text column is hard to read if it's too wide. There's a good reason behind the use of columns in newspapers: it makes skipping to the next line much, much easier.
(Somewhat) hard to implement, because of the limitations in CSS.
If you're showing tabular data (iTunes, db manager, ...), fluid width is good. If you're showing text (articles, wiki pages, ...) fluid width is bad.
From my iPhone's perspective, fixed width layout is problematical when using code blocks. The scrollbar for wide code blocks doesn't show up, so I can't read the far right of the block.
Otherwise, I think it's a simple matter of what kind of site you're designing and how it looks on different size screens and windows. As previously mentioned, there's an option to set a maximum width, but the same caveat applies to code blocks and iPhones. I've designed both, and I don't prefer one over the other.
Although, it's fun to watch the boxes move around as I play with the browser size with a fluid layout, but I can be easily amused.
The most important thing is to consider dominant use cases of your web site or application. Do you expect people to use it exclusively on mobile devices? Mobile phones, netbooks, desktops?
Take a look at "Responsive Web Design" by Ethan Marcotte: http://www.alistapart.com/articles/responsive-web-design/
Great article that demonstrates the use of truly fluid layouts using media-queries. Sometimes you need to built out a separate front end for different user-agents, but sometimes media-queries are the perfect tool to service multiple resolutions across different user-agents.
It depends on what you're trying to do. Take a look at SO. It's fixed width and it's great. In fact, if it were fluid, it would be a bit of a PITA. Some sites look better with fluid layouts, but personally, I'd go with fixed unless you have a good reason to go fluid.
Many good points in the comments but from your question it seems you really like fluid designs and want to create one so go for it, it's your site, it doesn't have to be like every other site on the web.
Just be aware of pros ond cons of every solution.
Up to a point - yes.
There's a certain width, where text begins to become annoying to read if it's too wide. Easy to test if you have a large monitor, just grab notepad and paste some text into it without line breaks.
However, when going down to smaller sizes, being fluid might be a good idea. Mobile phone browsers are more and more capable of displaying "normal" websites just fine, but they are sometimes width-constrained, and as such, benefit if your site can fit in a bit smaller space.
Personally I also like to keep browser on my monitor but only at half of the monitor's width (24"). Sites which scale nicely into that are very good.
I think it's mostly a user convenience case. Not all sites will benefit from being fluid, but I think sites which have lots of text content are the ones that will most benefit from it, at least if they are fluid up to a max width (say 800px or whatever)
Yes. Page zooming is great but it is primarily used to make text bigger, not to make text fill the viewport. Certainly if the body text is already too wide, zooming down to make it fit will usually make it unreadable.
You need liquid layout if you're going to make the text fit the viewport whether or not it's zoomed.
The point about ‘long lines being hard to read’ is often overstated by designers trying to justify fixed width designs(*), but in reality it doesn't seem to hold quite as strongly on-screen as it did on paper. Of course setting a good leading/line-height is important, and max-width can be used to inhibit the worst excesses of long lines. (Set it in font-relative em units.) You don't get max-width in IE6, but that's not the disaster it once was. (You can fix it with a little bit of JavaScript if you really care about those guys. I don't.)
(* which are indeed less work for highly graphical layouts. But for a simpler layout like, er, StackOverflow's, there isn't really any reason not to go liquid. Tsk #SO, eh!)
Preface: Not a professional web artist.
I've found that there's way too many fiddly bits to get things to flow just so at cell-phone and uber-widescreen sizes, especially in anything of reasonably interesting complexity.
Typically, I design around having a fixed-width site in some fashion; usually bounded at [600,1200].
I also find super-wide columns of content to be a hassle to read. I seem to remember that there's some research which suggests an optimal number of words per column line.
You can make it like this.
# Make the main layout fluid and apply 'max-width: 1140px' to it and center it.
By this there won't be 'long lines' of text on bigger screens and proper settlement of web page on smaller ones (excluding 800x*** and lowers).
I have implemented this method in my new projects and it's working like a charm.
a.t.b .. :)
I think the decision fluid/fixed should be based also on content of the website:
For sites with big amounts of plain
information (like news portals),
better to use fluid layout.
Web-services better look and work in
fixed dimensions, so you always know
where interface elements are located
in their places and they are not moving
around constantly.
Yes, fluid websites are worth creating
As you said, it looks good and reasonable when you plan properly at design phase.
Your doubt about the impact of Ctrl + Scrollbar is not a big deal.
This feature is primarily for accessibility, to make text more readable by increasing the size.
However, if you mention all your sizes in Pixels (px) it won't happen.
Proper adjustment happens only when you use "em" to specify size. So you have a way to turn it on/off
I'm a big fan of fixed at < 800px... it's easier to read narrower columns, and it will work anywhere. That is, if you're trying to make a website that presents hypertext... Websites which present application front-ends, are I think another can of worms entirely...
Fluid design - truly fluid - is hard. Very hard. It's not just a question of page width - do your fonts scale, and does everything scale with them? Ideally:
Sizes should be defined in em rather than px
...and that goes for element sizes, not just fonts!
Given a change in font size or zoom level, the page elements should be the same size relative to each other
Our main product is fluid, and it's a pain from my point of view as a designer, especially because it involves a lot of user-generated content.
For one thing, images - in a fixed-width site, you can have an image that fills half the width, and looks great. In a fluid site, this image is just as likely to be lost in a sea of whitespace, looking rather lonely.
Life should be easier once border-radius and other CSS3 properties come into play more, but sadly our core audience are government workers, who all, ALL STILL USE IE F#!*ING 6!
To answer the question, "is it worth it"? Yes, if you do it right.
Here's a scenario: choose a fixed-width site: your boss displays it to a client on his brand-new, 1920x1600 laptop, then complains to you about "how it all looks small on this guy's screen!"
I think it's nice to be able to scale well on a user's screen, rather than make the users pan and zoom. In a time when users surf the web from such a wide variety of devices, ranging from smartphones to ultra-mobile PCs, each with its own, possibly non-standard resolution, I think it's important to keep user-experience at a high level when your site is viewed on such screens. Regarding the text length, it could be bounded by a certain ratio, so it would fit nicely within the layout. I think there are also frameworks that may help with writing a site in a fluid manner, and help with coding maintainability.
I'm gonna go against the majority and say NO. Reasoning: fluid sites like Wikipedia are a nightmare to read on large screens due to their long line length (though its citations make it hard to read at the best of times).
The problem really occurs because there is no mechanism to size text relative to the screen resolution. If you could automatically make text bigger on bigger resolutions, you could stay closer to the 80-odd characters per line that's generally regarded as the best for readability.
There is also the problem of images and other fixed-size elements. You can have large images and let the browser shrink them if necessary, but then you run into other problems like much longer download times, and image quality problems in many browsers.
I'm a fan of sites that do have a fixed max width of between 800px - 1000px, but can also scale down so that I can read the content without scrolling side-to-side and also without zooming out because often the text becomes too small to read and it hurts my eyes. So, this is normally want I strive for because I want to build sites I can be proud of.