1024 x 768 or 800 x 600 - screen res

Keewee6

wat do u generally build for

Goodshape

1024, definitely.

Basq

Yep..

If you're on an 800 x 600 screen, get back to your 'Manic Miner'

tricky D

970/980 px wide

pixelburp

1024x768 - with your website around 960-980 in width. Nobody uses 800x600 anymore, bar some offices that can't / won't upgrade. Having said that, according to some statistics, 1024 isn't the dominant resolution anymore; it seems to be a mix of higher resolutions. I imagine it's because of all the Dell computers and their ilk being shipped with widescreen monitors:

http://www.w3schools.com/browsers/browsers_display.asp

aidan_walsh

Even at higher resolutions 960/980 is still a pretty good goal as most browsers won't be full screen.

TitoPuente

A year or two ago, I moved from 800x600 to 1024x768. Just moving with the times.

I considered moving back to 800 width designs when it looked like cheap netbooks were going to take over. Some of them have 800*600 as max resolution. I'm not seeing anything in analytics to suggest that I'll need to go back though. Just as well - 800 width sites look daft on a 1920 monitor

Goodshape

I think even netbooks are 1024 wide, no? Obviously aren't as tall but that's less of an issue.

Some could only manage 800 when I was looking a year or two back...

red_ice

min-width: 1000px;

lucideer

Neither. Flexible-width pages are now more relevant than they ever were before, due to a new consideration - mobile/device browsers.

So forget 800px/1024px widths - you now need to be developing for 320px width. Media-queries and viewport meta-tags (and soon @viewport in the newest CSS3 drafts - when it gets some support) can help in adapting, but you still need to be designing your site layouts with this in mind from the beginning...

Goodshape

lucideer wrote: »

Neither. Flexible-width pages are now more relevant than they ever were before, due to a new consideration - mobile/device browsers.

Designing for mobile devices is a separate task.

Liam Byrne

lucideer wrote: »

Neither. Flexible-width pages are now more relevant than they ever were before, due to a new consideration - mobile/device browsers.

So forget 800px/1024px widths - you now need to be developing for 320px width. Media-queries and viewport meta-tags (and soon @viewport in the newest CSS3 drafts - when it gets some support) can help in adapting, but you still need to be designing your site layouts with this in mind from the beginning...

That might be possible for text-based sites, where you can use percentages and em for layout, however if you introduce graphical elements and images it's almost a non-runner.

Even if you do have an image set to appear as 100%, the original source file will look crap if resized in-browser, and if you do upload a high-res file and use server-side processing to scale it up you'll end up with a 2 or 3 meg download on a 1920x or larger screen, which would be far too slow.

lucideer

Goodshape wrote: »

Designing for mobile devices is a separate task.

Only if you're planning on providing an alternate mobile site, which is somewhat inconvenient, not only to maintain in parallel, but also for mobile/device users.

Liam Byrne wrote: »

That might be possible for text-based sites, where you can use percentages and em for layout, however if you introduce graphical elements and images it's almost a non-runner.

Even if you do have an image set to appear as 100%, the original source file will look crap if resized in-browser, and if you do upload a high-res file and use server-side processing to scale it up you'll end up with a 2 or 3 meg download on a 1920x or larger screen, which would be far too slow.

I'm not sure what you mean by "graphical elements and image" - I assume photo galleries. If so, I don't really see where the problem is - terms like "non-runner" and "look crap" are fairly strong, particularly given (for example) the number of JS-library based galleries using extensive in-browser image resizing, and all sorts of other dynamic image-manipulation methods to produce perfectly acceptable looking sites. I've certainly never seen a need for 2-3meg downloads for decent web quality images.

Unless you were referring to something else I couldn't deduce...

Goodshape

lucideer wrote: »

Only if you're planning on providing an alternate mobile site, which is somewhat inconvenient, not only to maintain in parallel, but also for mobile/device users.

It's really not that difficult if you're using an MVC structure for your website/app.

Fluid width works for some sites -- usually text heavy, information based sites. Boards.ie, for instance, has a fluid width (and even then they still have a mobile version) and that works fine. As does Wikipedia (and again, still maintain a separate mobile version). A rectangular box can be any width it needs to be. But if you're actually interested in creating a visual experience then fluid just doesn't work in most cases, and isn't worth the hassle in most others.

Do you have any examples of fluid-width websites that look well across desktop and mobile? I really can't think of any. As the two examples I've used illustrate, even a fluid-width desktop style isn't going to look fantastic on mobile. It works no better on my mobile (Android) than a 1024 optimised site... which is fine in most cases! Renders fine, can zoom where I want... but to get the most out of it a separate design / stylesheet for mobile is required.

There's also a lot more to consider with mobile web design than just screen size.

Liam Byrne

lucideer wrote: »

I'm not sure what you mean by "graphical elements and image" - I assume photo galleries. If so, I don't really see where the problem is - terms like "non-runner" and "look crap" are fairly strong, particularly given (for example) the number of JS-library based galleries using extensive in-browser image resizing

In-browser image resizing is generally pretty chronic; there's no interpolation to handle scaling upwards and unless it's resized by an even factor it looks crap when scaled downwards.

lucideer wrote: »

I've certainly never seen a need for 2-3meg downloads for decent web quality images.

If you have a gallery with 10 sharp images that are 1920x pixels, then each image would be about 300K, giving a 3 meg download before the gallery is loaded, and if you're using browser resizing that will be required before even thumbnails display.

Web quality images are usually lower quality, so the phrase "decent web quality images" is already making an assumption as to what is acceptable.

Try scaling an 80K, 800x600 web quality image to 1920x1440 (over 4 times the size)and see how sharp and defined the result is.

lucideer

Goodshape wrote: »

Do you have any examples of fluid-width websites that look well across desktop and mobile? I really can't think of any.

Alas the majority of the web as usual takes time to catch up to best-practice web-design techniques, so there aren't really a whole lot of great examples of this yet. Any that are are typically tech-oriented sites of people/companies/conferences involved in web development.

Two fairly good ones are http://2010.dconstruct.org/ (fluid @<450px) and http://hicksdesign.co.uk/ - I'm sure there are others out there, and the number should grow given the likes of alistapart and quirksmode encouraging this method of design.

Liam Byrne wrote: »

Web quality images are usually lower quality, so the phrase "decent web quality images" is already making an assumption as to what is acceptable.

And therein lies my point. They don't call 'em "web quality" for nathin'. They're "WEB quality" as they're intended for use on the web. Linking to hi-res images is all well and nice, but if you're honestly inlining edit-quality images for every one of your visitors, I'm certainly not going to want to be visiting your site too often, neither on mobile nor desktop.

Liam Byrne

lucideer wrote: »

And therein lies my point. They don't call 'em "web quality" for nathin'. They're "WEB quality" as they're intended for use on the web. Linking to hi-res images is all well and nice, but if you're honestly inlining edit-quality images for every one of your visitors, I'm certainly not going to want to be visiting your site too often, neither on mobile nor desktop.

I didn't mention anything about "edit-quality" or "hi-res", because I'm not the one advocating having images capable of filling any resolution screens.

I also didn't mention anything about having them "inline", because if slightly higher quality images are required I would ensure that thumbnails are all that's inline.

But since you're advocating javascript and in-browser scaling, those "thumbnails" will be a FAR, FAR higher resolution than required.

If you want decent quality images (e.g. photographer or stock photo websites) that don't look crap because they're scaled upwards, then you'll need to handle that - properly.

Your suggestions mean that either (a) you lower the quality of the images so that your ideas work; (b) the site will be far, far slower than anything I would even consider implementing or (c) the site will look crap at 100% on higher resolution screens.

EDIT : I just had a look at one of the sites you linked to above - http://2010.dconstruct.org - and all of the images disappear completely if you make the site small. Doubt that would work for iStockPhoto.

Goodshape

lucideer wrote: »

Two fairly good ones are http://2010.dconstruct.org/ (fluid @<450px) and http://hicksdesign.co.uk/ - I'm sure there are others out there, and the number should grow given the likes of alistapart and quirksmode encouraging this method of design.

They're both lovely and yes, fluid, but the design of each changes drastically when you get down to mobile width. The entire structure changes and each *set width* would need to be thought about and designed separately.

It's a nice technique but doesn't change that it's two (at least) separate designs. And dConstruct doesn't go any lower than ~1024 until you get to mobile width. So, 1024 or 800? Looks like they've gone for 1024. And a separate mobile design.

lucideer

Goodshape wrote: »

They're both lovely and yes, fluid, but the design of each changes drastically when you get down to mobile width. The entire structure changes and each *set width* would need to be thought about and designed separately.

It's a nice technique but doesn't change that it's two (at least) separate designs. And dConstruct doesn't go any lower than ~1024 until you get to mobile width. So, 1024 or 800? Looks like they've gone for 1024. And a separate mobile design.

Ha - well yes, ok. Technically you're right. Both "separate" designs use the same markup and content though, so it's effectively the same thing. I wasn't saying one should target 800px wide screens in your design, merely that one should consider device screens in the SAME design. That is all.

Keewee6

thanks for above posts - are there any links to fluid width tutorials

Bob_Harris

Fluid layout to adapt to mobile and desktop me arse.

The only reason I use mobile specific sites is because there is less content on screen and less data to download.

One site for all doesn't solve that problem, you still have the same amount of markup and content you would on a "full" website.

Horizonal scrolling on a mobile device isn't the end of the world you know, infact I kind of expect it.

Pixelcraft

Not so, you can have a site adapt to mobile layout that doesn't show unnecessary desktop content.

lucideer

Keewee6 wrote: »

thanks for above posts - are there any links to fluid width tutorials

"Fluid width" is kind of a big field, but just on the subject of media-queries (i.e. adaptive width CSS) here's a few links of interest:

http://www.alistapart.com/articles/responsive-web-design/
http://vimeo.com/12976832

Important to note that the idea of this is not to make an optimised mobile-ready site - if you look at big websites like twitter/facebook they use alternate sites - the point is to make your existing page as "friendly" to different devices/screens as is reasonable. If your site is really enormously heavy and has a lot of mobile traffic, you probably need to be considering an alternate domain for performance but shouldn't be the case for 99% of reasonably well-coded sites.

There's a pretty good discussion of it here that links to alternative views (including some that agree completely with Liam Byrne's above) - it's by Opera Software, who make the most popular mobile browser (yes it's more popular than the iPhone): http://my.opera.com/ODIN/blog/theres-more-to-mobile-than-media-queries