Sensible advice from Chris:
So what’s the best rendering method? Whatever works best for you, but perhaps a hierarchy like this makes some general sense:
- Static HTML as much as you can
- Edge functions over static HTML so you can do whatever dynamic things
- Server generated HTML what you have to after that
- Client-side render only what you absolutely have to
This sounds like seamful design:
How to enable not users but adaptors? How can people move from using a product, to understanding how it hangs together and making their own changes? How do you design products with, metaphorically, screws not nails?
An ode to the network architecture of the internet:
I believe the DNA of resiliency built into the network manifests itself in the building blocks of what’s transmitted over the network. The next time somebody calls HTML or CSS dumb, think about that line again:
That simplicity, almost an intentional brainlessness…is a key to its adaptability.
It’s not a bug. It’s a feature.
Yes! I wish more web developers would take cues from the very medium they’re building atop of.
2010 was quite a year:
And exactly three weeks after Jeremy Keith’s HTML5 For Web Designers was first published, “Responsive Web Design” went live in A List Apart.
Nothing’s been quite the same since.
I remember being at that An Event Apart in Seattle where Ethan first unveiled the phrase and marvelling at how well everything just clicked into place, perfectly capturing the zeitgeist. I was in. 100%.
Trys describes the backend architecture of the excellent Sofa Conf website. In short, it’s a Jamstack dream: all of the convenience and familiarity of using a database-driven CMS (Craft), combined with all the speed and resilience of using a static site generator (Eleventy).
I love the fact that anyone on the Clearleft events team can push to production with a Slack message.
I also love that the site is Lighthousetastically fast.
The cloud gives us collaboration, but old-fashioned apps give us ownership. Can’t we have the best of both worlds?
We would like both the convenient cross-device access and real-time collaboration provided by cloud apps, and also the personal ownership of your own data embodied by “old-fashioned” software.
This is a very in-depth look at the mindset and the challenges involved in building truly local-first software—something that Tantek has also been thinking about.
Mike sees the church of JS-first ignoring the lessons to be learned from the years of experience accumulated by CSS practitioners.
As the responsibilities of front-end developers have become more broad, some might consider the conventions outlined here to be not worth following. I’ve seen teams spend weeks planning the right combination of framework, build tools, workflows and patterns only to give zero consideration to the way they architect UI components. It’s often considered the last step in the process and not worthy of the same level of consideration.
It’s important! I’ve seen well-planned project fail or go well over budget because the UI architecture was poorly planned and became un-maintainable as the project grew.
Through planning and architectural design, Le Corbusier hoped to create a scientifically rational and comprehensive solution to urban problems in a way that would both promote democracy and quality of life. For him, the factory production process applied to high-rise buildings with prefabricated and standardized components is the most modern and egalitarian of urban forms.
Something something top-down design systems.
We’ve industrialized design and are relegated to squeezing efficiencies out of it through our design systems. All CSS changes must now have a business value and user story ticket attached to it.
Dave follows on from my post about design systems and automation.
At the same time, I have seen first hand how design systems can yield improvements in accessibility, performance, and shared knowledge across a willing team. I’ve seen them illuminate problems in design and code. I’ve seen them speed up design and development allowing teams to build, share, and validate prototypes or A/B tests before undergoing costly guesswork in production. There’s value in these tools, these processes.
Here’s the video of the opening talk I gave at New Adventures earlier this year. I think it’s pretty darn good!
An online documentary series featuring interviews with smart people about the changing role of design.
As technology becomes more complex and opaque, how will we as designers understand its potential, do hands-on work, translate it into forms people can understand and use, and lead meaningful conversations with manufacturers and policymakers about its downstream implications? We are entering a new technology landscape shaped by artificial intelligence, advanced robotics and synthetic biology.
So far there’s Kevin Slavin, Molly Wright Steenson, and Alexandra Daisy Ginsberg, with more to come from the likes of Matt Jones, Anab Jain, Dan Hill, and many, many more.
53% of mobile visits leave a page that takes longer than 3 seconds to load. That means that a large number of visitors probably abandoned these sites because they were staring at a blank screen for 3 seconds, said “fuck it,” and left approximately half way before the page showed up. The fact that the next page interaction would have been quicker—assuming all the JS files even downloaded correctly in the first attempt—doesn’t amount to much if they didn’t stick around for the first page to load. What was gained by putting the business logic in the front end in this scenario?
If there are no specific reasons to build a single-page application, I will go with a traditional server-rendered architecture every day of the week.
Procedurally generated medieval town plans. Pick a size and then have some fun with the “warp” option.
I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.
Fascinating snippets of information about some of the most interesting buildings in Brighton.
(The website was made by Lydia and Tash as a project for Code First: Girls)
It is very disheartening to read misinformation like this:
A progressive web app is an enhanced version of a Single Page App (SPA) with a native app feel.
To quote from The Last Jedi, “Impressive. Everything you just said in that sentence is wrong.”
But once you get over that bit of misinformation at the start, the rest of this article is a good run-down of planning and building a progressive web app using one possible architectural choice—the app shell model. Other choices are available.
What these brands are taking from web-brutalism — and truly, we should all be learning something here — is that User-centered design doesn’t need to be monopolized by the same colors, same buttons, same photography and even same copy you see in pretty much every single website or product.
The transcript of a terrific talk by Paul, calling for a more thoughtful, questioning approach to digital design. It covers the issues I’ve raised about Booking.com’s dark patterns and a post I linked to a while back about the shifting priorities of designers working at scale.
Drawing inspiration from architectural practice, its successes and failures, I question the role of design in a world being eaten by software. When the prevailing technocratic culture permits the creation of products that undermine and exploit users, who will protect citizens within the digital spaces they now inhabit?
Cameron contrasts Syd Mead with Frank Lloyd Wright.
Mastery of materials is a valuable thing to have. It will help you build what’s needed now and forge ahead into the near future. But vision is also valuable – it helps inspire and drive teams, and lays out a longer term future that can alter the path of humanity. What I take from the futurists and the realists is that there’s a place for every person and every process; what you need to do is find your own place, get comfortable, and own it.