Folks, this is not okay. Our industry is characterized by institutional recklessness and a callous lack of empathy for our users.
Tuesday, October 19th, 2021
Thursday, October 7th, 2021
This is a terrific and nuanced talk that packs a lot into less than twenty minutes.
(The secret sauce in transitional web apps is progressive enhancement.)
Thursday, September 30th, 2021
If Apple allowed Safari to actually compete, it would be better for web developers, businesses, consumers, and for the health of the web. Come on, Apple, set Safari free!
Wednesday, September 29th, 2021
TAKE MY MONEY!!!
Tuesday, September 28th, 2021
I have this expensive computer in my pocket and it feels unfair that it is hamstrung in this very specific way of not allowing other browser engines. I also have an Apple laptop and it’s not hamstrung in that way, and I really hope it never is.
Wednesday, September 22nd, 2021
Design research on the Clearleft podcast
Episode three is all about design research. I like the narrative structure of this. It’s a bit like a whodunnit, but it’s more like a whydunnit. The “why” question is “why aren’t companies hiring more researchers?”
The scene of the crime is this year’s UX Fest, where talks by both Teresa Torres and Gregg Bernstein uncovered the shocking lack of researchers. From there, I take up the investigation with Maite Otondo and Stephanie Troeth.
I won’t spoil it but by the end there’s an answer to the mystery.
I learned a lot along the way too. I realised how many axes of research there are. There’s qualitative research (stories, emotion, and context) and then there’s quantitative research (volume and data). But there’s also evualative research (testing a hyphothesis) and generative research (exploring a problem space before creating a solution). By my count that gives four possible combos: qualitative evaluative research, quantitative evaluative research, qualitative generative research, and quantitative generative research. Phew!
Steph was a terrific guest. Only a fraction of our conversation made it into the episode, but we chatted for ages.
And Maite kind of blew my mind too, especially when she was talking about the relationship between research and design and she said:
Research is about the present and design is about the future.
I’m going to use that quote again in a future episode. In fact, this episode on design research leads directly into the next two episodes. You won’t want to miss them. So if you’re not already subscribed to the Clearleft podcast, you should get on that, whether it’s via the RSS feed, Apple, Google, Spotify, Overcast, or wherever you get your podcasts from.
Have a listen to this episode on design research and if you’re a researcher yourself, remember that unlike most companies we value research at Clearleft and that’s why we’re hiring another researcher right now. Come and work with us!
Tuesday, September 14th, 2021
It sometimes feels like we end up testing the limitations of our tools rather than the content and design itself.
What Benjamin found—and I heartily agree—is that HTML prototypes give you the most bang for your buck:
Monday, September 13th, 2021
I cannot wait for this book (apart) by Jeremy Wagner to arrive—it’s gonna be sooooo good!
Thursday, September 9th, 2021
You may not realise that all browsers on iOS are required to use the same rendering engine as Safari. On other platforms, this is not the case.
A terrific in-depth look at the frustrating state of the web on iOS.
So it’s not just one browser that falls behind. It’s all browsers on iOS. The whole web on iOS falls behind. And iOS has become so important that the entire web platform is being held back as a result.
And this damning assessment is mercifully free of conspiracy theories.
The Safari and Chrome team both want to make the web safer and work hard to improve the web. But they do have different views on what the web should be.
Google is focussing on improving the web by making it more capable.
Safari seems to focus on improving the web as it currently is.
Read the whole thing—it’s excellent!
There can only be one proper solution: Apple needs to open up their App Store to browsers with other rendering engines. Scrap rule 2.5.6 and allow other browsers on iOS and let them genuinely compete. Even though Apple has been forced to compromise on some App Store rules, I have little hope for this to happen.
Tuesday, September 7th, 2021
Bruce Lawson’s personal site : Briefing to the UK Competition and Markets Authority on Apple’s iOS browser monopoly and Progressive Web Apps
Following on from Stuart’s, here’s Bruce’s presentation to the CMA on Apple’s monopolistic practices and hostility to progressive web apps.
What I would like is that I can give users the best experience on the web, on the best mobile hardware. That best mobile hardware is Apple’s, but at the moment if I want to choose Apple hardware I have to choose a sub-par web experience. Nobody can fix this other than Apple, and there are a bunch of approaches that they could take — they could make Safari be a best-in-class experience for the web, or they could allow other people to collaborate on making the browser best-in-class, or they could stop blocking other browsers from their hardware. People have lots of opinions about which of these, or what else, could and should be done about this; I think pretty much everyone thinks that something should be done about it, though.
Saturday, September 4th, 2021
An oldie but a goodie. If you think you’re getting statistically significant results from A/B testing, you should probably consider doing some A/A testing.
In an A/A test, you run a test using the exact same options for both “variants” in your test.
Thursday, August 26th, 2021
Lara’s superb book on public speaking is now available in its entirity for free as a web book!
And a very beautiful web book it is too! All it needs is a service worker so it works offline.
Friday, August 20th, 2021
…you would be forgiven if you saw an API where a feature went from green (supported) to red (unsupported) and you thought: is the browser being deprecated?
the onus is not on web developers to keep track of older features in danger of being deprecated. That’s on the browser makers. I sincerely hope we’re not expected to consult a site called canistilluse.com.
It’s weirdly gratifying to see a hastily-written sarcastic quip tuned into something real.
Thursday, August 19th, 2021
Wednesday, August 18th, 2021
Monday, August 16th, 2021
After I jotted down some quick thoughts last week on the disastrous way that Google Chrome rolled out a breaking change, others have posted more measured and incisive takes:
- Chris Ferdinandi wrote Google vs. the web,
- Rich Harris wrote Stay alert,
- Jim Nielsen wrote I Want To Confirm a Prompt That We Stay Alert
In fairness to Google, the Chrome team is receiving the brunt of the criticism because they were the first movers. Mozilla and Apple are on baord with making the same breaking change, but Google is taking the lead on this.
As I said in my piece, my issue was less to do with whether
alert() should be deprecated but more to do with how it was done, and the woeful lack of communication.
Thinking about it some more, I realised that what bothered me was the lack of an upgrade path. Considering that
dialog is nowhere near ready for use, it seems awfully cart-before-horse-putting to first remove a feature and then figure out a replacement.
I was chatting to Amber recently and realised that there was a very different example of a feature being deprecated in web browsers…
We were talking about the
KeyboardEvent.keycode property. Did you get the memo that it’s deprecated?
But fear not! You can use the
KeyboardEvent.code property instead. It’s much nicer to use too. You don’t need to look up a table of numbers to figure out how to refer to a specific key on the keyboard—you use its actual value instead.
So the way that change was communicated was:
Hey, you really shouldn’t use the
keycodeproperty. Here’s a better alternative.
But with the more recently change, the communication was more like:
Hey, you really shouldn’t use
alert(). So go fuck yourself.
HTML sits on a boundary between the machine, the creator, and the reader.
Tuesday, August 10th, 2021
It’s not just a story about unloved APIs, it’s a story about power, standards design, and who owns the platform — and it makes me afraid for the future of the web.
A thoughtful, considered post by Rich Harris on the whole ballyhoo with
alert and its ilk:
For all its flaws, the web is generally agreed to be a stable platform, where investments made today will stand the test of time. A world in which websites are treated as inherently transient objects, where APIs we commonly rely on today could be cast aside as unwanted baggage by tomorrow’s spec wranglers, is a world in which the web has already lost.
Monday, August 9th, 2021
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.