When I wrote about the idea of declarative design it really resonated with a lot of people.
I think that there’s a general feeling of frustration with the imperative approach to designing and developing—attempting to specify everything exactly up front. It just doesn’t scale. As Jason put it, the traditional web design process is fundamentally broken:
This is the worst of all worlds—a waterfall process creating dozens of artifacts, none of which accurately capture how the design will look and behave in the browser.
In theory, design systems could help overcome this problem; spend a lot of time up front getting a component to be correct and then it can be deployed quickly in all sorts of situations. But the word “correct” is doing a lot of work there.
If you’re approaching a design system with an imperative mindset then “correct” means “exact.” With this approach, precision is seen as valuable: precise spacing, precise numbers, precise pixels.
But if you’re approaching a design system with a declarative mindset, then “correct” means “resilient.” With this approach, flexibility is seen as valuable: flexible spacing, flexible ranges, flexible outputs.
These are two fundamentally different design approaches and yet the results of both would be described as a design system. The term “design system” is tricky enough to define as it is. This is one more layer of potential misunderstanding: one person says “design system” and means a collection of very precise, controlled, and exact components; another person says “design system” and means a predefined set of boundary conditions that can be used to generate components.
Personally, I think the word “system” is the important part of a design system. But all too often design systems are really collections rather than systems: a collection of pre-generated components rather than a system for generating components.
The systematic approach is at the heart of declarative design; setting up the rules and ratios in advance but leaving the detail of the final implementation to the browser at runtime.
Let me give an example of what I think is a declarative approach to a component. I’ll use the “hello world” of design system components—the humble button.
Two years ago I wrote about programming CSS to perform Sass colour functions. I described how CSS features like custom properties and calc() can be used to recreate mixins like darken() and lighten().
I showed some CSS for declaring the different colour elements of a button using hue, saturation and lightness encoded as custom properties. Here’s a CodePen with some examples of different buttons.
If these buttons were in an imperative design system, then the output would be the important part. The design system would supply the code needed to make those buttons exactly. If you need a different button, it would have to be added to the design system as a variation.
But in a declarative design system, the output isn’t as important as the underlying ruleset. In this case, there are rules like:
For the hover state of a button, the lightness of its background colour should dip by 5%.
In this kind of design system you can look at some examples to see the results of this rule in action. But those outputs are illustrative. They’re not the final word. If you don’t see the exact button you want, that’s okay; you’ve got the information you need to generate what you need and still stay within the pre-defined rules about, say, the hover state of buttons.
This seems like a more scalable approach to me. It also seems more empowering.
One of the hardest parts of embedding a design system within an organisation is getting people to adopt it. In my experience, nobody likes adopting something that’s being delivered from on-high as a pre-made sets of components. It’s meant to be helpful: “here, use this pre-made components to save time not reinventing the wheel”, but it can come across as overly controlling: “we don’t trust you to exercise good judgement so stick to these pre-made components.”
The declarative approach is less controlling: “here are pre-defined rules and guidelines to help you make components.” But this lack of precision comes at a cost. The people using the design system need to have the mindset—and the ability—to create the components they need from the systematic rules they’ve been provided.
My gut feeling is that the imperative mindset is a good match for most of today’s graphic design tools like Figma or Sketch. Those tools deal with precise numbers rather than ranges and rules.
The declarative mindset, on the other hand, increasingly feels like a good match for CSS. The language has evolved to allow rules to be set up through custom properties, calc(), clamp(), minmax(), and so on.
So, as always, there isn’t a right or wrong approach here. It all comes down to what’s most suitable for your organisation.
If your designers and developers have an imperative mindset and Figma files are considered the source of truth, than they would be better served by an imperative design system.
But if you’re lucky enough to have a team of design engineers that think in terms of HTML and CSS, then a declarative design system will be a force multiplier. A bicycle for the design engineering mind.
There’s a lot of emphasis put on decision-making: making sure you’re making the right decision; evaluating all the right factors before making a decision. But we rarely talk about revisiting decisions.
I think perhaps there’s a human tendency to treat past decisions as fixed. That’s certainly true when it comes to evaluating technology.
I’ve been guilty of this. I remember once chatting with Mark about something written in PHP—probably something I had written—and I made some remark to the effect of “I know PHP isn’t a great language…” Mark rightly called me on that. The language wasn’t great in the past but it has come on in leaps and bounds. My perception of the language, however, had not updated accordingly.
I try to keep that lesson in mind whenever I’m thinking about languages, tools and frameworks that I’ve investigated in the past but haven’t revisited in a while.
The carousel is like one of those on a game show that shows the prizes that can be won. The tool will sit on there until I think it’s gone through enough maturing to actually be a viable tool for me, the team I’m working with and the clients I’m working for.
Crucially a carousel is circular: tools and technologies come back around for re-evaluation. It’s all too easy to treat technologies as being on a one-way conveyer belt—once they’ve past in front of your eyes and you’ve weighed them up, that’s it; you never return to re-evaluate your decision.
This doesn’t need to be a never-ending process. At some point it becomes clear that some technologies really aren’t worth returning to:
It’s a really useful strategy because some tools stay on the carousel and then I take them off because they did in fact, turn out to be useless after all.
See, for example, anything related to cryptobollocks. It’s been well over a decade and blockchains remain a solution in search of problems. As Molly White put it, it’s not still the early days:
How long can it possibly be “early days”? How long do we need to wait before someone comes up with an actual application of blockchain technologies that isn’t a transparent attempt to retroactively justify a technology that is inefficient in every sense of the word? How much pollution must we justify pumping into our atmosphere while we wait to get out of the “early days” of proof-of-work blockchains?
Back to the web (the actual un-numbered World Wide Web)…
Nolan Lawson wrote an insightful article recently about how he senses that the balance has shifted away from single page apps. I’ve been sensing the same shift in the zeitgeist. That said, both Nolan and I keep an eye on how browsers are evolving and getting better all the time. If you weren’t aware of changes over the past few years, it would be easy to still think that single page apps offer some unique advantages that in fact no longer hold true. As Nolan wrote in a follow-up post:
My main point was: if the only reason you’re using an SPA is because “it makes navigations faster,” then maybe it’s time to re-evaluate that.
“You look around one day and realize the things you assumed were immutable constants of the universe have changed. The foundations of our reality are shifting beneath our feet. We live in a house built on sand.”
The day I discovered that Apple Maps is kind of good now
Perhaps the best example of a technology that warrants regular re-evaluation is the World Wide Web itself. Over the course of its existence it has been seemingly bettered by other more proprietary technologies.
Flash was better than the web. It had vector graphics, smooth animations, and streaming video when the web had nothing like it. But over time, the web caught up. Flash was the hare. The World Wide Web was the tortoise.
In more recent memory, the role of the hare has been played by native apps.
I remember talking to someone on the Twitter design team who was designing and building for multiple platforms. They were frustrated by the web. It just didn’t feel as fully-featured as iOS or Android. Their frustration was entirely justified …at the time. I wonder if they’ve revisited their judgement since then though.
In recent years in particular it feels like the web has come on in leaps and bounds: service workers, native JavaScript APIs, and an astonishing boost in what you can do with CSS. Most important of all, the interoperability between browsers is getting better and better. Universal support for new web standards arrives at a faster rate than ever before.
Alas, inertia is a very powerful force. Sticking with a past decision—even if it’s no longer the best choice—is easier than putting in the effort to re-evaluate everything again.
What’s the phrase? “Strong opinions, weakly held.” We’re very good at the first part and pretty bad at the second.
Just the other day I was chatting with one of my colleagues about an online service that’s available on the web and also as a native app. He was showing me the native app on his phone and said it’s not a great app.
“Why don’t you add the website to your phone?” I asked.
“You know,” he said. “The website’s going to be slow.”
He hadn’t tested this. But years of dealing with crappy websites on his phone in the past had trained him to think of the web as being inherently worse than native apps (even though there was nothing this particular service was doing that required any native functionality).
It has become a truism now. Native apps are better than the web.
And you know what? Once upon a time, that would’ve been true. But it hasn’t been true for quite some time …at least from a technical perspective.
But even if the technologies in browsers have reached parity with native apps, that won’t matter unless we can convince people to revisit their previously-formed beliefs.
The technologies are the easy bit. Getting people to re-evaluate their opinions about technologies? That’s the hard part.
This is really interesting. I hadn’t thought too much about the connection between design engineering and declarative design before now, but Jim’s post makes the overlap very clear indeed.
Cardigans are not entirely necessary for a show or a film to fit within the Cardigan sci-fi subgenre (although they certainly help). It’s the lack of polish in the world, it’s the absence of technological fetishism in the science fiction itself. The science or the tools or the spaceships do not sit at the heart of Cardigan sci-fi — it’s all about the people that wear the cardigans instead.
Another day, another transphobic opinion piece in The @Guardian.
This was the final straw. I’ve cancelled my account.
We had plans to do a one-off dConstruct anniversary event in 2020. It would’ve been five years since the event ran its ten year course from 2005 to 2015.
We all know what happened next. Not only was there no dConstruct in 2020, there were no live events at all. So we postponed the event. 2021 was slightly better than 2020 for live events, but still not safe enough for us.
Now, finally, the fifteenth anniversary edition of dConstruct is happening, um, on the seventeeth anniversary of dConstruct.
It’s all very confusing, I know. But this is the important bit:
dConstruct 2022 is happening on Friday, September 9th in the Duke of York’s picture house in Brighton.
Or, at least some tickets are available now. Quite a lot of eager folks bought tickets when the 2020 event was announced and those tickets are still good for this 2022 event …which is the 2020 event, but postponed by two years.
I’m currently putting the line-up together. I’m not revealing anything just yet, but trust me, you will want to be there.
If you haven’t been to a dConstruct event before, it’s kind of hard to describe. It’s not a practical hands-on conference where you learn design or development skills. It’s brain food. It’s about technology, culutre, design, society, the future …well, like I said, it’s kind of hard to describe. Have a poke around the dConstruct archive and listen to the audio from previous talks to get some idea of what might be in store.
Well, that’s not entirely true. There’s exactly one build tool involved. I’m using Sergey to include global elements—the header and footer—something that’s still not possible in HTML.
So it’s minium viable static site generation rather than actual static files. It’s still very hands-on though and I enjoy that a lot; editing HTML and CSS directly without intermediary tools.
When I update the site, it’s usually to add a new speaker to the line-up (well, not any more now that the line up is complete). That involves marking up their bio and talk description. I also create a couple of different sized versions of their headshot to use with srcset. And of course I write an alt attribute to accompany that image.
By the way, Jake has an excellent article on writing alt text that uses the specific example of a conference site. It raises some very thought-provoking questions.
I enjoy writing alt text. I recently described how I updated my posting interface here on my own site to put a textarea for alt text front and centre for my notes with photos. Since then I’ve been enjoying the creative challenge of writing useful—but also evocative—alt text.
People sitting around in the dappled sunshine on the green grass in a park with the distinctive Indian-inspired architecture of the Brighton Pavilion in the background, all under a clear blue sky.
Looking down on the crispy browned duck leg contrasting with the white beans, all with pieces of green fried herbs scattered throughout.
But when I was writing the alt text for the headshots on the UX London site, I started to feel a little disheartened. The more speakers were added to the line-up, the more I felt like I was repeating myself with the alt text. After a while they all seemed to be some variation on “This person looking at the camera, smiling” with maybe some detail on their hair or clothing.
A profile shot of Adekunle wearing a jacket and baseball cap standing outside.
The more speakers were added to the line-up, the harder I found it not to repeat myself. I wondered if this was all going to sound very same-y to anyone hearing them read aloud.
But then I realised, “Wait …these are kind of same-y images.”
By the very nature of the images—headshots of speakers—there wasn’t ever going to be that much visual variation. The experience of a sighted person looking at a page full of speakers is that after a while the images kind of blend together. So if the alt text also starts to sound a bit repetitive after a while, maybe that’s not such a bad thing. A screen reader user would be getting an equivalent experience.
That doesn’t mean it’s okay to have the samealt text for each image—they are all still different. But after I had that realisation I stopped being too hard on myself if I couldn’t come up with a completely new and original way to write the alt text.
And, I remind myself, writing alt text is like any other kind of writing. The more you do it, the better you get.
I think it was Jason who once told me that if you want to make someone’s life a misery, teach them about typography. After that they’ll be doomed to notice all the terrible type choices and kerning out there in the world. They won’t be able to unsee it. It’s like trying to unsee the arrow in the FedEx logo.
I think that Stewart Brand’s pace layers model is a similar kind of mind virus, albeit milder. Once you’ve been exposed to it, you start seeing in it in all kinds of systems.
Each layer is functionally different from the others and operates somewhat independently, but each layer influences and responds to the layers closest to it in a way that makes the whole system resilient.
Last month I sent out an edition of the Clearleft newsletter that was all about pace layers. I gathered together examples of people who have been infected with the pace-layer mindworm who were applying the same layered thinking to other areas:
Hey, wait a minute! If you put that list in reverse order it looks an awful lot like the pace-layers model with the slowest moving layer at the bottom and the fastest moving layer at the top. Perhaps there’s even room for an additional layer when patterns go into production:
Production
Patterns
Principles
Purpose
Your purpose should rarely—if ever—change. Your principles can change, but not too frequently. Your patterns need to change quite often. And what you’re actually putting out into production should be constantly updated.
As you travel from the most abstract layer—“purpose”—to the most concrete layer—“production”—the pace of change increases.
I can’t tell if I’m onto something here or if I’m just being apopheniac. Again.
Two thematically-linked talks have been added to day one. Emma Parnell will be talking about the work she did with NHS Digital on the booking service for Covid-19 vaccinations. Videha Sharma—an NHS surgeon!—will be talking about co-designing and prototyping in healthcare.
There’s a bunch of new additions to day three. Amir Ansari will be talking about design systems in an enterprise setting and there’ll be two different workshops on design systems from John Bevan and Julia Belling.
But don’t worry; if design systems aren’t your jam, you’ve got options. Also on day three, Alastair Somerville will be getting tactile in his workshop on sensory UX. And Trenton Moss will be sharing his mind-control tricks in his workshop, “How to sell in your work to anyone.”
You can peruse the full schedule at your leisure. But don’t wait too long before getting your tickets. Standard pricing ends in ten days on Friday, June 3rd.
And don’t forget, you get quite a discount when you buy five or more tickets at a time so bring the whole team. UX London should be your off-site.
Heard the sad news of Cathal Coughlan’s passing.
I’ll be spending the rest of the day revisiting a mispent youth moshing at Fatima Mansions gigs in Cork.
There’s a feeling in the air. A zeitgeist. SPAs are no longer the cool kids they once were 10 years ago.
And I think he’s right to frame the appeal of single page apps in terms of control (even if that control comes at the expense of performance and first-load user experience).
There was a week recently where I was out and about nearly every night.
One night, Jessica and I went to the cinema. There was a double bill of Alien and Aliens in the beautiful Duke of York’s picture house. We booked one of the comfy sofas on the balcony.
Then on the third night, we went to see Low playing in a church. Rich and Ben were there too.
It really felt like The Before Times. Of course in reality it wasn’t quite like old times. There’s always an awareness of relative risk. How crowded is the cinema likely to be? Will they have the doors open at The Jolly Brewer to improve the airflow? Will people at the Low gig comply with the band’s request to wear masks?
Still, in each case, I weighed the risk and decided the evening was worth it. If I caught Covid because of that cinematic double bill, or that tune-filled gathering, or that excellent gig, that price would be acceptable.
Mind you, I say that without having experienced the horribleness of having a nasty bout of coronavirus. And the prospect of long Covid is genuinely scary.
But there’s no doubt that the vaccines have changed the equation. There’s still plenty of risk but it’s on a different scale. The Situation isn’t over, but it has ratcheted down a notch to something more manageable.
Now with the weather starting to get nice, there’ll be more opportunities for safer outdoor gatherings. I’m here for it.
Actually, I’m not going to literally be here for all of it. I’m making travel plans to go and speak at European events—another positive signal of the changing situation. Soon I’ll be boarding the Eurostar to head to Amsterdam, and not long after I’ll be on the Eurostar again for a trip to Lille. And then of course there’s UX London at the end of June. With each gathering, there’s an inevitable sense of calculated risk, but there’s also a welcome sense of normality seeping back in.
Checked in at Haus On The Hill. Sunday roast — with Jessica
Glenn Davis of Project Cool’s Cool Site Of The Day from waaaay back in the day is writing his online memoirs.
Depending on when you got online, this will either bring back a lot of memories or sound like something from a different century (which technically it is).
When I was first putting that page together I had the name of each speaker followed by their job title and company. But when I stopped and thought about it—not to be too blunt—I realised “who cares?”. What matters is what they’ll be talking about.
You can peruse the schedule—which is almost complete now—to get a feel for how each day will flow.
But I’m not just excited about this year’s UX London because of the great talks and workshops. I’m also really, really excited at the prospect of gathering together—in person!—over the course of three days with my peers. That means meeting new and interesting people, but frankly, it’s going to be just as wonderful to hang out with my co-workers.
Clearleft has been a remote-only company for the past two years. We’ve still got our studio and people can go there if they like (but no pressure). It’s all gone better than I thought it would given how much of an in-person culture we had before the pandemic hit. But it does mean that it’s rare for us all to be together in the same place (if you don’t count Zoom as a place).
UX London is going to be like our off-site. Everyone from Clearleft is going to be there, regardless of whether “UX” or “design” appears in their job title. I know that the talks will resonate regardless. When I was putting the line-up together I made sure that all the talks would have general appeal, regardless of whether you were a researcher, a content designer, a product designer, a product manager, or anything else.
I’m guessing that the last two years have been, shall we say, interesting at your workplace too. And even if you’ve also been adapting well to remote work, I think you’ll agree that the value of having off-site gatherings has increased tenfold.
So do what we’re doing. Make UX London your off-site gathering. It’ll be a terrific three-day gathering in the sunshine in London from Tuesday, June 28th to Thursday, June 30th at the bright and airy Tobacco Dock.
If you need to convince your boss, I’ve supplied a list of reasons to attend. But you should get your tickets soon—standard pricing ends in just over two weeks on Friday, June 3rd. After that there’ll only be last-chance tickets available.
The idea that only Designers should Design strikes me as a kind of protective gatekeeping, not unlike the idea that only Priests know the word of God, and it should be spoken in Latin.
It turns out that in 2022, for a lot of apps, the dream of write once run anywhere has finally arrived.
Every year browsers and web technologies become more capable and more powerful. Every year there are more kinds of app that you can make cross platform.
So before you start your next project, why don’t you take a look at cross platform web apps. Maybe they aren’t right for your project, but maybe, like me, you’ll discover that you can code once and run everywhere. And I think that’s amazing.
… blogging is great isn’t it? You don’t have to write every week or every day. Just write when you have something you want to write about, and up it pops in RSS feed readers, or posted to Twitter, or whatever. Lovely.
Design Thinking didn’t change business at all, rather it changed Design into business, adopting its language, priorities and techniques. It sold out Design in an attempt to impress those in power, and in so doing lost its heart.
I added a “notes” section to this website eight years ago. I set it up so that notes could be syndicated to Twitter. Ever since then, that’s the only way I post to Twitter.
Something’s bothered me for a long time though. I initially thought that if I posted a photo, then the accompanying text would serve as a decription of the image. It could effectively act as the alt text for the image, I thought. But in practice it didn’t work out that way. The text was often a commentary on the image, which isn’t the same as a description of the contents.
I needed a way to store alt text for images. To make it more complicated, it was possible for one note to have multiple images. So even though a note was one line in my database, I somehow needed a separate string of text with the description of each image in a single note.
I eventually settled on using the file system instead of the database. The images themselves are stored in separate folders, so I figured I could have an accompanying alt.txt file in each folder.
This means I’m reading a file every time I need the alt text instead of reading from a database, which probably isn’t the most performant way of doing it, but it seems to be working okay.
In order to add the alt text to the image, I needed to update my posting interface. By default it’s a little textarea, followed by a file upload input, followed by a toggle (a checkbox under the hood) to choose whether or not to syndicate the note to Twitter.
The interface now updates automatically as soon as I use that input type="file" to choose any images for the note. Using the FileReader API, I show a preview of the selected images right after the file input.
Here’s the code if you ever need to do something similar. I’ve abstracted it somewhat in that gist—you should be able to drop it into any page that includes input type="file" accept="image/*" and it will automatically generate the previews.
I was pleasantly surprised at how easy this was. The FileReader API worked just as expected without any gotchas. I think I always assumed that this would be quite complex to do because once upon a time, it was quite complex (or impossible) to do. But now it’s wonderfully straightforward. Story of the web.
My own version of the script does a little bit more; it also generates another little textarea right after each image preview, which is where I write the accompanying alt text.
I’ve also updated my server-side script that handles the syndication to Twitter. I’m using the /media/metadata/create method to provide the alt text. But for some reason it’s not working. I can’t figure out why. I’ll keep working on it.
In the meantime, if you’re looking at an image I’ve posted on Twitter and you’re judging me for its lack of alt text, my apologies. But each tweet of mine includes a link back to the original note on this site and you will most definitely find the alt text for the image there.
I think, with the sheer volume of functionality available to us nowadays on the front-end, it can be easy to forget how powerful and strong the functionality is that we get right off shelf with HTML. Yes, you read that right, functionality.
Watching the livestream of @KLBouman introducing us to @EHTelescope’s image of Sagittarius A*—amazing!
This quote from the brilliant Molly White is about web3/blockchain/cryptobollocks but it applies to evaluating technology in general (like, say, JavaScript frameworks):
I firmly believe that companies first need to identify and research the problem they are trying to solve, and then select the right technology to do it. Those technologies may not be the latest buzzword, and they may not cause venture capitalists to come crawling out of the woodwork, but choosing technologies with that approach tends to be a lot more successful in the long run — at least, assuming the primary goal is to actually solve a problem rather than attract VC money.
Broadly, these are websites which are still web pages, not web applications; they’re pages of essentially static information, personal websites, blogs, and so on, but they are slightly dynamic. They might have a style selector at the top of each page, causing a cookie to be set, and the server to serve a different stylesheet on every subsequent page load.
This rings sadly true to me:
Suppose a company makes a webpage for looking up products by their model number. If this page were made in 2005, it would probably be a single PHP page. It doesn’t need a framework — it’s one SELECT query, that’s it. If this page were made in 2022, a conundrum will be faced: the company probably chose to use a statically generated website. The total number of products isn’t too large, so instead their developers stuff a gigantic JSON file of model numbers for every product made by the company on the website and add some client-side JavaScript to download and query it. This increases download sizes and makes things slower, but at least you didn’t have to spin up and maintain a new application server. This example is fictitious but I believe it to be representative.
Also, I never thought about “serverless” like this:
Recently we’ve seen the rise in popularity of AWS Lambda, a “functions as a service” provider. From my perspective this is literally a reinvention of CGI, except a) much more complicated for essentially the same functionality, b) with vendor lock-in, c) with a much more complex and bespoke deployment process which requires the use of special tools.
To be honest, I’m not all that convinced by Robin’s arguments here about overhauling the governance model at the World Wide Web Consortium (partly because the way he describes the current model sounds pretty okay to me). But I’m very interested in what he has to say in the broader philosophical sense about using values to solve problems:
A value is worth something if it’s there to help you when the rubber hits the road and starts hydroplaning. Sure, you’ll need a handful of high-level lofty values as reminders, if only because there’s always a vocal guy (it’s always a guy) who thinks it’s just outrageous to put people before profits. But mostly you want Values You Can Use.
That might be the best description I’ve come across yet for design principles: values you can use.
When we say that engineering is about trade-offs, we’re saying that engineers solve their hardest problems using values (which they call “heuristics” because everyone’s entitled to be fancy some). In implementing a system, you might need to decide between an option that provides people with the best experience, another that delivers the greatest value to the shareholders, and yet a third one that makes the control centre blinkenlights dance in the prettiest way.
If you think about design principles for any period of time, it inevitably gets very meta very quickly. You start thinking about what makes for good design principles. In other words, you start wondering if there are design principles for design principles.
I’ve written before about how I think good design principles should encode some level of prioritisation. The classic example is the HTML design principle called the priority of consitituencies:
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
It’s wonderfully practical!
I realised recently that there’s another set of design princples that put prioritisation front and centre—the Agile manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
And there’s this excellent explanation which could just as well apply to the priorty of constituencies:
That is, while there is value in the items on the right, we value the items on the left more.
Yes! That’s the spirit!
Ironically, the Agile manifesto also contains a section called principles behind the Agile manifesto which are …less good (at least they’re less good as design principles—they’re fine as hypotheses to be tested).
Agile is far from perfect. See, for example, Miriam Posner’s piece Agile and the Long Crisis of Software. But where Agile isn’t fulfilling its promise, I’d say it’s not because of its four design principles. If anything, I think the problems arise from organisations attempting to implement Agile without truly internalising the four principles.
Oh, and that’s another thing I like about the Agile manifesto as a set of design principles—the list of prioritised principles is mercifully short. Just four lines.
The result of adding more constraints means that the products have a broader appeal due to their simple interface. It reminds me of a Jeremy Keith talk I heard last month about programming languages like CSS which have a simple interface pattern: selector { property: value }. Simple enough anyone can learn. But simple doesn’t mean it’s simplistic, which gives me a lot to think about.
Irina Rusakova will be giving a talk on day one, the day that focuses on research. Her talk on designing with the autistic community is one I’m really looking forward to.
Also on day one, my friend and former Clearleftie Cennydd Bowles will be giving a workshop called “What could go wrong?” He literally wrote the book on ethical design.
Day two is all about creation. My co-worker Chris How will be speaking. “Nepotism!” you cry! But no, Chris is speaking because I had the chance to his talk—called “Unexpectedly obvious”—and I thought “that’s perfect for UX London!”:
Let him take you on a journey through time and across the globe sharing stories of designs that solve problems in elegant if unusual ways.
Also on day two, you’ve got two additional workshops. Lou Downe will be running a workshop on designing good services, and Giles Turnbull will be running a workshop called “Writing for people who hate writing.”
I love that title! Usually when I contact speakers I don’t necessarily have a specific talk or workshop in mind, but I knew that I wanted that particular workshop from Giles.
When I wrote to Giles to ask come and speak, I began by telling how much I enjoy his blog—I’m a long-time suscriber to his RSS feed. He responded and said that he also reads my blog—we’re blog buddies! (That’s a terrible term but there should be a word for people who “know” each other only through reading each other’s websites.)
Anyway, that’s another little treasure trove of speakers added to the UX London roster:
That’s nineteen speakers already and we’re not done yet—expect further speaker announcements soon. But don’t wait on those announcements before getting your ticket. Get yours now!
Some interesting thoughts from Tim here. What if CSS could “displace” design decisions from one area to another?
For example, a flexible line spacing value in one container could influence margins that surround the text block. That change in spaciousness may mean that nearby headings need size or spacing adjustments to stay feeling connected.
This feels like the complete opposite way that most people approach design systems—modular, componentised, and discrete—but very in-line with the way that CSS has been designed—interconnected, relational and cascading.
Platforms come and go. Buy a domain and set up a permanent space on the web where others to find you and link back to. I have no idea what I put on Myspace back in the day, but everything I’ve published on this site since 2008 is still accessible and the links still work.
A personal website is a digital homestead that you can improve, tinker with, and live in for years to come. It is a home for your thoughts, musings, opinions, trials, and happenings, built in a way that suits you.
I like this little prompt:
What do you wish you had found via Google today but didn’t? Write that.
This is kind of a Utopia lite: pop in your minimum and maximum font sizes along with a modular scale and it spits out some custom properties for clamp() declarations.
To complement her talk at Beyond Tellerrand, Stephanie goes through some of the powerful CSS features that enable intrinsic web design. These are all great tools for the declarative design approach I was talking about:
This is a great case study of switching from a framework mindset to native browser technologies.
Though this is quite specific to Jack’s own situation, I do feel like there’s something in the air here. The native browser features are now powerful and stable enough to make the framework approach feel outdated.
And if you do want to use third-party dependencies, Jack makes a great case for choosing smaller single-responsibility helpers rather than monolithic frameworks.
Replacing lit-html would be an undertaking but much less so than replacing React: it’s used in our codebase purely for having our components (re)-render HTML. Replacing lit-html would still mean that we can keep our business logic, ultimately maintaining the value they provide to end-users. Lit-Html is one small Lego brick in our system, React (or Angular, or similar) is the entire box.
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.
A while back I wrote a blog post called Web Audio API weirdness on iOS. I described a bug in Mobile Safari along with a hacky fix. I finished by saying:
If you ever find yourself getting weird but inconsistent behaviour on iOS using the Web Audio API, this nasty little hack could help.
Again, this warmed the cockles of my heart. Bugblogging is worth doing just for the reward of that feeling.
There’s a similar kind of blog post where, instead of writing about a bug, you write about a particular technique. In one way, this is the opposite of bugblogging because you’re writing about things working exactly as they should. But these posts have a similar feeling to bugblogging because they also result in a warm glow when someone finds them useful.
Here are some recent examples of these kinds of posts—tipblogging?—that I’ve found useful:
Twitter is a chatroom, and the problem that Twitter really solved was the discoverability problem. The internet is a big place, and it is shockingly hard to otherwise find people whose thoughts you want to read more of, whether those thoughts are tweets, articles, or research papers. The thing is, I’m not really sure that Twitter ever realized that this is the problem they solved, that this is where their core value lies. Twitter kept experimenting with algorithms and site layouts and Moments and other features to try to foist more discoverability onto the users without realizing that their users were discovering with the platform quite adeptly already. Twitter kept trying to amplify the signal without understanding that what users needed was better tools to cut down the noise.
Twitter, like many technology companies, fell into the classical trap by thinking that they, the technologists, were the innovators. Technologists today are almost never innovators, but rather plumbers who build pipelines to move ideas in the form of data back and forth with varying efficacy. Users are innovators, and its users that made Twitter unique.
How is all this social? It’s just slow social. If you want to respond to me, publish something linking to what I said. If I want to respond to you, I publish something linking to what you wrote. Old school. Good school. It’s high-effort, but I think the required effort is a positive thing for a social network. Forces you to think more.
I am extremely confident that pretty much any HTML I write today will render the same way in 50 years’ time. How confident am I that my CSS will work correctly? Mmmm…70%. Hand-written JavaScript? Way less, maybe 50%. A third-party service I install on a website or link to? 0% confident. Heck, I’m doubtful that any third-party service will survive until next year, let alone 50 years from now.
