- Original Poster
- #1
When you're developing a new website, with which screen resolutions do you test? Which resolutions are most frequently encountered today?
Standard screen resolutions
- Thread starter Cornish Steve
- Start date
All down to 800 * 600 it's a PIA trying to get fluid layouts to work. And that's before you look into mobile layouts... The biggest PIA is using images sure you could use a sniffer and redirect but how many people/comps have the time and dosh to create 4 versions of every site.
Upvote
0
I created my site to work on a minimum of 800x600, was tricky to test as I my main monitor is wide screen. I managed to use a DIV layer to contain and center everything within about 750 pixels. This effectively is a centered layout that is even visible on a low resolution monitor. I can dig the code out if you need it. See my website - adamcanfixyourcomputer.co.uk , good luck.
Upvote
0
M
Mortime Business Software
I'm not a web developer, but I seem to remember (from my very basic knowledge in this area) that in the old days, if you were prepared to make certain constraints on the output to the browser, then it was possible to cater for every screen size by using percentages to proportion the pages to suit the user's screen.
Is this no longer possible?
I was thinking along the lines of the following. If we have a letter height of 30 pixels which we have specified for a screen height of 700 pixels, and the client's screen has a height of 600 pixels, then we need to tailor the output for this user by making the letter height (6/7)*30 = 25.7, i.e. 26 pixels (or even 25 pixels if we want to see if the line length comes down enough).
I know this is very simple, and I realise that I have not considered whether line lengths will be changed in proportion with letter heights, but surely there has to be a way to cater for all screen resolutions (excluding mobile phone screens of course).
Dave
Is this no longer possible?
I was thinking along the lines of the following. If we have a letter height of 30 pixels which we have specified for a screen height of 700 pixels, and the client's screen has a height of 600 pixels, then we need to tailor the output for this user by making the letter height (6/7)*30 = 25.7, i.e. 26 pixels (or even 25 pixels if we want to see if the line length comes down enough).
I know this is very simple, and I realise that I have not considered whether line lengths will be changed in proportion with letter heights, but surely there has to be a way to cater for all screen resolutions (excluding mobile phone screens of course).
Dave
Upvote
0
B
brownie
http://www.onestat.com/html/aboutus_pressbox31.html
The most popular screen resolutions on the web in the world are:
1.1024 x 768 54.02%
2.800 x 600 24.66%
3.1280 x 1024 14.1%
4.1152 x 864 4%
5.640 x 480 0.6%
6.1600 x 1200 0.8%
7.1152 x 870 0.1%
The most popular screen resolutions on the web in the world are:
1.1024 x 768 54.02%
2.800 x 600 24.66%
3.1280 x 1024 14.1%
4.1152 x 864 4%
5.640 x 480 0.6%
6.1600 x 1200 0.8%
7.1152 x 870 0.1%
Upvote
0
Brownie - those stats include a lot of people who won't be visiting and I can tell you from our client sites that they aren't right.
We test from mobile phone right through to 1920x1200 and even 40" TVs. Testing done, and coverage available, really depends on what the client is willing to pay.
So think about it - if you're doing a site that's targetted mainly at people using a Wii, then that's quite a different proposition for one that primarily designed for iPhone users.
We can no longer say "design a site for 800x600 as that's the starting point." It isn't. People are surfing on phones, TVs, and even fridges I suppose.
If you're designing a general purpose site in the UK I wouldn't even think too hard about 800x600 - I'd stick to 1024 as the base width. 800x600 looks pretty rubbish and squished up on large monitors. It's also not great if you need to make images an important part of the message.
But like I say - it depends on what the client needs and what they want to pay for.
We test from mobile phone right through to 1920x1200 and even 40" TVs. Testing done, and coverage available, really depends on what the client is willing to pay.
So think about it - if you're doing a site that's targetted mainly at people using a Wii, then that's quite a different proposition for one that primarily designed for iPhone users.
We can no longer say "design a site for 800x600 as that's the starting point." It isn't. People are surfing on phones, TVs, and even fridges I suppose.
If you're designing a general purpose site in the UK I wouldn't even think too hard about 800x600 - I'd stick to 1024 as the base width. 800x600 looks pretty rubbish and squished up on large monitors. It's also not great if you need to make images an important part of the message.
But like I say - it depends on what the client needs and what they want to pay for.
Upvote
0
No, 1280x1024 is a valid and normal screen size.
These are some stats for one of our sites:
1.
1024x768
17,636 29.12%
2.
1280x1024
15,452 25.51%
3.
1280x800
9,179 15.16%
4.
1440x900
4,030 6.65%
5.
1680x1050
3,808 6.29%
6.
1600x1200
1,882 3.11%
7.
1920x1200
1,853 3.06%
8.
1152x864
1,527 2.52%
9.
1400x1050
1,178 1.94%
10.
800x600
810 1.34%
These are some stats for one of our sites:
1.
1024x768
17,636 29.12%
2.
1280x1024
15,452 25.51%
3.
1280x800
9,179 15.16%
4.
1440x900
4,030 6.65%
5.
1680x1050
3,808 6.29%
6.
1600x1200
1,882 3.11%
7.
1920x1200
1,853 3.06%
8.
1152x864
1,527 2.52%
9.
1400x1050
1,178 1.94%
10.
800x600
810 1.34%
Upvote
0
M
Mortime Business Software
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
No, 1280x1024 is a valid and normal screen size.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yes, the monitor I'm currently on has a height which is 0.8 of its height. Is this because screens are now plasmanadonic instead of cathode-ray-tubonified?
(I've just taken the dimensions of all four of my old crt monitors, and also the three TV's. Their heights are all 0.75 of their widths.)
This is even more reason why there needs to be a way of catering for any *continuous* size (within a certain domain of course).
Dave
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
No, 1280x1024 is a valid and normal screen size.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yes, the monitor I'm currently on has a height which is 0.8 of its height. Is this because screens are now plasmanadonic instead of cathode-ray-tubonified?
(I've just taken the dimensions of all four of my old crt monitors, and also the three TV's. Their heights are all 0.75 of their widths.)
This is even more reason why there needs to be a way of catering for any *continuous* size (within a certain domain of course).
Dave
Upvote
0
M
Mortime Business Software
I don't think it would be a huge scientific breakthrough or revelation if someone was to come up with a set of design constraints for web pages which should use the available screen space effectively.
For now, to keep it simple, let's make the following assumptions:
(1) Screen heights can vary between y1 pixels and y2 pixels.
Screen widths can vary between x1 pixels and x2 pixels.
The proportion that the screen height is of the screen width can vary between p1 and p2.
(2) A web page consists of CSS panels, text, images, form widgets.
(3) Text and images can be enclosed within hyperlink tags.
(4) CSS panels can be empty, or can contain any of the components mentioned in (2), fully or partially.
(5) The components in (2) may or may not lie within CSS panels fully or partially.
(6) Flash has been flushed down the bog where it belongs, along with any graphic designers who have ever used it. In fact, let's just flush all graphic designers down the bog anyway - nobody will ever notice they've gone!
I think that little lot would allow for some really spiffy web pages, and give us something complex enough to start some serious research.
All we need to do now is identify some variables, and come up with an algorithm which can tailor web pages according to screen size.
Easy!
Dave
For now, to keep it simple, let's make the following assumptions:
(1) Screen heights can vary between y1 pixels and y2 pixels.
Screen widths can vary between x1 pixels and x2 pixels.
The proportion that the screen height is of the screen width can vary between p1 and p2.
(2) A web page consists of CSS panels, text, images, form widgets.
(3) Text and images can be enclosed within hyperlink tags.
(4) CSS panels can be empty, or can contain any of the components mentioned in (2), fully or partially.
(5) The components in (2) may or may not lie within CSS panels fully or partially.
(6) Flash has been flushed down the bog where it belongs, along with any graphic designers who have ever used it. In fact, let's just flush all graphic designers down the bog anyway - nobody will ever notice they've gone!
I think that little lot would allow for some really spiffy web pages, and give us something complex enough to start some serious research.
All we need to do now is identify some variables, and come up with an algorithm which can tailor web pages according to screen size.
Easy!
Dave
Upvote
0
It's easy to do - simply have different versions for different sizes.
Problem is you're missing my point about screen sizes. There's no guarantee of screen size. And even if you know, you can't be sure if a window is full screen or a quarter of the screen.
Look at this image taken from my blog:
There's no easy algorithm. MS, Apple, Opera and others have all tried to create ways of viewing full content websites on small screens. They all work in certain ways, but ultimately it's actually a better and quicker experience when content providers supply different versions of the site. For example, BBC News is available in Mobile Phone, PDA and full size versions. Most of our sites, when confronted with phones with limited browsers, will apply a phone specific stylesheet. My own site has an Phone suitable back end to make it easier for me to post while on the move, but I only see it if I use the phone.
You're trying to solve a problem that's already been worked out....
Problem is you're missing my point about screen sizes. There's no guarantee of screen size. And even if you know, you can't be sure if a window is full screen or a quarter of the screen.
Look at this image taken from my blog:
There's no easy algorithm. MS, Apple, Opera and others have all tried to create ways of viewing full content websites on small screens. They all work in certain ways, but ultimately it's actually a better and quicker experience when content providers supply different versions of the site. For example, BBC News is available in Mobile Phone, PDA and full size versions. Most of our sites, when confronted with phones with limited browsers, will apply a phone specific stylesheet. My own site has an Phone suitable back end to make it easier for me to post while on the move, but I only see it if I use the phone.
You're trying to solve a problem that's already been worked out....
Upvote
0
Hi Steve,
Here are the stats for UKBF:
1. 1024x768 37.90%
2. 1280x800 18.88%
3. 1280x1024 17.04%
4. 1440x900 7.54%
5. 1680x1050 4.71%
6. 800x600 3.00%
7. 1152x864 2.76%
8. 1280x768 2.02%
9. 1920x1200 1.55%
10. 1400x1050 0.93%
Here are the stats for UKBF:
1. 1024x768 37.90%
2. 1280x800 18.88%
3. 1280x1024 17.04%
4. 1440x900 7.54%
5. 1680x1050 4.71%
6. 800x600 3.00%
7. 1152x864 2.76%
8. 1280x768 2.02%
9. 1920x1200 1.55%
10. 1400x1050 0.93%
Upvote
0
I'd suggest a little target audience research before making your decision.
We have analytics set up on all our sites and less than 5% of users tracked are using 800x600 monitors.
All that aside, does the design warrant being larger than 770 pixels wide? less is more?
good luck
Paul
We have analytics set up on all our sites and less than 5% of users tracked are using 800x600 monitors.
All that aside, does the design warrant being larger than 770 pixels wide? less is more?
good luck
Paul
Upvote
0
M
Mortime Business Software
Interconnect. You missed my point about "...a set of design constraints".
If there was an algorithm to tailor pages within a certain set of design constaints which some customers would be willing to accept, then you will not have to require those customers to pay more for a wider distribution.
That is, you would not have to create different versions of your web pages for the different screen shapes. You would simply slip tailored values into your output to the browser.
This would give you, at least for a while, a competetive edge over those who are providing web pages which are not making use of the available space.
Dave
If there was an algorithm to tailor pages within a certain set of design constaints which some customers would be willing to accept, then you will not have to require those customers to pay more for a wider distribution.
That is, you would not have to create different versions of your web pages for the different screen shapes. You would simply slip tailored values into your output to the browser.
This would give you, at least for a while, a competetive edge over those who are providing web pages which are not making use of the available space.
Dave
Upvote
0
Dave - have you by any chance ever tried to design a website? From code upwards?
It's not the same as an application that's running locally which has a lot of information available to it about fonts, screen size, window size and so on.
You absolutely must remember that the web server hasn't a clue about what's receiving its output.
It's not the same as an application that's running locally which has a lot of information available to it about fonts, screen size, window size and so on.
You absolutely must remember that the web server hasn't a clue about what's receiving its output.
Upvote
0
Just checked some data I collected from my website, and in the top 3 of visitors resolutions are 1024x768, 1680x1050 and 1280x1024 and the 800 x600 at ten. The maximum resolution was 2560x1600, 18th. So I'd say 800x600 is still used today!
Upvote
0
It's still used, but you have to make percentile decisions.
8 foot giants may try to drive a MINI, and BMW may choose to want to service that customer or may not, according to budget available. But what you'll find is that most designers will work to servicing a certain percentage of the market.
If each new customer is worth £50k and 50% use 800x600 screens then it's important to service them. If however, designing for small screens isn't going to win you new business then why should you?
8 foot giants may try to drive a MINI, and BMW may choose to want to service that customer or may not, according to budget available. But what you'll find is that most designers will work to servicing a certain percentage of the market.
If each new customer is worth £50k and 50% use 800x600 screens then it's important to service them. If however, designing for small screens isn't going to win you new business then why should you?
Upvote
0
M
Mortime Business Software
IC. I am one of those boring farts who lurks behind the controller in the model area wishing death on flash users!
My web site design skills are elementary, so please be merciful with me.
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dave - have you by any chance ever tried to design a website? From code upwards?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yes. I've played around with HTML, JavaScript and Perl/CGI on UNIX/Apache and Windows/Apache, but I am not an expert.
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's not the same as an application that's running locally which has a lot of information available to it about fonts, screen size, window size and so on.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I realise this, but we only need the window size!
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You absolutely must remember that the web server hasn't a clue about what's receiving its output.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I said my knowledge in this area is elementary - not non-existent!
Sorry, I don't understand. Correct me if I'm wrong, but you seem to be trying to tell me that a server would be able to get the screen size for the purpose of outputting one of several pre-determined layouts (for which a customer is asked to pay extra), but the server would not be able to get the screen size if we wanted to pass that information to a program which would, from a single web page specification, create a web page to suit the user's current browser window (for which there would be no extra charge to the customer).
If you open a late version of IE with an image in the window, then you will see that the image is automatically resized to fit any window size. It seems obvious to me that, sooner or later, a similar feature (which prevents the horizontal scroll bar) will be available for web pages. However, I would imagine that, initially, some design constraints will have to be adhered to, and server side languages will probably evolve accordingly so as to aid web programmers in using the feature.
Even at this present time, I find it ridiculous that several versions of a web page should be created in readiness for their corresponding screen sizes - and not one of them will be able to adjust to a variable minimised window being resized.
Dave
My web site design skills are elementary, so please be merciful with me.
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dave - have you by any chance ever tried to design a website? From code upwards?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yes. I've played around with HTML, JavaScript and Perl/CGI on UNIX/Apache and Windows/Apache, but I am not an expert.
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's not the same as an application that's running locally which has a lot of information available to it about fonts, screen size, window size and so on.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I realise this, but we only need the window size!
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You absolutely must remember that the web server hasn't a clue about what's receiving its output.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I said my knowledge in this area is elementary - not non-existent!
Sorry, I don't understand. Correct me if I'm wrong, but you seem to be trying to tell me that a server would be able to get the screen size for the purpose of outputting one of several pre-determined layouts (for which a customer is asked to pay extra), but the server would not be able to get the screen size if we wanted to pass that information to a program which would, from a single web page specification, create a web page to suit the user's current browser window (for which there would be no extra charge to the customer).
If you open a late version of IE with an image in the window, then you will see that the image is automatically resized to fit any window size. It seems obvious to me that, sooner or later, a similar feature (which prevents the horizontal scroll bar) will be available for web pages. However, I would imagine that, initially, some design constraints will have to be adhered to, and server side languages will probably evolve accordingly so as to aid web programmers in using the feature.
Even at this present time, I find it ridiculous that several versions of a web page should be created in readiness for their corresponding screen sizes - and not one of them will be able to adjust to a variable minimised window being resized.
Dave
Upvote
0
I think Dave that you need to understand the problems of rapid scaling. If you look at scaled images in IE they're incredibly rough, because scaling well would take too much time.
Maybe in five years time we can consider it, but then you have to think of mobile phones.
Rendering of web pages is actually a very processor intensive job - complex pages with a lot of elements particularly so.
Given that visuals are important, this is a big limitation. As cpu cycles get cheaper, it's possible that more options will come up.
The cheap and easy solution is to use Flash, but that comes with its own set of problems and is incredibly cpu hungry - which is why my iPhone presents Flash based sites as nothing more than a blank screen with a little blue box in the middle.
Maybe in five years time we can consider it, but then you have to think of mobile phones.
Rendering of web pages is actually a very processor intensive job - complex pages with a lot of elements particularly so.
Given that visuals are important, this is a big limitation. As cpu cycles get cheaper, it's possible that more options will come up.
The cheap and easy solution is to use Flash, but that comes with its own set of problems and is incredibly cpu hungry - which is why my iPhone presents Flash based sites as nothing more than a blank screen with a little blue box in the middle.
Upvote
0
Yes, I know...
Ultimately Flash is far too cpu hungry. I've had poorly written banner ads whack the CPU on my workstation to 50% - having those in a full browser on a phone just isn't going to work well.
The N95 handles flash content, but have some flash running in the background and you'll find that an hour later you have a hot phone with no battery charge left. It's also pretty limited in the flash content that it can handle. I have one of those phones as well as the iPhone. Don't forget, I'm very very geeky
Ultimately Flash is far too cpu hungry. I've had poorly written banner ads whack the CPU on my workstation to 50% - having those in a full browser on a phone just isn't going to work well.
The N95 handles flash content, but have some flash running in the background and you'll find that an hour later you have a hot phone with no battery charge left. It's also pretty limited in the flash content that it can handle. I have one of those phones as well as the iPhone. Don't forget, I'm very very geeky
Upvote
0
I know what you mean about CPU usage, I was editing a web page with code from photobucket and when I previewed it on IE7 or FF2 it crashed the browser. I even had Process Lasso run to catch apps using too much CPU, it looked more like a memory leak, could have put it in a sandbox but that wont solve much!
I know that mobiles are becoming all in one media devices and a lot of the technology is new. What do you think of Google's development of the Android phone, a Linux based device?
It may be that flash code needs to be more stringently tested or coding more efficient and flexible for various platforms.
I'd like to test my N95 with some naff flash. Can you share a link?!
I know that mobiles are becoming all in one media devices and a lot of the technology is new. What do you think of Google's development of the Android phone, a Linux based device?
It may be that flash code needs to be more stringently tested or coding more efficient and flexible for various platforms.
I'd like to test my N95 with some naff flash. Can you share a link?!
Upvote
0
I'll test it on my phone, but doubt it will be usable!
I think when you create a website to keep it viewable in 800x600 on a desktop or laptop and create a separate lighter version if required for the mobile.
I think when you create a website to keep it viewable in 800x600 on a desktop or laptop and create a separate lighter version if required for the mobile.
Upvote
0
M
Mortime Business Software
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I think Dave that you need to understand the problems of rapid scaling. If you look at scaled images in IE they're incredibly rough, because scaling well would take too much time.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I've just tried it with a couple of images in an older version of IE, and I found that each time the image was rescaled it turned out remarkably clear. It even did this when I made rapid circular motions with the mouse, and it is also very fast.
I can't believe I'm explaining this!
You do realise that I was not suggesting that a web page be rescaled each time there is a single-pixel change in the width or height of the window - don't you?
Surely, as far as resizing is concerned, you realised that I was thinking more along the lines of...
mouse down
drag to resize window
mouse up
rescale page to fit window
...and we don't even need the browser to do this!
And anyway, I didn't even mention rescaling when the window is resized - you brought that up! All I wanted to do is provide a page according the maximised window size.
So this begs the question, how does the technique that you are currently using handle user resizing of the browser?
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rendering of web pages is actually a very processor intensive job - complex pages with a lot of elements particularly so.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If a processor can manage to execute a set of instructions which operate on some complex data once in order to present a web page, then it will be able to do it again with the data adjusted! (Again I can't believe I'm explaining this. Am I in the right thread here?)
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Given that visuals are important, this is a big limitation. As cpu cycles get cheaper, it's possible that more options will come up.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Don't you think you are now complicating the problem? My original proposed solution needed no more processing power than the ungainly technique that you and many other web developers are currently using.
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The cheap and easy solution is to use Flash, ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please don't say things like this. You're making all my corns bleed and my joints are starting to swell up.
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
... but that comes with its own set of problems and is incredibly cpu hungry - which is why my iPhone presents Flash based sites as nothing more than a blank screen with a little blue box in the middle.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I hate mobile phones nearly as much as I hate Flash. Why when I was a lad, we were quite happy to walk around eating pork pies instead of fiddling with mobile phones, which means that we only have to die from heart disease whereas you will probably die of a mixture of heart disease and head cancer!
So far, considering all of your arguments, you have not come up with a single technical reason why this cannot be done given a sufficient 'rearrangement' algorithm.
Is this because you don't want to consider that there just might be a better way of serving your customers than the one you currently use?
I don't normally argue as strongly as this about something mathematical without some kind of proof. But in this case my intuition is based on actual examples of similar solutions which have been around for many years. Indeed, I remember creating simple web pages with tables and using percentages. This seemed to work fine for many window sizes, and shows that your argument about processors not being fast enough is nonsensical.
(And no, I'm not advocating a return to tables!)
Dave
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I think Dave that you need to understand the problems of rapid scaling. If you look at scaled images in IE they're incredibly rough, because scaling well would take too much time.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I've just tried it with a couple of images in an older version of IE, and I found that each time the image was rescaled it turned out remarkably clear. It even did this when I made rapid circular motions with the mouse, and it is also very fast.
I can't believe I'm explaining this!
You do realise that I was not suggesting that a web page be rescaled each time there is a single-pixel change in the width or height of the window - don't you?
Surely, as far as resizing is concerned, you realised that I was thinking more along the lines of...
mouse down
drag to resize window
mouse up
rescale page to fit window
...and we don't even need the browser to do this!
And anyway, I didn't even mention rescaling when the window is resized - you brought that up! All I wanted to do is provide a page according the maximised window size.
So this begs the question, how does the technique that you are currently using handle user resizing of the browser?
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rendering of web pages is actually a very processor intensive job - complex pages with a lot of elements particularly so.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If a processor can manage to execute a set of instructions which operate on some complex data once in order to present a web page, then it will be able to do it again with the data adjusted! (Again I can't believe I'm explaining this. Am I in the right thread here?)
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Given that visuals are important, this is a big limitation. As cpu cycles get cheaper, it's possible that more options will come up.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Don't you think you are now complicating the problem? My original proposed solution needed no more processing power than the ungainly technique that you and many other web developers are currently using.
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The cheap and easy solution is to use Flash, ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please don't say things like this. You're making all my corns bleed and my joints are starting to swell up.
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
... but that comes with its own set of problems and is incredibly cpu hungry - which is why my iPhone presents Flash based sites as nothing more than a blank screen with a little blue box in the middle.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I hate mobile phones nearly as much as I hate Flash. Why when I was a lad, we were quite happy to walk around eating pork pies instead of fiddling with mobile phones, which means that we only have to die from heart disease whereas you will probably die of a mixture of heart disease and head cancer!
So far, considering all of your arguments, you have not come up with a single technical reason why this cannot be done given a sufficient 'rearrangement' algorithm.
Is this because you don't want to consider that there just might be a better way of serving your customers than the one you currently use?
I don't normally argue as strongly as this about something mathematical without some kind of proof. But in this case my intuition is based on actual examples of similar solutions which have been around for many years. Indeed, I remember creating simple web pages with tables and using percentages. This seemed to work fine for many window sizes, and shows that your argument about processors not being fast enough is nonsensical.
(And no, I'm not advocating a return to tables!)
Dave
Upvote
0
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, whereas fixed width websites are more predictable since it is the same fixed layout on larger screens but just in the centre (only the left and right border space either side varies).
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. This frees up more time to test other important platform differences, including Windows version, screen font size settings (small fonts, large fonts), browser type and version, non-Windows platforms, non-PC platforms, etc. With a sitebuilder service no site is really new since it is using the same tried and tested underlying technology used by other sitebuilder sites, so this gives us some testing advantages too.
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.
Whilst the web stats over the last few years have seen a drop in those with 800 width screens, past performance is not an indicator of future performance as they say, and I think stats for 800 widths will go up again what with the introduction of mass-market ultra small and ultra cheap laptops (£260 Asus Eee PC and £99 Elonex One both have 800 widths - why have the BBC recently moved from an 800 fixed width to 1024 fixed width design, didn't they know about the laptop for every school kid educational push based on 800 screens?), and as more phones and MP4 players are introduced with decent browsing capabilities (via Opera for devices) to compete with the iPhone and iPod Touch.
Personally I do not see the mobile phone market pre-iPhone as an important browser test market, mainly due to the fact that it didn't really deliver the desktop internet experience so never had a chance of taking off mainstream (there are other reasons for this too). The smartphones are so high end and expensive (some more expensive than laptops) that they cannot really be considered as mass-market, and some of the mass market phones have such low resolutions and low specs that it isn't worth bothering to browse internet sites, since not only do you need the website in a different style, you also need a totally different version of the content (a much shorter version of the text), this goes beyond different styled XHTML/CSS sites, separate sites are required.
So pre-iPhone, phone browsing hasn't been too important to us, and we knew it wouldn't be from our previous experience as a company developing games for the Java mobile phone games market. Post iPhone (still not mass market) and iPod Touch (more mass market) and their competitors, it is worth spending more time keeping these devices on the radar and testing on.
Aside from what widths to test for, the issue of what width to design for has also cropped up on this forum on a number of threads:
Web design and screen sizes
Best width for a site ??
web design problems
We were also asked recently why we favour 800 width fixed width designs with our sitebuilder service, so we have added a Web Design Width and Web Screen Size article in our FAQ section.
Upvote
0
That's an excellent post there Paul and sums it up well.
There's no easy solution, and people who provide limited market websites will probably continue to work on the largest percentiles. It's too expensive to do otherwise. The BBCs, Amazons and so on of this world, however, will need to consider this more and code accordingly - which is in fact, what the BBC does at least.
The BBC's new homepage is designed for the largest market, but they do deliver different content for different users and will no doubt continue to do so. I was surprised that you now got advertisements if you logged in from abroad....
There's no easy solution, and people who provide limited market websites will probably continue to work on the largest percentiles. It's too expensive to do otherwise. The BBCs, Amazons and so on of this world, however, will need to consider this more and code accordingly - which is in fact, what the BBC does at least.
The BBC's new homepage is designed for the largest market, but they do deliver different content for different users and will no doubt continue to do so. I was surprised that you now got advertisements if you logged in from abroad....
Upvote
0
I'm not a designer but used to create fluid sites, as screen resolutions
got bigger and, especially with widescreens the fluid sites were trickier to
keep looking nice. I much prefer to see a centred fixed width layout rather
than a page which is really expanded. Plus it is a lot easier and less time
consuming.
got bigger and, especially with widescreens the fluid sites were trickier to
keep looking nice. I much prefer to see a centred fixed width layout rather
than a page which is really expanded. Plus it is a lot easier and less time
consuming.
Upvote
0
M
Mortime Business Software
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.
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)?
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'.
Dave
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
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)?
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'.
Dave
Upvote
0
Dave - you're taking this approach that always happens with people of little experience - you assume that things are simple and good, whereas actually they're very hard and all a bit cr*p really.
We're not really here to educate you on how to build websites, and your questioning is pretty much asking us to do that. You give no thanks (you've never thanked anybody by clicking the thanks button according to your stats) and expect a lot.
Sorry, but I'm not personally going to continue trying to educate you - there's nothing in it for me. And yes, that may sound selfish, but it's time I could otherwise spend on my business, my girlfriend or my home....
If you're not going to accept people's explanations then you need to become an expert yourself in order to show why they're wrong.
We're not really here to educate you on how to build websites, and your questioning is pretty much asking us to do that. You give no thanks (you've never thanked anybody by clicking the thanks button according to your stats) and expect a lot.
Sorry, but I'm not personally going to continue trying to educate you - there's nothing in it for me. And yes, that may sound selfish, but it's time I could otherwise spend on my business, my girlfriend or my home....
If you're not going to accept people's explanations then you need to become an expert yourself in order to show why they're wrong.
Upvote
0
M
Mortime Business Software
Hello All.
Since this is a serious, technical, or even scientific, discussion, it is only right and proper that it should have some sort of formal conclusion.
Here is a selection of some of the assertions which have been made in this thread, and which we should all accept without question.
------------------------------------------------------------------
Assertion (1)
The server (that is, the set of programs running on the server) knows nothing about the entity which is receiving its output.
This is clearly false because, for a start, the browser type is contained within the request from the client.
Knowing this, the server can easily acquire more information about the client's browser.
------------------------------------------------------------------
Assertion (2)
Rapidly rescaled images and web pages in a browser are "incredibly rough".
Here it is implied that it is not worth the effort in trying to offer a continuous solution rather than an incremental one.
But folks, please try the following web page in a minimised browser window, and drag the resize handle as fast as you can around your desktop...
http://www.bpresent.net.au/tutorial/web/s_web-layout.php
That *WEB PAGE* contains an *IMAGE*.
Did it look "incredibly rough" to you?
------------------------------------------------------------------
Assertion (3)
Rescaling would take too much time.
Actually, it turns out that some browsers have been able to rescale web pages for many years now, at almost lightening speed.
Do the exercise in Assertion (2) above to convince yourself of this.
------------------------------------------------------------------
Assertion (4)
There is not enough processing power to cope with fluid web page layouts.
Ha ha ha, ho ho, hee hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL,hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL, hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL, hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL,
...
hee, LOL, Ha ha ha, ho ho, hee hee hee hee, LOL, Ha ha ha, ho ho, hee hee hee ...
------------------------------------------------------------------
Assertion (5)
A mobile phone displays a "little blue box" where some flash should go because the processor is not powerful enough.
If I could laugh any more I would!
I actually believed this horse plop until someone wearing his undies on the outside of his trousers suddenly appeared on the scene and told us that actually it was simply because of a missing plug-in!
------------------------------------------------------------------
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.
Dave
Since this is a serious, technical, or even scientific, discussion, it is only right and proper that it should have some sort of formal conclusion.
Here is a selection of some of the assertions which have been made in this thread, and which we should all accept without question.
------------------------------------------------------------------
Assertion (1)
The server (that is, the set of programs running on the server) knows nothing about the entity which is receiving its output.
This is clearly false because, for a start, the browser type is contained within the request from the client.
Knowing this, the server can easily acquire more information about the client's browser.
------------------------------------------------------------------
Assertion (2)
Rapidly rescaled images and web pages in a browser are "incredibly rough".
Here it is implied that it is not worth the effort in trying to offer a continuous solution rather than an incremental one.
But folks, please try the following web page in a minimised browser window, and drag the resize handle as fast as you can around your desktop...
http://www.bpresent.net.au/tutorial/web/s_web-layout.php
That *WEB PAGE* contains an *IMAGE*.
Did it look "incredibly rough" to you?
------------------------------------------------------------------
Assertion (3)
Rescaling would take too much time.
Actually, it turns out that some browsers have been able to rescale web pages for many years now, at almost lightening speed.
Do the exercise in Assertion (2) above to convince yourself of this.
------------------------------------------------------------------
Assertion (4)
There is not enough processing power to cope with fluid web page layouts.
Ha ha ha, ho ho, hee hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL,hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL, hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL, hee hee, LOL, Ha ha ha, ho ho, hee hee hee, LOL,
...
hee, LOL, Ha ha ha, ho ho, hee hee hee hee, LOL, Ha ha ha, ho ho, hee hee hee ...
------------------------------------------------------------------
Assertion (5)
A mobile phone displays a "little blue box" where some flash should go because the processor is not powerful enough.
If I could laugh any more I would!
I actually believed this horse plop until someone wearing his undies on the outside of his trousers suddenly appeared on the scene and told us that actually it was simply because of a missing plug-in!
------------------------------------------------------------------
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.
Dave
Upvote
0
Just to confirm the conversation between me and Interconnect IT regarding the little icon on the phone. If you checked carefully the response was that there is no plugin for flash on the iPhone an upgrade coming soon will resolve this. There is a lot of technology to keep track of, especially when dealing with web design and phones as the software, hardware and displays vary greatly. If you have not created a website or thought of the design process, even maintained a edge on technology, you can't point the finger and laugh saying he's wrong. Search the web for iphone flash player or support and see what you find. This is constructive discussion about web design not child's play, with horse plop. You'll find on this forum a lot of varying levels of education and we are here to exchange thoughts and information.
Upvote
0
M
Mortime Business Software
Hi Adam.
This is what IC wrote in post #22...
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The cheap and easy solution is to use Flash, but that comes with its own set of problems and is incredibly cpu hungry - which is why my iPhone presents Flash based sites as nothing more than a blank screen with a little blue box in the middle.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In post #23 you replied...
Adam wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That icon means that there is no plugin or player for that type of content
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
And you have now confirmed that statement with...
Adam wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...the response was that there is no plugin for flash on the iPhone an upgrade coming soon will resolve this.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dave
This is what IC wrote in post #22...
Interconnect wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The cheap and easy solution is to use Flash, but that comes with its own set of problems and is incredibly cpu hungry - which is why my iPhone presents Flash based sites as nothing more than a blank screen with a little blue box in the middle.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In post #23 you replied...
Adam wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That icon means that there is no plugin or player for that type of content
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
And you have now confirmed that statement with...
Adam wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...the response was that there is no plugin for flash on the iPhone an upgrade coming soon will resolve this.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dave
Upvote
0
B
brownie
------------------------------------------------------------------
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.
------------------------------------------------------------------
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.
------------------------------------------------------------------
Upvote
0
Similar threads
Latest Articles
-
90,000 jobs are heading your way. Your rates bill might get there firstIf you run a business in Manchester, Birmingham, Leeds or Bristol, you were probably told some...- Ozzy
- Updated:
- 8 min read
-
How to Price a New Product or Service: We Asked UKBFOn 5 August, @Data Swami posted in the General Business Forum with a question that ought to have...
- Ozzy
- Updated:
- 7 min read
-
70 years of director bans in six months: Companies House has stopped asking nicelyCompanies House published a release on August 6th 2026 that every company director should read...
- Ozzy
- Updated:
- 7 min read
-
MTD for Income Tax: your first quarterly update is due 7 August.If you are a sole trader or landlord and your gross income from self-employment and property was...- maka
- Updated:
- 4 min read
-
Andy Burnham's Manifesto for Small Business, and How It Stacks Up Against Count BinfaceIf all goes to plan (or rather, to Labour's timetable), Andy Burnham will be sworn in as Prime...
- Ozzy
- Updated:
- 5 min read