Tags: principles

78

sparkline

Exclusive Design

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.

  1. Everybody’s paradox
  2. The defaults suck
  3. Flipping things
  4. Fuckup’s mama
  5. More death to more bullshit
  6. Design like it’s 1999
  7. Invisible Animations
  8. Semantics schmemantics
  9. Stress cases
  10. Coders should learn how to design
  11. Add nonsense
  12. Conclusion

The 100 Year Web (In Praise of XML)

I don’t agree with Steven Pemberton on a lot of things—I’m not a fan of many of the Semantic Web technologies he likes, and I think that the Robustness Principle is well-suited to the web—but I always pay attention to what he has to say. I certainly share his concern that migrating everything to JavaScript is not good for interoperability:

This is why there are so few new elements in HTML5: they haven’t done any design, and instead said “if you need anything, you can always do it in Javascript”.

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.

Requiring a webpage to depend on a particular 100-year-old implementation of Javascript is not exactly evidence of future-thinking.

Drupal’s commitment to accessibility | Dries Buytaert

Shots fired!

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.

Rams — Gary Hustwit

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.

Tweeting for 10,000 Years: An Experiment in Autonomous Software — Brandur Leach

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.

The principles behind Bulb’s design – Making Bulb – Medium

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 Protocol - Protocol Design System

Mozilla’s work-in-progress style guide and pattern library.

Developer happiness considered harmful (sometimes)

Thoughts on my favourite design principle (because I’m that much of a design principles nerd that I have a favourite).

Developer happiness is only a benefit if it first does no harm to others. Even better if it genuinely amplifies benefits to those further up chain of priorities.

“Distinct Design Systems,” an article by Dan Mall

Dan asks:

Do we have too many design systems?

Spoiler: the answer is “no”. There. Saved you a click.

(Not really; you should definitely click.)

From Purpose to Patterns // Speaker Deck

A great slide deck from Alla, all about design principles. From purpose to principles to patterns.

The Eponymous Laws of Tech - daverupert.com

Dave has curated a handy list of eponymous laws.

Fantasies of the Future: Design in a World Being Eaten by Software / Paul Robert Lloyd

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?

Using Ethics In Web Design — Smashing Magazine

A remarkably practical in-depth guide to making ethical design decisions, with enjoyable diversions into the history of philosophy throughout.

Progressive enhancement and the things that are here to stay, with Jeremy Keith | Fixate

I enjoyed chatting to Larry Botha on the Fixate On Code podcast—I hope you’ll enjoy hearing it.

Available for your huffduffing pleasure.

Laws of UX

  1. Fitts’s Law
  2. Hick’s Law
  3. Jakob’s Law
  4. Law of Prägnanz
  5. Law of Proximity
  6. Miller’s Law
  7. Parkinson’s Law
  8. Serial Position Effect
  9. Tesler’s Law
  10. Van Restorff Effect

Not listed:

  1. Murphy’s Law
  2. Sturgeon’s Law

Design Principles

Collections of design principles that you can contribute to.

The aim of the site is to help us analyse what good Design Principles are. How Design Principles are created and measured. How they develop.

Another Lens - News Deeply x Airbnb.Design

Little interventions for designers in the form of questions designed to challenge assumptions. Kind of like Brian Eno’s oblique strategies.

The Fallacies of Distributed Computing (Applied to Front-End Performance) – CSS Wizardry – CSS Architecture, Web Performance Optimisation, and more, by Harry Roberts

Harry cautions against making assumptions about the network when it comes to front-end development:

Yet time and time again I see developers falling into the same old traps—making assumptions or overly-optimistic predictions about the conditions in which their apps will run.

Planning for the worst-case scenario is never a wasted effort:

If you build and structure applications such that they survive adverse conditions, then they will thrive in favourable ones.

Relative Requirements – CSS Wizardry

I really like this exercise by Harry. I’ve done similar kinds of grading using dot-voting in the past. It feels like an early step to establishing design principles: “this over that.”

By deciding what we value up-front, we have an agreement that we can look back on in order to help us settle these conflicts and get us back on track again.

Relative Requirements remove the personal aspect of these disagreements and instead focuses on more objective agreements that we made as a team.