On the Misuse of Common Tags

There are a number of HTML tags which are commonly misunderstood and misused. I’ve done it myself, with some frequency over the years. I’ve argued that some of these are deprecated, when they weren’t. And now I’ve come full circle, and I had a full on argument with someone over the use of the i tag recently, and I wanted to talk about four specific and oft misused tags: i, b, em and strong.

The Wrongest Interpretation – i = em, b = strong

Here is the worst stance you can have.

  • i and em mean italic and are the same
  • b and strong mean bold and are the same

There are a lot of people that still think this. It’s wrong. These don’t have the meanings that you think they do. em does not mean italic. i does not mean italic (not anymore, anyways, though techetymologically that’s where it came from).

Better, but not Great: i -> em, b -> strong

I was in this group for a long time, but after I started reading spec for HTML a few years ago, I started to understand that it’s incorrect:

  • i has been deprecated. Always use em instead.
  • b has been deprecated. Always use strong instead

Someone told me this and I listened, and went with it. I told other people this for years. I never really stopped to think about too hard, because I figured that better heads than mine had this figured out. The basic argument is that i and b have no meaning, but em and strong do have meaning. Well, that’s crap. They’re just tags; they only have the meaning that we attribute to them. Also, if we use this onto mapping, then strong and em have the exact same problems that b and i do, because they’re the same elements. Changing the tag has no added benefit.

The Right Way – i, b, em, strong are all viable tags

Here’s the right answer: i, b, em, and strong are all worthwhile and useful tags to use. That’s right – you can use the i tag and the b tag for things in your code. You’re absolutely right to do so! Just understand what each of them mean. Here are my interpretations of the HTML spec.

i

The i element is for text that is separate from normal prose, using a different voice, but with no particular emphasis. Some valid examples of this are technical jargon, taxonomies, transcriptions of altered states, or (very specifically) ship names in Western texts. These are items which are distinct from things that require emphasis; they are outside of the normal flow, and we do not necessarily want to attribute extra gravity to things inside of i tags.

For example, The Edmund Fitzgerald gets i-tagged if I were talking about the boat, but if I were talking about the song, I might emphasize The Wreck of The Edmund Fitzgerald.

If one were transcribing an experience that one had while under the influence of narcotics, one might put those in italics:

His eyes adjusted to the dimness after he put down his opium pipe. The walls took a deep breath and expelled it slowly. "This," thought the man, "is very good." 

If one were to explain in writing to the captain, via blog post, that one was out of dilithium crystals for the warp drive, one could use an i tag.

b

This is for use similarly; ascribing no extra emphasis, but without the need for a different voice. The best example for this is straight from the spec: text-driven adventure games where items are denoted, but have no particular emphasis on the items:

 You enter a small room. Your sword glows brighter. A rat scurries past the corner wall. 

em

Semantic markup for text that is emphasized for whatever reason – it attributes greater gravity to that section of the text.

You use this tag whenever something is quite important.

strong

Semantic markup for text with strong emphasis. This is text that has the greatest gravity.

Use this to emphasize things, not just to make them bold.

And that is probably more discussion that you’ve ever cared to read on those particular HTML tags!

Consistency and Death

This post is not about taxes.

There are a few key concepts that people rely on with a user interface and one of them is consistency. Consistency is one of the most important parts of a UI, and trumps practically any other; we want things to behave in a way that we are used to. This makes it easier for us to use things. Doors, for instance, have the same general UI in most cases; there is a handle, some hinges, and a big solid part that you can’t walk through until the handles and hinges have been dealt with. This is pretty standard, and we understand it and deal with it, even though it’s not the most user friendly way of dealing with changing state from room to room. A door is a pretty ho-hum kind of example though, especially when I have already insinuated that death is on the line in the title.

Let’s talk about traffic lights.

Traffic lights work in a fairly consistent fashion here in Ontario. I would say that 99% of the traffic I encounter on a daily basis follows these patterns and it’s important to note that this is not an optimal traffic pattern, but it is certainly sufficient, and one we are all used to. There are corresponding pedestrian signals; when one has a red light, one will expect pedestrians to pass perpendicular to your direction of travel, and while green, parallel. Here’s a bit of a chart.

My traffic signal Pedestrians perpendicular to me
Red Walk
Advanced Green (left turn only) Don’t Walk
Green Don’t Walk
Amber Get ready to Walk.

Here’s where I encountered a problem.

While driving the other day on the Hanlon in Guelph, I was waiting to turn left at an intersection that has recently undergone construction. There are now two left turn lanes, and the flow is generally better. However, I almost saw a pedestrian die, because the UI changed dramatically from the norm. When you are waiting to turn left, the pattern that you experience is like this: Red -> Green -> Advanced Green (left turn only – traffic parallel but opposite gets an amber) -> Amber. This is a simple change, but it made a big difference to the guy who almost got creamed by the Peterbilt that was roaring down the expressway. He was watching our signals, because he understood that there is a correspondence between those signals and his signals. He was watching the lights of the traffic coming towards me, and when it turned red, he made the assumption that he had a walk sign, because in the table above, that’s how it goes. That’s what he’s used to seeing.

However, the traffic my way did not have a red light; we had an advanced green, and the huge truck narrowly missed this fellow. There was much squawking of horns, and the guy ended up jumping out of the way; the truck squealed around to the right, and almost went off the road. It was a horrendous mess, and it almost ended up with an innocent guy, with a fair understanding of patterns, getting dead.

The lesson that I took away is this: if something is consistently done in a particular way, even if you think that you might have a better way to do it, consider long and hard all the ramifications of any changes you might make.

Why External Links Should NOT Open in New Tabs

I read an article today called Why External Links Should Open in New Tabs. This is something that is near and dear to my heart, and especially so since it is so very, very wrong.

Savvy Users have Changed Everything

Users are getting more and more used to how the web works and how to use their browser software. It’s true that if you ask the average person on the street what a browser is, they’re likely to say Google, but that doesn’t mean that when they open up “the internet” they don’t know what they’re doing. Using the web is part of the daily routine for millions of people, and those people are knowing more and more about how to use their browsers. People who know how their browser works know that they have the freedom to open links in another tab.

What About Old People?

Some people are not frequent users of the internet; they aren’t browser experts. The tabbed interface means nothing to them, and is only a confusion. They look at a browser, and when they click on something, they go somewhere. When they want to get back to where they have been, they use the Back Button. For this reason, opening a new window commits one of the cardinal sins of Usability: DON’T BREAK THE BACK BUTTON.
I’ve done UX testing on a good cross section of the population, but my favourite person to test on is my dad. He’s an “I am not good with computer” sort of person. When a site opens a new window, and he wants to get back to where he was, he cannot get back. He experiences extreme frustration, and stops web browsing. There have been several situations where he has been browsing to make a purchase, gotten frustrated, and left the computer to go to a store in person. That website lost a sale. This is a repeatable pattern; non-savvy person gets frustrated, closes entire window, does not finish call to action.

I’ve also done UX testing with people who have disabilities. The most frequently checked disability is sight loss; new tabs can present almost insurmountable problems to people who have poor sight. They cause confusion, frustration, and break the fundamental back button. The same is true for people who have cognition issues, or low sight, or manual dexterity issues.

Back Button Fatigue

This is not a real thing. People understand the back button, and are frustrated when it doesn’t work. Savvy users can open in a new window, or use bookmarks for navigation; if they don’t want to use the back button to navigate, they don’t.

Saving Website Resources

This is not an issue for a well crafted website. Your resources should be cached and have proper expires, and will load almost instantly and cost very little overhead after a back press.

Inaccurate Analytics

This is actually completely backwards. If a user is not reading your site, but has left it to read something else, your analytics should reflect this. They will then return to your site and finish reading. If you use external links, you end up with less useful information about how people are using your site; you over-report the time that people are spending on pages, and do not have an accurate representation of what is happening. Consider these user stories.

Story 1

Dave goes to http://www.acmewidgets.com and starts reading a stellar article about Acme’s latest widget. After reading for 5 minutes and getting midway through the article, there is a link to a wikipedia page that explains the science behind this widget. Dave opens this link, and it opens in a new tab automatically. Dave reads this page for 15 minutes, then closes that tab. This returns Dave to Acme’s page, and Dave continues reading for 10 minutes, then closes the Acme Widgets site.

Analytics show: Dave on site for half an hour. Time Dave spent on site: 15 minutes.

Story 2

Similar set up. Dave reads the article for 5 minutes, then clicks on a link, which opens in the same tab. He reads that link for 15 minutes, then returns to the site and reads for a further 10 minutes.

Analytics show: Dave on site for 5 minutes, then left, then returned for 10 minutes. Time Dave spent on site: exactly as analytics reported.

Overreporting your analytics is a bad idea. It give you false confidence and decisions based on bad data can give you bad results.

It’s All About Freedom, Baby

The bottom line is this: as a UX designer and developer, you have to consider several different users, and how they can interact with your site. Going out and talking to people about how they interact with a site is very helpful, but it’s even more helpful to observe how people interact with a site, and what causes frustration and what does not. A User should be free to do whatever they want with a given link; open in a new tab, open in the same tab, whatever they want to do. The basic groups to consider here are:

Super Savvy users, Super Savvy users who are disabled: they’re already middle clicking on things they want to open later. I’m guessing that Anthony, the author, is in this group, because the flow described here is one for a quite savvy user. This group doesn’t care if you open new windows or not, unless you specify to open a new window *when they want to open the link in the same window*. Then they experience frustration.

Medium Savvy users: they don’t necessarily know to middle click, but they know how to navigate. When something opens in the same tab, they know to use the back button. If something opens in a new tab, they can switch tabs. They’ll take whatever you throw at them. They may experience frustration if they click on a link, and have to go back, or re-navigate to your site; this is typically a fairly mild, momentary frustration.

Medium-Savvy users who are disabled: New tabs and New windows are the single worst thing on the internet.

Non-Savvy users, Non-Savvy users who are disabled: new tabs are scary. The back button is broken. Nothing works the way I want it to work. I’m closing this whole internet and going to the store or watching TV. New tabs are causing extreme frustration.

In Conclusion

Making the web accessible should be one of your highest priorities as a UX designer. Everyone needs to be able to do everything on the internet. It’s not about being fair (though accessibility does aim to be fair); it’s about getting people to do what you want them to do on your website. The bottom line is that making an accessible website isn’t particularly difficult to do, and it will increase your bottom line, whether that is more traffic, more money, or more users.

All links should be left alone to be opened however users want to open them. If you are trying to control how your users experience the web, you’re doing a disservice to them and to your website. You’ll erroneously inflate some of your analytics, and you’ll frustrate a significant portion of your user base.

Other resources:

Nielsen: http://www.useit.com/alertbox/9605.html

Webcredible: http://www.webcredible.co.uk/user-friendly-resources/web-usability/new-browser-windows.shtml

Good News Everyone!

In addition to reading this in the voice of Professor Farnsworth, you now know that my IE6 usage has dropped to well under 1%. To those of you still visiting in IE6, please take the time to complain to the internet cafe that you are browing from in Indonesia.

Yes, Google Analytics can be fairly specific…

That’s Undemocratic!

The past weekend, I was fortunate enough to get involved in a project called That’s Undemocratic, which is a tongue-in-cheek political satire site. My good friend Sean had the idea to use a popular style of meme featuring a focal picture, with two text areas, in an effort to remove the efficacy of the words “That’s Undemocratic” from the rhetoric of the current Canadian Election. I don’t want to get too politically preachy, but it seems like someone who shall remain nameless (but who has the initials “Stephen Harper”) used the phrase to describe something perfectly democratic.

It’s not a particularly difficult concept, and Imgur is doing the heavy lifting for us, but it was fun to work on. I mostly helped with planning (mostly over the phone) and also contributed the logo.

All you need is love. Du du du du du.