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.
I saw Daniel give a talk at Async where he compared linguistic rules with code style:
We find the prescriptive rules hard to follow, irrespective of how complex they are, because they are invented, arbitrary, and often go against our intuition. The descriptive rules, on the other hand, are easy to follow because they are instinctive. We learned to follow them as children by listening to, analysing and mimicking speech, armed with an inbuilt concept of the basic building blocks of grammar. We follow them subconsciously, often without even knowing the rules exists.
Thus began some thorough research into trying to uncover a universal grammar for readable code:
I am excited by the possibility of discovering descriptive readability rules, and last autumn I started an online experiment to try and find some. My experiment on howreadable.com compared various coding patterns against each other in an attempt to objectively measure their readability. I haven’t found any strong candidates for prescriptive rules so far, but the results are promising and suggest a potential way forward.
I highly recommend reading through this and watching the video of the Async talk (and conference organisers; get Daniel on your line-up!).
My trip to Nottingham for the New Adventures conference went very well indeed.
First of all, I had an all-day workshop to run. I was nervous. Because I no longer prepare slides for workshops—and instead rely on exercises and discussions—I always feel like I’m winging it. I’m not winging it, but without the security blanket of a slide deck, I don’t have anything to fall back on.
As it turned out, I needn’t have worried. The workshop went great. Well, I thought it went great but you’d really have to ask the attendees to know for sure. One of the workshop participants, Westley Knight, wrote about his experience:
The workshop itself was fluid enough to cater to the topics that the attendees were interested in; from over-arching philosophy to technical detail around service workers and new APIs. It has helped me to understand that learning in this kind of environment doesn’t have to be rigorously structured, and can be shaped as the day progresses.
With the workshop done, it was time for me to freak out fully about my conference talk. I was set to open the show. No pressure.
Actually, I felt pretty damn good about what I had been preparing for the past few months (it takes me aaages to put a talk together), but I always get nervous about presenting new material—until I’ve actually given the talk in front of a real audience, I don’t actually know if it’s any good or not.
Clare was speaking right after me, but she was having some technical issues. It’s funny; as soon as she had a problem, I immediately switched modes from conference speaker to conference organiser. Instead of being nervous, I flipped into being calm and reassuring, getting Clare’s presentation—and fonts—onto my laptop, and making sure her talk would go as smoothly as possible (it did!).
My talk went down well. The audience was great. Everyone paid attention, laughed along with the jokes, and really listened to what I was trying to say. For a speaker, you can’t ask for better than that. And people said very nice things about the talk afterwards. Sam Goddard wrote about how it resonated with him.
You can peruse the slides from my presentation but they make very little sense out of context. But video of the talk is forthcoming.
The advantage to being on first was that I got my talk over with at the start of the day. Then I could relax and enjoy all the other talks. And enjoy them I did! I think all of the speakers were feeling the same pressure I was, and everybody brought their A-game. There were some recurring themes throughout the day: responsibility; hope; diversity; inclusion.
So New Adventures was already an excellent event by the time we got to Ethan, who was giving the closing talk. His talk elevated the day into something truly sublime.
Look, I could gush over how good Ethan’s talk was, or try to summarise it, but there’s really no point. I’ll just say that I felt the same sense of being present at something genuinely important that I felt when I was in the room for his original responsive web design talk at An Event Apart back in 2010. When the video is released, you really must watch it. In the meantime, you can read through the articles and books that Ethan cited in his presentation.
New Adventures 2019 was worth attending just for that one talk. I was very grateful I had the opportunity to attend, and I still can’t quite believe that I also had the opportunity to speak.
A really terrific piece from Garrett on the nature of the web:
Markup written almost 30 years ago runs exactly the same today as it did then without a single modification. At the same time, the platform has expanded to accommodate countless enhancements. And you don’t need a degree in computer science to understand or use the vast majority of it. Moreover, a well-constructed web page today would still be accessible on any browser ever made. Much of the newer functionality wouldn’t be supported, but the content would be accessible.
I share his concerns about the maintainability overhead introduced by new tools and frameworks:
I’d argue that for every hour these new technologies have saved me, they’ve cost me another in troubleshooting or upgrading the tool due to a web of invisible dependencies.
Here are the slides for the opening keynote I delivered at the New Adventures conference in Nottingham on Thursday. They make no sense out of context like this. You kinda had to be there (or suggest to some other conference that I should deliver this talk again—hint, hint).
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.
An excellent thorough analysis by Chris of the growing divide between front-end developers and …er, other front-end developers?
The divide is between people who self-identify as a (or have the job title of) front-end developer, yet have divergent skill sets.
On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.
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.
I have to admit, I’m kind of nervous about this talk. It’s been quite a while since the last New Adventures, but it’s always had quite the cachet. I think I went to most of them. It’s quite strange—and quite an honour—to shift gears from attendee to speaker.
The talk I’ll be giving is called Building. That might be a noun. That might be a verb. You decide:
Every new medium looks to what has come before for guidance. Web design has taken cues from centuries of typography and graphic design. Web development has borrowed metaphors and ideas from the world of architecture. Let’s take a tour of some of the most influential ideas from architecture that have crossed over into the web, from pattern languages to responsive design. Together we’ll uncover how to build resilient, performant, accessible and beautiful structures that work with the grain of the materials of the web.
This talk builds upon the talk I gave at last year’s An Event Apart called The Way Of The Web. It also reflects many of the ideas in Resilient Web Design. When I gave a run-through of the talk at Clearleft last week, Andy called it a “greatest hits.” For a while there, I was feeling guilty about retreading some ground I’ve covered in previous talks and writings. Then I realised it was pretty arrogant of me to think that anyone in the audience would be familiar with any of it.
Besides, I’ve got a whole new avenue of exploration in this talk. It’s about language and metaphor—how we talk about what we do on the web. I’ve just finished giving another run-through at the Clearleft studio and I’m feeling pretty good about it. That’s good, because I find that giving a talk in a small room to a handful of colleagues is way more stressful than giving a talk to hundreds of people at a conference.
Just as I put together links related to last year’s talk, I figured I’d provide some hyperlinks for anyone interested in the topics raised in this new talk…
There’s something quite lovely about this site, both in its purpose and execution.
Dimensions.Guide is a comprehensive reference database of dimensioned drawings documenting the standard measurements and sizes of the everyday objects and spaces that make up our world. Created as a universal resource to better communicate the basic properties, systems, and logics of our built environment, Dimensions.Guide is a free platform for increasing public and professional knowledge of life and design.
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.
In which Matthew disects a multiple choice quiz that uses CSS to do some clever logic, using the
:checked pseudo-class and
Dave on the opaqueness of toolchains:
As toolchains grow and become more complex, unless you are expertly familiar with them, it’s very unclear what transformations are happening in our code. Tracking the differences between the input and output and the processes that code underwent can be overwhelming. When there’s a problem, it’s increasingly difficult to hop into the assembly line and diagnose the issue.
There’s a connection here to one of the biggest issues with what’s currently being labelled “AI”:
In the same way AI needs some design to show its work in how it came to its final answer, I feel that our automated build tools could use some help as well.
I really like this suggestion for making the invisble visible:
I sometimes wonder if Webpack or Gulp or [Insert Your Build Tool Here] could benefit from a Scratch-like interface for buildchains.
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?
A starter list of Fractal examples and links. You can expand it.
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.
When is a space not a space?
Tom talks about ogham stones and unicode.