I wish more publishers and services took this approach to evaluating technology:
We scrutinize third-party services before including them in our articles or elsewhere on our site. Many include trackers or analytics that would collect data on our readers. These may be standard across much of the web, but we don’t use them.
A lovely bit of real-time data visualisation from Robin:
It’s a personal project created at home in Wales with an aim to explore and visualise renewable energy systems. Specifically, it aims to visualise live generation from renewable energy systems around Great Britain and to show where that generation is physically coming from.
Check out the demo that Rich has put together to go with Amelia’s proposed syntax.
So then the question becomes: how do you most effectively communicate designs, to facilitate the best discussions about those designs? My answer is: lots of little prototypes built with HTML, CSS, and JavaScript.
Rich explains what text-wrap:balance does …and what it doesn’t.
I did not know about box-decoration-break—sounds like a game-changer for text effects that wrap onto multiple lines.
If you’ve made a computer do something - anything - in a logical fashion, you’re a programmer. Scratch? Programmer! CSS? Programmer? Conditional formatting in Excel? Programmer!
I often use the word quality when referring to apps, products and services I hold in a high regard but another word that often comes up in this context is craft. Craft, as in something that is handcrafted where something someone spent a lot of time on and maybe even embedded their own personal touches and personality in it. Often something handcrafted feels more premium.
A free PDF with five articles:
Three of those authors spoke at this year’s UX London!
Y’know, I started reading this great piece by Claire L. Evans thinking about its connections to systems thinking, but I ended up thinking more about prototyping. And microbes.
Dave rounds up some of the acronymtastic ways of scoping your CSS now that we’ve got a whole new toolkit at our disposal.
If your goal is to reduce specificity, new native CSS tools make reducing specificity a lot easier. You can author your CSS with near-zero specificity and even control the order in which your rules cascade.
I’m 100% convinced that working demo-to-demo is the secret formula to making successful creative products.
A stylesheet to imitate paper—perfect for low-fidelity prototypes that you want to test.
A fascinating and inspiring meditation on aerodynamics.
We’re all LARPing on LinkedIn.
We noticed a trend: students who pick a UI framework like Bootstrap or Material UI get off the ground quickly and make rapid progress in the first few days. But as time goes on, they get bogged down. The daylight grows between what they need, and what the component library provides. And they wind up spending so much time trying to bend the components into the right shape.
I remember one student spent a whole afternoon trying to modify the masthead from a CSS framework to support their navigation. In the end, they decided to scrap the third-party component, and they built an alternative themselves in 10 minutes.
This tracks with my experience. These kinds of frameworks don’t save time; they defer it.
The one situation where that works well, as Josh also points out, is prototyping.
If the goal is to quickly get something up and running, and you don’t need the UI to be 100% professional, I do think it can be a bit of a time-saver to quickly drop in a bunch of third-party components.
City of Women encourages Londoners to take a second glance at places we might once have taken for granted by reimagining the iconic Underground map.
I love everything about this …except that there’s no Rosalind Franklin station.
Rather than thinking, “how do I combine a bunch of disparate content, templates, and tooling into a functioning website?”, you might think “how do I start at a functioning website with content and then use templates and build tooling to enhance it?”
I think Jim is onto something here. The more dependencies you have in your build process, the likelier it is that over time one of them will become a single point of failure. A progressive enhancement approach to build tools means you’d still be able to launch your site (even if it’s not in its ideal state).
I want to be able to view, edit, and if need be ship a website, even if the build process fails. In essence, if the build does fail I can still take all the source files, put them on a server, and the website remains functional (however crude).
It sometimes feels like we end up testing the limitations of our tools rather than the content and design itself.
What Benjamin found—and I heartily agree—is that HTML prototypes give you the most bang for your buck:
At the point of preparing for usability testing, it seemed ludicrous to move to any prototyping material other than the one we were already building in. The bedrock of the web: HTML, CSS and Javascript.