Handling links in Angular, buttons versus links, design system architecture, journey mapping

I found finishing last week’s weeknotes really fun. But I found writing them wasn’t as easy as I thought they’d be. That’s because it takes me a really long time to write things down with any clarity.

Still, they were really valuable to me. And like I said at the end of last week’s notes, having a more ‘official’ set of weeknotes will stop me drowning in Google Keep notes that, if I’m honest, I’m probably not going to look at again.

And then there’s the fact you can’t see them either 'coz their private.

One of the things I like already about writing weeknotes is that I can see how half-baked my thoughts are about things. And I hope to see how long it takes to find clarity on some of the topics I write down here.

There are so many interesting topics that crop up in my head, on the service I’m designing or more often that not talking to other people about an interesting thing. And to be able to remember them and realise how uncertain I am about them is useful to me.

Let’s go.

Insanity Max 30 — week three done

This training program is really hard and really fun. And in the third week it gets harder on day 2 and 4 with Tabata Strength. You’ll see that in my times below.

Also, I’m giving the optional 6th day a miss coz I’m to tired and I’m writing these notes instead.

First week fail times: 7:01 9:49 7:51 10:42 8:35

Second week fail times: 9:17 10:43 10:01 10:48 11:45

Third week fail times: 17:15 7:14 12:01 8:15 11:43

Five weeks to go.

Angular can handle links (yay)

Last week I noted down that Angular had problems with implementing links as links. And it doesn’t. I was wrong to say that.

This is how you do it:

<a [routerlink]="/url/goes/here">

And this will generate a regular link with an href that Angular knows to intercept. Lovely.

Buttons versus links

Last week I watched Oliver Byford’s brilliant talk at the London Accessibility Meetup. And at 11 minutes in he talks about how and why the GOV.UK start buttons (which are links) are converted into buttons.

In short:

  • JavaScript makes the space key activate the link
  • role="button" is added to the link so that it’s recognised and announced as button by voice dictation and screen reader software.
  • draggable="false" is added to the link so that people with dexterity impairments don’t accidentally drag the link instead of cliking it.

Things swirling around in my head are:

  • It’s a win for voice dictation users because they see a button and they interact with it as a button.
  • For screen reader users I’m less sure. Normally links would be part of the links list (activated with a special shortcut). If it was a link, users may want to bookmark or open it in a new window. On the other hand, start buttons in this context aren’t likely to be bookmarked. And sighted (screen reader) users might not realise it’s a link because it looks like a button, so they wouldn’t bother trying to do those things anyway.
  • Preventing the ability to drag the button (link) stops me from dragging it onto the bookmarks bar. And arguably we’d want to add the attribute to every link on the page, not just ones that look like buttons? Maybe more needs to be done here beyond just an attribute. Like if the user does a little drag ignore it, but a big drag might indicate a clearer intent to drag it.
  • Implementation wise, I’m thinking why not just make it a button (when JS is available and capable) and make it redirect. That should be a lot less code overall.
  • The team that worked on this are the most thoughtful designers I know so I’m interested to find out more about what went into the decision.

Like always, design is about tradeoffs—more specifically making the right ones. Despite the points above, it still seems like a reasonable decision has been made.

Design system architectural choices

From the same talk I noticed that Ollie’s fictional service used bolder and bigger label/legend styles for the form fields than what the default provides in the GOV.UK Design System.

And I found that interesting because in the services I’ve been designing I’ve also made the labels/legends bigger and bolder. I’ve done this because:

  • it’s more consistent with fields where the label or legend and h1 are one and the same and therefore bold and much bigger.
  • it provides a better hierarchy by clearly differentiating between the field’s label and the hint text. Or the individual input label within the field like you’d find with radio buttons.

That led me to asking the GOV.UK Design System team why the defaults are smaller and not bold. This was the response:

The reason the labels have the standard font size / style as default is that in a lot of cases this is what you’d want. Any scenario that has a group of inputs, such as Addresses, Credit card numbers, Date Input want the lowest hierarchy on the inputs themselves so that you can bump up the legend one level.

In addition to that is also allows us to have a label component that can be used across radios and checkboxes. It’s not a technical constraint as such, it was a system choice.

Because most of the way we’ve constructed the components is additive , the default for something like this would be the base style and we give you the tools to add to it when your design requires.

This is really useful to know because I can see how my suggestion is problematic within the current architecture. And while there are ways around it, there would be tradeoffs in changing the defaults to be what I thought they should be.

Which is another important point. The design system serves lots of users. This would need to become a much bigger problem to warrant the effort of changing this. Because ultimately with little effort I am able to configure the components as I need.

This is good example of how technology and design are intertwined and should be considered together.

Confused by mapping

One of my big skills gaps is in creating maps: journey maps, service blueprints and things like that.

I get confused partly because I’ve just not done very much of it, and because I am often finding myself getting hung up on what the columns and swimlanes should be. Other times I think I need a journey map, but what I need is more like a comic book strip.

What I’m very slowly learning is to not get hung up on the structure and think about the problem I’m trying to solve and who the map is intended for. That sounds great, but I feel this will take me a long time to grasp.

I really need someone to model this for me—like with 100 different maps. Any takers?