I have been looking at some established, even ‘geeky’, sites trying to analyze their practices. I understand that that a popular practice is not necessarily a good practice. Still I was taken aback, especially when it comes to branding/search/and navigation areas … how the container explicit dimensions or explicit height.
Examples: visit Cnet , Facebook , SITEPOINT!??!. These are HUGE sites, right? Now if you set your UA preferences to ZOOM TEXT ONLY and zoom in you will see that the navigation/login areas quickly overflow and become nearly inaccessible. (not to mention it just feels like the layout i essentially broken even if the elements remain in place)
OK at this point I know I am getting quite a few “who the hells zooms text only anyway…you even had to change the prefs for this to happen!” and honestly, I am tempted to agree. With the one caveat that I tend to see this as an bad sign for what could happen if the nav/branding content ever was more than expected.
As an art director who codes I struggle with this from an efficiency point of view. I can create BGs that can tile or fade vertically for this eventually but it does limit the design options and makes both the aesthetics and the code orders of magnitudes more difficult to do. Of course all this extra effort may be moot if few if any users dont have text only zoom enabled.
Is it still bad practice to make a fixed height area ( such as navigation, header or footer) knowing that it will likely overflow if zoomed in with zoom text only enabled ? Is it an accessibly disaster and the mark of a “PS jokey” or is that just a requirement of decades past that is just no longer worth the extra effort?
I agree not setting explicit heights is definitely the way forward.
Zooming text is one issue, but for me it’s more an issue of making device resizing easier. You can set a default body EM height on the BODY element and use media queries to update that body default at different screen sizes. If you’ve hardcoded pixel heights on the layout, it’s a lot more work to over-ride them in your media queries.
Personally, I have found it a little harder to design layouts in EMs and percentages, but there is a big payoff when you start tweaking for device sizes.
One thing: It’s hard work retrofitting this into templates originally designed with pixel heights in mind, which probably goes some way to explaining why many sites aren’t doing it.
I agree not setting explicit heights is the way definitely forward.
the funny thing is I notice MORE sites are setting heights now, than before.
What I see in in nav styles like CNETs. because the logo is “etched” into the side of the navigation,and a centered gradient background is employed, if only the text then the logo would proportionally ‘get lost’ and the nav bar gradient would no longer seemed centered ( and consequently the ‘gloss’ illusion would be lost). So it’s a choice: this specific ‘look and feel’ or flexibility.
And yes many big sites like sitepoint and etc don’t do seem to care about this. But they should because then it doesn’t work on iPhone s and like. It’s it always just zoom you have to worry about.
I much prefer text-only zoom, so I’m disappointed that browsers now default to whole page zoom. (I hate the way a lot of sites don’t have a max-width: 100% or whatever, and thus get lost off each side of the page.)
If designs do have a max width, though, they can still get bitten if there are heights set, so even with whole page zooming, fixed heights are still a bad idea.
actually , ( at least on my mac browsers)… ‘regular’ zooming does act like “getting closer” to the screen, everything is enlarged proportionally ( including element sizes, of course this means bitmaps get pixelated). I suppose that the way people expected zoom to be from the start, BUT I wonder if this wave of non-text-zoom-co0nsidering sites is because the “regular” zoom is now default?
Incidentally, in all fairness to the sites mentioned ( at least nav area wise) you can text zoom 3 times before anything overflows. My issue however is that they are “allowing for” a set # of zooms when designing graphics/coding as opposed to going for more limiting but flexible graphic design/coding solutions.
Yeah, the zooming of images is interesting. Personally i don’t like it, but does zooming an image up – even though that just makes it big and blurry – actually make it easier for a vision-impaired user to perceive?
I’m guessing that, even though there isn’t any more image data there, it does hit more photoreceptors in the eye.
I’m guessing that, even though there isn’t any more image data there, it does hit more photoreceptors in the eye.
Don’t know about PC, but Mac also has a screen zoom feature that I find quite useful. (Strangely, it’s not enabled by default in the lastest Mac OS.) Even though images get more grainy as they enlarge, I do find it useful to get this closer look sometimes.
so… then the “screen zoom” feature in the UA ( not part of the OS) is the reason why using scalable ( as in tiles) and flexible containers may be going out of style?
I would guess that the “screen zoom” feature is becoming more popular because “text zoom” can create a bit of confusion as users switch between sites and do not realize what their text size settings are. When they come back another time or use a different computer, the site look “different”.
In a similar vein, I have often wondered why so many site are using such small screen fonts and suspected that the coders had their fonts zoomed larger than normal or were using large monitors with magnified resolution rather than “normal”. Why create pages that so many users have to zoom up a notch or two to read? Our forum is no exception.
Regarding the reluctance of large sites to redesign to accommodate “text zoom”, I would guess that the reason is economic. Not enough bang for the bucks required to redesign the code. Most of those sites were created before text zooming became popular… when fixed-width or fluid-with-a-minimum-width sites were in vogue. Fixed width or limited width design is easier/cheaper. Someone has to see a need for better designed functionality before they are willing to pay for it. If they don’t see it as broken, they ain’t gonna pay to fix it.
Of course, we can’t rule out big business influence/pressure to limit the costs of doing business, too. If major businesses don’t have to pay for better menu designs by influencing browser development, so much the better for their bottom line.
In the end, it’s boiling down to money. Creativity is being stifled by the economics involved. An old story.