Screen Resolution "Friendly" Website

[dansbanners]

Hi,

Anyone have any recommendations or suggestions on how one could create a screen resolution "friendly" website ?

In another word, a website that'll look good in all or in most of the up to date, more commonly used resolutions ?

Cause my experience is that sometime I'd make a website generally based on how it looks in one resolution, only for it not too look quite as good when I switch to an higher one. Especially after getting a new computer ?

I'd appreciate it. Thanks in advance !

[johnfl68]

I think lately people have been authoring for 1024 x 768, and this is what I do. Also, based on the site content, either variable width (as possible) or floating center content with the left and right side background expanding (for wider screens).

It is almost impossible to match all screen resolutions these days. Here are the browser resolutions from Google Analytics for one of my sites:

1024 x 768
1280 x 1024
1280 x 800
800 x 600
1280 x 960
1280 x 768
1152 x 864
1440 x 900
1280 x 1050
1400 x 1050
1280 x 720
1920 x 1200
1600 x 1200
320 x 396 (cell phone?)
1344 x 840
1360 x 768
1120 x 840
1152 x 870
1300 x 1300
1600 x 900
1152 x 720
1600 x 1000
1600 x 1024
800 x 628
800 x 664
819 x 614

How do you possibly code to look good on ALL of those! :confuz:

I typically look at the first 3 resolutions as listed above (Firefox with Web Developer Add-on - using the resize feature), and if it looks decent for them leave it at that.

That is about the best you can hope to do.

John

[Randall]

Our breakdown looks pretty similar to Jeff's -- the top four match exactly. But I'm not willing to write off the 800x600 demographic just yet. Makes up less than 10% of our traffic, but that's still almost 21,000 page views.

640x480 is #25 on the list, only 0.08% of our traffic in the past 12 months, so I'm somewhat comfortable leaving them behind...

My approach is to fix the width at an 800x600-friendly size (you have to account for the vertical scrollbar, so I've settled on 770px as a safe choice) and center it on the page. Looks much better that way on a 1680x1050 monitor than pinned to the left edge.

To make it look more natural on wider screens, I'll use things like a top logo bar that spans the entire page and/or a background color or pattern outside the 770px content space. On an 800x600 monitor you don't see those details, but they aren't critical to the site. Just a little something extra for those monster monitors. :wink:

(I'm also experimenting with ways to let the home page expand to two columns on 1440px+ screens, but it's pretty crude so far.)

Randall

[dansbanners]

Hi,

Is there some kind of a tool that'll enable you to test your websites in different browsers or resolutions ?

One such tool that I know of that does some of that is the Netmechanic.

However, I'm also looking around to see if there are other similar tools other than the one mentioned in this post ?

Thanks again !

[Matt]

Fluid designs allow you to look good across a range of resolutions, but you have less control over how one element is going to be positioned relative to another one.

As far as fixed width design is concerned, you have to be careful of printer constraints. Somewhere in the neighborhood of 800 pixels wide, printers cut off the sides in portrait mode (and you can assume the bulk of users will print in portrait mode). So, if you build for higher resolution, you should offer a print-specific version. Finally, just because my monitor is running at 1280 x 1024 doesn't mean I have the browser windows maximized (it kind of defeats the purpose of having a larger monitor, in my opinion). Inevitably, you will run across someone who's running browser windows maximized at 1600 x 1200, but I wouldn't design for this.

-Matt

[jmihawkins]

Randall, how do you know the user's screen-res stat???

640x480 is #25 on the list, only 0.08% of our traffic in the past 12 months, so I'm somewhat comfortable leaving them behind...

[Randall]

Fluid designs allow you to look good across a range of resolutions, but you have less control over how one element is going to be positioned relative to another one. That's what I'm thinking about for our home page. The trick is, I want fixed-width columns that flow automatically, and so far you can only do that in the Mozilla and Safari browser families: -moz-column-width:600px;
-moz-column-gap:10px;
-webkit-column-count:600px;
-webkit-column-gap:10px Looks great in the right browser, but it's just one wide column in IE. As far as fixed width design is concerned, you have to be careful of printer constraints. Somewhere in the neighborhood of 800 pixels wide, printers cut off the sides in portrait mode (and you can assume the bulk of users will print in portrait mode). So, if you build for higher resolution, you should offer a print-specific version. I'm contemplating a printer-friendly version that would dump the navigation menus (don't work too good on paper :wink:) and pretty much the entire style sheet. Should I expect the browsers to set sensible page widths if I don't specify anything at all? Finally, just because my monitor is running at 1280 x 1024 doesn't mean I have the browser windows maximized (it kind of defeats the purpose of having a larger monitor, in my opinion). This is especially true on Macs, where "maximizing" is a foreign concept. Basically when you click on the "zoom" button, the application decides how wide the window should be. Firefox 2 only goes out to 1312 pixels on my 1440 pixel screen. On the older "desk lamp" iMacs (http://www.everymac.com/systems/apple/imac/stats/imac_800_fp.html) it would be only 896 pixels.

(Firefox 3 does a PC-style maximize, which has been controversial. Frankly, I don't understand Mac users' hatred of full-screen windows -- you can unmaximize them anytime you want.)

Also consider that some people use the sidebar in Firefox or IE, which takes away some screen real estate even in a maximized window. And then there's AOL... :rolleyes:

And yeah, I'm one of those people running browser windows at 1680x1050. :rasberry:

Randall

[Randall]

Randall, how do you know the user's screen-res stat??? Google Analytics tracks screen resolution, among other things. I don't know how complete it is (people who browse with Javascript turned off won't be counted), but hopefully the relative figures are close to reality.

Randall

[jmihawkins]

As far as fixed width design is concerned, you have to be careful of printer constraints. Somewhere in the neighborhood of 800 pixels wide, printers cut off the sides in portrait mode (and you can assume the bulk of users will print in portrait mode).

And back when I started, the suggested fixed width for 'printer-friendly' was 535px. I still code certain forms at 535px, those intended to be printed, filled-out, then mailed or faxed, and I'm amazed how many of my customers have reset font sizes to LARGE or LARGE-LARGE, so the print STILL runs off the right side....

Those 'monster' monitors do create a few problems for some of us oldsters. I recently helped my uncle set up a new 21-in landscape - everything was 'squashed' at the default res, then couldn't be read at the 'correct' res. So we bumped font sizes, changed mouse speeds, modified browser settings, etc, etc. So no matter what you code for, there are way too many ways for 'them' to screw it up.

[Randall]

And back when I started, the suggested fixed width for 'printer-friendly' was 535px. That's a good practice even for onscreen design, because it makes for more comfortable reading. There's a reason why books are the size they are: People can lose their place if the text is too wide.

If you do feel compelled to "go wide" -- like the leading paragraph in some magazines -- you should compensate by increasing the line spacing or the font size. That keeps the eyeballs on track.

Hmmm, maybe my ideal "liquid" layout would be one that increases the font size as the window widens. I think you'd need some Javascript to do that. Those 'monster' monitors do create a few problems for some of us oldsters. I recently helped my uncle set up a new 21-in landscape - everything was 'squashed' at the default res, then couldn't be read at the 'correct' res. So we bumped font sizes, changed mouse speeds, modified browser settings, etc, etc. So no matter what you code for, there are way too many ways for 'them' to screw it up. Yes, there is the Aging Eyeball Factor to consider. :wink:

I'm actually rather surprised at how easily my (older) coworkers have adjusted to the native LCD res, now that we've rid ourselves of the last of the CRTs. These are people who used to crank a 19" CRT up to 800x600. I guess they're resigned to wearing their reading glasses at the computer now.

Initially I was steering them toward 19" LCDs because you've got the same pixel count as a 17" in a bigger screen. But now that the market's dominated by lower quality LCD panels, I see better value in a good 17-incher. (Seems like the Dell 2007WFP (http://accessories.us.dell.com/sna/productdetail.aspx?c=us&cs=19&l=en&s=dhs&sku=320-4688) is the last of the great consumer-level monitors -- I've got one at Job #2 and I love it.)

Another point to consider: When I was testing the early Firefox 3 betas, I found myself using its zoom feature on a number of web sites. Unlike the usual "zoom" feature we're used to, Firefox 3, IE7 and just about any version of Opera can increase the size of everything on the page at once, not just the fonts. So if readers find your fonts a little too small for comfort and zoom in a notch, a 1024px design may run off the sides of the screen.

Randall

[jmihawkins]

Yes, I'm perfectly happy with nice 17", std width, dont care for the landscape monitors. My uncle was perfectly happy with his 17 - and actually I think his newest is a 21, maybe not - but it seemed to defeat most of the purpose to increase font and window sizes to mimic the 17.
And dont forget the other direction in user screens - mobile devices.... The rec's are to provide yet another version of every page, coded for ease of use on THAT format.

[dansbanners]

Fluid designs allow you to look good across a range of resolutions, but you have less control over how one element is going to be positioned relative to another one.

As far as fixed width design is concerned, you have to be careful of printer constraints. Somewhere in the neighborhood of 800 pixels wide, printers cut off the sides in portrait mode (and you can assume the bulk of users will print in portrait mode). So, if you build for higher resolution, you should offer a print-specific version. Finally, just because my monitor is running at 1280 x 1024 doesn't mean I have the browser windows maximized (it kind of defeats the purpose of having a larger monitor, in my opinion). Inevitably, you will run across someone who's running browser windows maximized at 1600 x 1200, but I wouldn't design for this.

-Matt

Are you talking about that fluid designs would be something along the lines of using percentages as in "width=75%" as opposed to using a specific pixel number as in "width=650" or something to that sort right ?

[McDuff]

I think you should look first at your target group; who do you want to reach.

If you are trying to reach nerds, young, university, or upper business class, probably they will have new stuff with high resolution and big, wide-screen monitors.

Your average Joe probably still is happy with a 15, max 17 inch monitor and max 1280 x 1024 but probably less, and normal 4/3 ratio. Quite a lot of average homes or institutions don't even reach that. Have a look in the average library; quite a lot of them are still using these rounded 14-15" CRTs with W98 or worse.

I think Randall gave the best strategy (which we follow also :wink: ) , that is, make things look perfect in 800x600 and add some extras so it still looks good in higher resolutions, you never can go wrong that way.

Making it perfect for 1280 or more and annoying 75% of your target group is also not good business.

[jmihawkins]

I agree with the 800x600 strategy (subtract 50 or so for scroll bars). I suspect a hi-percent of monitors are now 17's running at 1024x768 (since that's whats been shipping as 'standard' with most new systems for 3-4 years now), but there are probably quite a few 15's and even some 13's still around, especially in SMBs - but those 640x480 users are probably used to having to scroll-right by now. I think the landscapes, 19's, and 21's are just beginning to populate over the past coupla years or so, and those users are probably used to not getting a screenful.
'Fluid design' (by which I mean using percents instead of fixed) is great if you dont care about the object/text relationships, but I'm a little too much of a control-freak to be comfortable with that.
I'm still coding in html3 fixed-width and for 640x480 res - yeh, yeh, I know I need to get out of the 1990s and 'move up', but the prospect of converting all those tables on 500+ pages is pretty darn daunting. And finding the time to learn html4 and css...

[Randall]

I'm still coding in html3 fixed-width and for 640x480 res - yeh, yeh, I know I need to get out of the 1990s and 'move up', but the prospect of converting all those tables on 500+ pages is pretty darn daunting. And finding the time to learn html4 and css... The site I'm working on now was designed for 640 pixels, more or less (I think the designer forgot the scroll bars, so it spills over a bit). I built it with tables, because the only CSS I trusted at the time (mid 2003) was text formatting.

But one smart thing I did was to keep the table tags and the content separated. I make heavy use of server-side scripting (ASP in this case), bringing the basic page content and the global elements -- header, menus, footer -- together from separate files. Helps maintain consistency, and it's easy to make site-wide design changes. I've survived two previous redesigns thanks to that strategy.

So now I can replace the 90s-era header/footer files with spiffy new CSS-based designs, update the text style sheets and basically leave the content alone. Or so I hope. :safegrin:

Randall

[jmihawkins]

Randall, maybe I'm misunderstanding? In another life I was a COBOL, CICS, and C coder, and was well used to changing an 'include' file that was then incorporated into existing code. My biggest lament is the tedious chore of changing headers, footers, and other 'standard' test page-by-page across multiple pages. Are you saying I can do this with CSS? I can't find that described in any of my $$$ worth of books...

[jmihawkins]

Or maybe it's the 'server-side' that makes the diff?

[McDuff]

Are you saying I can do this with CSS? I can't find that described in any of my $$$ worth of books......Or maybe it's the 'server-side' that makes the diff.....

"sever side" and CSS doing it together and its easy to learn. We had a HTML frames site but shifted to dynamic php two years ago. We now have one simple index.php and a CSS file that control everything (including positioning of pictures on the page), the rest are body-content pages that have only meat, no coding (except for maybe a bit of font adjustment).

Another tread (http://www.aota.net/forums/showthread.php?t=23831) describes our set-up. I am trying to sort out the last problems with dynamic page titles with a lot of help from other FQers (great forums on FQ :bow:, quick and good replies); that and the sitemap are the last things needed on the coding side. After that, it's just adding or updating an individual page without coding.:clown:, making links in the index.php, or adjusting the entire layout by changing some things in CSS.

Easy to learn because others before us already invented the wheel and gave pretty good descriptions on how to change the tires.

[dansbanners]

My site was originally built based on the 800 x 600. But the dilemma is that I used "width= %" in the codes. Such that what may look good in a 800 x 600 using something like "width = 90%" would wind up looking "too long" in a 1280 x 1024, the resolution that came with my new computer.

Anyone have any suggestions on how to get around this ? I guess one way would be to use fixed width dimensions such as "width = 600", "width = 750", etc. Right ?

[jmihawkins]

I use a table to hold the entire page, fixed width, and code within that.
You can then code subsequent tables, cells, etc as a '%', constrained by the 'whole-page' table width.
There are plenty of other methods. One would be '%' for the 'whole-page' table to allow stretching header backgrounds, then fixed-width centered tables under that with '%' for individual cells.
And then there's the html4 school of thought that wants us to move away from tables ...

[Matt]

dansbanners wrote: Are you talking about that fluid designs would be something along the lines of using percentages as in "width=75%" as opposed to using a specific pixel number as in "width=650" or something to that sort right ?Yes and no. Text that runs more than about 500 pixels wide starts to get too long, in my opinion. So, a block of text would be defined with a specific pixel width, but it would float in a container defined by a percentage. A header might have a pixel width of 750px, but float on a background of 100% width that makes header appear to expand and contract, based on window size. Still, it's hard to make a design that's going to scale from 800 x 600 (or less) to 1600 x 1200 (or more) and look good at every resolution. -Matt

[Arthur]

Anyone have any suggestions on how to get around this ? I guess one way would be to use fixed width dimensions such as "width = 600", "width = 750", etc. Right ? There are three basic layout options; fixed width, fluid/liquid layout and elastic layouts.

Elastic layouts stretch but not endlessly, like liquid layouts. You basically get the benefits of both fixed and fluid layouts, although it does have its downsides (backward compatibility for one).

There are loads of pages on the subject, here are some to start with;
- A List Apart (http://www.alistapart.com/articles/elastic/)
- 456 Berea St. (http://www.456bereastreet.com/archive/200803/specify_a_maximum_width_for_embased_layouts/)

-Arthur

[dansbanners]

I use a table to hold the entire page, fixed width, and code within that.
You can then code subsequent tables, cells, etc as a '%', constrained by the 'whole-page' table width.
There are plenty of other methods. One would be '%' for the 'whole-page' table to allow stretching header backgrounds, then fixed-width centered tables under that with '%' for individual cells.
And then there's the html4 school of thought that wants us to move away from tables ...

Michael,

I hope you don't mind my asking you this, but is your site, the one in your profile, an example that uses the above ?

[dansbanners]

As a continuation of the discussion, so does that explain why some sites seem to consist of two main, large border tables on their pages ?

The outer showing just the background and the inner showing the page's texts, links, graphics, menus, etc ? Is that part of the idea, making it compatible with the different resolutions ?

[jmihawkins]

dansbanners,
Bearing in mind my site is running as a VERY 1990's site, coded in (sloppy) HTML3, for 13in monitors with 640x480 res ...
I do use a main table to hold the entire page, set at 595px, default-justified (ie, left), and then code within that. I don't use percents, all table cell sizes are calculated by hand and hardcoded.
I've done the initial 'design' (hah) work on 3 or 4 other sites for friends, and on those I did play with various percent type options, but still using a main table as the page 'container'. I think all those sites used a centered main-table, and played around on 1 or 2 of them with multiple colors and sizes for background, borders, etc. They liked it, I wasnt real happy.
Truth be told, I've no business writing anything in this discussion - I'm working with 15-year-old tech and concepts, and ALL the others here are way more knowledgeable!

[jmihawkins]

As a continuation of the discussion, so does that explain why some sites seem to consist of two main, large border tables on their pages ?

The outer showing just the background and the inner showing the page's texts, links, graphics, menus, etc ? Is that part of the idea, making it compatible with the different resolutions ?

Maybe they've coded it that way, or maybe they've just set a body background color, so the entire page is all one color.... depends on the tech they're using. I believe with CSS and containers, you can set the overall body BG color, and then set the container to another color. Much more tedious and far less cross-browser compatible to do that using my tech. I use a body background color, so the entire page is all one - left, center, right.

[dansbanners]

dansbanners,
Bearing in mind my site is running as a VERY 1990's site, coded in (sloppy) HTML3, for 13in monitors with 640x480 res ...
I do use a main table to hold the entire page, set at 595px, default-justified (ie, left), and then code within that. I don't use percents, all table cell sizes are calculated by hand and hardcoded.
I've done the initial 'design' (hah) work on 3 or 4 other sites for friends, and on those I did play with various percent type options, but still using a main table as the page 'container'. I think all those sites used a centered main-table, and played around on 1 or 2 of them with multiple colors and sizes for background, borders, etc. They liked it, I wasnt real happy.
Truth be told, I've no business writing anything in this discussion - I'm working with 15-year-old tech and concepts, and ALL the others here are way more knowledgeable!

No problem. Just wanted to make sure you were aware of it. I'm wondering why not make the page more attuned to the center of the screen ? I'd think that'll make it look a little better regardless of which resolution one use. That is seeing the page on the center of the browser, rather than just to the left which could come across even smaller on a screen with a larger resolution.

Just my humble opinion. It's your preference.

[Randall]

In another life I was a COBOL, CICS, and C coder, and was well used to changing an 'include' file that was then incorporated into existing code. My biggest lament is the tedious chore of changing headers, footers, and other 'standard' test page-by-page across multiple pages. Or maybe it's the 'server-side' that makes the diff..... Bingo. :yeah:

Includes in PHP, ASP, etc all work on that same principle: Move stuff that most every page needs into a separate file and have the web page proper include() it inline. When the includes themselves are server-side scripts, you can build very complex pages using little more than CSS, generic HTML and maybe a few custom functions. With your programming background, you will love this stuff. :winky:

I'm still frustrated by some of the limitations of CSS layouts -- certain things are much more straightforward using tables. For the hard cases, I'll start with a table, then go work on other stuff for a while. Later when I feel adventurous, I start experimenting with floats and relative/absolute positioning until I get what I want. It was still simpler to do it with a table, but I've learned something in the process -- and the code does look cleaner and easier to maintain.

I imagine that CSS is a little easier to understand if you have experience in desktop publishing, since that was the inspiration behind it. I'm wondering why not make the page more attuned to the center of the screen ? Centering is a big help with larger screens. You can make the site as narrow as you want -- or even limit its vertical size -- and it still looks good.

The problem is, it's way easier to do this with tables. I find myself using a raft of complicated CSS techniques to ensure that the page centers in all modern browsers, and the zoom feature in IE7 adds an extra wrinkle because it behaves differently than Firefox 3 or Opera. (What else is new?) Fixing it for IE can create some bizarre problems in all of the other browsers, so I'm resorting to IE-specific conditional comments to make sure IE7 gets the TLC it needs. Arg. :blah:

Randall

[jmihawkins]

I'm wondering why not make the page more attuned to the center of the screen ? I'd think that'll make it look a little better regardless of which resolution one use.

Because way back in 1999, when I was running IE4 and Netscape3, they both treated full-table centering VERY different - if I remember correctly align=center for a table attribute wouldn't work in Netscape, and the code needed for Netscape centering screwed up my overall layout in IE ....

Since the trend even then was toward IE, and I had a 'template' of sorts that worked, I kept coding in that direction, and then the site got too big and my time got too little, and so there's no going back and 'fixing' some 500 pages one by one these days. <sigh>

[jmihawkins]

With your programming background, you will love this stuff...
I imagine that CSS is a little easier to understand if you have experience in desktop publishing, since that was the inspiration behind it.

Us greybeards used green-screen dumb-terminals - I never touched a mouse til '98 or so when they forced me to, and then just to get logged onto the mainframe so I could do 'real' work. :wink:
Desktop publishing? For a COBOL coder? Never heard of it...
After I quit, I moved into 'application user' and never came up to speed on 'modern day' langs. Shoot, nearly everything I do in front of this screen is derived from those over-control COBOL/CICS days. :hrmm: