This long zoom by Andy is right up my alley—a history of UX design that begins in 1880. It’s not often that you get to read something that includes Don Norman, Doug Engelbart, Lilian Gilbreth, and Vladimir Lenin. So good!
Sally takes a long hard look at permissions on the web. It’s a fascinating topic because of all the parties involved—browsers, developers, and users.
In order to do permissions well, I think there are two key areas to think about - what’s actually being requested, and how it’s being requested.
Is a site being intrusive with what they can potentially learn about me (say, wanting my precise location when it’s unnecessary)? Or is it being intrusive in terms of how they interact with me (popping up a lot of notifications and preventing me from quickly completing my intended task)? If one of those angles doesn’t work well, then regardless of whether the other is acceptable to someone, they’re likely to start opting out and harbouring negative feelings.
Just last week I came across an example of what Ethan describes here: accessibility (in a pattern library) left to automatic checks rather than human experience.
Inclusive design is also future-proofing technology for everyone. Swan noted that many more developers and designers are considering accessibility issues as they age and encounter poor eyesight or other impairments.
A lot of the issues here are with abuses of the placeholder attribute—using it as a label, using it for additional information, etc.—whereas using it quite literally as a placeholder can be thought of as an enhancement (I almost always preface mine with “e.g.”).
Still, there’s no getting around that terrible colour contrast issue: if the contrast were greater, it would look too much like an actual pre-filled value, and that’s potentially worse.
I’ve been wondering about this for quite a while: surely demanding specific patterns in a password (e.g. can’t be all lowercase, must include at least one number, etc.) makes it easier to crack them, right? I mean, you’re basically providing a ruleset for brute-forcing.
Turns out, yes. That’s exactly right.
When employees are faced with this requirement, they tend to:
- Choose a dictionary word or a name
- Make the first character uppercase
- Add a number at the end, and/or an exclamation point
If we know that is a common pattern, then we know where to start…
Following on from Charlie’s experiment last year, Chris Ashton has been assessing which sites rely on JavaScript, and which sites use it in a more defensive, resilient way. Some interesting results in here.
A good core experience is indicative of a well-structured web page, which, in turn, is usually a good sign for SEO and for accessibility. It’s usually a well designed web page, as the designer and developer have spent time and effort thinking about what’s truly core to the experience. Progressive enhancement means more robust experiences, with fewer bugs in production and fewer individual browser quirks, because we’re letting the platform do the job rather than trying to write it all from scratch.
Paul walks us through the process of making some incremental accessibility improvements to this year’s 24 Ways.
Creating something new will always attract attention and admiration, but there’s an under-celebrated nobility in improving what already exists. While not all changes may be visual, they can have just as much impact.
Great advice for writing usable alt attributes. This gem seems obvious in hindsight but I hadn’t considered it before:
End the alt-text with a period. This will make screen readers pause a bit after the last word in the alt-text, which creates a more pleasant reading experience for the user.
This article about a specific security flaw in voice-activated assistants raises a bigger issue:
User-friendliness is increasingly at odds with security.
This is something I’ve been thinking about for a while. “Don’t make me think” is a great mantra for user experience, but a terrible mantra for security.
Our web browsers easily and invisibly collect cookies, allowing marketers to follow us across the web. Our phones back up our photos and contacts to the cloud, tempting any focused hacker with a complete repository of our private lives. It’s as if every tacit deal we’ve made with easy-to-use technology has come with a hidden cost: our own personal vulnerability. This new voice command exploit is just the latest in a growing list of security holes caused by design, but it is, perhaps, the best example of Silicon Valley’s widespread disregard for security in the face of the new and shiny.
I’ve gotten a little tired of showing up to a Medium-powered site on a non-medium.com domain and getting badgered to Sign Up! or Get Updates! when I’m already a Medium user.
A Chrome extension to Make Medium Readable Again by:
- Keeping the top navigation bar from sticking around
- Hiding the bottom “Get Updates” bar completely
- (Optionally) hiding the clap / share bar
- (Optionally) loading all post images up front, instead of lazy loading as you scroll
Shame there isn’t a mobile version to get rid of the insulting install-our-app permabutton.
This article makes a good point about client-rendered pages:
Asynchronously loaded page elements shift click targets, resulting in a usability nightmare.
…but this has nothing, absolutely nothing to do with progressive web apps.
More fuel for the fire of evidence that far too many people think that progressive web apps and single page apps are one and the same.
James gives—if you’ll pardon the pun— hands-on advice on making sites that consider motor impairment:
Far from being a niche concern, visitors with some form of motor impairment likely make up a significant percentage of your users. I would encourage you to test your website or application with your less dominant hand. Is it still easy to use?
If you thought Vitaly’s roundup of date pickers was in-depth, wait ‘till you get a load of this exhaustive examination of slider controls.
It pairs nicely with this link.
I really like this “evil” design exercise that Jared has documented on Ev’s blog.
I broke them up into small groups of three, spreading each role across separate groups. I then asked each person to grab a sheet of paper and make their own list of ways they imagined the product’s user experience could be made worse.
So many folks spend time on their CSS and their UX/UI but still come up with URLs that are at best, comically long, and at worst, user hostile.
A few straightforward steps for improving the usability of credit card forms. The later steps involve JavaScript but the first step uses nothing more than straight-up HTML.
A deep dive into formatting credit card numbers with spaces in online forms.
Some interesting insights from usability and accessibility testing at the Co-op.
We used ‘nesting’ to reduce the amount of information on the page when the user first reaches it. When the user chooses an option, we ask for any other details at that point rather than having all the questions on the page at once.