Designing by Numbers -- Statistics and No Lies!

Understanding the Audience's Screen Resolutions

When you set out to redesign a site, the first thing you’ll notice is how many people still view your pages on a 640 × 480 screen. Even though the percentage has shrunk over the years, it remains a relevant data point because it forces you to think about layout constraints. In a recent audit of my own website, the raw numbers broke down like this: 2 % of visitors were on an unknown resolution, 9 % still clung to 640 × 480, 61 % were comfortably seated at 800 × 600, 23 % hopped to 1024 × 768, and the rest of the spectrum was split between 1152 × 864, 1280 × 1024, and 1600 × 1200, each with less than 2 % share.

Because the majority of users sit in the 800 × 600 to 1024 × 768 range, a pragmatic approach is to design for a fixed width of around 750 pixels. This middle ground keeps the visual experience tidy for 800‑pixel wide viewers while still allowing a reasonable amount of horizontal space for menus and additional content on larger screens. If you rely on tables for layout, this width keeps column widths from stretching into ridiculous ratios that break readability on higher‑resolution monitors.

The temptation to create a fully responsive design - using 100 % widths that automatically scale across every possible resolution - remains strong. However, the complexity it introduces can outweigh the benefits. Table‑based layouts, when set to a constant width, maintain consistent column widths, which is critical when you embed images or interactive widgets that otherwise would warp or become misaligned. If you need a truly fluid layout, CSS flexbox or grid are modern alternatives that offer responsiveness without sacrificing structure.

It’s worth testing your design on the most common resolutions. On Windows, right‑clicking the desktop background and selecting Properties lets you temporarily switch between 640 × 480, 800 × 600, and 1024 × 768. After a short preview period the system reverts automatically. This quick test shows how the layout behaves under each setting. For developers who need to see a page in multiple configurations without changing the host machine’s settings, a small utility called SilverThingy (available from Sausage Software) lets you preview your page in all three popular resolutions side‑by‑side within the same browser window. These tools are handy for spotting broken images or misaligned tables before your audience sees them.

While 1024 × 768 is now the second most common resolution, it still carries a hidden risk: many sites built with a 800‑pixel base width look oddly stretched on it. If your design feels uneven, consider adjusting the container width or adding padding to cushion the content. Remember that each user’s screen is an ecosystem of resolution, browser, and operating system; a thoughtful compromise that respects the most common environment reduces frustration for the majority of visitors.

Browser and Operating System Landscape

The next pillar of data that shapes design decisions is the software stack your audience runs. In the latest snapshot of my site’s traffic, Microsoft Internet Explorer 5.x and 6.x together claim a staggering 97 % of the browser market share. Netscape users are now a tiny fraction - less than 2 % combined for all versions, including Netscape 4.x, 5.x, and the early Netscape 6 releases. A handful of visitors still use older versions like IE 4.x or IE 3.x, but these numbers are so small that targeting them becomes a diminishing‑returns exercise.

When the lion’s share of users lands on IE 5+ or 6, the CSS support you rely on will hold for virtually every visitor. Even if your design uses subtle visual effects like box shadows or gradient backgrounds, IE 6 can handle most of them with proper fallbacks or VML. However, keep an eye on upcoming browsers - while the older versions dominate, the web is moving toward standards‑compliant engines. Google Chrome and Mozilla Firefox already offer advanced features that may soon eclipse IE’s user base.

Operating systems follow a similar pattern. In the same analysis, 69 % of visitors run Windows 98, 15 % run Windows 95, and only 6 % are on Windows NT. Windows 2000 and later are barely in the mix, each with a two‑percent share. macOS users represent a mere 1 % of the traffic. Linux, Unix, and other platforms are essentially invisible on the statistics screen.

These figures have real implications. If you’re targeting the majority, sticking to the simplest, most widely supported features is sensible. Avoid heavy dependencies on platform‑specific capabilities like ActiveX or Java applets, which can cripple users on non‑Windows systems. On the other hand, if your business model depends on serving a specialized audience - say, scientific researchers who tend to run macOS or Linux - then a more inclusive design becomes necessary.

Cross‑browser testing tools such as AnyBrowser can help you verify that your pages render correctly across the most common engines. Upload a page, choose the browsers you wish to test, and the service will show you side‑by‑side snapshots. While the data shows that the older browsers are already on the decline, a quick test will reveal any last‑minute quirks before you push a redesign to production.

Java, JavaScript, and Additional Technical Considerations

Beyond the visual and operating environment, modern web pages frequently lean on JavaScript and Java for interactivity. In my own analytics, 94 % of visitors enable JavaScript, and 92 % have Java turned on. Only 5 % choose to run the site without JavaScript, while just 2 % disable Java. Java usage shows a similar pattern: 6 % have an unknown status, 2 % have it disabled, and the rest actively use it. The consensus is clear: most visitors welcome these technologies, but they are not omnipresent.

Because JavaScript can fail silently or trigger a browser crash, it is wise to guard critical navigation elements with graceful fallbacks. For example, if a drop‑down menu relies on JavaScript, provide a plain‑HTML alternative or use progressive enhancement so that the menu still works, just without the fancy animation. The same principle applies to Java applets; a lightweight JavaScript alternative often suffices, and it avoids the security warnings that applets can trigger.

When you need server‑side interaction - like dynamic menus or user‑specific content - consider using CGI scripts or server‑side includes instead of JavaScript. CGI keeps the client light and reduces the risk of JavaScript‑specific errors. Server‑side includes (SSI) can inject the current date or other server‑controlled data without any client‑side processing.

Performance is another factor. Heavy JavaScript libraries, especially those that bundle dozens of files, can slow down page load times for users on slower connections or older hardware. Use a module loader or a minifier to bundle and compress your scripts. Also, test your page on a network with limited bandwidth; tools like Google's PageSpeed Insights can pinpoint scripts that are blocking rendering.

Finally, remember that design decisions should align with the actual user base, not just a theoretical ideal. If the analytics show a small minority of users on older systems, it is reasonable to focus on the features that benefit the majority while still offering basic functionality for the outliers. The goal is to create a browsing experience that feels seamless for the 97 % who visit your site with IE 5+ or 6 on Windows 98 or newer, while keeping an eye on emerging standards that will shape the web in the next few years.