Just like brand values, mission statements, or vision decks, design principles can be generic and provide little to no actual value.
But used correctly, design principles help you make decisions resulting in a superior experience.
New principle: Do not design around third-party tools unless it actually breaks the Web · Issue #335 · w3ctag/design-principles
There’s a really interesting discussion here, kicked off by Lea, about balancing long-term standards with short-term pragmatism. Specifically, it’s about naming things.
Naming things is hard. Naming things in standards, doubly so.
Applying Postel’s Law to relationships:
I aspire to be conservative in what and how I share (i.e., avoid drama) while understanding that other people will say all sorts of unmindful things.
This looks like an excellent proposal for agreement around discussing privacy on the web.
Its fiduciary duties include:
- Duty of Protection
- Duty of Discretion
- Duty of Honesty
- Duty of Loyalty
I was really chuffed to see some posts of mine referenced in this rather excellent piece about design principles for front-end development.
Principles behind the design of web APIs:
- Put user needs first (Priority of Constituencies)
- It should be safe to visit a web page
- Trusted user interface should be trustworthy
- Ask users for meaningful consent when appropriate
- Support the full range of devices and platforms (Media Independence)
I should add these to my collection.
RFC 8890 maybe the closest thing we’ve got to a Hippocratic oath right now.
A community that agrees to principles that are informed by shared values can use them to navigate hard decisions.
Many discussions influenced this document, both inside and outside of the IETF and IAB. In particular, Edward Snowden’s comments regarding the priority of end users at IETF 93 and the HTML5 Priority of Constituencies were both influential.
It all started at Patterns Day…
(Note: you’ll probably need to use Reader mode to avoid taxing your eyes reading this—the colour contrast …doesn’t.)
“Serverless”, is a buzzword. We can’t seem to agree on what it actaully means, so it ends up meaning nothing at all. Much like “cloud” or “dynamic” or “synergy”. You just wait for the right time in a meeting to drop it, walk to the board and draw a Venn Diagram, and then just sit back and wait for your well-deserved promotion.
That’s very true, and I do not like the term “serverless” for the rather obvious reason that it’s all about servers (someone else’s servers, that is). But these three principles are handy for figuring out if you’re building with in a serverlessy kind of way:
- You have no knowledge of the underlying system where your code runs.
- Scaling is an intrinsic attribute of the technology; so much so that it just happens automatically.
- You only pay for what you use.
Abstraction; scale; consumption.
Don’t build more JS than you can maintain over the long term. If you’re going to be building something for a long time, make sure what you are building will grow with you. Make sure you don’t depend on other people’s work too much, lest you want to keep refactoring your code when the framework you picked goes out of style.
Here’s the video of the talk I gave at State Of The Browser last year. The audio is a bit out of sync with the video.
The talk is called The Web Is Agreement. It’s ostensibly about web standards, but I used that as a jumping off point for talking about life, the universe, and everything.
I enjoyed giving this talk, but I’ve only ever given it this one time. If you know of any events where this talk would be a good fit, let me know.
- There is one web
- The web should not cause harm to society
- The web must support healthy community and debate
- The web is for all people
- Security and privacy are essential
- The web must enable freedom of expression
- The web must make it possible for people to verify the information they see
- The web must enhance individuals’ control and power
- The web must be an environmentally sustainable platform
- The web is transparent
- The web is multi-browser, multi-OS and multi-device
- People should be able to render web content as they want
Vasilis has published his magnificent thesis online. It’s quite lovely:
You can read this thesis in a logical order, which is the way that I wrote it. It starts with a few articles that explore the context of my research. It then continues with four chapters in which I describe the things I did. I end the thesis with four posts with findings, conclusions and recommendations.
And they all have.
And they are all different.
Read this talk transcript, and even if you don’t agree with everything in it today, you may end up coming back to it in the future. He’s playing the long game:
The web is the way now that we distribute information. We will need the web pages we create now to be readable in 100 years time, just as we can still read 100-year-old books.
I’ve come to believe that accessibility is not something you do for a small group of people. Accessibility is about promoting inclusion. When the product you use daily is accessible, it means that we all get to work with a greater number and a greater variety of colleagues. Accessibility benefits everyone.
The newest Gary Hustwit film is a documentary about Dieter Rams, featuring plinkity music by Brian Eno.
Rams is a design documentary, but it’s also a rumination on consumerism, materialism, and sustainability.
Taking the idea of the Clock of the Long Now and applying it to a twitterbot:
Software may not be as well suited as a finely engineered clock to operate on these sorts of geological scales, but that doesn’t mean we can’t try to put some of the 10,000 year clock’s design principles to work.
The bot will almost certainly fall foul of Twitter’s API changes long before the next tweet-chime is due, but it’s still fascinating to see the clock’s principles applied to software: longevity, maintainability, transparency, evolvability, and scalability.
Software tends to stay in operation longer than we think it will when we first wrote it, and the wearing effects of entropy within it and its ecosystem often take their toll more quickly and more destructively than we could imagine. You don’t need to be thinking on a scale of 10,000 years to make applying these principles a good idea.
This is a great piece by Alla, ostensibly about Bulb’s design principles, but it’s really about what makes for effective design principles in general. It’s packed full of great advice, like these design principles for design principles:
- Good principles are genuine
- Good principles have a point of view
- Good principles are memorable
Mozilla’s work-in-progress style guide and pattern library.