When we rethink our approach to development, we go beyond just the base level of access to information. Inclusive development means making something valuable, not just accessible, to as many people as we can.
As usual, Ethan makes a lot of sense in this post about how the way we build is impacted by the environment in which we build:
In our little industry, we often work on decent hardware, on reliable networks. But according to Pew Research, thirty percent of Americans don’t have broadband at home. One in ten American adults are smartphone-only internet users, while 13% of American adults don’t use the internet at all.
Meanwhile, we make mobile-friendly websites with widescreen devices, using broadband to design experiences for slow, unstable networks. In a lot of ways, we’re outliers among the people we’re designing for.
I really enjoyed this post from Dropbox about what they do to help cultivate an internal culture of accessibility.
Unsurprisingly, a lot of the advice here mirrors the same sort of good advice an organization might here about cultivating cultures of performance, security or any other critical yet overlooked component of design and development: share knowledge, experience the issues first-hand, celebrate improvements, and build it directly into your workflow.
Even in my tiny design practice, every decision I make is shaped by my biases; every decision I make is capable of harm. And it’s so, so easy to forget this: to focus on the layout challenge in front of me, to fulfil the client’s latest request, or to meet a business goal. When I do these things, I occasionally forget to ask myself who’ll be impacted by my work and, most importantly, to ask how I can mitigate that harm.
By now I think it’s become pretty clear that we haven’t done a great job of educating people about the security and privacy implications of the technology they use. Much of the information around these topics tends to lean more towards fear-mongering than towards providing actionable advice and hope.
The Privacy Paradox, a five-part series of podcasts done by Note to Self, does an excellent job of explaining what the risks are and what can be done about it. The episodes are short and actionable: each spends some time on a privacy risk followed by a specific “challenge” you can do to take back a little control. Well worth a listen.
I was just talking to Marcin Wichary last week about my love for post-it notes and he admitted the most common colors are not exactly aesthetically pleasing. Looks like we have pure convenience to blame.
The yellow color was chosen for convenience, according to Nicholson: it was what the lab next door had available, so they used it.
Una recently added a “Save Offline” button to her blog posts that gives users control over whether an article will be saved offline or not. There was some recent discussion prompted by Nicholas Hoizey about how much data is too much to save offline. Giving users control (whether on an individual post basis or in bulk) seems like one way to deal with that question.
A fantastic breakdown of the impact media has on how we perceive reality. The post starts by looking at the huge difference between coverage of terrorist attacks and the reality, demonstrating that media’s fixation (and the attention we give those articles) makes terrorism seem far more prevalent than it is.
Then there’s this sobering, accurate and important conclusion:
In addition to selective data, as readers we’re over-generalizing our view of the entire other side , based on extreme events or commentary from a select fringe.
Fantastic breakdown about the different “zones of death” in the browser. It really hammers home the importance, and difficulty, of designing for security.
The history of email, following a progression from write all the way to what we have today.