Interesting to see an article on web performance on the BBC. Perhaps we should be emphasising green over speed?
Behind the scenes, animation and interaction effects were added using HTML and CSS, two fundamental web languages. That meant there was no need to download large JavaScript files often used to do this on other sites.
Container queries can’t be used in the sizes attribute for responsive images. Here, Jason breaks down why that is (spoiler: it’s the lookahead pre-parser) and segues into a truly long term solution: a “magical” image format.
If you’ve ever thought it felt weird to put media conditions inside the HTML for responsive images, this will resonate.
I’ve been redesigning UX London. I don’t mean the website. I mean the event itself.
Don’t worry, it’s nothing too radical. It’s not like we’re changing the focus of the event, which remains a nerdfest for all things design-related.
But there are plenty of other opportunities for tweaking a conference like this: the format, the timings, the location.
For 2023 we’re not changing the location. Tobacco Dock worked out well for last year’s event, although it is very expensive (then again, so is anywhere decent in London). Last year there were a lot of unknowns in play because it was our first time using the venue. It feels good that this year we don’t have to go through quite as much uncertainty.
The most obvious change to UX London this year is the length. The event will last for two days instead of three.
Running a three-day event was a lot of work, so this helps relieve the pressure. It was also asking a lot of attendees. That’s why we also offered one-day tickets. For the people who couldn’t commit to three days at a conference, there was the option to pick and choose.
But that brought its own issues. Instead of everyone having the same shared experience, the audience was a bit fractured.
Now that we’ve slimmed it down to two days, we’re selling the same two-day tickets for everyone. No more single-day tickets; no more partial attendance. Judging by the way ticket sales have been going, this is a very welcome move.
(Even before announcing any speakers, we had already sold a healthy amount of tickets. That’s probably testament to the great reputation that UX London has built up over the years. I need to make sure I don’t squander that good will. No pressure.)
On the subject of everyone having a shared experience, there’s something about the format of UX London that’s bothered me for a while…
Each day is split into two halves. In the morning, you’ve got inspirational talks. That’s one single track. Then in the afternoon, you’ve got hands-on practical workshops. They happen in parallel.
That makes for a great mix, but the one downside is that the day ends with the audience split across the different workshops.
This year I’m tweaking the format slightly. We’ll still have a single track of talks in the morning followed by multiple workshops in the afternoon, but I’m shortening the workshop length slightly to fit in one last talk at the end of the day. That way, everybody will come back together again after their workshops to participate in a shared experience.
The audience will converge at the beginning of the day, diverge in the afternoon, and this time we’ll converge again at day’s end.
The workshops are a big part of what makes UX London stand out. But they also pose a big design challenge. How do you ensure that everyone gets to attend the workshops they want?
We could make people pick their workshops in advance. But then you end up with the office Christmas dinner party problem—you know the one; everyone has to choose their meal way in advance, and then on the day, no one remembers what they ordered.
Besides, if we make people choose in advance, it’s not fair on people who buy their ticket close to the event.
In the end, using a first-come, first-served strategy on the day has worked out best. But it’s not ideal. You could miss out on attending your first choice of workshop if you’re not fast enough.
This year we’re trying something new. Each afternoon there’ll be a choice of workshops, as always. But this time, it’ll be the same workshops on both days. That way, every attendee gets a second chance to get to the workshops they want. And it’ll help reduce the FOMO—Fear Of Missing Out. It still won’t be possible to attend all the workshops without cloning yourself, but this way, you get to attend half of them.
To recap, here’s the redesigned format for UX London 2023:
The line-up is coming together nicely. I’ve got more confirmed speakers, who I don’t want to reveal just yet. But trust me, you won’t want to miss this!
Oh, and you should probably grab your ticket this week if you haven’t already: early-bird pricing ends on midnight on Friday, February 24th.
I guess the biggest criticism here is that it feels like people who believe in the superiority of single page applications and the entire ecosystem focus more on developer experience (DX) than user experience. That sounds like a dangerous blanket statement, but after all these years, I never had the feeling that the argument “better DX leads to better UX” was ever true. It’s nothing more than a justification for the immense complexity and potentially significantly worse UX. And even if the core argument isn’t DX, other arguments like scalability, maintainability, competitive ability, easier recruiting (“everyone uses React”), and cost effectiveness, in my experience, only sound good, but rarely hold up to their promises.
Mat has written this free course for you all about images on the web. Covering image formats, responsive images, and workflows, this is one to keep on speed dial.
- Make the right thing easy
- Always answer “so what”?
- Close the gap between “something is wrong” to “we fixed it”
A person seeking help in a time of crisis does not care about TypeScript, tree shaking, hot module replacement, A/B tests, burndown charts, NPS, OKRs, KPIs, or other startup jargon. Developer experience does not count for shit if the person using the thing they built can’t actually get what they need.
Imagine the web is a storefront, React is a hot dog car, and here’s Create React App dressed as a hot dog:
HTML is the cornerstone of the web — so why does creating a “React app” produce an empty HTML file? Why are we not taking advantage of the most basic feature of the web—the ability to see content quickly before all the interactive code loads? Why do we wait to start loading the data until after all the client-side code has finished loading?
So much ink spilled supposedly explaining what “the web platform” is …when the truth is you can just swap in the “the web” every time that phrase is used here or anywhere else.
Anyway, the gist of this piece is: the web is good, actually.
I quite like this change of terminology when it comes to making fast websites. After all, performance can sound like a process of addition, whereas efficiency can be a process of subtraction.
The term ‘performance’ brings to mind exotic super-cars suitable only for impractical demonstrations (or ‘performances’). ‘Efficiency’ brings to mind an electric car (or even better, a bicycle), making effective use of limited resources.
Forms on the web are an opportunity to make big improvements to the user experience with very little effort. The effort can be as little as sprinkling in a smattering of humble HTML attributes. But the result can be a turbo-charged experience for the user, allowing them to sail through their task.
This is particularly true on mobile devices where people have to fill in forms using a virtual keyboard. Any improvement you can make to their flow is worth investigating. But don’t worry: you don’t need to add a complex JavaScript library or write convoluted code. Well-written HTML will get you very far.
If you’re using the right input type value, you’re most of the way there. Browsers on mobile devices can use this value to infer which version of the virtual keyboard is best. So think beyond the plain text value, and use search, email, url, tel, or number when they’re appropriate.
But you can offer more hints to those browsers. Here are three attributes you can add to input elements. All three are enumerated values, which means they have a constrained vocabulary. You don’t need to have these vocabularies memorised. You can look them when you need to.
inputmodeThe inputmode attribute is the most direct hint you can give about the virtual keyboard you want. Some of the values are redundant if you’re already using an input type of search, email, tel, or url.
But there might be occasions where you want a keyboard optimised for numbers but the input should also accept other characters. In that case you can use an input type of text with an inputmode value of numeric. This also means you don’t get the spinner controls on desktop browsers that you’d normally get with an input type of number. It can be quite useful to supress the spinner controls for numbers that aren’t meant to be incremented.
If you combine inputmode="numeric" with pattern="[0-9]", you’ll get a numeric keypad with no other characters.
The list of possible values for inputmode is text, numeric, decimal, search, email, tel, and url.
enterkeyhintWhereas the inputmode attribute provides a hint about which virtual keyboard to show, the enterkeyhint attribute provides an additional hint about one specific key on that virtual keyboard: the enter key.
For search forms, you’ve got an enterkeyhint option of search, and for contact forms, you’ve got send.
The enterkeyhint only changes the labelling of the enter key. On some browsers that label is text. On others it’s an icon. But the attribute by itself doesn’t change the functionality. Even though there are enterkeyhint values of previous and next, by default the enter key will still submit the form. So those two values are less useful on long forms where the user is going from field to field, and more suitable for a series of short forms.
The list of possible values is enter, done, next, previous, go, search, and send.
autocompleteThe autocomplete attribute doesn’t have anything to do with the virtual keyboard. Instead it provides a hint to the browser about values that could pre-filled from the user’s browser profile.
Most browsers try to guess when they can they do this, but they don’t always get it right, which can be annoying. If you explicitly provide an autocomplete hint, browsers can confidently prefill the appropriate value.
Just think about how much time this can save your users!
There’s a name value you can use to get full names pre-filled. But if you have form fields for different parts of names—which I wouldn’t recommend—you’ve also got:
given-name,additional-name,family-name,nickname,honorific-prefix, andhonorific-suffix.You might be tempted to use the nickname field for usernames, but no need; there’s a separate username value.
As with names, there’s a single tel value for telephone numbers, but also an array of sub-values if you’ve split telephone numbers up into separate fields:
tel-country-code,tel-national,tel-area-code,tel-local, andtel-extension.There’s a whole host of address-related values too:
street-address,address-line1,address-line2, andaddress-line3, but alsoaddress-level1,address-level2,address-level3, andaddress-level4.If you have an international audience, addresses can get very messy if you’re trying to split them into separate parts like this.
There’s also postal-code (that’s a ZIP code for Americans), but again, if you have an international audience, please don’t make this a required field. Not every country has postal codes.
Speaking of countries, you’ve got a country-name value, but also a country value for the country’s ISO code.
Remember, the autocomplete value is specifically for the details of the current user. If someone is filling in their own address, use autocomplete. But if someone has specified that, say, a billing address and a shipping address are different, that shipping address might not be the address associated with that person.
On the subject of billing, if your form accepts credit card details, definitely use autocomplete. The values you’ll probably need are:
cc-name for the cardholder,cc-number for the credit card number itself,cc-exp for the expiry date, andcc-csc for the security again.Again, some of these values can be broken down further if you need them: cc-exp-month and cc-exp-year for the month and year of the expiry date, for example.
The autocomplete attribute is really handy for log-in forms. Definitely use the values of email or username as appropriate.
If you’re using two-factor authentication, be sure to add an autocomplete value of one-time-code to your form field. That way, the browser can offer to prefill a value from a text message. That saves the user a lot of fiddly copying and pasting. Phil Nash has more details on the Twilio blog.
Not every mobile browser offers this functionality, but that’s okay. This is classic progressive enhancement. Adding an autocomplete value won’t do any harm to a browser that doesn’t yet understand the value.
Use an autocomplete value of current-password for password fields in log-in forms. This is especially useful for password managers.
But if a user has logged in and is editing their profile to change their password, use a value of new-password. This will prevent the browser from pre-filling that field with the existing password.
That goes for sign-up forms too: use new-password. With this hint, password managers can offer to automatically generate a secure password.
There you have it. Three little HTML attributes that can help users interact with your forms. All you have to do was type a few more characters in your input elements, and users automatically get a better experience.
This is a classic example of letting the browser do the hard work for you. As Andy puts it, be the browser’s mentor, not its micromanager:
Give the browser some solid rules and hints, then let it make the right decisions for the people that visit it, based on their device, connection quality and capabilities.
Over the past 10 years or so, we’ve slowly but very surely transitioned to a state where frameworks are the norm, and I think it’s a problem.
I concur.
Use the frameworks and libraries that make sense for you to deliver the best UX possible. But also learn the web platform from the ground up. Take time to understand how web browsers work and render webpages. Learn HTML, CSS, JavaScript. And keep an eye, if you can, on the new things.
Write meaningful HTML that communicates the structure of your document before any style or additional interactivity has loaded. Write CSS carefully, reason your methodology and stick to it, and feel empowered to skip frameworks. When it comes time to write JavaScript, write not too much, make sure you know what it all does, and above all, make sure the website works without it.
The whole article is great, and really charmingly written, with some golden nuggets embedded within, like:
- You’ll find that spending more time getting HTML right reveals or even anticipates and evades accessibility issues. It’s just easier to write accessible code if it’s got semantic foundations.
- In my experience, you will almost always spend more time overriding frameworks or compromising your design to fit the opinions of a framework.
- Always style from the absolute smallest screen your content will be rendered on first, and use
@media (min-width)queries to break to layouts that allow for more real estate as it becomes available.- If your site doesn’t work without JavaScript, your site doesn’t work.
- Always progressively enhance your apps, especially when you’re fucking with something as browser-critical as page routing.
It is not an exaggeration to say that modern frontend is so enamoured by post-scarcity fairy tales that it is mortgaging the web’s future for another round of night drinking at the JavaScript party.
Strong—and true—words from Alex.
This isn’t working for users or for businesses that hire developers hopped up Facebook’s latest JavaScript hopium. A correction is due.
I concur.
Frontend’s failure to deliver in today’s mostly-mobile, mostly-Android world is shocking, if only for the durability of the myths that sustain the indefensible. We can’t keep doing this.
If you disagree, I encourage you to dive into the data that Alex shares.
Mastodon is not a platform. Mastodon is just a tiny part of a concept many have been dreaming about and working on for years. Social media started on the wrong foot. The idea for the read/write web has always been different. Our digital identities weren’t supposed to end up in something like Twitter or Facebook or Instagram.
Decentralisation, Federation, The Indie Web: There were many groups silently working on solving the broken architecture of our digital social networks and communication channels – long, long before the “web 3” dudes tried to reframe it as their genius new idea.
I’ve been a part of this for many years until I gave up hope. How would you compete against the VC money, the technical and economical benefits of centralised platforms? It was a fight between David and Gloiath. But now Mastodon could be the stone.
I’ve always liked the idea that your website can be your API. Like, you’ve already got URLs to identify resources, so why not make that URL structure predictable and those resources parsable?
That’s why the (read-only) API for The Session doesn’t live at a separate subdomain. It uses the same URL structure as the regular site, but you can request the resources in an alternative format: JSON, XML, RSS.
This works out pretty well, mostly because I put a lot of thought into the URL structure of the site. I’m something of a URL fetishist, but I think that taking a URL-first approach to information architecture can be a good exercise.
Most of the resources on The Session involve nouns like tunes, events, discussions, and so on. There’s a consistent and predictable structure to the URLs for those sections:
/things/things/new/things/searchAnd then an idividual item can be found at:
things/IDThat’s all nice and predictable and the naming of the URLs matches what you’d expect to find:
Tunes, events, discussions, sessions. Those are all fine. But there’s one section of the site that has this root URL:
When I was coming up with the URL structure twenty years ago, it was clear what you’d find there: track listings for albums of music. No one would’ve expected to find actual recordings of music available to listen to on-demand. The bandwidth constraints and technical limitations of the time made that clear.
Two decades on, the situation has changed. Now someone new to the site might well expect to hit a link called “recordings” and expect to hear actual recordings of music.
So I should probably change the label on the link. I don’t think “albums” is quite right—what even is an album any more? The word “discography” is probably the most appropriate label.
Here’s my dilemma: if I update the label, should I also update the URL structure?
Right now, the section of the site with /tunes URLs is labelled “tunes”. The section of the site with /events URLs is labelled “events”. Currently the section of the site with /recordings URLs is labelled “recordings”, but may soon be labelled “discography”.
If you click on “tunes”, you end up at /tunes. But if you click on “discography”, you end up at /recordings.
Is that okay? Am I the only one that would be bothered by that?
I could update the URLs to match the labelling (with redirects for the old URLs, of course), but I’m not so keen on this URL structure:
/discography/discography/new/discography/search/discography/IDIt doesn’t seem as tidy as:
/recordings/recordings/new/recordings/search/recordings/IDBut if I don’t update the URLs to match the label, then I’m just going to have to live with the mismatch.
I’m just thinking out loud here. I think I should definitely update the label. I just won’t make any decision on changing URLs for a while yet.
Wouldn’t it be nice to have a site that’s not run by an amoral billionaire chaos engine, or algorithmically designed to keep you doomscrolling in a state of fear and anger, or is essentially spyware for governments and/or corporations? Wouldn’t it be nice not to have ads shoved in your face every time you open an app to see what your friends are up to? Wouldn’t it be nice to know that when your friends post something, you’ll actually see it without a social media platform deciding whether to shove it down your feed and pump that feed full of stuff you didn’t ask for?
Wouldn’t that be great?
Your easy guide to starting a new blog.
A blog is an easy way to get started writing on the web. Your voice is important: it deserves its own site. The more people add their unique perspectives to the web, the more valuable it becomes.
A recurring theme in my writing and talks is “lay off the JavaScript, people!” But I have to make a conscious effort to specify that I mean client-side JavaScript.
I thought it would be obvious from the context that I was talking about the copious amounts of JavaScript being shipped to end users to download, parse, and execute. But nothing’s ever really obvious. If I don’t explicitly say JavaScript in the browser, then someone inevitably thinks I’m having a go at JavaScript, the language.
I have absolutely nothing against JavaScript the language. Just like I have nothing against Python or Ruby or any other language that you might write with on your machine or your web server. But as soon as you deliver bytes over the wire, I start having opinions. It just so happens that JavaScript is the universal language for client-side coding so that’s why I call for restraint with JavaScript specifically.
There was a time when JavaScript only existed in web browsers. That changed with Node. Now it’s possible to write code for your web server and code for web browsers using the same language. Very handy!
But just because it’s the same language doesn’t mean you should treat it the same in both circumstance. As Remy puts it:
There are two JavaScripts.
One for the server - where you can go wild.
One for the client - that should be thoughtful and careful.
I was reading something recently that referred to Eleventy as a JavaScript library. It really brought me up short. I mean, on the one hand, yes, it’s a library of code and it’s written in JavaScript. It is absolutely technically correct to call it a JavaScript library.
But in my mind, a JavaScript library is something you ship to web browsers—jQuery, React, Vue, and so on. Whereas Eleventy executes its code in order to generate HTML and that’s what gets sent to end users. Conceptually, it’s like the opposite of a JavaScript library. Eleventy does its work before any user requests a URL—JavaScript libraries do their work after a user requests a URL.
To me it seems obvious that there should an entirely different mindset for writing code intended for a web browser. But nothing’s ever really obvious.
I remember when Node was getting really popular and npm came along as a way to manage all the bundles of code that people were assembling in their Node programmes. Makes total sense. But then I thought I heard about people using npm to do the same thing for client-side code. “That can’t be right!” I thought. I must’ve misunderstood. So I talked to someone from npm and explained how I must be misunderstanding something.
But it turned out that people really were treating client-side JavaScript no different than server-side JavaScript. People really were pulling in megabytes of other people’s code to ship to end users so that they could, I dunno, left pad numbers or something.
Listen, I don’t care what you get up to in the privacy of your own codebase. But don’t poison the well of the web with profligate client-side JavaScript.
Guess which format is going to outlast all these proprietary syndication formats. I’d say RSS, which I believe to be true, but really, it’s HTML.