Link tags: principles

102

sparkline

WebPageTest’s Guiding Principles - WebPageTest Blog

  1. Make the right thing easy
  2. Always answer “so what”?
  3. Close the gap between “something is wrong” to “we fixed it”

Accessibility strategy – GOV.UK Design System

The primary goals of this strategy are to inform decision-making and enhance the success of accessibility-related activities within the GOV.UK Design System team.

Interestingly, accessibility concerns are put into two categories: theoretical and evidenced (with the evidenced concerns being prioritised):

  1. Theoretical: A question or statement regarding the accessibility of an implementation within the Design System without evidence of real-world impact.
  2. Evidenced: Sharing new research, data or evidence showing that an implementation within the Design System could cause barriers for disabled people.

Design Principles For The Web - Jeremy Keith - YouTube

Here’s the video of the talk I gave at Web Dev Conf in Bristol recently. I think you can tell that I had fun—it was a good audience!

Design Principles For The Web - Jeremy Keith

Malleable Systems Collective

Modern computing is far too rigid. Applications can only function in preset ways determined by some far away team. Software is trapped in hermetically sealed silos and is rewritten many times over rather than recomposed.

This community catalogs and experiments with malleable software and systems that reset the balance of power via several essential principles…

I’ll be adding those principles to my collection.

ADL Social Pattern Library | Anti hate by design

A collection of design patterns and principles for mitigating the presence and spread of online hate and harassment in social platforms.

A Matter of Principle

This is an oldie from Julie Zhou, but it’s a timeless message about the value of good (i.e. actually useful) design principles.

See also what she said on this podcast episode:

When push comes to shove and you have to make a trade off, how are you, in those moments, as a team or a company going to prioritize? What are you going to care about the most? Good values will be controversial in that respect because it’s something that another company might have made a different decision than you.

WWC22 - Design Principles For The Web - YouTube

Here’s the video of the talk I gave in front of an enormous audience at the We Are Developers conference …using a backup slidedeck.

WWC22 - Design Principles For The Web

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.