Categories
User experience, web, technology

The problem with the line break (BR) tag

We’ve got the <br /> tag all wrong. It’s time to make it right.

We all know the <br /> tag is used to insert a line break in HTML. But what we’ve been missing is that we were too often after something else. Let me explain.

Common reasons to use line breaks

Why would a web writer interrupt a passage of text with a forced line break? Here are a few possibilities.

  • Trying to avoid an orphan
  • Inserting a line break before a 2-word proper noun, like “American Airlines,” so the noun isn’t split
  • Formatting content like a mailing address

The problem with line breaks (<br /> tags)

Forcing a line to break in a document that will be printed is a no-brainer. But web writing has different constraints that we shouldn’t ignore.

Copy on the web has the luxury and burden of being portable. That text can show up anywhere:

  • in an e-mail message
  • on some other web page
  • in an RSS reader
  • copied and pasted into a Tweet
  • in a web browser on a mobile phone

This means that the line length you wrote your text for is simply not reliable. You need to consider how that text will show up in other places too, at unknown line lengths.

A line break may look fine on your screen, but it might look really awkward when that text appears somewhere else beyond your control.

Instead of splitting text, stick text together

Orphans

Avoid orphans especially where the text is most likely to appear, but relax. You can’t prevent them altogether.

Instead of inserting a line break, opt to rephrase the text to change the length and prevent the orphan. But realize that when that text appears elsewhere, it might just have an orphan.

You also have the option of a special white-space character called a non-breaking space. In HTML, it looks like this: &nbsp;. When you put a non-breaking space between two words, those two words will always be on the same line of text.

2+ word proper nouns

If you want to be sure that “American Airlines” remains on the same line in body text, employ a sprinkle of CSS magic. In the markup, a corporate name should be contained within a span element, like this:

<span class="brand_name">American Airlines</span>

And then to make sure that those two words stay on the same line, add a line like this to your CSS file.

.brand_name {white-space: nowrap;}

That will prevent the brand name text from being split at the end of a line. Instead, both words will flip to the next line if there is not enough room for them on the current line of text.

Formatting content like mailing addresses

In this case, I’m actually okay with using <br /> tags. But, left to my own devices, I might use some different markup and some CSS instead.

Let’s say we have an address like this fictional one.

Samuel Clemens
1835 Huckleberry Row
Hannibal, MO 63401

You could just put that text in an address element and use line breaks.

Or you could mark it up in the hcard microformat, and then think about styling it based on that markup. So, it might instead be coded like this.

<address class="vcard">
<span class="fn">Samuel Clemens</span>
<span class="street-address">1835 Huckleberry Row</span>
<span class="locality">Hannibal</span>,
<abbr title="Missouri" class="region">MO</abbr>
<span class="postal-code">63401</span>
</address>

And then a little bit of CSS like this would take care of the line breaks.

.vcard .fn,
.vcard .street-address{
display: block;
}

The point: we overuse line breaks because they don’t require any extra thought

Instead, let’s consider why we actually want a line break the next time we go to use one. There’s probably a better option once you realize that you don’t actually want to break a line of text, you really just want some of the text to stick together.

Categories
User experience, web, technology

A model for UX design reviews

Design reviews are so important for our work as user experience designers, but they too often fail us. Here is a model for design reviews that overcomes the problems of ego, emotion, and communication that so often get in the way of helpful feedback.

Alaina Kraus, Caitlin Potts, and I presented this process for the Jan 27, 2011 IxDA Lansing meeting.

Roles in the design review process

  1. Designer
  2. Facilitator (may also be a reviewer)
  3. Reviewers (you’ll need at least 2, but 6 may be too many)

Step 1: Designer explains the project and design concerns

At this step the designer shows the design (on paper, on screen, a prototype, etc.) and explains to the reviewers the context of this design. The designer should also point out specific areas that she wants feedback on.

Step 2: Reviewers discuss the design

This is the part that’s going to go against your habits.

The designer steps back and withdraws from the discussion. She should use body language to exclude herself to make it harder for the reviewers to address her. She should instead focus on her listening and note-taking.

Meanwhile, the reviewers are discussing the design amongst themselves. Instead of referring to the designer, they should refer to the design. Instead of talking to the designer, they should talk to each other.

Of course, the reviewers should point out good aspects of the design as well as discuss areas that they’d like to see improved.

By intentionally excluding the designer from this conversation, the dialogue can cover more ground and the feedback can be more honest. Otherwise, the dialogue has a good chance of focusing on a single point or so as the designer begins to explain or defend her decisions. That will derail good feedback, and everyone loses out on good information. People’s feelings are also at risk.

Step 3: The designer rejoins the conversation.

Finally, once the facilitator has determined the design has been discussed enough, he will invite the designer back into the discussion.

The designer can now summarize the notes she has taken in order to give the reviewers the opportunity to catch any misinterpretations. She can also ask follow up questions to clarify feedback she may not have fully understood.

The designer will probably want to defend the work or explain it, but really doesn’t have to. The goal is feedback for her, and at this point, she has it.

Why this method works

This method works because it makes it okay for the designer to simply listen in without feeling a need to defend her work. Likewise, it frees up the reviewers to not have to worry about hurting the designer’s feelings or fear the reaction of feedback taken poorly. While the method may feel a little awkward at first, after a few times it becomes easier.

What kinds of feedback make sense?

The reviewers should provide feedback that matches the fidelity of the design. This is to say, if it’s a rough sketch or task flow diagram, talking about pixel-perfect alignment of the layout is inappropriate. This should be obvious to most of us.

Also, instead of simply presenting your opinion about a design, discuss it in terms of usability heuristics (Nielsen’s list of 10, Tognazzini’s 1st principles document), accessibility concerns, visual design principles (e.g., proximity, alignment, repetition, contrast), and your observations from usability tests.

Where did this method come from?

In the mid-90s I worked at the Michigan State University Writing Center, and we used a similar process that we called the “fishbowl” to teach people to do peer-review writing workshops. In many ways, writing and designing are similar. When I started doing more design work, I recalled this process and adapted it to design reviews. It seems to work great. I credit learning this method from Dr. Sharon Thomas and Dr. Laura Julier of Michigan State University.

Update Feb 26, 2011: Wordcast live on Design Critique

Tim Keirnan over at the Design Critique podcast posted an interview we did on this process. Check it out! And thanks, Tim, for inviting me.

Update July 14, 2011: Michigan UPA workshop

This evening Alaina, Caitlin and I ran this workshop for a Michigan UPA event in Lansing. We had fun and it sounded like the attendees enjoyed themselves while learning this model. Thanks again Second Gear Coworking for letting us use your excellent venue!

Categories
Management User experience, web, technology

Addendum to “Getting More From Analysis” by Lewandoswki and Dilworth

UX Magazine published Getting More From Analysis by Jared Lewandowski and John Dilworth on Dec 16, 2010. The authors provide a  summary of analysis as part of three design activities:

  1. Analysis
  2. Synthesis
  3. Evaluation

Diagramming these activities

They also provide some models for conceiving of these three activities, from linear to finally advising on a traditional equally-weighted 3-circle Venn diagram.

I like the thinking, and the clear reclassifying of design as including all of these activities, as opposed to only synthesis. However, their Venn diagram leaves direction out of the picture. I like this approach better.

Design as Venn diagram of Analysis, Synthesis, Evaluation, with clockwise arrows.

This model simply adds the arrows to what Lewandowski and Dilworth provided. It’s simple, but serves to organize the concepts.

Working together isn’t always simple

In addition, the authors recommend involving analysts in synthesis activities, and designers and developers in analysis activities. This, I agree, is good advice, but they didn’t provide any techniques to help you actually pull this off.

Analysis, synthesis, and evaluation each require different types of thinking, and a person specialized in, say, analysis may end up stepping on the toes of the people specialized in synthesis. The result may be a stunted synthesis activity, shut down because an analyst broke down the problem again before a designer or developer had a real chance to synthesize the ideas into various solutions.

To avoid these types of problems, creating intentional design (be they analysis, synthesis, or evaluation) sessions is important.

Setting up design facilitation sessions

I’ve been listening lately to some lectures by Professor Michael Roberto, and in them he’s advised what he calls the 4-Cs of encouraging real ideas in a debate. Roberto is focused on strategic decision making, but I think we can learn from this advice and apply similar thinking to how to set up design facilitation sessions.

  1. Composition – of group, who should be invited
  2. Context – Atmosphere, shared norms, ground rules, location
  3. Communication – How will we discuss and exchange views? E.g., subgroups, devil’s advocates.
  4. Control the process – Will I as leader be in the room? Do I ask for a packaged solution or do I ask to see a debate.

You might think this is over-thinking it all. Just put the people in the same room and have them discuss the design, and good things should happen right? Maybe. But why gamble? Even 10 minutes of planning a design session based on these 4-Cs could turn a waste of time into a breakthrough design session.

Categories
User experience, web, technology

Signing and Encrypting E-mail on Mac OS X 10.6 Using Self-Signed Certificates

A few years ago I wrote about using Thawte’s personal e-mail signing certificates for setting up secure S/MIME encryption with Apple Mail. Well, Thawte, so I understand, is phasing out that service. So, I’ve been wondering how to do self-signing on the Mac to set up S/MIME encrypted e-mails. This evening, I found out.

Credit where it is due: James Walker’s post on how to set up self-signed certificates for e-mail with OS 10.4. His post gave me a few steps to follow that I’m  just updating here to match what is needed for Mac OS 10.6.

Create your certificate

Open up Keychain Access. This is an application in your Applications/Utilities directory. (It is faster to just hit command+spacebar to open Spotlight, then enter keych, and hit the enter key when Keychain Access appears highlighted.)

Click on the Keychain Access menu, hover over the Certificate Assistant option, and then select Create a Certificate….

Create Your Certificate in Apple's Certificate Assistant window

Here are a few details to note about the Create  Your Certificate options.

  • You might want to add an e-mail descriptor to the name field. E.g., Davin Granroth (gmail).
  • Go with Self-Signed Root and S/MIME (Email).
  • By default, the certificate will be valid for a year. If you want to extend that a bit, you need to check the Let me override defaults checkbox. You’ll get to make changes after you click the Continue button.
  • If you need a certificate for your non-primary e-mail account, you’ll need to check the Let me override defaults box for that too.

If you checked the override box, you’ll eventually see a series of Extension windows. Just go with the default values. Apple figures out what you need based on the first screen where you chose the certificate type.

Continue and you’ll see a window with your new certificate information in it. Congratulations!

Certificate Assistant window showing the newly minted cert. It also says: This root certificate is not trusted.

Now if you could only trust that certificate.

Trusting your certificate

If you haven’t already, click the Done button to close that Certificate Assistant window. Now, back in Keychain Access, click on the My Certificates category on the right of the main Keychain Access window.

You’ll see your new certificate listed with a little white X in a red circle on the icon. That indicates the certificate is not trusted. Double-click on the certificate, and a new window will open with details of the certificate.

Certificate window with Always Trust selected.

Near the top of that window you’ll notice the word Trust with a little triangle to the left of it. Click the triangle to twist open the Trust options.

In the When using this certificate select list, select Always Trust. Then close that window. You’ll be prompted for your administrator password. Enter it, and you should be all set. Your new certificate should now be trusted.

Sending signed or encrypted e-mails

At this point, if you restart Apple Mail, you’ll notice a new option available when you compose a message.

Compose message with sign and s/mime options
The check icon indicates that your signed certificate will be included in the message. Once you've exchanged signed certs with your recipient, you'll be able to exchange S/MIME encrypted messages.

For more on exchanging signed or encrypted e-mails, see James Walker’s article. Scroll down to the section on Exchanging Signed or Encrypted E-mail.

Why would you want to send encrypted e-mails?

Hah! “Why wouldn’t you want to,” is the better question. Actually, if you send or receive sensitive information like usernames and passwords, legal information, or confidential business information, you might really want to consider this.

The trick is getting the person you exchange these messages with to also set up S/MIME on their end of the e-mail.

Categories
User experience, web, technology

Google Analytics for WordPress (version 4.09) trips HTML validation when tracking outbound links

When I write HTML, running code through the W3C Validator is part of my process. If the code doesn’t pass the validator, there’s a slim chance I’ll consider that code ready for anything.

So after I upgraded this blog to WordPress 3.01’s Twenty Ten theme, I was mildly irritated to find that I had a few validation errors. I viewed the source code to investigate the offending lines of code, and noted that the code the validator cited was not in the source.

This phantom code led me to suspect that DOM scripting from a plugin caused the errors by inserting more code into the markup. That was it, and this evening I finally took the time to track it down. Here’s the scoop.

First, the phantom code that broke validation

W3C validator error message indicating an empty target attribute
The error indicates an empty target attribute. It turned out, this code was inserted by a plugin.

Honestly, the first time I saw this error message, I didn’t notice the error text that pointed to the target attribute. No, I was first startled by a pattern that looked to me like the tail-end of Javascript code used in an anchor’s href or onclick attribute. I was startled because, having already looked through the code, I thought I would’ve noticed that pattern, since it is one that I avoid.

Where was this code? Well, all 9 errors were in the same area of code: links to other websites (blogroll) in the sidebar. I wanted to see it for myself, so I opened the page and viewed the source code. I used the Find command and pasted in some of the code from the validator error message, but the Find came up empty-handed.

While the offending code was not in the served markup, the validator was certainly picking it up, so I went back to the validator to examine that code in more detail.

Code with an onclick javascript snippet inserted for Google Analytics tracking.
Code with an onclick Javascript snippet inserted for Google Analytics tracking. Note the target attribute.

The value of the onclick attribute was the immediate tell for where this code came from. It was the Google Analytics plugin I’m using.

Investigating the plugin that caused the validation error

Google Analytics for WordPress is a fantastic plugin. It makes integrating Google Analytics easy, and it has some excellent advanced settings.

One setting is to track outbound clicks and downloads as events so they are are viewable in Google Analytics.

Checkbox to track outbound links in WordPress.
Checkbox to track outbound links in WordPress.

To test the theory, I unchecked that box, saved the settings, and revalidated the web page.

It passed with flying colors.

Validation error identified, but I’m actually curious about tracking downloads

For the time being, I’m okay with leaving that feature turned off. I’ll let the plugin author know about it and hope the problem will be resolved soon.

Yes, I lose a feature to get back to valid code. Perhaps there is a support group for this kind of behavior.

But in my defense, this is just a personal site. I don’t make any money on it, and my interest in tracking downloads is just curiosity. I only have a few downloads or outbound links I’m interested in, and I have nothing riding on that knowledge beyond satisfied curiosity.

Still, the entirety of this problem can be laid to rest on a simple, meddlesome, and empty target="" attribute. That’s irritating.

Categories
User experience, web, technology

Thoughts on Richard Saul Wurman’s Why Design Now talk

Richard Saul Wurman, author of “Information Architects” and founder of the TED conference, spoke at the Cooper-Hewitt National Design Museum‘s “Why Design Now” event. This is that talk.

Wurman emphasizes that so much is designed, even the questions that we ask. To illustrate, at one point he asked Bill Moggridge, who was attending as the new director of the Cooper-Hewitt, how old he is. Bill answered the question, and Wurman pointed out, “Now we all know your age, but you know nothing new.” His point is that the power is in the question, not the answer.

That is worth ruminating on. From a design perspective, coming up with good questions to understand a problem is often difficult. It takes dialogue and exploration and work before you get to the good questions. And then you begin to understand the problem better. Wurman also points out in this talk that organizations too often jump to action before they really understand the problem.

Wurman packs a lot, including some humor, into this short talk. It’s worth watching.

Categories
User experience, web, technology

I got to help UXmatters with print styling

UXMatters print pageA few months ago I contacted UXmatters online magazine to let them know of a problem I had printing out articles with Firefox. The first page would print, but that was all. I could switch to Safari and print fine, but that just didn’t seem right.

I found out that they were a little shorthanded on specialized web help, so I  volunteered to assist. Pabini Gabriel-Petit, the publisher and editor-in-chief, graciously accepted my offer.

Creating print CSS is usually simpler than web page layouts, because the goal is typically to have the content of the page print out well on standard size paper. Multiple columns and site navigation are usually uncalled for.

My first try was to revise the existing print CSS file. After half an hour at that, I decided it would be simpler to start from scratch. The original print CSS was quite complex, and it seemed I was searching for one issue: why did the pages stop printing after page 1?

So I rewrote the CSS, simplifying the CSS code greatly. I had the layout in good shape, but oddly still had the 1 page issue.

I went back to the main screen CSS file and begin sifting through it, looking for clues. Then on a hunch, I found the issue.

The global CSS file is thick. There’s a ton going on there to defend against various cross browser issues. One particular rule I saw repeatedly was the use of overflow: hidden. That rule is used for a few reasons, but one of them is to force a floated box (div or what have you) to expand when it wants to collapse, vertically. This allows things like backgrounds to show through properly.

One of the selectors that this rule was used on was actually a wrapper for much of the page content. It made sense to me, in a way, that this could confound a browser into hiding paged content that went beyond a page.

So the real key to the much simpler CSS file was to add in an overflow: visible to a large set of selectors to override that overflow: hidden for printed pages.

I sent Pabini the new code, and over the following weeks she tested it and added some details I had missed. About a month ago she deployed the new print CSS code  to the website.

This little evening project was a fun puzzle, and I’m glad I was able to help make such great content on the UXmatters website print out better for more people.

(Back in 2002 or 2003, I forget when, I wrote an article on print styling for web pages.)

Categories
User experience, web, technology

IxDA Lansing kickoff featured speaker Dan Klyn

Last night was the inaugural event for IxDA (Interaction Design Association) Lansing, and information architect Dan Klyn presented “The Nature of Information Architecture.”

Presentation overview

Dan’s presentation was both informative and controversial. He provided some nice background on the naming of the field of information architecture, citing Richard Saul Wurman phrasings at the 1976 AIA convention in Philadelphia and then Wurman’s book “Information Architects.”

Dan also proposed a way of considering what information architecture is through a target diagram, from core to outside as:

  1. Ontology (the study of being)
  2. Taxonomy (the science of order or arrangement)
  3. Choreography (writing/describing circular dance)

I like this description of IA. I do feel it gets to the heart of the work, and I can immediately consider certain areas of my own job in this light. Of course there are plenty of other descriptions of IA from Wurman, Rosenfeld, Morville, and others, but as I bring them to mind, they seem to be more focused on describing IA to outsiders whereas this one speaks to those of us already  in the field.

I wouldn’t, for instance, walk up to a client and say, “I’m concerned with the ontology of your system.” But I can talk with other information architects about questions of ontology, and they will likely bring their own experiences to bear.

After discussing this model for IA and how it circles the concept of understanding, Dan shared two ways to answer the question “How do we know when IA is good?”

  • performance (need to measure change in performance from a benchmark)
  • propriety (how appropriate to the context is the IA solution)

When discussing this question of quality of IA, the point was made that a functional, adequate solution is artless. It is insufficient. We’ve all used a website or service that we end up getting irritated with, and could comment afterward “Well at least it worked.” Good IA goes beyond sheer performance to fulfill propriety as well.

Isn’t naming always controversial?

The controversial part of Dan’s presentation is in the naming of things. The gist of my issue is that I felt Dan was saying that strategic-level IA work—the work that involves not just end-users but is concerned with larger business concerns—is beyond the scope of user experience work. (I really hope I’m not misrepresenting Dan’s meaning.)

My experience as a UX professional (note that I used to refer to myself as an information architect) says that UX begins with understanding both user and business needs, and is best done when exploring the strategic-level in order to frame the tactical work.

That said, I will say that with all the work demanded of UX in my job, I regret that I haven’t had the time to devote to a more traditional strategic IA-based analysis of our systems.

Dan made the point that this strategic work, though done by a smaller group, has greater leverage than choosing which style of form field to use. He is right, of course. I just think that that work is still to be done under the UX umbrella.

Thanks Dan for the talk, and Chris Bachelder for bringing it together

All-in-all, I’m really glad I had this opportunity to take part in Dan Klyn’s presentation. It was well-done and thought-provoking. Dan has shared his slides for “The Nature of Information Architecture.”

IxDA Lansing is the first Michigan group of the Interaction Design Association, and was initiated by Chris Bachelder of Techsmith Corp. I, for one, am grateful to have a Lansing-based group to advance UX events. Thanks Chris!

Categories
User experience, web, technology

Stop the stopwatch, UXers!

Stopwatch graphic from Casey Marshall
Stopwatch graphic by Casey Marshall

Recently, I watched a series of people observe informal usability tests.

Two of the observers have recently graduated with Masters degrees in HCI or an adjacent field.

Both recent graduates used a watch to record time-on-task and completion of the task. One actually broke out a stopwatch while the other referred to his wristwatch.

While these stopwatch fixations livened my day, I do wonder about graduate education in the usability field.

I recall that for the first half-dozen website usability tests that I moderated, I also recorded time. Then I realized that timing tasks obscured more important observations, and I haven’t bothered with timing since then. Besides, we can get times off the recordings.

Is the working world really that far off from graduate studies?

So why did these two graduates pull out timers?

Well, I think they were parroting “proper” methods they were taught without understanding when it is useful. If, in grad school, they only practice for ideal research situations, they’re missing out on the realities of the work world.

I’ve worked in an Agile development environment for the last couple years, and for the decade prior to that I worked on fast-moving projects that used whatever SDL I applied to them. The mission: Deliver value, ASAP.

With that charge, decisions are made that don’t allow for insight from in-depth, long-term studies with huge numbers of participants. I’m grateful for even the small, quick sessions of user and design research.

Regardless, I got a chuckle out of seeing these two bring out timers for a completely informal, one-off usability test. As expected, they both missed seeing key interactions because they were watching the clock.

When to be concerned about time, usability-wise

Okay, I’d hate to give the impression that time doesn’t matter. I just find that a long time to complete a task on a website is rarely the issue, instead it may be a symptom of other issues which become apparent during research.

However, I do find response times of a system to a user’s actions to be very important because too much delay in a system’s response can really hurt the user’s experience and even distract people from completing whatever they set out to complete. Still, this class of problem is often noticeable during observation. (Unless you missed it while you were fiddling with your stopwatch.)

With that in mind, I’ll gesture towards Nielsen’s take on response times.

Categories
User experience, web, technology

Newsweek’s Spring 2010 Website Redesign

Home page of Newsweek.com, May 31, 2010
Home page of Newsweek.com, May 31, 2010

I don’t know when it happened, exactly, but Newseek.com was recently redesigned. There is so much to say about it, and it is mostly good.

I’ll start with the most obvious: the design.

In short, the home page is easy to scan. There is a clear visual hierarchy. The lead photos and articles have been spot-on for Memorial Day news items, and the clarity of the layout made certain I couldn’t miss them.

The article pages are easy to read and keep enough of the patterns, like the byline and publication date, that it’s easy to figure out what’s what.

My biggest complaint is one that they no doubt haven’t figured out how to get rid of yet: the banner ads.

There’s more talk about the visuals for the new newsweek.com at nymag.com. I won’t go on about that, myself, other than to say, gee, it looks like a professional blog. Oddly, that’s a compliment.

Now let’s look at the markup.

Code for namespaces on newsweek.com
Newsweek.com's namespaces point to interesting uses of meta data.

I’ve had a penchant for information architecture since the late 1990s, and about the first thing I noticed when glancing at the markup for the home page is the references to the Dublin Core meta data definitions and other meta data sets.

I was suddenly intrigued. Good use of meta data is sadly absent in many large-scale websites, and it’s really great to see an effort to play the game for real.

So, at a quick glance through the markup you’ll notice some unusual pieces, first this:
data-track="{'title':'stories being discussed'}", which is an attribute with a value that looks a bit like JSON.

I admit to being behind the times with studying HTML 5, but that attribute spurred my suspicion that this page was using HTML 5. I stopped wondering a few lines later when I spotted an article element, followed soon thereafter by a header element, and a nav element sporting an attribute of role="navigation". Whoa. Newsweek jumped right in.

So what about the meta data? Well, I can’t really know what they’re actually doing, but here is an observation. In a sidebar, they have a list of quotes. Each quote is marked up as a blockquote with an id attribute. Following each quote is a span with attributes like property="dc:creator" and about="#q1". The about attribute refers to the id of the blockquote in question. The content of that span itself is the name of the quoted person, plus which publication the quote came from.

Pretty cool idea: internal markup references like this can build relationships into the content. It could provide some interesting opportunities for parsing later on. Yeah, that’s right, the semantic web.

The problem with this all is…it’s half-baked!

Newsweek.com meta tags, bad markup
Newsweek.com used "http-equiv" when they needed "name". Oops.

That list of quotes with the ID attributes? All that meta data is duplicated and thereby meaningless! Further, why use a span element when they could have used a cite element? More semantic and those attributes would’ve played as well. Gah!

And back at the top of the markup by those meta data namespace references there is another set of meta tag elements which are sadly marked up incorrectly.

There is a stack of 5 meta elements that use the http-equiv attribute when they should have used the name attribute. I’ll bet whoever coded that knows the difference, but I wonder if they were rushed to get this version out. It feels like a beta.

They are so close to providing some really great examples of meta data use in HTML 5! I hope they release another version soon that gets more precise and cleans up some of this code.