thoughts about sitewide optimization

… when all depends on user preferences.

Want to design and populate the perfect web site? One that satisfy every software standard, customer, and end-user's preferences? I hope not, as just trying to define such a site will be a futile and never-ending task. The search for perfection all too often waste time better used on figuring out what works.

A site that works reasonably well for the largest number of the intended group of visitors, is a nice and reachable goal. The less one has to tell visitors about how it works and how to find their way around, the better.
Of course; if one regards ones own designs as pure works of art and want them appreciated as such, then more balanced and sensible goals as alluded to above, do not apply. Art galleries may be the right venues for presenting those…

That a site should works reasonably well for all who happen to come by, including those who depend on assistive technology, is a sensible requirement for official and commercial sites. Such “universal functionality” has never hurt any of “the other” web sites either, as long as they pass real world tests in that respect and not just sets of technical guidelines.

avoid playing catch-up

A few hours a month spent on scanning the web for inspiration and ideas worth my attention, is the least I can invest in keeping up my interest in web design. Nothing much may come out of it for months, but at least it keeps me somewhat updated.

Evaluating evolving standards and trends to see if any of it makes sense for ones own work, is a very sensible use of time no matter how comfortable one feels about ones own products. The world does not stand still, and neither should we who design, work, and/or play around with web sites and related stuff. One can never pick up too much knowledge about what's good and what's bad.

Most front-end coders have preferred solutions and ways to deal with translation of visual designs into markup and styles, and may have to step out of their comfort zone when designs and/or functionality require something extra. All that will be a lot easier for those who frequently take time to look into and refresh on standards and other people's work. What we may have no need for today, may be in high demand tomorrow.

content supporting designs…

Content on web pages/sites is text, images, and audio/video. Should work fine as long as the software/hardware is up to the tasks at the reciving end. If it does not work, there isn't much we can do but to make sure our creations work in accordance with relevant standards, as we have no control over how compliant end-users' setups are or how it is used.
I personally am not much for bending over backwards in order to be in compliance with all standards and rules that may apply to web sites. However, in web design those standards and rules do provide us with the only common ground, and somewhat safe fallback, if anyone complains.

Providing authors/copywriters with the tools they need to make their stuff stand out visually, is in my opinion the most important built-in functionality of a site's design oriented code. The main functionality of most web pages' stucture is after all to carry content through to visitors, and in their simplest forms not much structural design is needed to perform that role on screens.

If the visual side of content matters beyond “looking good on screens”, then a little effort should be made to extend that side of content delivery to non-visual software/hardware – that is: AT (Assistive Technology). Important to balance one's approach here, as cluttering up markup and styles with “solutions” in order to be “helpful”, may easily end up as just that: “meaningless clutter”.
Regular markup can fill most roles needed by AT when applied properly, and only when that falls short of what is needed should one consider adding roles and other AT oriented code.

The final challenge: how to solve all problems TC (Technology Challenged) users may run into, is beyond me. Too many potential variables to be covered by standards. However, it still pays not to clutter up the source code and design with “helpful” solutions and thereby further complicate access to content and functionality on our sites for TC users.

ignore those boxes

“Thinking outside the box” is an oldfashioned phrase by now, and my headline says it better. As long as what should be visible on screens end up on those screens, it is well within the limits of visual web design.

Still many front-end coders who only think inward – container by container – and not outward when planning page layouts, which is a pity. The basics behind crossing edges works well in many cases, and can be used for any type of content. Same goes for “overshooting” elements, like the one on top of this page. Use your imagination to expand on those thoughts.
If nothing else; such minor visual design variations may create a sense of dynamics in web pages, and make bits of content stand out.

In addition: nothing prevents us from pushing content off screen, and, for instance, pull it back in as a response to user action. One only has to remember that users may turn off any “off screen” styling as part of browsers' normal functionality or extensions, and get it all into view when, and where, we did not intend it to be. Thorough testing of which method(s) that work best for the individual site and targeted audience, is adviced.

styling for various media

Styling for smartphone screens is often the starting point for today's web sites, and many cover the entire range of screen sizes with those styles and (maybe) a few @media queries. Simple, and well suited for text-rich content, for instance medium to long articles about whatever, with few or no images.

Styling for wide screens is what we used to call “the norm” back when screens ranged from 640×480 to 1280×1024 with 1/1 res/px, IE6 was the king on the hill, and phones was anything but smart. Basic layout usually a bit more complex than for smartphones, but not necessarily by much.

Depending on type of site – what type of content it has to carry – the “single styled” or the “multi styled” approach may be preferred. As end-user I have no problem with either, while as designer I prefer the latter whenever I can make it make sense – which is almost always.

Fluidity across the screen range is a logical “must” unless one wants to sort out and style up for every single screen size, screen orientation, and user preference a design may have to adapt to – a futile task if there ever was one.
A combo of responsive and adaptive web design will make the most out of screen areas and design in most cases, and is what I usually end up with.

I see no point in spending time on “making the right choice” when deciding what page/screen sizes switching between styles should take place. Some will always claim the chosen values are wrong anyway, and tomorrow or the day after “what is right” will have changed with the arrival of new smartphone models and other screen types/shapes/sizes/resolutions into some other “perfect” values. I have only changed switchover values 3-4 times over the last 10 years, so must have landed close enough for comfort from the start

Styling for print may take up valuable time better used for “real design-work”, and Gecko-based browsers still are not up to much in the print department. Chrome-based browsers are not too bad though, all things considered, and might be worth the time it takes to build basic print/PDF styling, and include a few more classes in the source code where needed in individual pages.

A bit disappointing that print styles are not fully supported across browser-land, but it is not for me to worry about. Those who build browsers have their priorities, and users (hopefully) choose browser(s) based on their own needs for work and leisure. At least I do…

a bundle of thoughts

Practical to have places to collect thoughts, as otherwise they may simply fly away and be forgotten. I also can not see any reasons for keeping these thoughts to myself and/or out of view, as there is nothing unique, harmful, or worthy of censorship, in them. Or at least so one might think … these days one never knows.

The way rules and regulations – standards and such, and personal views of the few – big players and what not, more and more are used to limit what we can and can not do in web design (as in all other walks of life). Just having thoughts of our own may end up as rare exceptions.
Copy and paste of entire paragraphs – unedited of course, followed by long series of “shall this” and “must that”, is taking over for creative thinking, while the software that is supposed to act as tools at both ends become more and more standardized and uniform – will only allow what conforms letter by letter to the afore mentioned rules and regulations.
May turn into a “very interesting” future in the digital world, and elsewhere, for some of us. Definitely worth an advance notice…

sincerely georg; sign

Hageland 12.may.2021
last rev: 12.may.2021

side notes.

issuing incomplete reports…

All reports are by definition incomplete. So also mine, which is why I may add some when and where I feel the need.

The old question: “who do you design for”, pops up on occasions. My answer used to be: “for whoever pays the bills, and then some”, but lately that has changed to: “for myself mostly, but also of course for whoever happens to pass by”.
In short: I'm retired, but we all need hobbies, and designing and populating web sites is one of mine.

As light and slick web page/site structures is no longer important to me personally, I can load my own sites with whatever I want to test, with no considerations for superfluous code load. FWIW: at the time of writing, the CSS behind this site is at least four times the amount needed for its regular visuals.
Some CSS code may only be used once, while others may be used many times on every page. Some code is included to test for particuler behaviors in particular browsers on “live” pages, and most of the tests that are included are not meant to be noticed as such by the average visitor.

This is a site in permanent transformation, but with only minor changes in overall visual design over time. I kind of like it as is, and cannot come up with a good enough reason to scrap it.
Evolution serves me better than revolutions, so the basics of what I designed a decade ago are still very much visible on screens of all sizes today. The entire “picture” is just more fine-tuned and flexible than back when only a limited number of browsers could render it somewhat correct.
Those were the days…

on the “unsafe” side…

Only what has been released onto the world wide web as parts of complete designs, can be fully tested. All else will remain isolated test cases or just untested ideas on someone's computer or mind, which is fine but does not tell all.
This is where I want to ignore all rules and recommendations about how things should be done, and check out what happens if/when whatever is combined with whatever else on any of the many levels that make up our web design toolbox.

“Playing it safe” is counter-productive in experimental web design, as nothing but ones expectations can be really broken. It is after all just packets of simple code served to be processed by software, not some form of delicate, precious and irreplaceable porcelain.

buggy browsers are no excuse…

No browser on the market is anywhere near being bug- and error-free, and blaming them for whatever weakness we find in our designs neither helps us nor the visitors to our “works of art”. I love counting pixels and checking lineups, but spending time on making everything add up as perfect as I'd like in fluid/responsive designs across the entire range of available devices, is as foolish now as when IE6 reigned on bulky and slow desk-top boxes – it simply can not be done.

As screen resolution becomes more fine grained, browsers adapt, and zoom levels vary, the +/-2 CSS px deviations from “pixel perfect” we may have had to accept a couple of decades ago, has shrinked to +/-1 CSS px or less.
Making it look right regardless of actual precision will have to do for a long time, and hacking lineups across browserland for those minor deviations we may have left is best described as “nonsensical”. Few if any visitors will notice and bother to check and compare our work across the wide range of software, hardware and screens we have today anyway.

As always: what browsers can't do browsers can't do, and that could be it on the subject. Except that; for a while now we have been able to “ask them” if they can handle this or that, or not. See: @supports.
Most browsers in use today respond correctly to @supports, and will let us use this or that code released in latest CSS standards while allowing us to serve something else and simpler to less capable browsers, without having to rely on less reliable methods or version hacking.

There are cases when @supports come handy, but for the average web site those cases will be few and far between. Also, the majority of end users will have their preferred browser set to auto-update, and at worst they won't be far behind latest versions in what they actually support.

everybody's talking…

There are always some who know better than you and me regarding this and that, for real or only in their own minds. Does not hurt to ask around if one is stuck with too few or too many options, as some out here may provide the right answer to get us unstuck. Still many functioning fora available for those of us who may be in need of help and advices from time to time.

Now and then I get unsolicited advices on how, and why, I should go about having one or more of my sites redone to meet whatever design ideas someone else inside or outside the relevant professions has come up with. I may respond with a “thanks, but no thanks”, if I feel like responding. However, in most cases I just ignore unrequested suggestions regarding such matters.
It makes sense to hear others out before choosing to ignore their advices and/or sales pitches, but to end up saying that those who want particular solutions should feel free to produce and present them on their own sites, is fair and respectful enough in my book.

The reasons presented by some for why I should change this or that, or rather hire others to “correct” it for me, are all over the place and for the most part not well suited for listing up since some may actually take them serious.
That some well-known big players in the digital world have recommended that this or that should be done this or that way, may sound convincing to some. The technical reasons are however often so poorly founded, that the most logical is to respond with a “so what‽”, and leave it there. Most well-known big players in any and all areas are (at best) best known for serving themselves rather than providing solutions.

inspiration…

I never made one of my discoveries through the process of rational thinking
— Albert Einstein

If everyone is thinking alike, then somebody isn't thinking.
— George S. Patton

Those who can, do. Those who can't, criticize.
— Robin Sharma

thoughts about site­wide opti­mi­za­tion

… when all depends on user pref­er­ences.