brutalism
177 Huntington
Guidelines for Brutalist Web Design
An Article by David Bryant Copeland- Content is readable on all reasonable screens and devices.
- Only hyperlinks and buttons respond to clicks.
- Hyperlinks are underlined and buttons look like buttons.
- The back button works as expected.
- View content by scrolling.
- Decoration when needed and no unrelated content.
- Performance is a feature.
This page is a truly naked, brutalist html quine
An Article by Leon BambrickI decided to make a truly naked, brutalist html page, that is itself a quine. And this page is it.
Viewing the source of this page should reveal a page identical to the page you are now seeing. Nothing is hidden. It's a true "What you see is what you get."
What On Earth is a Brutalist Website?
An ArticleSome of the web’s early richness has gradually been getting lost in a sea of landing pages, hero images, sans-serifs, and calls-to-action. “Web brutalism” is a valid reminder that there is still a world of possibilities out there, if we are bold enough to break free of our UI kits and stock photos.
Web Brutalism, seamfulness, and notion
An Essay by Brandon DornHow a tool for sensemaking reconciles two distinct software design ideologies.
- Seamful vs. seamless
- Reveling in infrastructure
- The brilliance of notion
- How our understanding is working
The split personality of brutalist web development
An ArticleWhen brutalist web design isn’t going all in on rationalism and functionality, it’s laughing in the face of rationalism and functionality. All clear?
The term has grown to encompass approaches that are in many senses at odds with each other. Indeed, Pascal Deville, who founded the Brutalist Websites directory after coining the term in 2014, thinks the style has splintered into three micro-stylistics:
- Purists,
- UX minimalists,
- Anti-ists (or artists).
Recognizing Constraints
Super Nintendo games were the flavor of the decade when I was younger, and there’s no better example of building incredible things within comparably meager constraints. Developers on SNES titles were limited to, among other things:
- 16-bit color.
- 8 channel stereo output.
- Cartridges with storage capacities measured in megabits, not megabytes.
- Limited 3D rendering capabilities on select titles which embedded a special chip in the cartridge.
Despite these constraints, game developers cranked out incredible and memorable titles that will endure beyond our lifetimes. Yet, the constraints SNES developers faced were static. You had a single platform with a single set of capabilities. If you could stay within those capabilities and maximize their potential, your game could be played—and adored—by anyone with an SNES console.
PC games, on the other hand, had to be developed within a more flexible set of constraints. I remember one of my first PC games had its range of system requirements displayed on the side of the box:
- Have at least a 386 processor—but Pentium is preferred.
- Ad Lib or PC speaker supported—but Sound Blaster is best.
- Show up to the party with at least 4 megabytes of RAM—but more is better.