When in doubt, label your icons.
When not in doubt, you probably should be.
When in doubt, label your icons.
When not in doubt, you probably should be.
Nine people came together at CERN for five days and made something amazing. I still can’t quite believe it.
Coming into this, I thought it was hugely ambitious to try to not only recreate the experience of using the first ever web browser (called WorldWideWeb, later Nexus), but to also try to document the historical context of the time. Now that it’s all done, I’m somewhat astounded that we managed to achieve both.
Want to see the final result? Here you go:
That’s the website we built. The call to action is hard to miss:
Behold! A simulation of using the first ever web browser, recreated inside your web browser.
Now you could try clicking around on the links on the opening doucment—remembering that you need to double-click on links to activate them—but you’ll quickly find that most of them don’t work. They’re long gone. So it’s probably going to be more fun to open a new page to use as your starting point. Here’s how you do that:
Documentfrom the menu options on the left.
Open from full document reference.
You are now surfing the web through a decades-old interface. Double click on a link to open it. You’ll notice that it opens in a new window. You’ll also notice that there’s no way of seeing the current URL. Back then, the idea was that you would navigate primarily by clicking on links, creating your own “associative trails”, as first envisioned by Vannevar Bush.
But the WorldWideWeb application wasn’t just a browser. It was a Hypermedia Browser/Editor.
Documentmenu you opened, select
Mark allfrom the
test.htmldocument, and highlight a piece of text.
Link to markedfrom the
If you want, you can even save the hypertext document you created. Under the
Document menu there’s an option to
Save a copy offline (this is the one place where the wording of the menu item isn’t exactly what was in the original WorldWideWeb application). Save the file so you can open it up in a text editor and see what the markup would’ve looked it.
I don’t know about you, but I find this utterly immersive and fascinating. Imagine what it must’ve been like to browse, create, and edit like this. Hypertext existed before the web, but it was confined to your local hard drive. Here, for the first time, you could create links across networks!
After five days time-travelling back thirty years, I have a new-found appreciation for what Tim Berners-Lee created. But equally, I’m in awe of what my friends created thirty years later.
Of course Mark wanted to make sure the font was as accurate as possible. He and Brian went down quite a rabbit hole, and with remote help from David Jonathan Ross, they ended up recreating entire families of fonts.
Through it all, Craig and Martin put together the accomanying website. Personally, I think the website is freaking awesome—it’s packed with fascinating information! Check out the family tree of browsers that Craig made.
Bringing gradients back, baby!
This is going to be a handy reference to keep on hand whenever you want a button to actually look like a button.
A history of buttons …and the moral panic and outrage that accompanies them.
By looking at the subtexts behind complaints about buttons, whether historically or in the present moment, it becomes clear that manufacturers, designers and users alike must pay attention to why buttons persistently engender critiques. Such negativity tends to involve one of three primary themes: fears over deskilling; frustration about lack of user agency/control; or anger due to perceptions of unequal power relations.
It’s our job as designers to bring clarity back to the digital canvas by crafting reading experiences that put readers first.
A fellow URL fetishest!
I love me a well-designed URL scheme—here’s four interesting approaches.
URLs are consumed by machines, but they should be designed for humans. If your URL thinking stops at “uniquely identifies a page” and “good for SEO”, you’re missing out.
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?
I’ve come to believe that accessibility is not something you do for a small group of people. Accessibility is about promoting inclusion. When the product you use daily is accessible, it means that we all get to work with a greater number and a greater variety of colleagues. Accessibility benefits everyone.
I quite like this date-picking interface. It would be nice if browsers picked it up for
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?”
How mucking about in HTML and CSS can lead to some happy accidents.
‘Sfunny, people often mention the constraints and limitations of “designing in the browser”, but don’t recognise that every tool—including Sketch and Photoshop—comes with constraints and limitations. It’s just that those are constraints and limitations that we’ve internalised; we no longer even realise they’re there.
If you must add a rich text editor to an interface, this open source offering from Basecamp looks good.
URLs are the single greatest feature of the web.
The latest version of Chrome is removing seams by messing with the display of the URL.
This is a bug.
Change will be controversial whatever form it takes. But it’s important we do something, because everyone is unsatisfied by URLs. They kind of suck.
Citation very fucking needed.
I’m trying very hard to give Google the benefit of the doubt here, but coming as it does on top of all the AMP shit they’re pulling, it sure seems like Google are trying to remake the web in their image.
Oh, and if you want to talk about URLs confusing people, AMP is a great example.
I’m going through a pattern library right now, and this rings true:
I’m of the opinion that all cards in a Card UI are destined to become baby webpages. Just like modals. Baby hero units with baby titles and baby body text and baby dropdown menu of actions and baby call to action bars, etc.
In some ways this outcome is the opposite of what you were intending. You wanted a Card UI where everything was simple and uniform, but what you end up with is a CSS gallery website filled with baby websites.
I love, love, love all the little details of HTML that Aaron offers up here. And I really like how he positions non-visual user-agents like searchbots, screen readers, and voice assisants as headless UIs.
HTML is a truly robust and expressive language that is often overlooked and undervalued, but it has the incredible potential to nurture conversations with our users without requiring a lot of effort on our part. Simply taking the time to code web pages well will enable our sites to speak to our customers like they speak to each other. Thinking about how our sites are experienced as headless interfaces now will set the stage for more natural interactions between the real world and the digital one.
Enumerating the anti-patterns that cause serious user experience issues that don’t get nearly enough attention:
While such intrusions can be a source of irritation or even stress for many people, they may be complete showstoppers for people with anxiety or panic disorders.
I’m looking forward to reading the follow-up post.
(I was going to say I was anxiously awaiting the follow-up post but …never mind.)