On Big Picture Thinking in Web Development
Published on NovĀ 22, 2017 (updated FebĀ 5, 2024), filed under development, performance, maintainability, accessibility, design (feed). (Share this on Mastodon orĀ Bluesky?)
As a former Googler Iāve been exposed to big thinking, by, as Larry liked to say, moon shots. As a student of Gary Kellerās The ONE Thing, Iām trying to learn more about big thinking and clear focus where I can (it wasnāt always like this, and Iāll share more about my dilemma). But here and humbly I want to briefly talk about big picture thinking. About thinking outside the box. In tech. Using five examples.
Contents
Selector Performance
I much like this example, I had also mentioned it in What We Should Teach Up-and-Coming Developers.
Years ago, performance evangelistsānotably Steveāstudied the performance of selectors and found that the universal selector is most expensive performance-wise. The instant response from our community was to get a collective nervous breakdown and YouTube-style troll anyone using universal selectors and: make everyone write more complicated, less understandable CSS code. Steve hadnāt suggested to do thatāhe had simply done important pioneering workābut the thinking became āslower = bad,ā without noting how no one had style sheets so big as to even notice an effect of poor selectors. I still donāt want to pin this on anyone, but rather say that we, as the more experienced members of our field, should have probably stepped up sooner and more vocally saying that yes, selector performance differs, but no, donāt change anything, donāt sacrifice good CSS engineering practices for imperceptible performance gains. Big picture thinking.
Web performance can impact how we write CSS, and as such itās useful to investigate what impact that is exactly.
Maintainability
Maintenance is important and so do we need to make sure that code is actually maintainable. In the āfirst paradigmā of web development, maintainability hinges on lean HTML and strict separation of concerns. But being that strict, as the maintainability specialist has a tendency to be, shifts a lot of complexity and responsibility and also the maintenance burden into the neighboring codeānotably, into style sheets and scriptsāand as such has to be gauged carefully, demonstrating contextual, big picture thinking. Example? An extreme (but nowadays more palatable) case is that of avoiding any use of IDs and classes in the markup. With ever more powerful and better supported selectors, this has definitely become a viable option, but the simplicity this can bring on the HTML end does make for a superb (but now less drastic) increase of complexity on the CSS end.
Maintainability is asymmetrical in parts, as such the effects of good maintainability may be felt somewhere else, and for that reason we need to carefully assess the effects of maintainability recommendations before making them.
Design Consistency
I havenāt worked with any people lately who would have pushed for, even talked about āpixel-perfectā implementations of websites. āPixel-perfectā used to refer to a websiteās equal appearance in different browsers, it was briefly discussed in the field under responsiveness considerations, and it still has a place in coding up designer mocks. Here a website or app is pixel-perfect when it completely matches the designerās screens and ideas. Big picture thinking in a sense of understanding related fields typically means one thing here: that consistency is both the designerās and the developerās friend. Consistency is good from a usability point of view, and good from a code complexity point of view. When pixel-perfect means that a button that accidentally sits five pixels lower on one mock than on the other has to also be coded this way, instead of achieving better design consistency and simpler code by granting buttons the same placement, then somethingās wrong.
Web design affects how we write HTML and CSS, and as such itās useful to understand how HTML and CSS are written when designing websites, at least when accepting and approving them for release.
Accessibility
Accessibility takes up a special status for not only is there a moral side to it but also a legal one; and with that lopsidedness (an observation, no judgment), thereās no evident counter-weight in terms of assessing accessibility norms and techniques from the view of their effect on other disciplines in techāre: big picture thinking. Accessibility has been super-charged so that often, only technical unfeasibility is taken as an argument. Again, I wish to only note the particular situation here, though I believe that weāve seen large effects on the way we code because of it. The end may justify the means (just once), but the accessibility end here is, particular.
Accessibility is critical to allow everyone access to information and services but it affects many parts in professional web design, from content to design to code; as such, while we want to make accessibility an absolute priority in our work, we need a solid understanding of these effects for the accessibility norms and methods we put in place.
Vision
Vision, here, refers to our idea of web development. If we have one, because āget it doneā or āmake it workā are not visions; they are mere pragmatism. Iām not sure I want to try a bulletproof definition of āvisionā here but a vision would need to provide long-term direction. The idea to build websites of high quality, to build websites that last, to build websites that have a low chance of unnecessary changes seems useful to me, for example; and it may allow us to see how it cannot mean to overshadow everything else, because one of the first things someone technical whoās reluctant to change (for the higher goal and vision of simplicity and stability) experiences is a particular skepticism around design changes (Iāve been there). What we may observe then is an odd twist of someone actually having a āvisionā but working in a silo, of: not seeing the big picture.
Our ideas and visions of web development inevitably shape more than just code, and as such they require attention not to impair specific parts of our work and, with that, the greater whole again.
ā§ I wish these five examples give an impression for how very different issues, generic and specific, can all reach beyond their perimeter. Yet although Iāve set them up to sound problematic as to require not only a good understanding of the whole range and field of web development, but also a delicate, diplomatic sense for priority and compromise, I donāt demand we always display that sense, that web development was now all about diplomacy, consensus, compromise. No: In my view things start with awareness, and an awareness that our decisions may bleed out into other areas of our work, as well as a curiosity about the effects and alternatives sound like quite a nice accomplishment, too. Web development is an increasingly powerful and increasingly interlinked field, and I believe we can appreciate the possibilities and responsibilities that means.
Iām writing about higher level aspects of web development and design quite regularly. Why not check the archives or one of my books on web development?
About Me
Iām Jens (long: Jens Oliver Meiert), and Iām a web developer, manager, and author. Iāve been working as a technical lead and engineering manager for companies youāve never heard of and companies you use every day, Iām an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for OāReilly and Frontend Dogma.
I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)