- Have a dedicated page for login
- Expose all required fields
- Keep all fields on one page
- Don’t get fancy
Ire takes a deep dive into implementing an accessible tool tip.
It’s our job as designers to bring clarity back to the digital canvas by crafting reading experiences that put readers first.
This is an excellent case study!
The technical details are there if you want them, but far more important is consideration that went into every interaction. Every technical decision has a well thought out justification.
These are good challenges to think about. Almost all of them are user-focused, and there’s a refreshing focus away from reaching for a library:
It’s tempting to read about these problems with a particular view library or a data fetching library in mind as a solution. But I encourage you to pretend that these libraries don’t exist, and read again from that perspective. How would you approach solving these issues?
The sentiment is that front-end development is a problem to be solved: “if we just have the right tools and frameworks, then we might never have to write another line of HTML or CSS ever again!” And oh boy what a dream that would be, right?
Well, no, actually. I certainly don’t think that front-end development is a problem at all.
What Robin said.
I reckon HTML and CSS deserve better than to be processed, compiled, and spat out into the browser, whether that’s through some build process, app export, or gigantic framework library of stuff that we half understand. HTML and CSS are two languages that deserve our care and attention to detail. Writing them is a skill.
This instance of collective action from inside a tech company is important, not just for the specifics of Google, but in acting as an example to workers in other companies.
And of all the demands, this is the one that could have the biggest effect in the US tech world:
An end to Forced Arbitration.
We use too many damn modals.
Amen! This site offers some alternatives, or—if you really must use a modal dialogue—some dos and dont’s.
And remember to always ask, kids: “Why does this have to be a modal?”
This is a rather beautiful piece of writing by Tom (especially the William Gibson bit at the end). This got me right in the feels:
Web 2.0 really, truly, is over. The public APIs, feeds to be consumed in a platform of your choice, services that had value beyond their own walls, mashups that merged content and services into new things… have all been replaced with heavyweight websites to ensure a consistent, single experience, no out-of-context content, and maximising the views of advertising. That’s it: back to single-serving websites for single-serving use cases.
A shame. A thing I had always loved about the internet was its juxtapositions, the way it supported so many use-cases all at once. At its heart, a fundamental one: it was a medium which you could both read and write to. From that flow others: it’s not only work and play that coexisted on it, but the real and the fictional; the useful and the useless; the human and the machine.
It’ll never catch on.
Oh, this will be good! Adam has been working on, thinking and writing about forms for quite a while and he has distilled that down into ten patterns. You just know that progressive enhancement will be at the heart of this book.
By the end of the book, you’ll have a close-to exhaustive list of ready-to-go components, delivered as a design system that you can fork, contribute to and use immediately on your projects. But more than that, you’ll have the mindset and rationale behind when or when not to use each solution, which is just as important as the solution itself.
I love this deep dive that Sara takes into the question of marking up content for progressive disclosure. It reminds me Dan’s SimpleQuiz from back in the day.
Then there’s this gem, which I think is a terrificly succinct explanation of the importance of meaningful markup:
It’s always necessary, in my opinion, to consider what content would render and look like in foreign environments, or in environments that are not controlled by our own styles and scripts. Writing semantic HTML is the first step in achieving truly resilient Web sites and applications.
A handy bunch of checklists from Dave for creating accessible components. Each component gets a card that lists the expectations for interaction.
A great collection of styled and accessible form elements:
Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.
Sara shows a few different approaches to building accessible toggle switches:
Always, always start thinking about the markup and accessibility when building components, regardless of how small or simple they seem.
Ethan’s ode to the
fr unit in CSS grid.
A website is not a magazine, though it might have magazine-like articles. A website is not an application, although you might use it to purchase products or interact with other people. A website is not a database, although it might be driven by one.
Dave is liking the word “telepresence”:
On social media we broadcast our presence and thoughts over radio and wire and I likewise consume your projections as they echo back to me. We commune over TCP/IP.
Just wait until he discovers the related neologism coined by Ted Nelson.