I have no idea what the web will look like in another 30 years. But I am sure that we will look back at the first 30 years of the Web like we look back at the silent era in cinema today: as the formative years of a medium that was about to evolve to even higher heights.
The Web has always been about what each and every one of us contributes. And contributing is easier and more important than ever. So let’s not leave the future of the Web to big tech alone. Inclusiveness, accessibility, performance, security, usability, decentralization, openness – in almost all areas, the Web is far from done.
Keep refreshing until you find your next job title.
Want to work with me? If so, come and be a design engineer at Clearleft!
We’re looking for a design-friendly front-end developer with demonstrable skills in pattern-based prototyping and production to join our friendly and supportive team in the heart of Brighton.
Even if this isn’t for you, please spread the word …especially to potential candidates who aren’t mediocre middle-aged white dudes (I’ve already got that demographic covered).
We need engineers, we need designers, and we absolutely need design engineers to make that connection across the great divide between the front-of-the-front-end and the back-of-the-front-end. It’s only then that we can make truly great things together.
The intent is for this website to be used by self-forming small groups that want to create a “watching club” (like a book club) and discuss aspects of technology history that are featured in this series.
I’m about ready to rewatch Halt And Catch Fire. Anybody want to form a watching club with me?
This is a very handy table of elements from Steve of where
aria-label can be applied.
Like, for example, not on a
I’d maybe simplify this people problem a bit: the codebase is easy to change, but the incentives within a company are not. And yet it’s the incentives that drive what kind of code gets written — what is acceptable, what needs to get fixed, how people work together. In short, we cannot be expected to fix the code without fixing the organization, too.
Another five pieces of sweet, sweet low-hanging fruit:
- Always label your inputs.
- Highlight input element on focus.
- Break long forms into smaller sections.
- Provide error messages.
- Avoid horizontal layout forms unless necessary.
Five pieces of low-hanging fruit:
- Unlabelled links and buttons
- No image descriptions
- Poor use of headings
- Inaccessible web forms
- Auto-playing audio and video
A great talk by Ethan called The Design Systems Between Us.
This is a superb twenty minute presentation by Trys! It’s got everything: a great narrative, technical know-how, and a slick presentation style.
Conference organisers: you should get Trys to speak at your event!
A handy reminder from Léonie (though remember that the best solution is to avoid the problem in the first place—if you avoid using ARIA, do that).
Smart thoughts from Ethan on how design systems can cement your existing ways of working, but can’t magically change how collaboration works at your organisation.
Modern digital teams rarely discuss decisions in terms of the collaborative costs they incur. It’s tempting—and natural!—to see design- or engineering-related decisions in isolation: that selecting Vue as a front-end framework only impacts the engineering team, or that migrating to Figma only impacts designers. But each of these changes the way that team works, which impacts how other teams will work and collaborate with them.
You see, diversity of rendering engines isn’t actually in itself the point. What’s really important is diversity of influence: who has the ability to make decisions which shape the web in particular ways, and do they make those decisions for good reasons or not so good?
Five moments in the lifecycle of a design system. They grow up so fast!
- Formation of the Design System Team
- First Page Shipped
- Consumable Outside the Main Product
- First Non-System Team Consumer
- First Breaking Change
Dave makes the observation that design systems are less like open source software and more like enterprise software—software you didn’t choose to use:
Often, in my experience, for an internal Design System to have widespread adoption it requires a literal executive mandate from the top floor of the building.
Also: apparently design systems have achieved personhood now and we’re capitalising them as proper names. First name Design, last name System.
“Please, call me Design. Mr. System was my father.”
Some good writing advice in here:
- Spell out your acronyms.
- Use active voice, not passive voice.
- Fewer commas. More periods.
Some good thought morsels from Robin on product design:
Bad product design is when folks talk more about the UI than what the UI is built on top of.
There’s a lot of talk about how great design is invisible—mostly boring conversations with little substance—but! I think that’s true when it comes to product design.
Bad product design is when your interface looks like your org chart.