Category Archives: Web design and technology

Posts on technology and design, in general.

Small-caps, web text, and CSS

Posted on by
3

There’s a trick to getting small-caps to work on the web, and it’s counter-intuitive.

Let’s say you had an abbreviation, like CSS, that you wanted to put into small-caps, say with a little extra tracking. You might think you could use the CSS property font-variant: small-caps, and you’d be good to go. Not so.

Here’s why. Because for small-caps to work, you need to start with lowercase letters.

However, when you’re simply typing your thoughts out before you’ve decided on small-caps for abbreviations, acronyms, etc., you probably typed those abbreviations in uppercase.

So, when you tried small-caps, it simply didn’t work. For example, see this web page from 2005 that Joe Clark wrote to test small-caps. Note how the small-caps versions are more like regular capital letters. Not cool. It makes the hack look good, which is bad.

So, here’s what you can do (and what I think browsers ought to be doing automatically anyway):

  1. First apply text-transform: lowercase
  2. Then apply font-variant: small-caps

That ought to do it.

Here’s a more specific example of the CSS.

abbr, acronym {
text-transform: lowercase;
font-variant: small-caps;
letter-spacing: 1px;
}

The problem with the line break (BR) tag

Posted on by
2

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.

A model for UX design reviews

Posted on by
6
IxDA-Lansing Design Reviews workshop

Jan 27, 2011 - I had the pleasure of sharing this design review method at an IxDA Lansing meeting. Here are designers practicing this method. Photocredit: Chris Bachelder.

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!