Tags: ui

709

sparkline

Tuesday, April 16th, 2019

Three more Patterns Day speakers

There are 73 days to go until Patterns Day. Do you have your ticket yet?

Perhaps you’ve been holding out for some more information on the line-up. Well, I’m more than happy to share the latest news with you—today there are three new speakers on the bill…

Emil Björklund, the technical director at the Malmö outpost of Swedish agency inUse, is a super-smart person I’ve known for many years. Last year, I saw him on stage in his home town at the Confront conference sharing some of his ideas on design systems. He blew my mind! I told him there and then that he had to come to Brighton and expand on those thoughts some more. This is going to be an unmissable big-picture talk in the style of Paul’s superb talk last year.

Speaking of superb talks from last year, Alla Kholmatova is back! Her closing talk from the first Patterns Day was so fantastic that it I just had to have her come back. Oh, and since then, her brilliant book on Design Systems came out. She’s going to have a lot to share!

The one thing that I felt was missing from the first Patterns Day was a focus on inclusive design. I’m remedying that this time. Heydon Pickering, creator of the Inclusive Components website—and the accompanying book—is speaking at Patterns Day. I’m very excited about this. Given that Heydon has a habit of casually dropping knowledge bombs like the lobotomised owl selector and the flexbox holy albatross, I can’t wait to see what he unleashes on stage in Brighton on June 28th.

Emil Björklund Alla Kholmatova Heydon Pickering
Emil, Alla, and Heydon

Be there or be square.

Tickets for Patterns Day are still available, but you probably don’t want to leave it ‘till the last minute to get yours. Just sayin’.

The current—still incomplete—line-up comprises:

That isn’t even the full roster of speakers, and it’s already an unmissable event!

I very much hope you’ll join me in the beautiful Duke of York’s cinema on June 28th for a great day of design system nerdery.

Wednesday, April 10th, 2019

Improving accessibility with accessibility acceptance criteria — Paul Hayes

Wouldn’t it be great if every component in your design system had accessibility acceptance criteria? Paul has some good advice for putting those together:

  • Start with accessibility needs
  • Don’t be too generic
  • Don’t define the solution
  • Iterate criteria

Monday, April 8th, 2019

User interfaces: hiding stuff should be a last resort by Adam Silver

When we hide content, there’s a greater risk the user won’t see it. There’s a higher reliance on digital literacy and it’s generally more labour intensive for the user.

Worse still, sometimes we kill off essential content.

Sunday, April 7th, 2019

Drag’n’drop revisited

I got a message from a screen-reader user of The Session recently, letting me know of a problem they were having. I love getting any kind of feedback around accessibility, so this was like gold dust to me.

They pointed out that the drag’n’drop interface for rearranging the order of tunes in a set was inaccessible.

Drag and drop

Of course! I slapped my forehead. How could I have missed this?

It had been a while since I had implemented that functionality, so before even looking at the existing code, I started to think about how I could improve the situation. Maybe I could capture keystroke events from the arrow keys and announce changes via ARIA values? That sounded a bit heavy-handed though: mess with people’s native keyboard functionality at your peril.

Then I looked at the code. That was when I realised that the fix was going to be much, much easier than I thought.

I documented my process of adding the drag’n’drop functionality back in 2016. Past me had his progressive enhancement hat on:

One of the interfaces needed for this feature was a form to re-order items in a list. So I thought to myself, “what’s the simplest technology to enable this functionality?” I came up with a series of select elements within a form.

Reordering

The problem was in my feature detection:

There’s a little bit of mustard-cutting going on: does the dragula object exist, and does the browser understand querySelector? If so, the select elements are hidden and the drag’n’drop is enabled.

The logic was fine, but the execution was flawed. I was being lazy and hiding the select elements with display: none. That hides them visually, but it also hides them from screen readers. I swapped out that style declaration for one that visually hides the elements, but keeps them accessible and focusable.

It was a very quick fix. I had the odd sensation of wanting to thank Past Me for making things easy for Present Me. But I don’t want to talk about time travel because if we start talking about it then we’re going to be here all day talking about it, making diagrams with straws.

I pushed the fix, told the screen-reader user who originally contacted me, and got a reply back saying that everything was working great now. Success!

Saturday, April 6th, 2019

Accessibility for Vestibular Disorders: How My Temporary Disability Changed My Perspective · An A List Apart Article

This is a fascinating insight into what it’s like to use the web if you’ve got vertigo (which is way more common than you might think):

Really, there are no words to describe just how bad a simple parallax effect, scrolljacking, or even background-attachment: fixed would make me feel. I would rather jump on one of those 20-G centrifuges astronauts use than look at a website with parallax scrolling.

Every time I encountered it, I would put the bucket beside me to good use and be forced to lie in bed for hours as I felt the room spinning around me, and no meds could get me out of it. It was THAT bad.

Cool goal

One evening last month, during An Event Apart Seattle, a bunch of the speakers were gathered in the bar in the hotel lobby, shooting the breeze and having a nightcap before the next day’s activities. In a quasi-philosophical mode, the topic of goals came up. Not the sporting variety, but life and career goals.

As I everyone related (confessed?) their goals, I had to really think hard. I don’t think I have any goals. I find it hard enough to think past the next few months, much less form ideas about what I might want to be doing in a decade. But then I remembered that I did once have a goal.

Back in the ’90s, when I was living in Germany and first starting to make websites, there was a website I would check every day for inspiration: Project Cool’s Cool Site Of The Day. I resolved that my life’s goal was to one day have a website I made be the cool site of the day.

About a year later, to my great shock and surprise, I achieved my goal. An early iteration of Jessica’s site—complete with whizzy DHTML animations—was the featured site of the day on Project Cool. I was overjoyed!

I never bothered to come up with a new goal to supercede that one. Maybe I should’ve just retired there and then—I had peaked.

Megan Sapnar Ankerson wrote an article a few years back about How coolness defined the World Wide Web of the 1990s:

The early web was simply teeming with declarations of cool: Cool Sites of the Day, the Night, the Week, the Year; Cool Surf Spots; Cool Picks; Way Cool Websites; Project Cool Sightings. Coolness awards once besieged the web’s virtual landscape like an overgrown trophy collection.

It’s a terrific piece that ponders the changing nature of the web, and the changing nature of that word: cool.

Perhaps the word will continue to fall out of favour. Tim Berners-Lee may have demonstrated excellent foresight when he added this footnote to his classic document, Cool URIs don’t change—still available at its original URL, of course:

Historical note: At the end of the 20th century when this was written, “cool” was an epithet of approval particularly among young, indicating trendiness, quality, or appropriateness.

Thursday, April 4th, 2019

A progressive disclosure component - Andy Bell

This is a really nice write-up of creating an accessible progressive disclosure widget (a show/hide toggle).

Where it gets really interesting is when Andy shows how it could all be encapsulated into a web component with a progressive enhancement mindset

Friday, March 29th, 2019

CSS { In Real Life } | Building a dependency-free site in 2019

I think we’re often guilty of assuming that because our tools are great solutions for some things, they’re automatically the solution for everything.

Wednesday, March 13th, 2019

Unpoly: Unobtrusive JavaScript framework

This looks like it could be an interesting library of interface patterns.

Saturday, March 9th, 2019

Handing back control

An Event Apart Seattle was most excellent. This year, the AEA team are trying something different and making each event three days long. That’s a lot of mindblowing content!

What always fascinates me at events like these is the way that some themes seem to emerge, without any prior collusion between the speakers. This time, I felt that there was a strong thread of giving control directly to users:

Sarah and Margot both touched on this when talking about authenticity in brand messaging.

Margot described this in terms of vulnerability for the brand, but the kind of vulnerability that leads to trust.

Sarah talked about it in terms of respect—respecting the privacy of users, and respecting the way that they want to use your services. Call it compassion, call it empathy, or call it just good business sense, but providing these kind of controls in an interface is an excellent long-term strategy.

In Val’s animation talk, she did a deep dive into prefers-reduced-motion, a media query that deliberately hands control back to the user.

Even in a CSS-heavy talk like Jen’s, she took the time to explain why starting with meaningful markup is so important—it’s because you can’t control how the user will access your content. They may use tools like reader modes, or Pocket, or have web pages read aloud to them. The user has the final say, and rightly so.

In his CSS talk, Eric reminded us that a style sheet is a list of strong suggestions, not instructions.

Beth’s talk was probably the most explicit on the theme of returning control to users. She drew on examples from beyond the world of the web—from architecture, urban planning, and more—to show that the most successful systems are not imposed from the top down, but involve everyone, especially those most marginalised.

And even in my own talk on service workers, I raved about the design pattern of allowing users to save pages offline to read later. Instead of trying to guess what the user wants, give them the means to take control.

I was really encouraged to see this theme emerge. Mind you, when I look at the reality of most web products, it’s easy to get discouraged. Far from providing their users with controls over their own content, Instagram won’t even let their customers have a chronological feed. And Matt recently wrote about how both Twitter and Quora are heading further and further away from giving control to their users in his piece called Optimizing for outrage.

Still, I came away from An Event Apart Seattle with a renewed determination to do my part in giving people more control over the products and services we design and develop.

I spent the first two days of the conference trying to liveblog as much as I could. I find it really focuses my attention, although it’s also quite knackering. I didn’t do too badly; I managed to write cover eleven of the talks (out of the conference’s total of seventeen):

  1. Slow Design for an Anxious World by Jeffrey Zeldman
  2. Designing for Trust in an Uncertain World by Margot Bloomstein
  3. Designing for Personalities by Sarah Parmenter
  4. Generation Style by Eric Meyer
  5. Making Things Better: Redefining the Technical Possibilities of CSS by Rachel Andrew
  6. Designing Intrinsic Layouts by Jen Simmons
  7. How to Think Like a Front-End Developer by Chris Coyier
  8. From Ideation to Iteration: Design Thinking for Work and for Life by Una Kravets
  9. Move Fast and Don’t Break Things by Scott Jehl
  10. Mobile Planet by Luke Wroblewski
  11. Unsolved Problems by Beth Dean

Thursday, March 7th, 2019

Optimizing for outrage – A Whole Lotta Nothing

I have no doubt that showing just the top outrageous tweets leads to more engagement. If you’re constantly hitting people with outlandish news stories they’ll open the app more often and interact and post about what they think so the cycle continues.

Tuesday, March 5th, 2019

Mobile Planet by Luke Wroblewski

It’s the afternoon of day two of An Event Apart in Seattle. The mighty green one, Luke Wroblewski, is here to deliver a talk called Mobile Planet:

With 3.5 billion active smartphones on Earth, we’re now faced with the challenges and opportunities of designing planet-scale software. Through a data-informed, big-picture walk-through of our mobile planet, Luke will dig into how people use computing devices today and how the design of our products needs to adapt to this reality. He’ll cover key issues like app on-boarding and performance in enough detail to give you clear ways to improve first time and subsequent use of your mobile apps and sites.

Luke has been working on figuring out hardware and software for years. He looks at a lot of data. The more we understand how people use technology in their daily lives, the better we can design for them.

Earth is the third planet from the sun, and the only place that we know of that harbours life. Our population is at about 7.7 billion people. There are about 5.6 billion people in our addressable market (people over 14 years old). There are already 5 billion mobile subscribers in there. That’s interesting, but which of those devices are modern smartphones? There are about 3.6 billion active smartphones. Compare that to about 1.3 billion active personal computers—the vast majority of them Windows devices (about 1.2 billion). Over the next four or five years, we’ll have about 5 billion smartphone users and a global population of 8 billion.

The point is that we can reach a significant proportion of the human species. The diversity of our species makes it challenging to design for everyone.

Let’s take a closer look at these 3.6 billion active smartphones. About 25% of them are iOS devices. 75% of them are Android. Bear in mind that these are active devices—what’s actually being used. That’s different to shipping devices. Apple ships 15% of smartphone, and Android ships 85%, but the iOS devices tend to have longer lifespans (around 2 years for Android; around 4 years for iOS).

The UK has 82% smartphone penetration. Compare that to India, where it’s 27%. There’s room to grow.

Everywhere you look, the growth of these devices has led to a shift of digital things overtaking analogue. Shopping, advertising, music, you name it. We’ve seen enough of these transitions happen, that we should be prepared for it.

So there are lots of smartphones, with basically two major operating systems. But how are people using these devices?

In the US, adults spend about 2.3 - 3.5 hours per day on their mobile devices. Let’s call it an even 3 hours. That’s a lot of time. Where does that time come from? Interestingly, as time spent on mobile devices has surged, time spent on other media has only slowly declined. So mobile is additive. It’s contributing to more time spent on the internet rather than taking it away from existing screen time.

Next question: what the hell are people doing during those 3 hours per day on smartphones? Native apps get about 169 minutes of time compared to only 11 minutes on the web. There are about 2 million native apps on Apple, and about 2 million native apps on Android. But although people have a lot of apps, people only use about half them. Remember folks, downloads does not equal usage. Most apps don’t make it past the first opening. Only a third make it past being opened ten times.

Because people spend so much time and energy on these apps, and given the abysmal abandonment, people start freaking out about “engagement.” So what do they reach for? Push notifications. Either that or onboarding.

Push notifications. The worst. I mean, they do succeed in getting your attention: push notifications do increase the amount of time spent in your app …but there’s a human cost.

Let’s look at app onboarding. Take Flickr, for example. It walks through some of the features and benefits of the service. But it doesn’t actually help you much. It’s a list of marketing slogans. So why do people reach for onboarding?

If you just drop people into an interface and talk to them about it, they’ll say things like “I don’t know what to do. I’m lost.” The Intuit team heard this from people using their app. They reached for onboarding to solve the problem. They created guided tutorials and intro tours. Turns out that nobody would read these screens and everyone would try to skip them. What the hell, people!?

So they try in-context help, with a cute cartoon robot to explain the features. Or they scribble Einstein’s equations over the interface. Test this. People respond with “Please make it stop.”

They decided to try something simpler: one tip that calls out a good first step. That worked.

Vevo used to have an intro tour. Most people were swiping through without reading. They experimented with not running the tour. They got a 10% increase in log-ins and a 6% increase in sign-ups.

Vevo got rid of their tour, but left the sign-in/registration step. You can’t remove that, right?

Well, Hotel Tonight experimented with not doing registration. Signing up was confusing people—it’s Hotels Tonight, not Accounts Today. When they got rid of accounts, they saw a 15% increase in conversions.

Ruthlessly edit.

Google Photos used to have an in-depth on-boarding experience. First they got rid of the animation. Then the start-up screen. Then the animated tutorial. Each time they removed something, conversion went up. All that was left from the original onboarding was a half screen with one option to turn on auto-backup.

Get to your product value as fast as possible. Of course that requires you to know what your core value is. And that’s not easy to figure out.

Google Maps went through a similar reduction, removing intro screens and explanations. Now they just drop you into the map.

It’s not “get rid of everything”. It’s “get rid of everything that gets in the way of the core user action.”

Going back to the Intuit example, that’s exactly what they did in the end. That one initial tip was for the core action.

But it’s worth discussing how to present this kind of thing. If you have to overlay a tooltip for an important UI feature, maybe that UI feature should have a clearer affordance. People treat overlays as annoyances. People ignore or dismiss overlays when they’re focused on a task. It’s like an instinct to get rid of them. So if you put something useful or valuable there, it’s gone.

The core part of your application should feel like the core part of your application. It’s tough because stakeholders want to make things “pop.” We throw contrast, colour, and animation at things. But when something sticks out from the UI, people ignore it. Integrate the core action into the product UI. When elements feel foreign to a product UI, they are at best ignored, or at worst dismissed.

These is why cohesive design matters. It’s not about consistency. It’s about feeling integrated. In many cases, consistency can be counter-productive.

Some principles for successful onboarding:

  1. Get to to the product value as fast as possible. Grubhub needs your address. Pinterest needs your interests.
  2. Get rid of everything that doesn’t lead to that product value. Ruthlessly edit. Remove all friction that distracts the user from experiencing product value.
  3. Don’t be afraid to educate contextually. But do so with integrated UI.

Luke talked a lot about what’s happening in mobile apps, and mentioned that the mobile web only gets 11 minutes to the native’s 169. But let’s dive into this, because people sometimes think that a “mobile strategy” comes down to picking between these two. 50% of those 169 minutes are spent in your most used app (Facebook). 78% of the time is spent in the top 5 apps. Now the mobile web doesn’t look so bad. It turns out you can get people to a mobile web experience much, much faster than to a native one. The audience size is much, much, much higher on the web (although people will do more in a dedicated native app). So strategically both are useful—the web can attract people to native.

Back to our planet, and those 3 hours of usage on smartphones every day. People unlock their phones around 80 times a day. The average time people sleep is about 8 hours. So for every 12 waking minutes, you’re unlocking your phone. Given this frequency, it’s unsurprising that most sessions are very short—most under 30 seconds.

Given that, if things are slow, you’re going to really, really, really hate it. Waiting for slow pages to load is what really pisses people off.

The cognitive load and stress of waiting for slow pages is worse than waiting in line in a store, or watching a horror movie. That’s an industry that’s all about stressing people out by design! But experiencing mobile delays is more stressful! Probably because people aren’t watching horror movies every 12 minutes.

Because mobile delays are such a big deal, many mobile apps reach for loading spinners. But Luke saw that adding a spinner to his product increased complaints of slow loading times. Of course! The spinner is explicitly telling people, “Hey, we’re slow.”

So the switched to skeleton screens. This should feel like something is always happening. Focus on the progress, not the progress indicator. Occupied time feels shorter than unoccupied time.

A lot of people have implemented skeleton screen, but without the progressive loading. Swapping out a skeleton screen to a completely different UI all at once doesn’t help. The skeleton screens should represent the real content.

This is a lot of work; figuring how to prioritise what to load first. Luke isn’t talking about the techical side here, but the user’s experience. Investing in getting this right makes a lot of sense.

Let’s look a little closer at this number: people interacting with their phones 80 times a day. The average user touches the device 2,617 times a day. A power user touches the device over 5,000 times a day. Most touches are within one app.

90% of the touches are dealing with one thumb. Young people tend to operate with one hand. For older people, it’s more like 60%.

This is why your interface targets need to work for the thumb.

On phones, 90% of the time you’re dealing with portrait mode. Things at the top of the screen on larger devices are hard to reach. Core actions gravitate to the bottom of the screen.

Opera Touch is a new browser designed specifically for one-handed use. The Palm Pre’s WebOS was also about one-hand usage. Now that’s how iOS and Android work: swiping up from the bottom.

So mobile usage is:

  • One-handed/thumb.
  • In portrait mode on large screens.
  • Design accordingly.

What’s next? What do we need to be aware of so we don’t get caught with our pants down?

We can use the product lifecycle chart to figure this out. There’s an emergent phase, then a growth phase, then consolidation in a mature market, and then that gets disrupted and becomes a declining market.

  • Mobile devices—hand computers—are in a mature consolidated market.
  • Desktop and laptop computers are in a declining market.
  • Wrist computers and voice computers are in a growth market.

Small screens get used more frequently, but for shorter periods of time than large screens. Wrist and voice computers are figuring out what their core offerings are.

In the emergent category, it’s all about exploration. We have no idea how things will turn out. We just don’t know. But we do know that we are now designing for lots and lots of different devices.

For today, though, focusing on mobile is still a pretty good idea.

To summarise:

  • It’s a mobile planet.
  • Understanding real world usage helps you design.
  • Prep for what’s next

Thursday, February 28th, 2019

Patterns Day 2: June 28th, 2019

Surprise! Patterns Day is back!

The first Patterns Day was in the Summer of 2017, and it was a glorious—a single day devoted to all things design system-y: pattern libraries, style guides, maintainability, reusability. It was a lot of fun, so let’s do it again!

Patterns Day 2 will take place on Friday, June 28th, in the beautiful Duke of York’s cinema in Brighton. If you went to the first Patterns Day, then you’ll know how luxuriously comfy it is in there.

Tickets are £175+VAT. The format will likely be the same as before: an action-packed day of eight talks, each 30 minutes long.

I’ve got an amazing line-up of speakers, but instead of telling you the whole line-up straightaway, I’m going to tease a little bit, and announce more speakers over the next few weeks and months. For now, here are the first three speakers, to give you an idea of the quality you can expect:

  • All the way from the US of A, it’s Una Kravets, who needs no introduction.
  • From the Government Digital Service, we’ve got Amy Hupe—she’ll have plenty to share about the GOV.UK design system.
  • And we’ve got Yaili, now a senior designer at Microsoft, where she works on the Azure DevOps design system.

Patterns Day will have something for everyone. We’ll be covering design, development, content strategy, product management, and accessibility. So you might want to make this a one-day outing for your whole team.

If you want to get a feel for what the day will be like, you can watch the videos of last year’s talks

Tickets for last year’s Patterns Day went fairly fast—the Duke of York’s doesn’t have a huge capacity—so don’t dilly-dally too long before grabbing your ticket!

Friday, February 22nd, 2019

Don’t Get Clever with Login Forms | Brad Frost

  1. Have a dedicated page for login
  2. Expose all required fields
  3. Keep all fields on one page
  4. Don’t get fancy

Thursday, February 21st, 2019

Design sprint?

Our hack week at CERN to reproduce the WorldWideWeb browser was five days long. That’s also the length of a design sprint. So …was what we did a design sprint?

I’m going to say no.

On the surface, our project has all the hallmarks of a design sprint. A group of people who don’t normally work together were thrown into an instense week of problem-solving and building, culminating in a tangible testable output. But when you look closer, the journey itself was quite different. A design sprint is typical broken into five phases, each one mapped on to a day of work:

  1. Understand and Map
  2. Demos and Sketch
  3. Decide and Storyboard
  4. Prototype
  5. Test

Gathered at CERN, hunched over laptops.

There was certainly plenty of understanding, sketching, and prototyping involved in our hack week at CERN, but we knew going in what the output would be at the end of the week. That’s not the case with most design sprints: figuring out what you’re going to make is half the work. In our case, we knew what needed to be produced; we just had to figure out how. Our process looked more like this:

  1. Understand and Map
  2. Research and Sketch
  3. Build
  4. Build
  5. Build

Now you could say that it’s a kind of design sprint, but I think there’s value in reserving the term “design sprint” for the specific five-day process. As it is, there’s enough confusion between the term “sprint” in its agile sense and “design sprint”.

Sunday, February 17th, 2019

The ineffectiveness of lonely icons | Matt Wilcox, Web Developer & Tinkerer

When in doubt, label your icons.

When not in doubt, you probably should be.

Saturday, February 16th, 2019

WorldWideWeb

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:

worldwideweb.cern.ch

That’s the website we built. The call to action is hard to miss:

Launch WorldWideWeb

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:

  1. Select Document from the menu options on the left.
  2. A new menu will pop open. Select Open from full document reference.
  3. Type a URL, like, say https://adactio.com
  4. Press that lovely chunky Open button.

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.

  1. From that Document menu you opened, select New file…
  2. Type the name of your file; something like test.html
  3. Start editing the heading and the text.
  4. In the main WorldWideWeb menu, select Links.
  5. Now focus the window with the document you opened earlier (adactio.com).
  6. With that window’s title bar in focus, choose Mark all from the Links menu.
  7. Go back to your test.html document, and highlight a piece of text.
  8. With that text highlighted, click on Link to marked from the Links menu.

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.

Remy did all the JavaScript for the recreated browser …in just five days!

Kimberly was absolutely amazing, diving deep into the original source code of the application on the NeXT machine we borrowed. She uncovered some real gems.

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.

John exhaustively documented UI patterns that Angela turned into marvelous HTML and CSS.

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.

What a team!

Saturday, February 9th, 2019

Proper UI hierarchy · accssible

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.

Friday, February 1st, 2019

Readable Code without Prescription Glasses | Ocasta

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!).

Thursday, January 31st, 2019

New Adventures 2019

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.

(By the way, if you’d like me to run this workshop at your company, get in touch.)

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.

Wearing my eye-watering loud paisley shirt on stage at New Adventures.

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.