Link tags: principles

94

sparkline

Reinventing W3C Governance

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.

Agile and the Long Crisis of Software

Time and again, organizations have sought to contain software’s most troublesome tendencies—its habit of sprawling beyond timelines and measurable goals—by introducing new management styles. And for a time, it looked as though companies had found in Agile the solution to keeping developers happily on task while also working at a feverish pace. Recently, though, some signs are emerging that Agile’s power may be fading. A new moment of reckoning is in the making, one that may end up knocking Agile off its perch.

The Design System Priority of Constituencies - Cloud Four

Jason applies my favourite design principle to design systems.

User needs come before the needs of component consumers, which come before the needs of component developers, which come before the needs of the design system team, which come before theoretical purity.

Also: how frickin’ cool is it that the Cloud Four office has the priority of constituencies emblazoned on the wall!

Defining the WHAT and WHY of Design Principles — Anton Sten — UX-lead

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.

An Idea from Computer Science That Can Change Your Life – Jorge Arango

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.

Principles of User Privacy (PUP)

This looks like an excellent proposal for agreement around discussing privacy on the web.

The section on user agents resonates with what I wrote recently about not considering Google Chrome a user agent any more:

Its fiduciary duties include:

  • Duty of Protection
  • Duty of Discretion
  • Duty of Honesty
  • Duty of Loyalty

The web we choose to build. Principles for user-centred front-end development by Colin Oakley

I was really chuffed to see some posts of mine referenced in this rather excellent piece about design principles for front-end development.

Web Platform Design Principles

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.

mnot’s blog: RFC8890: The Internet is for End Users

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.

Also worth noting:

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.

A walkthrough of our design system and how we got here | Kyan

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.)

The 3 Laws of Serverless - Burke Holland

“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:

  1. You have no knowledge of the underlying system where your code runs.
  2. Scaling is an intrinsic attribute of the technology; so much so that it just happens automatically.
  3. You only pay for what you use.

Abstraction; scale; consumption.

Modest JS Works | You were never sold on heavy-handed JavaScript approaches. Here’s a case for keeping your JS modest.

The fat JavaScript stacks-du-jour have a lot of appeal. They promise you to be able to do more with less. But what if I want to do less?

This is a terrific little (free!) online book all about modest JavaScript. The second part has practical code, but it’s the first part—all about the principles of staying lean—that really resonates with me.

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.

The Book | The Lean Web

This is such a great little web book from Chris Ferdinandi that you can read online for free.

  1. Intro
  2. Modern Best Practices
  3. How did we get here?
  4. Lean Web Principles
  5. What now?

SOTB2018 - Jeremy Keith - The Web Is Agreement - YouTube

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.

#SOTB2018 - Jeremy Keith - The Web Is Agreement

W3C TAG Ethical Web Principles

  • 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

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.