Hixie’s Natural Log: When complaints are a good sign
This is a very smart way to handle feedback about a product.
Link tags: priorities
39
On Principles – technogoggles
The value of design principles done right:
What I’ve learnt is that principles are not a luxury. Making explicit and conscious what drives your behaviour can be incredibly powerful as a means to critically shape a team and organisation to be who they want to be.
Hixie’s Natural Log: Reflecting on 18 years at Google
On leaving the company, Hixie compares the Google of old to what it has become today:
Google’s culture eroded. Decisions went from being made for the benefit of users, to the benefit of Google, to the benefit of whoever was making the decision. Transparency evaporated. Where previously I would eagerly attend every company-wide meeting to learn what was happening, I found myself now able to predict the answers executives would give word for word. Today, I don’t know anyone at Google who could explain what Google’s vision is. Morale is at an all-time low. If you talk to therapists in the bay area, they will tell you all their Google clients are unhappy with Google.
To hell with the business case
I agree with everything that Matt says here. Evangelising accessibility by extolling the business benefits might be a good strategy for dealing with psychopaths, but it’s a lousy way to convince most humans.
The moment you frame the case for any kind of inclusion or equity around the money an organization stands to gain (or save), you have already lost. What you have done is turn a moral case, one where you have the high ground, into an economic one, where, unless you have an MBA in your pocket, you are hopelessly out of your depth.
If you win a business-case argument, the users you wanted to benefit are no longer your north star. It’s money.
How To Make A Strong Case For Accessibility – Smart Interface Design Patterns
Vitaly provides some sensible rebuttals.
Putting growth at the heart of GOV.UK’s strategy - Government Digital Service
This may mark the beginning of Gov.uk’s decline. The top-listed priorities are the very antithesis of starting with user needs. Instead from now on it’s going to be about growth, shiny new technology, having a native app, and literally pivoting to video.
It’ll be interesting to see if they try to maintain their existing design principles while simultaneously abandoning them.
Tech-last
I’ve spent a lot of time thinking, talking and writing about evaluating technology and what Robin describes here is definitely a bad “code smell” that should ring alarm bells:
What’s really concerning is when everyone is consumed with the technology-first and the problem-last.
Unless you’re working in an R’n’D lab, start with user needs.
I’m certain now that if you want to build something great you have to see through the tech. And that’s really hard to do when this cool new thing is all that anyone is talking about. But that’s why this one specific thing is the hallmark of a great organization; they aren’t distracted by short-lived trends and instead focus on the problem-first. Relentlessly, through the noise.
Craft — PaulStamatiou.com
I often use the word quality when referring to apps, products and services I hold in a high regard but another word that often comes up in this context is craft. Craft, as in something that is handcrafted where something someone spent a lot of time on and maybe even embedded their own personal touches and personality in it. Often something handcrafted feels more premium.
Giving your future self a little credit with progressive enhancement - Blog - Pixo | Apps, websites, and software development
We often talk about technical debt — the costs we’ll need to pay in the future when we make short-term compromises. Progressive enhancement is the opposite of that — a sort of technical credit that will make things easier for us in the future.
A good explanation of how progressive enhancement works perfectly with the idea of a minimal viable product:
We focus first on a core experience that delivers what your users are looking for, and then we start adding enhancements that will delight them.
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.
When shaken to the core, we get priorities right. Can we stick to it? – Dr. Carolina Odman
Carolina’s post reminds me of A Paradise Built In Hell by Rebecca Solnit:
In the face of disaster, survivors get together, make time and help one another regardless of their differences. It is beautiful and inspiring.
Priorities
The quest for more is a kind of prison that we make for ourselves. The idea that if we work ourselves to the bone now we can live a better life later is a convenient lie that we’ve been conditioned to tell ourselves.
An open and honest post from Ben.
I see decentralization as a way to lead to a more equitable society through disassembling existing hierarchies, for example, but I see straight through the people who see these ideas as a way to build a new hierarchy for their own benefit. We used to talk about abolishing gatekeepers in the early days of the web, too, until it became clear that many people just wanted to become a new kind of gatekeeper themselves.
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.
Remote to who? A working letter
The idea that your job should be the primary source of meaning in your life is an elaborately made trap, propped up across industries, designed to make you a loyal worker who uses the bulk of their intellectual and creative capacity to further their own career.
What is the Value of Browser Diversity? - daverupert.com
I’ve thought about these questions for over a year and narrowed my feelings of browser diversity down to two major value propositions:
- Browser diversity keeps the Web deliberately slow
- Browser diversity fosters consensus and cooperation over corporate rule
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.
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.
Prioritizing users in a crisis: Building the California COVID-19 response site
This is a great case study of the excellent California COVID-19 response site. Accessibility and performance are the watchwords here.
Want to know their secret weapon?
A $20 device running Android 9, with no contract commitment has been one of the most useful and effective tools in our effort to be accessible.
Leaner, faster sites benefit everybody, but making sure your applications run smoothly on low-end hardware makes a massive difference for those users.
Design Can Change the World - But It’s Up to Us to Make it So by Daniel Burka
There is a huge world out there where design isn’t embraced, where designers are clawing for resources, and where design isn’t prioritized. Most of the organizations that are changing your world don’t know much about design, aren’t looking for designers, and won’t even understand what designers are talking about when they show up at the front door.
Visitors, Developers, or Machines
Garrett’s observation is spot-on here:
I’ve been trying to understand the appeal of these frameworks by giving them an objective chance. I’ve expanded my knowledge of JavaScript and tried to give them the benefit of the doubt. They do have their places, but the only explanation I can come up with is that developers are taking a similar approach as Ruby and focusing on developer convenience and productivity. Only, instead of Ruby’s performance being tied to the CPU level, JavaScript frameworks push the performance burden to the client.
In both cases, the tradeoff happens in the name of developer happiness and productivity, but the strategies have entirely different consequences. With Ruby, the CPU is still (mostly) the responsibility of the development team, and it can be upgraded. With JavaScript, the page weight becomes an externality pushed onto visitors.