Paul Parks has released PUDL, the Pleasantly Usable Design Language, which says that flat design started as a fair rebellion against skeuomorphism1 and then went too far: it stripped out the cues that tell a user what can be pressed, what can be typed into, and what can only be read. PUDL's answer is one visual representation per affordance2, so that someone who learned how to use something in one application can open the next one and know how to use it on sight. It's a stylesheet, a theme script, a font, and a handful of optional scripts. There's no framework, no build phase, and every project that uses it carries its own copy.

It's at 0.37.0 as of this writing (with a very rapid early release cycle), under Apache 2.0. The name rhymes with "puddle," which Parks calls a joke at its own expense3: a puddle is the flattest thing there is, and PUDL insists that everything a user can touch has depth.

The Language

The rules are short, and thus they're relatively easy to follow. Elevation signals interactivity: a raised control can be pressed, a sunken field takes input, and anything flat is there to be read. The element categories stay separate, so a button never borrows a link's appearance and a tab never borrows a button's. Color is never the only signal4; every state also carries a glyph, a position, or an elevation. State is marked with the ARIA attribute that states it, so the eye and a screen reader are told the same thing. Each visible context gets one primary button. Links are underlined. Numerals are tabular wherever a number is data. Dialogs are native <dialog> elements the server renders, and a page never falls back on confirm(). Glyphs are drawn from the stylesheet, not typed, so they never turn into somebody's color emoji.

That's it. That's the whole language. A project could adopt every one of those rules against a stylesheet it already has, and it would probably be a better stylesheet for it, really. The reference page shows what they look like applied, in both provided themes.

The Heritage

If those rules sound familiar - or even logical - they should. IBM published Common User Access in 1987 as part of Systems Application Architecture, and it's why a menu bar reads File, Edit, View from left to right, the reason Alt-F opens the file menu, and the reason a dialog's buttons sit where they sit. OS/2 and Windows adopted it, and every desktop toolkit since has inherited a lot of CUA whether it admits it or not. CUA's premise was that a user should learn an application once and carry that knowledge to the next one, that every control should be reachable from the keyboard, and that the same visual element should mean the same thing everywhere.

PUDL's README says its grammar is modeled on desktop toolkits, GTK in particular, and doesn't mention CUA. It's not CUA, not formally or informally; CUA is a concrete specification with page numbers, and PUDL is nine rules and a stylesheet. CUA and PUDL are not the same... but the concepts are similar and are similarly useful. "Learned it in one application, knows the next one on sight" is CUA's mission statement with the nouns changed. The arrow keys move a window and Shift with them resizes it; ESC closes what's in front and never a top-level window; Home and End go to the limits of a divider. None of that is web convention. It's the desktop coming back through the browser, on purpose.

The Toolkit

It's funny, sort of: PUDL is a "design language," but PUDL's distribution is mostly a toolkit5.

Floating windows keep their entire arrangement in the query string: which windows are open, which one is on top, which are minimized, and where each one sits as fractions of the layer. A page with three windows open can be bookmarked, reloaded, and handed to someone else, and Back steps through arrangements rather than pages. The server renders the windows the URL names, so they appear without script; the script adds dragging, snapping, and the keyboard. Every window button is a real link to the state that pressing it produces.

Regions swap only the part of a page that a navigation changed. A category tab or a filter fetches the target page, replaces the regions it has counterparts for, and leaves the open windows exactly where they were, scroll positions included. If the fetch fails or the target page doesn't match, the browser navigates the way it always did, so the worst case is an ordinary page load.

Applets - executable code in portions of the window - get a host handshake so that one script runs unchanged in a page of its own, embedded in an article, or inside a window, and knows which of the three it landed in without knowing anything else about its host. Menus can be summoned by a single key, with a filter that ends in an address, which makes a launcher a go-to palette that always resolves to a URL. The master-detail layout collapses to one pane at a time by container query rather than viewport, so it behaves the same inside a narrow floating window as it does on a phone.

All of it is server-rendered, all of it works with script off, and all of it treats the address as the state. That last part is the design decision the rest hangs on, and it's the reason the whole thing can be a stylesheet and a few scripts instead of a framework.

In practice, it's really easy to build and work with, as long as the paradigm fits the application you're targeting.

The nine rules go anywhere. They're prescriptions about what raised, sunken, and flat mean, and any project on any stack can take them. The windows, regions, and applets are a commitment to a particular kind of application: server-rendered, addressable, no client framework, with the URL as the source of truth. That's a good commitment - URLs end up being concrete for the application representation - but it is a commitment, and a reader should know that they can take the language without making the commitment itself.6

In Practice

There's now a BCN front end on PUDL, a feature-complete peer of the main site, currently built with NextJS, talking to the same backend API. It... works. For administration functions, where BCN needs to act like an application, it's highly functional, more than the "news-site" focus of the NextJS implementation; most of the administration is now done with the PUDL implementation, because the desktop-toolkit structure works quite well.

Now What?

The puddle joke turns out to be the thesis. PUDL insists that everything you can touch has depth: anything flat is there to be read. That's a rule for reading surfaces as much as for application surfaces, and it costs nothing to adopt, but it's a commitment to design principles that can feel dated for some users; on mobile it's incredibly functional, but in desktop browsers, it feels... archaic, because material design and other such approaches are more the order of the day for many designers.

And that's sort of the point: for better or for worse, design largely follows the crowd, madding or not, and if the crowd prefers material designs that hide functionality behind emojis or colors or special sigils, well, users do expect the web to work in common fashion across many applications; it's why plain HTML pages work but anyone reading pages rendered without extensive styles is left with vague unease that nobody actually cared about design.

But with that said, CUA still lives today in every major graphical toolkit, even if it's hidden or disguised with blinking lights and liquid glass, and if your application behaves like an application as opposed to like a page, PUDL turns out to represent that structure quite well, so far.

  1. Skeuomorphism7, a word I learned from this project, says that a derived object should retain ornamental design cues from structures present in the original, so a "door analog" needs to act like what users think of as a door, or else they'll wonder how to make it do door-like things.

    ↩

  2. An affordance here is "what you can do," not "what's on the page."

    ↩

  3. If you've read any of Your Humble Author's work, you'll surely be aware of how much said author appreciates jokes at one's own expense. It's the best kind of dad-joke there is, one with no victim but the one telling the joke, and it's undervalued.

    ↩

  4. I personally struggle to differentiate common color sets, so visual design elements that cater to physical design are quite valuable.

    ↩

  5. One of the joys of development right now is how freaking rapidly things can turn over. It used to be "release early, release often," but what we thought of as "often" even as recently as three years ago looks glacial sometimes. Since this draft was written, a much more formal pudl-spec was created, so there's an actual "language" for the "pleasantly usable design language" now.

    ↩

  6. PUDL has a lineage: the Tela Design Language came first, then Andoneer and Planning Fit design languages extended it, and the second version of Andoneer moved the control vocabulary to a grammar modeled on desktop toolkits, GTK in particular. PUDL is that second version, separated out so any project can share it. He’s using it on https://parkscomputing.com and addressing issues found from live adoption. That history is also why it feels like a toolkit rather than just a “design language”: it was extracted from an application, and the language was written down afterward.

    ↩

  7. I like PUDL, if it's not clear, but I'd like PUDL because it taught me a new word I was unaware of even if there was no other reason to admire the project. And yes, I am well aware that a footnote tied to another footnote is "bad style." Talk to my editor.

    ↩