Bad/bloated web design

[NiHaoMike]

Even 600x800 is often good enough for "banter" pictures...    A page full of 4K pictures would be hard for many connections to "swallow"!

Why should we limit ourselves to a standard that was in common use on the Web over 20 years ago? If anything, that's just too small on modern high resolution displays. I picked 1080p because it has been affordable for over 10 years and still looks great on the newest hardware.

[PlainName]

Why should we limit ourselves to a standard that was in common use on the Web over 20 years ago? If anything, that's just too small on modern high resolution displays.

You make the same mistake as the designers of bloaty web pages - screen resolution doesn't equate to window resolution. For example, I am using a 4K monitor now but this browser window is 1200x1200. I didn't buy a huge monitor so I could fill it with your photo (that I probably ain't interested in anyway). No, it is a huge monitor so I can fit more stuff on it without spilling over onto a second or third one. (In fact, this is my second 4K - the first was a 32" but the DPI was too fine for me so I had Windows set to scale 125%. That kind of worked but lost me a good part of the screen I bought for more dots. Dumped it and got this 43" which is perfect.)

Does it never occur to people that things that have lasted "over 20 years" might do so because they are pretty OK? This text you're reading - do you want/need to change the language because English must be pretty worn out now? Maybe use finger smears (and lots of white space) instead of thin lines?

It's not that long ago that web designers assumed their breathless prose would fit nicely our 1920-wide monitors and didn't allow for a non-maxed browser window. It's taken some time to disabuse them of that, and bumping up image resolution just because you can is missing the lessons learned.

If you really feel the need to post a huge, or even just large, image, please do us the courtesy of letting us choose whether to view it or not. The facility is there when you post: make it "end-of-post expandable thumbnail" or "inline expandable thumbnail" if that ever works properly again. Copying the full-size link to post in-text is just saying "my wishes are too important for you to have a choice".

[SilverSolder]

Even 600x800 is often good enough for "banter" pictures...    A page full of 4K pictures would be hard for many connections to "swallow"!

Why should we limit ourselves to a standard that was in common use on the Web over 20 years ago? If anything, that's just too small on modern high resolution displays. I picked 1080p because it has been affordable for over 10 years and still looks great on the newest hardware.

We don't "need" to limit it, but e.g. this flower is beautiful in 800x600 so why post the original 40+ megapixel image?

[james_s]

You make the same mistake as the designers of bloaty web pages - screen resolution doesn't equate to window resolution. For example, I am using a 4K monitor now but this browser window is 1200x1200. I didn't buy a huge monitor so I could fill it with your photo (that I probably ain't interested in anyway). No, it is a huge monitor so I can fit more stuff on it without spilling over onto a second or third one. (In fact, this is my second 4K - the first was a 32" but the DPI was too fine for me so I had Windows set to scale 125%. That kind of worked but lost me a good part of the screen I bought for more dots. Dumped it and got this 43" which is perfect.)

Exactly this. I have a 1080p display on my laptop, and I never have my browser maximized to fill the whole screen unless I'm watching a video that I want to focus entirely on. I tile the applications and windows I have open so I can multitask and see multiple things at once. I find it endlessly frustrating that there is this arms race where the more pixels I get, the more bloated and wasteful of said pixels everything gets. The whole point of a high resolution monitor is to display lots of information, scaling everything up so it looks the same size as it did on a lower resolution monitor defeats the purpose. 800x600 is perfectly adequate for a photo, having higher resolution available is nice if it's something that has detail someone may want to zoom in on but it should not be the default. Just because the pixels are there doesn't mean you should use them.

[NiHaoMike]

Does it never occur to people that things that have lasted "over 20 years" might do so because they are pretty OK? This text you're reading - do you want/need to change the language because English must be pretty worn out now? Maybe use finger smears (and lots of white space) instead of thin lines?

English has evolved considerably over the years - remember the Shakespeare they had you read in school and how it's so different to "modern" English? Increasing resolution isn't completely changing format, it's just adding more detail.

Looking back, I targeted 1024x768 in 2010, changing that to 1080p sometime in 2012. 1080p pictures are pretty easy to handle, even my old Core 2 Duo back in the day had no problem with it.

[PlainName]

English has evolved considerably over the years

That's so, but only in content rather than the mechanics. It is still upper- and lowercase, vertical lines and circles.

even my old Core 2 Duo back in the day had no problem with it

But your Core 2 Duo wasn't the one viewing the stuff.

I'm sure your images justify whatever pixel size you consider suitable. What we're asking is that you don't put those in the body text. Just use the thumbnail facility and anyone that wants or needs to see then in their unadulterated glory can do so with a click. Meanwhile, people that want to read the text can do so without having to wear out the mouse scrolling past them. And waiting for the damn page to stop filling with junk.

[MrMobodies]

I remembered my first monitor 17inch a Viewsonic in 1999 doing 1024 x 768 at 85hz or something like that. That broke many times so I got a philips 19inch that did 1280 x 2048 and that lasted many years until the day the vga plug broke which I could patched another one. I brought a HP2065 in 2006 which I am still using and no problems and that is 1600 x 1200 at 60 hz. I was given a couple of Sony monitors at about that time and  I think one of them was a 21inch and that could  1280 x 2048 at 85hz or 1600 x 1200 at 60hz?

I hardly had  no issues with web design (I can tollerate glitches and imperfections untill I started to notice this spammy behaviour in about 2015 (forced suggestions and sticky header/ (I just call it a spammy toolbars) rubbish started up then things started to get larger and larger and spaced out.

Like yesterday I was trying to get someone a camera driver. I ended downloading an older copy from an old direct link on google search leading to Logitech out of frustration of not being able to find it on the Logitech website. Eventually I found it after looking again for a couple of minutes because that was an older driver with things wrong wit hit but I didn't find it obvious at first time because of how large things were.


See attached pictures: Anyway with the extensions off, so I am missing anything that might be fixed and offer a quicker convenient url to the download (which I wouldn't want stuck there either. Scroll all the way down the page, okay, I see Specifications. Where are the drivers, when I looked it was under support.

https://www.logitech.com/en-gb/products/webcams/streamcam.html

A horrid toolbar with a "Buy" button : logitech.com##.component-secondary-nav.fixed-nav   (Like that is so important that with the space it takes up and the distraction it causes me for a button I'm not likely to click except add it to my blocklist well the Headerhiderhixer extension takes care of that.)

Click support then downloads.

Okay I click "View all downloads" then I redirected to this page:

https://support.logi.com/hc/en-gb/articles/360042746714-Download-Stub-Logitech-StreamCam

with a button "show all downloads".

By clicking that page I'd want to see all downloads without it being hidden under a button.

The side panel make some sense to me apart from this other distracting horrible spammy toolbar.
support.logi.com##.component-corporate-nav.corporate-nav.theme-dark.sticky
logitech.com##.component-secondary-nav.fixed-nav

Could do without the toolbars and a downloads url on top of the page that leads to downloads that actually show.

[james_s]

Looking back, I targeted 1024x768 in 2010, changing that to 1080p sometime in 2012. 1080p pictures are pretty easy to handle, even my old Core 2 Duo back in the day had no problem with it.

Good for you, you've been annoying people for 11 years since it worked for you and you never had the slightest concern for how other people may work. My computer can handle large pictures just fine, that doesn't mean I want to have them embedded so they fill my entire screen without me even clicking on a thumbnail to see them. You really are illustrating perfectly the mentality and complete and utter disregard for any use case other than your own that this thread is complaining about in the first place.

[SilverSolder]

Looking back, I targeted 1024x768 in 2010, changing that to 1080p sometime in 2012. 1080p pictures are pretty easy to handle, even my old Core 2 Duo back in the day had no problem with it.

Good for you, you've been annoying people for 11 years since it worked for you and you never had the slightest concern for how other people may work. My computer can handle large pictures just fine, that doesn't mean I want to have them embedded so they fill my entire screen without me even clicking on a thumbnail to see them. You really are illustrating perfectly the mentality and complete and utter disregard for any use case other than your own that this thread is complaining about in the first place.

Some web sites dish up different size pictures, depending on the size of the browser window.  (At least, in the days before everything had to be white pixels!)

[Nominal Animal]

Some web sites dish up different size pictures, depending on the size of the browser window.  (At least, in the days before everything had to be white pixels!)

A decade and a half ago I reimplemented (technically; no redesign work) the web pages for a university department (later the entire faculty of science).  Because of lack of SVG support in all browsers then, the fully autoscaling layout had a logo consisting of an SVG image, backed by MathML if SVG was not supported, backed by a PNG (or was it GIF?) image in case neither was supported.  Content scaled to fill the browser window naturally, and text size was freely scalable using the browser controls.  (Most of my work, however, was to re-engineer the backend, because we had a lot of different people maintaining different parts of the site, and they changed often; my job was to make it easier and more efficient for people.  The user-facing "adjustments" I did on my own, but they were very happily accepted.)

You see, I was disgusted to see that when lecturers showed a web page "designed for 800x600" or "1024x768" or whatever the designers had decided was the resolution, on the über-powerful projectors the content was this thin strip on the 6-meter wide canvas nobody could read.  Obviously, this was because the projector resolution was approx. double the typical display resolution then.  Useless; silly.  Made me angry, that.

After my meddling, everyone could read the very same pages on all different devices, from phones to 4K displays.  (We did do custom stylesheets for phones to rip out most of the eye candy, so phones would show content better.)  And they also fully conformed to XHTML 1.1 (unless a page maintainer introduced errors in the text content; which was stored in separate files from the UI stuff, and combined on the fly with my utterly simple "page engine").

It used to be much more work than nowadays, too, because of the numerous layout bugs in different browsers that needed to be worked around.  I'm old enough to remember when uploads themselves were technically difficult to handle robustly, just because each new browser version tended to have their own new bugs in their implementation...

I think I've only managed to anger a handful of (web) designers in my time.  The dozen or so I've talked to that were initially unhappy about my suggestions (who wanted to design for a specific resolution), all were really interested and happy to see how they could still fully control the layout and visual look while letting the content scale "naturally" to different devices and browser window sizes; especially since I was happy to do the technical conversion work, and they only specify the dimensions in appropriate units (either em or ex if dependent on text size, or percentage of window width, typically).  A big part of that, of course, was me showing their design in different situations in practice – I knew to always do that, because out of sight, out of mind, so realizing something often requires seeing it for oneself first.

Based on a lot of experience, I claim that such relative scaling is the correct way to design a web site.

With respect to image sizes on forums like this, it would work better if the [IMG] tag allowed an attribute to specify the displayed width of the image relative to the content area (in percentage) the image is scaled to, regardless of the resolution – and that it supported SVG images, too.  SVG is perfect for diagrams and schematics, and scale perfectly.  I suppose even a tag that caused the forum to generate a snippet of Javascript that switches between native size and scaled to content size keeping aspect ratio intact, would work.  (It'd be trivial to implement.)

Then, the pixel size of uploaded images would not matter nearly as much as it does right now.
As things stand right now, us SMF2 users have to consider the pixel size the presentation size, and that is wrong (based on above).
Plus, the [ATTACHIMG] tag doesn't seem to work at all, which means every post that contains images has to be edited to get the images inline.

[NiHaoMike]

Good for you, you've been annoying people for 11 years since it worked for you and you never had the slightest concern for how other people may work. My computer can handle large pictures just fine, that doesn't mean I want to have them embedded so they fill my entire screen without me even clicking on a thumbnail to see them. You really are illustrating perfectly the mentality and complete and utter disregard for any use case other than your own that this thread is complaining about in the first place.

Only 9 years since I decided to upgrade my target resolution to 1080p. Maybe that was a bit early but at some point any target resolution we set will become too low for the display technology in common use. I like to err on the side of setting the target high so it will continue to look good on newer hardware.

Some web sites dish up different size pictures, depending on the size of the browser window.  (At least, in the days before everything had to be white pixels!)

Or they just tell the browser to scale down pictures as needed. I remember one site that used some dumb code to scale down pictures crazy small which I hated, luckily I use Firefox so one extension to disable that and the site was usable on what was then a fairly new PC. Make the scaling code check the width of the browser window and it will auto adapt to what the user set it to.

[Nominal Animal]

As an example of how image resizing within posts should work, here's my suggestion: Initially 25% of available area width, first click resizes to 100%, second to native pixel size, and third click resizes to initial size.  Example implementation using capt bullshot's workbench image:

Code: [Select]

<!DOCTYPE html>
<html><head><title>Autoscaling example</title><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><style type="text/css">
.smallimg { width: 25%; }
.mediumimg { width: 100%; }
.largeimg { }
</style><script type="text/javascript">
function imgsize(element, w, h) {
    if (element.className == "smallimg") {
        element.className = "mediumimg";
    } else
    if (element.className == "mediumimg") {
        element.className = "largeimg";
    } else
    if (element.className == "largeimg") {
        element.className = "smallimg";
    }
}
</script></head><body>

<img class="smallimg" src="https://www.eevblog.com/forum/chat/whats-your-work-benchlab-look-like-post-some-pictures-of-your-lab/?action=dlattach;attach=1218714;image" alt="Click to resize" onClick="imgsize(this, 2559, 1600);">

</body></html>
There are even tidier, better ways to implement this, but this just to show how simple something like is to technically implement; it's only a question of what human designers deign to implement.  SMF already implements something much like this; the above code is not fully compatible with SMF's style system, but the tweaks needed to make it so are small and simple.

In other words, SMF users are currently "encouraged" to upload too-large images if they use large displays, because otherwise the images are shown smaller than necessary.  The pixel size of an image should be dictated by the fidelity required – large enough for text to be easily readable – and not the presentation size.  For vector formats like SVG, optimal for charts and diagrams, including board schematics, the scaling wouldn't even affect fidelity at all, but SMF's upload does not currently support SVG images as file uploads. (I link to SVG images on my own server, when I use those.)

The entire discussion on what pixel size images one should use, is therefore utterly silly, because it depends on the image content.  It's just that now, SMF forces an unnecessary and unreasonable relationship between presentation size and pixel size.

[DiTBho]

I have the same problem for a blog project. I need to learn things in order to avoid these silly mistakes.

[DiTBho]

How do you probe the screen resolution?

[Nominal Animal]

How do you probe the screen resolution?

Browser window width and height (excluding scrollbars) are window.width and window.height, the display width and height excluding taskbar is window.screen.availWidth and window.screen.availHeight (window.screen.width and window.screen.height including taskbar).

Basically, all you want to access from JavaScript hangs off either the document or the window objects.  This stuff is called "the Document Object Model", or DOM.

Personally, like I said, I use window-size-relative or text-relative layouts.  This means I don't care about the pixel dimensions at all, and use either relative-to-container sizing (percentage) or dependent-on-current-font (em and ex).

[DiTBho]

So, Javascript probes the browser and gets its property, but how do you then use this information on the PHP side to react and accordingly adjust the the html code with the proper css and style?

Suppose you have four css
- mobile_phones.css
- mobile_tablet.css
- computer_small_screen.css
- computer_big_screen.css

The PHP code has no idea about the browser but the Javascript knows the browser because it's executed by the browser so it can tell the PHP code to change the css accordingly.

Does it make sense? If so, how to do it?

[Nominal Animal]

Server side is not relevant here.  The content served from the server should always stay the same; all of the layout adjustment is done on the client side, with CSS and JavaScript.

(Even things like loading the best version of an image (that is the focus of the page, so you don't want to leave its scaling up to the browser, and want to use your own finely-prescaled versions instead), is best left to the JavaScript on the client side.)

The HTML <style type="text/css" media="media"> ... </style> and <link rel="stylesheet" type="text/css" href="URL" media="media"> tags apply the specified CSS or stylesheet only if the browser used matches the clause in media; see e.g here for the syntax and recognized values.

Most of my layout stuff I do in pure CSS.  I do use the <table> element for actual data tables, and when I need a specific form-type layout and control how fields expand/contract.  If you look at the source HTML of my FIR analysis tool page, sometimes one needs to use JavaScript to fix layout details after the contents has been loaded and laid out (the window.addEventListener("load", recalc); line causes the recalc() function to be called then) or whenever the browser window size changes (the window.addEventListener("resize", redraw); line causes the redraw() function to be called then); in that case, because we want to do an initial plot (no data, though) when the page is first loaded; and because the canvas properties need to be updated to match the current browser window whenever plotting the calculated data.  (To test that page, just put some coefficient, say 1 0 1 0 1, into the "FIR Filter Coefficients" box, and press Enter.)  That one is under 400 lines all told, and all in one file (no server side; it will work fine if you just save the page and use it locally, without a net connection), so even if you're not yet too familiar with HTML, CSS, and JavaScript, you should be able to work it out.  I think.

What guidelines to use for the layout itself, is up to a graphic designer, and I ain't one.  Or maybe up to an UX specialist; I'm not sure what the ones who don't just want to make things look stylish, but try to make the content useful and fit for purpose, call themselves nowadays.

Oh, and if someone disagrees, do pipe up, even if you think I sound like I know what I'm doing.  This is human interface stuff, so other opinions and experiences are just as valid here.  (Of course, as I wrote earlier in this thread, I do have reasons for these opinions; I think those reasons are much more interesting and useful than the opinions anyone has based on them.)

[DiTBho]

Ah OK.

I wrote it because a year ago I wrote a "presenter" in PHP that makes the site react differently depending on the incoming IP and other events.

Code: [Select]

function get_presenter
(
    $browser_ip,
    $mode
)
{
[..]
    else if ( server_is_out_of_service() == true )
    {
        $presenter_content_filename="handle/out-of-service.html";
    }
[..]
    else if ( cookie_is_bad() == true )
    {
        $presenter_content_filename="handle/forbidden2.html";
        ban_ip($browser_ip);
    }
[..]
    else if ( is_promo_ip($browser_ip, "Google") == true )
    {
        $presenter_content_filename="handle/Google.html";
    }
    else if ( is_promo_ip($browser_ip, "Yandex") == true )
    {
        $presenter_content_filename="handle/Yandex.html";
    }
    else if ( is_promo_ip($browser_ip, "wayback") == true )
    {
        $presenter_content_filename="handle/forbidden3.html";
    }
    else if ( is_promo_ip($browser_ip, "VPN") == true )
    {
        $presenter_content_filename="handle/forbidden2.html";
    }
    else if ( is_bad_ip($browser_ip) == true )
    {
        $presenter_content_filename="handle/forbidden1.html";
    }
[..]
    $presenter_content = file_get_contents($presenter_content_filename);

    return $presenter_content;
}

It's done for security reasons, it keeps away some attackers and it prevents Google and Yandex to cache the website as well as it doesn't allow a wayback machines to clone the site; before your clarification I was thinking to use something similar to manage the right css filename to be passed from a similar PHP function so it can be included into static html pages.

But it sounds much simpler to you JS code, thank you 

[Nominal Animal]

I wrote it because a year ago I wrote a "presenter" in PHP that makes the site react differently depending on the incoming IP and other events.

Yup; that's a completely different situation.

Another similar server-side choice wrt. what is served is done in many forums, depending on whether the client (browser) has logged in or not.

On the client side, I believe we want to think of JavaScript and CSS as acting behalf of the user – stuff like choosing displayed image sizes; and the server side acts on behalf of the service provider or owner.  This is a crude abstraction, but also works for basic security, because then you avoid bad models like attempting to do security on the client side (trivially bypassable by just modifying the received HTML/JS/CSS), or layout choices on the server side (slow, complicated, and not very responsive wrt. browser window size changes and such).

At least I personally switch between different "agencies" when writing such code.  (A third one is an attacker, wishing to exfiltrate data, or inject data on behalf of another user; a thief or a troll or a script kiddie.)  Devs sometimes joke it takes a dissociative personality to do that, but it's not true; it's just a change in perspective and goal, followed by examination of the implications, followed by bug-fixing.  I do like to have a sleep in between, makes easier to see (perceive details and implications).

If one has difficulty understanding how such two (or more) sides can do "contracts" and provide trust chains (of operations) and such – for example, that the form data submitted is associated with the session that provided login credentials sometime earlier, and not just someone who obtained stale cached data and is replaying the information –, reading overviews of public-key cryptography and key exchange, and the differences between encryption and message verification via cryptographically secure hashes, will help; that way one can discover both the patterns used, as well as how and why they work (and therefore when they can be relied upon, and with which limitations/assumptions).

[MrMobodies]

Homebase website now bloated.

I think I shopped there a couple months ago and the website seemed alright.
https://web.archive.org/web/20210115150429/www.homebase.co.uk/

A change in appearance:
https://web.archive.org/web/20210401135252/https://www.homebase.co.uk/
Some dimming on hovering mouse over the account and basket but no fixed header or widgets and no dimming on search box.



Looks the same initially but now with the nav toolbar fixed and fixed widget (price and delivery) stuck on the side, with the dimming EVERYWHERE on mouse hover on the menu items and all sorts of different element names.

www.homebase.co.uk

The dimming seems very excessive:





Looks better with the UI crap removed and the nav toolbar:

homebase.co.uk###responsiveAccountHeader_overlay
homebase.co.uk###responsiveFlyoutMenu_menuUnderlay.responsiveFlyoutMenu_menuUnderlay-show
homebase.co.uk###menuUnderlay
homebase.co.uk##.responsiveFlyoutMenu_menuUnderlay.responsiveFlyoutMenu_menuUnderlay-show
homebase.co.uk##.responsiveFlyoutBasket_overlay
homebase.co.uk##.responsiveAccountHeader_overlay
homebase.co.uk##.headerSearch_overlay.headerSearch_overlay-show
homebase.co.uk##.emailReengagement.show
homebase.co.uk##.westendHeader

Reminds me a little bit like scan.co.uk with the search box.

No care in the world for the eyes with the dimming but would that be worse for someone with sensory issues?

[SilverSolder]

[...]
No care in the world for the eyes with the dimming but would that be worse for someone with sensory issues?

I read an article recently that said Millennials are not having as much sex as previous generations.  -  could that frustration be a factor in all the bad web designs we are seeing?? 

[MrMobodies]

Joke: or maybe when developing this overlay rubbish to go on websites they were in a dark room with dark mode turned on.

https://www.androidauthority.com/dark-mode-1046425/

Love dark mode? Here’s why you may still want to avoid it
By Adamya Sharma
•April 10, 2021

Do you know that feeling when you’re comfortably sleeping in a dark room, and someone suddenly draws open the curtains to flood the room with sunlight? You feel a sudden shock in that moment because your iris hasn’t adjusted to the amount of light it needs to take in.

When you view things in dark mode for a prolonged period of time, say a few months, your eyes get accustomed to letting in less light. Because of this, when you do look at a bright screen from time to time, you feel a sense of discomfort.

This comes from personal experience. I used dark mode across my phone, PC, and tablet for about three months. When I described my growing aversion to bright screens to a surgeon friend, he explained that this is a pretty common phenomenon that occurs when our eyes get accustomed to dark mode.

Thankfully, he told me that this increase in sensitivity to bright

I am not surprised with the amount of backgound dimming stuff in everything that a "dark mode" was brought into it.

[james_s]

Dark mode itself is I think a band aid in response to the sea of bright white space trend. I have my phone set to switch to dark mode in the evening but many websites still ignore that. Many displays won't even go dim enough to comfortably use in a dark room.

[MrMobodies]

Many of mine are just 60hz.

[james_s]

60Hz was far too low for CRT displays once sizes went above about 15", but I have never had an issue with a 60Hz LCD, they don't flicker when they refresh the way a CRT does so the refresh rate is not nearly as important.