Standard screen resolutions

[Interconnect IT]

It's funny, I'd cheerfully talk about the subject with anyone, but what Dave Mortimer won't accept is that a website is meant to be entirely platform independent. It's got to work on practically anything. There's an awful lot of machines out there that can't run Flash and it *is* about cpu power. Similarly, page rendering time *is* significant - especially if Ajax is involved - Javascript is horrendously cycle hungry.

Now that's all fine, but from my statistics there are plenty of people visiting using plenty of ancient machines. Last month one of my sites had 400 people visiting with pre 2000 machines including one poor soul on a Win 95 machine!

All told, there were 17 different OSs (eg, Windows, Linux, Macintosh etc) - but that's OSs, not variants.

I'm gonna be boring now and break it down, because it's a fascinating insight into the technical problem of making a website:

On one of our popular sites we had:

9 Windows variants
2 Mac variants (can only split between Intel and PPC)
2 Linux variants (again, poor split - but imagine all the different desktops - Gnome, KDE etc)
iPhone
iPod
PS3
50 visitors with no OS information at all
Sun OS
3 varieties of Symbian OS (mobile phones)
HPUX
Nintendo Wii
PS Portable
Palm OS
AIX
Danger Hiptop whatever that is
FreeBSD
NetBSD

I actually got bored of trying to find variants. But let's just say there's a lot of them.

And that's just OSs! I know that for Symbian there's at least two good workable browsers, probably more. For WinCE there's three. For Linux - at least four, three main ones for Windows... They'll each have different interpretations of the standards, and if you're not careful you end up with a website that'll break in quite a few of them.

And Dave Mortimer has the temerity to start laughing, as if he's the expert and I've somehow revealed myself as an ignoramus. Well if this was a pub conversation I'd have left him to sit alone with his beer by now. Other people might even have given him a bloody nose. But of course, he's publicly slating my knowledge and background, so I quite have to defend my position. But I won't do it by directly responding to his comments because that's just feeding the troll.

 

[Cornish Steve]

What I've learned so far from this discussion is that layout depends on screen size (and there are several in use), browser, and operating system. Assuming there are 5 common screen resolutions, 5 popular browsers, and 5 frequently used OSs, that's 125 variations to test right there.

Right now, we're planning to test with Firefox, IE6, IE7, and Safari. I'll add to that the 4-5 most popular screen resolutions based on earlier messages in the thread (the sample lists were really useful, by the way). I hadn't thought about OS, but I'll ask our developers and IT people about that.

 

screen resolution from a very high traffic shopping site UKBF will not have your average web user.Earl

65.98%1024x76825.77%1280x10245.15%1152x8642.06%Unknown1.03%800x600

 

[Eagle]

Developers shoud be checking browser window size, not screen resolution!

My screen is 1920x1200 - you wanna dev for that! My browser window is still 1024x768 like I used when my screen res was 1280x960.

 

[Interconnect IT]

You can't check the browser window size. With javascript I believe you can, but I'm not a javascript developer so can't be sure.

http://whatsmy.browsersize.com/

It's interesting because you can see the problems.

 

[Eagle]

^ It's not very accurate, that.

 

[Cornish Steve]

I read through this thread again, more carefully this time, and I read some of the other UKBF threads on the topic of screen width. I've come to some conclusions about what we should do, and I'd like to get your feedback.

Despite Dave's objections, it seems a majority of people believe in fixed width sites. Despite the fact that 800x600 is now used by a small (and decreasing) number of users, most people suggest a site based on something a little less than 800 width. Indeed, quite a few people prefer some white space in a site.

Here's our situation. Our web application (accessed via login) consists of about 100 screens, with variable content and multiple ways to navigate among them. The layout of each screen is essentially the same: a centre column containing most of the material and left and right columns with useful supplemental material. Right now, the developers use the following dimensions (based on my direction): centre column is 740 pixels wide and left/right columns are 135 pixels wide. The remaining 14 pixels account for a vertical scroll bar on the right (which is displayed even if the bar is inactive). In other words, we've designed for a width of 1024 pixels.

So how does this work for someone using an 800x600 display? Presumably, our screens should be centred so those users can see all the centre column. Does their browser realise that left/right columns contain information and a horizontal scroll bar is needed? Do I need to direct my developers to do anything to cater for this scenario?

Once again, many thanks.

 

[Interconnect IT]

If you go to most (but not always all) our sites you'll see that content is designed to fit into 800 wide screens, so that people with low-res screens can at least read it ok.

But it's not perfect, and of course, you never know how big someone's scrollbars are going to be - people with disabilities will often have super-chunky scrollbars because they're easier to click on. You simply have no idea what the viewport size is.

 

[Mortime Business Software]

Steve wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Despite Dave's objections ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I wouldn't call them objections as such, I would say that I am merely trying to understand why such ubiquitous and well worn functionality in other areas of computer programming is not being applied in web site creation.

I still do not believe that a better solution is not possible, despite the different browsers and their different versions.

Although I have no time to become an expert in JavaScript, CSS, and web site development in general, in about four hours over a weekend, I did try to take some of brownie's advice, and I read some web tutorials.

There is quite a lot of good quality and bad quality material out there, but overall I was able to glean that using JavaScript object/method (or perhaps property) detection, and the fact that JavaScript can access almost all CSS properties, that the following simple strategy should be possible...

------------------------------------------------
If ( JavaScript is enabled ) then
{
If ( we can get the user's screen width ) then
{
use flexible page
}
Else
{
use fixed width page
}
}
Else
{
use fixed width page
}
------------------------------------------------

(Note that this is not pseudocode to be implemented as source code. It is just a formal expression of an overall strategy).

This is the approach I will be trying when I have my web site built because I would like to use all the available window space where ever that is sensible.

It is also important for me to avoid the horizontal scroll bar for as many users as possible. I know myself that when I am asked to fiddle around with a horizontal scroll bar, I immediately exit the site unless it is very important to me and I think I am unlikely to find similar material elsewhere. Even then, I copy and paste the content into a text editor so I can read it in peace.

brownie wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Assertion (1)
Nonsense, client browser type recognition is notoriously unreliable.

Assertion (2)
That's a text layout rescaling, not an image.

Assertion (3)
See 2 above, you're misunderstanding rescaling images and fluid webpage "layouts"

Assertion (4)
See 3 and learn some webpahe design theory.

Assertion (5)
I always thought scientists were mad.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(1) You are perfectly correct, and I have completely ditched the idea, not only because it is unreliable, but also because it is not required.

(2) Sorry, I thought it was an HTML web page. And there is an image near the bottom of the page.

(4) Okay!

(5) Again you are right.

Let me remind you that it was not me who introduced "rapid rescaling" into the discussion - Interconnect brought that up.

I started by asking if there was any way to tailor a web page on the fly to fit a range of screen sizes. Later, I realised that I should be thinking about fitting pages to browser windows rather than screens.

After Interconnect misinformed me that technology for this rapid rescaling does not exist, I observed that my older version of IE can rescale fluid web pages and images at about the speed of lightening (the web page I cited has an image at the bottom of the page).

My browser can do this using an old Pentium III processor which is on a computer that I bought for £30!

From this I concluded that technology already exists for what I was asking about in the first place.

Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Other people might even have given him a bloody nose. ... But I won't do it by directly responding to his comments because that's just feeding the troll.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So just because I refuse to passively "accept" some of your arguments and solutions which make no sense to me, I am a troll, and I deserve a bloody nose?

Even though the truth may hurt sometimes, we should never resort to violence.

And by the way, you started the insults by insinuating that, because I choose not to use the rather silly 'thanking' system, I am somehow morally inferior to those who do.

Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...what Dave Mortimer won't accept is that a website is meant to be entirely platform independent.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I would be most grateful if you would refrain from making lies up about me in order to support your weak arguments.

Can you please show us where I said that I do not realise that there are many platforms to consider?

Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
They'll each have different interpretations of the standards, and if you're not careful you end up with a website that'll break in quite a few of them.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So this means we cannot use fluid page layouts at all, because there are some platforms that will not accommodate them. Is that right?

You say that the reason why fluid web pages cannot be used is because there are so many platforms. But don't you have a similar multi-platform problem when providing fixed width pages?

Sorry to be so troublesome in expecting you to "educate" me (s******), but if a fluid layout will not work on a particular platform, then would it not be possible to use to a fixed width design for that platform?

Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can't check the browser window size. With javascript I believe you can, but I'm not a javascript developer so can't be sure.

http://whatsmy.browsersize.com/

It's interesting because you can see the problems.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you are a web developer, then shouldn't you at least have an overall working knowledge about JavaScript?

After all, it is closely related to one of the first fundamental principles that a web developer should know about, i.e. the relationship between a client and a server.

I am highly surprised at your above statements considering all your previous boasting.

Dave

 

[brownie]

Dave FYI Javascript isn't a favoured way of providing website functionality.

One of the main problems is Javascript executes on the client computer hence has been used for malicious purposes. As a result it is commonly turned off or blocked by an anti-spyware/anti-virus program on the client.

 

[Interconnect IT]

@Dave, you've misread or misinterpreted quite a few of what I and others have said.

For the sake of brevity:

1. High speed scaling of images is perfectly possible. Doing it well isn't. It looks rougher than a badger's wotsit. You can see it often on webpages.
2. Just because your Pentium can do things quickly doesn't mean other devices can. Your machine has many times the power of a mobile phone.
3. Do you realise that http is a stateless protocol? Do you understand the implications of this?
4. Do you know the limitations of fluid layout? Do you comprehend the problems of floated divs that are of differing heights? Do you understand why it's not good to fix the heights of those divs. Do you understand the consequences of fixing those heights?
5. Do you know that in computer science circles that most internet applications are considered low-bandwidth and high-latency. High bandwidth, low-latency is what happens between your CPU and you screen - which is quite a different thing than what's going on between your browser and a web server, web proxy, or cache.
6. Do you know that many web pages, images and scripts that arrive on your computer were never sent to your computer by the originating computer?
7. If the originating computer had to serve all of what I raised in 6. do you understand the impacts this would have on bandwidth usage, latency and web performance?

Even though the truth may hurt sometimes, we should never resort to violence.

And by the way, you started the insults by insinuating that, because I choose not to use the rather silly 'thanking' system, I am somehow morally inferior to those who do.

No, we should never resort to violence. As I said, I would have walked away from someone with your attitude in a real life situation.

As for whether the thanking system on this forum is silly or not... well, it's a forum you wish to partake in. If you wish to be a respected part of this community you should consider playing by its customs.

To the subject itself: It's easy enough to do fluid or fixed or limited width websites. There's just no easy way to provide a perfect solution for every single possible size of display, which is where we came in, really. Instead you can tailor things, and take educated guesses - but you can never know for sure what's going on at the other end, nor is there enough control in Javascript to allow you to do simply anything.

Interesting stat no 374:

Largest screensize to visit one of our sites this month: 3840x2400
Smallest screensize to visit one of our sites this month: 170x174

So that's 9,216,000 pixels vs 29,580 - in other words, the biggest screen is 312 times bigger than the smallest.

What's legible and usable on the largest isn't going to work on the smallest, or vice versa. So if you want to cover all bases you don't go applying algorithms, you design differently. You also have to consider the difference between touch screen, mouse and joypad users.

Now, that doesn't mean you can't represent a site well on a small screen. Opera Mini does a pretty decent job, but it's slow and clunky. Being a geek I surf both on very large screens and on small phone screens. Fully fluid designs have problems with line-length if viewed full screen on a large screen. It's difficult to read long lines.

So web designers are forced to make certain assumptions about the browsers that are visiting. Good designers are very good at making these judgement calls. They also know there's no perfect answer and will often propose multiple solutions. The client can then choose what they wish to pay for.

But Dave, you're going to have to drop the s******ing if you want a serious conversation. To be honest, I surprise myself that I continue with this thread.

 

[Mortime Business Software]

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Just because your Pentium can do things quickly doesn't mean other devices can. Your machine has many times the power of a mobile phone.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It was never my intention to consider smaller screens such as those for moble phones - you brought those up.

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do you realise that http is a stateless protocol? ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Obviously you do not understand what a protocol is. Show me a protocol that tracks the states of the communicating entities which use it.

Anyway it matters not. There are other ways to keep track of changing states.

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do you know that in computer science circles that most internet applications are considered low-bandwidth and high-latency.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Forget about network latency, and please try to keep up. I am now at the stage where all the relevant processing occurs on the client computer, so latency is negligible.

However, even if the feature had to be implemented over the network, latency does not have to pose a problem. This is because JavaScript can respond to mouse down, mouse up, resize, etc. events, and a new layout does not have to be conjured up for each pixel change in size.

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do you know that many web pages, images and scripts that arrive on your computer were never sent to your computer by the originating computer?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If a web developer does not want to include outside material in her web page, then she does not have to.

An item of outside web page material cannot just suddenly decide to behave like an asylum seeker sneaking into England on the back of a truck!

However, if the web developer wants to include outside material, then she can place restrictions on it.

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the originating computer had to serve all of what I raised in 6. do you understand the impacts this would have on bandwidth usage, latency and web performance?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Prepare to be amazed...



(1) The Browser requests the web page from the WebServer.
(2) The WebServer dispatches the WebPage to the Browser.
(3) The Browser renders the WebPage.
(4) A page loading event occurs.
(5) The Script gets the dimensions of the window from the Browser.
(6) The Script updates the CSS according to the window dimensions.
(7) The Browser reads the new CSS settings.
(8) The Browser renders the WebPage.
(9) While the resize event occurs ... loop through steps (5) to (8).

Please note that this diagram is only a sketch. But this does not matter because the outcome is exactly the same as similar schemas which are being implemented by many web developers from the so called "variable fixed width" and "fluid" camps (see below).

My diagram is the result of reading various snippets and web tutorials on the subject, and my time is limited. For conciseness and clarity, I have not included a rendering object, and I have separated the Browser and WebPage.

If for any reason it is not possible to fit the page to the browser window, a default fixed width page can be used.

THIS IS NOT ROCKET SCIENCE!

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There's just no easy way to provide a perfect solution for every single possible size of display, which is where we came in, really.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Er ... no ... that's where *you* came in! Incidentally, you say that there is "no *easy* way", which implies that you think that there is a way to do it.

You have not followed the thread properly. Go back to the beginning and read what I said about "a *range* of screen widths" and "excluding mobile phones".

I am not interested in your complications.

Moving on, I have emphasised that if a fluid solution is not possible (for example when JavaScript is disabled), then we can always fall back on a fixed width solution, which brings me to another interesting point that I discovered during my web tutorial surfing sessions.

There are actually three camps for the 'fixed versus fluid' debate...

(1) the "fixed width page" camp,

(2) the "fluid page" camp,

(3) the "variable fixed width" camp, which provides solutions for a *range* of screen widths between two arbitrary limits, and reverts to an arbitrary fixed width solution where variable width is not sensible or possible.

I have been in camp (3) throughout this discussion. You have been 'fixed' rigidly in camp (1).

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You also have to consider the difference between touch screen, mouse and joypad users.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

No I don't - not yet anyway. Again you are complicating a fairly simple problem by introducing extra conditions.

For now, I am concentrating on a "variable fixed width" solution - that's what I have said from the outset, but you keep complicating the problem.

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
No, we should never resort to violence. As I said, I would have walked away from someone with your attitude in a real life situation.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Oh right. So you would have walked away and left your imaginary friends to do the dirty work and bloody my nose? So why did you suggest such behaviour, and then blame it on imaginary friends?

And by the way. Please do not send me any more PM's demanding what you want of me. Considering your current tone in this discussion, I find them frightening and very creepy. Next time I will report you to the relevant authorities.

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As for whether the thanking system on this forum is silly or not... well, it's a forum you wish to partake in. If you wish to be a respected part of this community you should consider playing by its customs.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So I do not deserve any respect because I will not conform to the thanking system?

Of course, it is up to you if you want to endorse this ill-thought out scheme. I choose not to because it is too open to episodes like this...

http://www.ukbusinessforums.co.uk/forums/showthread.php?t=58660

Not my idea of how to quantify the amount of gratitude a person has received. And nor does it quantify the amount of gratitude a person deserves.

Are you listening to me IC?

Where are you?

Bluddy-ell! Are you all-right down there?


(Click on image to see Iinterconnect IC).

Dave

 

[Interconnect IT]

Oh right. So you would have walked away and left your imaginary friends to do the dirty work and bloody my nose? So why did you suggest such behaviour, and then blame it on imaginary friends?

And by the way. Please do not send me any more PM's demanding what you want of me. Considering your current tone in this discussion, I find them frightening and very creepy. Next time I will report you to the relevant authorities.

To the first statement - you're attributing behaviour to me that is quite simply abhorrent.

To the second - you said the following:

Beware!

Some people want you to "accept people's explanations" without any questions whatsoever. (I have noticed this in other threads too).

Beware of amateurs who say they can educate people.

I asked you, politely, to retract the suggestion that I'm an amateur or I would have to consider my options.

You're now suggesting that doing this is frightening and very creepy. Well I'm sorry about that, but... well... what do you expect?

 

[Interconnect IT]

To your points made...

Variable fixed width is easy enough. But it was you that suggested an algorithm could be written to take into account of screen sizes. You neither included, nor excluded mobile phones. Suddenly you want to exclude mobile phones. Why?

Instead web designers have to work within the constraints of budget, visual attractiveness (quickly resized images always look rough) and the one key and most important rule that http is all about... it's platform independent. So you have to make choices.

The problem with fluid designs is that images in those fluid designs will need to be rescaled in order to maintain the visual ratio of image to content. If you don't rescale the images you'll find them bumping into one another in certain situations leading to very unattractive layouts. If you do rescale the images, they'll start to look rough.

You also have the not inconsiderable problem of readability. Long lines of text are hard to read. So you need to scale the fonts. But someone with a large screen doesn't necessarily want inch-high content. They're happy that the font is small. In fact, they may have chosen their own standard font size. The server can have little control of that.

You talk as if you're an expert in web design... yet actually have no portfolio to show. You then laugh at me, suggest I'm an amateur, and then suggest that I'm creepy and frightening. I'm sorry, but that's not really acceptable is it?

 

[adamscomputers07]

With regards to all lasts posts by Dave, has he created a website and where is the proof? I think this post should be wrapped up. Dave assumes superior knowledge of web design and sounds very arrogant, see this http://www.wikihow.com/Be-Arrogant

 

[Interconnect IT]

For second I was worried - you see, I too am called Dave

Lovely link - could easily become very unproductive today surfing that website!

 

[sabian1982]

You've just made me look at my stats.

I run a site that gets a lot of general web users (ie none computer tech types).

Of the traffic, the majority of visitors come from the uk.

Its rather interesting to see that 800x600 is not the most popular resolution - infact its 4th!

45% 1024x768
23% 1280x800
11% 1280x1024
5.8% 800x600

Needless to say things aren't quite what they seem and the majority of 'standard' uses no longer use the 800x600 res.

That being said i tend to design for 780px but do something fun with repeating backgrounds so it doesn't look lost in the middle of the page on high resolutions!

The reason i have a dislike to fluid designs is because they usually look silly on high resolutions (or widescreens) or are too cramped on the lower res smaller screens. Also fixed width means i know exactly what visitors are going to see... which is exactly the same design. Getting a good fluid design is really rather difficult although i have seen it used effectively a number of times...

 

[Mortime Business Software]

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Variable fixed width is easy enough.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

What? After all this, you are now telling us that, in your esteemed majestic magnitudinal opinion, that "variable fixed width is easy enough"? This is supposed to be *my* argument, not yours (although I do not think that it is "easy enough")!

Make up your mind for goodness sake!

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
But it was you that suggested an algorithm could be written to take into account of screen sizes.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I did. But suitable algorithms already exist, as is evident from the many examples on the web. However, if an algorithm did not exist, I could write one.

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You neither included, nor excluded mobile phones. Suddenly you want to exclude mobile phones. Why?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I excluded mobile phones - see my very first post in this thread.

If I want to include small screens such as those for mobile phones, or large screens, then, since I am even more flexible than the most fluid web page layout, I would write an aggregating algorithm which would summarise the essentials of a web page, which of course, would have implications for the web page design contraints.

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
quickly resized images always look rough) and the one key and most important rule that http is all about... it's platform independent
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Quickly rescaled images do not *always* look rough. If they did, then how come my older IE version can rescale very complex images to a wide range of different sizes, and they all look very nice?

And what on earth has HTTP being platform independent got to do with any of this discussion?

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The problem with fluid designs is that images in those fluid designs will need to be rescaled in order to maintain the visual ratio of image to content. If you don't rescale the images you'll find them bumping into one another in certain situations leading to very unattractive layouts. If you do rescale the images, they'll start to look rough.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Images do not need to be rescaled continuously (here I mean very small discrete scalings). A good designer can use discrete scaling where discontinuity is commensurate with the design constraints that I stipulated earlier.

In fact, depending on the design constraints, a page's images may not need any rescaling at all. Your blanket reasoning also exludes pages which do not use any images.

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You also have the not inconsiderable problem of readability. Long lines of text are hard to read. So you need to scale the fonts. But someone with a large screen doesn't necessarily want inch-high content. They're happy that the font is small. In fact, they may have chosen their own standard font size. The server can have little control of that.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Again you are complicating the problem, and also, you are not thinking creatively enough as any proper designer should.

In common parlance, you are not thinking outside of the box.

With a "variable fixed width" solution you can restrict line lengths and keep font heights sensible. Further creativity and thought could even possibly use the wider screen areas by splitting the text into columns.

Again, the progressive designer will be able to set out his design constraints to suit. But you would never even consider this because of your rigid mindset, and this shows that you are not a designer.

Interconnect IT wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You talk as if you're an expert in web design... yet actually have no portfolio to show. You then laugh at me, suggest I'm an amateur, and then suggest that I'm creepy and frightening. I'm sorry, but that's not really acceptable is it?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As far as I can see, the only thing I'm missing here is the expertise of a web imaging expert such as someone like Eagle. Until then, I can always fall back on the strategy of using the original image within a carefully crafted set of design constraints, or even send three or four originals over to the client so that I have at least some flexibility within a fully fluid design within arbitrary width limits.

I do not need a portfolio to participate in this debate because there are many successful examples out there on the web which support my case.

Adam wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With regards to all lasts posts by Dave, has he created a website and where is the proof? I think this post should be wrapped up. Dave assumes superior knowledge of web design and sounds very arrogant, see this http://www.wikihow.com/Be-Arrogant
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Adam. Thank you for your idispensable contribution to the debate. Clearly, your profound insight and understanding of the problem proves that I am wrong.

I know that I am arrogant to a degree, but does that make me wrong?

You are quite right to ask for a proof, but your specific requirement for a proof shows that you do not really understand how a proof can be shown. All I have to do is refer you to the many successful examples out there on the web.

Adam. With reasoning like yours, I'm just happy that you are not on my side!

Dave

 

[adamscomputers07]

Slightly OT - My knowledge of web design is limited, I did however create my website using CSS-P and XHTML, I knew nothing about the coding and had a website up and running in a few weeks. I wouldn't know where to start if I were to create a fluid layout. This thread has provided some insight to it and I'm sure other readers would like to use the information here. As a suggestion, why not put list pro's and cons that you have so far in bullet points on this subject (anyone), making it easier to read and discuss. All comments here are valuable.

 

[dagr]

For those that gave real stats, I'm surprised that there are still so many 800x600 screens around. I would have guessed at a figure of <2%, and if someone had said "0.1%" I wouldn't have fallen off my seat.

If I were designing or spec'ing a site today, I would set it to 1024x768 if fixed, or that + higher if fluid.

 

[adamscomputers07]

I have a resolution of 1680x1050 on my monitor and have a program to reduce the window sizes so it is more usable/readable, also I can have 2 windows side by side. One question - what really counts, the window size or maximum resolution?

Does anyone else use a widescreen LCD and find this a problem?

 

[Interconnect IT]

@adams - there's a lot to learn, but mostly css and html is fairly straightforward. Only gets difficult, really, dealing with all the variability of browsers and screensizes.

@dagr - I'm not so surprised... you'll see lots of 800x600 screens in the third world still, although even that's improving.

@Dave Mortimer - thank you for improving on your civility this time around, so I'm more inclined to continue....

The following image, if it hotlinks, shows the variability of image scaling in different browsers:

It's quite simplistic, but an illustration of the problem. If you start with small images, scaling them up is going to be tricky. Start with big images and your bandwidth goes mental.

Things will get better in a lot of ways, however, as svg gains ground. In fact, it'll all be rather stunning - I look forward to websites rendering the graphical elements in svg.

It's not really about algorithms, so much as getting the underlying technology right. But still, even with svgs, a good interface for a dirty great 40" widescreen TV is going to be different to that of an Asus Eeepc... and different again to that of a 24" high-def desktop machine controlled by mouse.

 

[awebapart.com]

Thanks Interconnect IT Dave for finding an illustration, I have set up a similar one too:

The top row demonstrates what is common on most browsers, rescaling images using the fast but low quality nearest neighbour image processing algorithm, which can result in stepped jagged lines, pixelation and pixel loss. Most browsers do it this way because it is fast and can be done in real-time.

The bottom row demonstrates the better quality image processing algorithms of bilinear filtering or trilinear (bicubic) filtering (interpolation), which are much more processor intensive, and cannot be done in realtime without a background delay, which is why most browsers currently do not use this technique. This rescaling algorithm, whilst much higher quality than the other, has some issues too, it can make an image softer when shrinking, and it can make an image blurred when enlarging.

In laymans terms the reason for the difference in speed and quality of these 2 methods is because the 1st method looks at far less pixels when shrinking (selectively picking and disregarding the rest), and doesn't perform any further maths on the pixel values when shrinking and enlarging, whereas the second method looks at all pixels whether shrinking or enlarging, and performs further maths on those pixel values (averaging or interpolating maths).

With browsers which perform the second method, e.g. Firefox 3, and Safari on the iPhone/iPod Touch (the iPhone iPod Touch takes this one step further and shrinks or enlarges the whole page, not just the image), you will probably find that they perform a quick method 1 first, then replace it with a method 2 rescale later if they see that the user has decided to stay on that area of the page.

(5) The Script gets the dimensions of the window from the Browser.
(6) The Script updates the CSS according to the window dimensions.
(7) The Browser reads the new CSS settings.
(8) The Browser renders the WebPage.

I think that what Dave Mortimer is trying to say is that if you're clever enough you could code web pages that decide on a web design based on the browser window size, and dynamically render this on the fly. Yes this is possible, so Dave is right too (both Daves are right!). Even with the image issues mentioned here, these image issues can be overcome, if you have the time and inclination to work at it, with techniques borrowed from the 3D gaming industry (my company used to develop 3D games) - techniques such as level of detail or mipmapping whereby you have multiple copies of the same image at different sizes to choose from (depending on how close that object is from you in the 3D world), and you choose the image at runtime depending on browser size.

But, it is not just a case of if you're clever enough you should do it, there is also the issue of being too clever for your own good, and the idea of K.I.S.S. (keep it simple stupid) principle. Just because something is feasible and can be done, it doesn't mean that it is a good idea, it would require more work and testing, and this is probably pushing the existing technology (html/xhtml/css/javascript/ajax/bandwidth) a bit too far, possibly in a direction that it shouldn't really go, taking it outside its comfort and safety zone.

 

[awebapart.com]

Paul wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If your web design has a fluid layout where the width varies dependent upon the browser window size then more testing on more screen resolutions and more intermediate browser window sizes is required than for standard fixed width websites, since fluid websites are less predictable in how they render the layout,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't understand. If, for example, we know that a design works at a width of 600, and also at a width of 1024, then we can predict that the design will also work at all widths between 600 and 1024. Therefore, you need to test the layout at just two widths.

Fixed width design is more predictable at various widths. Fluid design is less predictable at various widths, especially where text is supposed to flow around other elements and images depending on available width (e.g. have a look at www.csszengarden.com at the smaller browser sizes to see how the layout flows and ends up in different places depending on width), and so requires more testing.

Paul wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Most of our web designs are fixed width layout, designed for 800 width monitors and above, and we test from 800 width up on the more common widths like 1024, 1280.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Why can't you just test at 800 and 1280, and then safely assume that it will also work at 1024 (which is between 800 and 1280)?

We test at the lowest, 800, and at the highest 1280, and in between 1024 just because that's what one of our machines is set to (and it is good to test on the most popular configuration). Beyond 1280 there is little point in us testing, since fixed width designs where the design is centred are pretty predictable as you increase the browser width. Our test machines don't just have different widths, and we don't test on them merely because they have different widths, they have different browser versions different operating system versions etc so these can be tested too.

Paul wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Before we introduced our sitebuilder service, at the time when screen sizes where getting bigger, this increase in screen sizes was one of the reasons we moved away from fluid layouts (our old company website still has a fluid layout) to fixed layouts - some people might think this is odd, as some people might think it should be the other way around.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yes, it does sound odd, and I would be grateful if you could explain.

I would have thought that you would have embraced the increase in screen size, and, say for a particular layout, gone up to a maximum at which the layout would work. After this arbitrary maximum where you consider that the layout does not work, you could then kick into 'fixed width mode'.

The reasons we have adopted our particular design approach were presented in my original post and the link that was provided in the original post to our web design width and web screen size faq article.

 

[Interconnect IT]

Two excellent posts there Paul, with great and clear explanations.

I'd just mention one thing:

Beyond 1280 there is little point in us testing

May not seem much point, but it's surprising how many sites look funny on very wide monitors - usually in regard to background images that don't tile correctly. Given that my TV is 1900px wide and will soon have a PC connected to it (as many will), this is worth considering...

 

[awebapart.com]

What I've learned so far from this discussion is that layout depends on screen size (and there are several in use)

As some others have mentioned, it is browser window size (and available display width within that window) not screen size which is important, because not everybody displays their browser maximised. Displaying browser windows maximised is more common on smaller screen sizes (e.g. 800, 1024) but less common as the screen size goes up, since people can then take advantage of the windowed multitasking environment more, to display their browser in a smaller window and still see other parts of the desktop or other windows. Unfortunately there are not many stats that back this up since everybody seems to be obsessed with collecting screen size stats, however some studies have been made on this, e.g.

http://tobyinkster.co.uk/article/browser-sizes/

Despite the fact that 800x600 is now used by a small (and decreasing) number of users

Personally, I think that the numbers with 800 widths will increase due to the increase in popularity of mass-market ultra-portable and ultra-cheap laptops like the Asus Eee PC and Elonex One, and what the phone manufacturers (Nokia, Samsung, Sony Ericsson, LG, Motorola etc) will do next to try to match or better the iPhone's desktop browsing experience (although the iPhone only has a 480x320 display, it assumes the user is browsing on a 1280x1024 desktop monitor and scales the resulting page image down, not all phone manufacturers will take this approach due to processing requirements, especially for cheaper mass market phones, and some will just continue to offer or increase their screen widths to 800 for improved browsing with no scaling, although Opera for devices doe have page scaling technology).

Right now, the developers use the following dimensions (based on my direction): centre column is 740 pixels wide and left/right columns are 135 pixels wide. The remaining 14 pixels account for a vertical scroll bar on the right (which is displayed even if the bar is inactive). In other words, we've designed for a width of 1024 pixels.

So how does this work for someone using an 800x600 display? Presumably, our screens should be centred so those users can see all the centre column. Does their browser realise that left/right columns contain information and a horizontal scroll bar is needed? Do I need to direct my developers to do anything to cater for this scenario?

Standard centre coding usually kicks in when there is more available display width than the width taken up by the web element. It doesn't normally kick in when the web element is bigger than the display width. You should be able to check this by opening up a browser window in windowed mode (not maximised), make the window small, and then load the website. If you really want to overcome this issue, you will probably have to add some javascript code.

 

[Interconnect IT]

My own feeling is that a website designed with broad appeal will need to have more considerations in the way its built.

The iPhone renders full size 1024 wide sites perfectly well... but... if you fill that full width with text its no fun. Keep column and line sizes sensible, however, and the site is perfectly usable.

I also have a yearning to built a website or WordPress theme especially for very large screen users! After all, they have needs too