Nice Touch: Background Window Scrolling in OS X

By Matt in OS X, Nice Touch, Usability

I was beaten to the punch. I was going to write a post about how great it would be if I could scroll windows in the background in OS X. I had even created a graphic for it.

“I’d love to be able to scroll through a webpage and take notes on it in Stickies without switching applications,” I was thinking.

But then Apple took care of it:

Excellent!

I’ve Reached My Limit: Approaches to Character Limit Cutoffs

By Matt in Design, Commentary, Usability

In real life, it’s important (and polite) not to obtrusively interrupt someone when they’re in the middle of something, and, of course, this carries over to website usability as well. So, how should we enforce form field character limits without disrupting what is already a potentially demanding process? I can think of two main use cases, distinguished by the length of the form one is filling out.

When filling in a small field like the zip code field featured below, users should be cut off at the character limit. It prevents error preemptively, before the form has been submitted. In most cases, users know why they can’t go any further because of the nature of the input (i.e., a phone number, credit card VIN, or age). If it’s unclear, some explanatory text will do the trick:

With larger text fields> (<textarea>s) we have to be more forgiving. Users can’t keep count of characters in their head (if they even know what a ‘character’ is), and it’s relatively likely that they’ll be looking not at the screen but at the keyboard, or at another window, or even at notes on their desk while typing. In this case, it’s dangerous to just stop accepting input. They may continue typing without actually accomplishing anything and not realize it until they’ve wasted time typing something they may not remember.

Thankfully, there are two real-world examples that I think demonstrate exactly how to get character limit enforcement wrong and how to do it right.

Twitter: “No — No Further!”

Type more than 140 letters into micro-blogging platform Twitter’s What are you doing? box, and you’ll be stopped without warning. If you’re not paying close attention to the box, you could go on typing without knowing what’s happened. If you’ve something longer than 140 characters to say, this quickly becomes frustrating. Because the field is frozen as soon as you hit the limit, any mid-sentence editing you want to do to whittle down your little tweet becomes an exercise in frustration. It can only be destructive, because you can only add or move words within the 140-character limit — any potential revision would have to be preceded by the deletion of something you’ve already typed and may not want to lose.

There is a nice numerical counter of the characters remaining, even nicer because its visibility — and, therefore, our awareness of the limit — is increased as you draw closer to zero.

But unfortunately it’s not enough to allay the problem. Okay, so I can see the words running out in front of my face, but I’ve already formed what I’m going to say in my head. Making the message fit their size constraint mid-thought isn’t my primary objective; I just want to type it all out and pare it down after. I respect the brevity inherent to Twitter, but it’s not something I’m really used to yet, so let me reorganize my words if I need to.

And what if you type your tweet somewhere else and paste it in to the Twitter website? Well, if it’s over 140 characters, you’ll have to guess how many you need to delete, because there’s no telling by how many characters you’ve gone over the limit.

And what’s more, you lose the end of the paste — what if you want to remove something that was in the middle?

How could this be handled more smoothly? Let’s see.

LinkedIn: A Polite Reminder

If you type too much in the contact form of professional networking site LinkedIn, you’ve much more leeway:

Instead of letting you proceed no further, LinkedIn simply tells you by how many characters you’ve exceeded the limit, allow you to easily pare down your message.

I think Twitter’s character counter should reflect just how far you’ve typed past the limit and not impose a character limit on the text box itself, much like LinkedIn used to do.

One area where I believe both approaches succeed is the size of the input area. Both LinkedIn and Twitter feature small text boxes, tailored to the exact amount of words they should (theoretically) contain. At first it may seem like an annoyance, but it’s a fantastic way to encourage concise writing and remind users of the limits.

Acknowledgments

This post was at least partially inspired by the work of usability guru Luke Wroblewski, whose presentation Best Practices for Form Design (and upcoming book, no doubt) contain guidelines very similar to these (see slides 105 and 106 in particular).

iKeepForgetting: Two Things iTunes Won’t Remember

By Matt in OS X, Commentary, Usability

Two reports on odd behavior in iTunes. For you. For Apple. For Google. For us.

iTunes Forgets View Preference Upon Clicking Altered Arrows

This is something you have probably never experienced, but it’s annoying nonetheless.

If you reverse the default action for your iTunes arrows — that is, change one of the iTunes hidden preferences to make the arrows redirect to your library instead of the iTunes Music Store — iTunes will always go back to list view, even you’ve set it to display album artwork. I’ve taken a short video to show you what I mean.

The first time I click is the default behavior — redirection to the iTunes Music Store. Going back to my library, all is preserved. The second time, though, when the arrow’s behavior has been altered, clicking the arrow lists the entire library centered on the song I’m listening to and forgets that I had set the view to “album art” mode. It’s slightly annoying.

Of course, this is a hidden preference, so it’s completely unsupported, and I don’t imagine Apple is too eager to help me avoid their Music Store by fixing it.

The second issue, though, is one you may have run into.

iTunes Forgets Scroll Location when Leaving Library View

Are you using the “Browse” viewing mode in iTunes? You know, the one activated by this button in the lower right-hand corner:

It activates the display of scrollable columns of artists, albums, and maybe genres above the list of tracks — convenient if you have hundreds of unsorted genres or more than a dozen artists or albums. Unfortunately, if you’re anywhere in the middle of those scrollable lists, you’re going to lose your place if you leave the library window. I’ve made a video demonstrating this as well.

Now that just doesn’t make any sense. Has this bothered you? Have you even noticed?

Nice Touch: Tips Pre-Calculated on Restaurant Bill

By Matt in Nice Touch, Usability

Perhaps some of you have already seen this, but we were recently impressed at a restaurant upon noticing the tip percentages for our meal printed on the bill. Check it:

You can even choose from three levels of benevolence. Have you run into this before, and do you find it useful? We think so, but do you find it tacky? Do you not like being told what to tip? Would a split-up of the cost between patrons be just as or more useful?

Woe Is iWeb

By Cody in Commentary, Usability

After our post about the inability to print pages created with iWeb, I decided to take a crack at the problem.

The first thing I did was to determine the exact cause of the problem. It turns out that the body_content <div> unnecessarily has the overflow property set to hidden. Since the <div> is relatively positioned it overflows the first page when printing, and therefore the overflow is hidden. By setting overflow: visible the problem would be fixed.

Unfortunately, iWeb writes this property as an inline style directly on the <div> itself, so there’s no way to override it. Even !important declarations with high selector specificity in external stylesheets don’t take precedence over inline styles. (This is unfortunate, in general.)

It was at this point we received a very friendly email from Mike Lee. He helpfully showed us that the printing problem doesn’t occur in Safari or when sending the page via Mail. This does make it clear that the iWeb developers were writing iWeb primarily for Safari. Not everyone is using Safari, though (we had been using Camino and Firefox). And while the Mail workaround let’s us print the page, it’s a big hack.

Mike’s suggestion was to write an XSLT stylesheet that would transform iWeb’s misbehaving inline CSS into something more palatable. And this is what I came up with:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <!– The identity template. –>
  <xsl:template match="@*|node()">
    <xsl:copy>
      <xsl:apply-templates select="@*|node()" />
    </xsl:copy>
  </xsl:template>
  <!– Add an ‘overflow: visible’ declaration to the body_content div. –>
  <xsl:template match="*[@id=’body_content’]/@style">
     <xsl:attribute name="style">
       <xsl:value-of select="concat(., ‘ overflow: visible;’)" />
     </xsl:attribute>
  </xsl:template>
</xsl:stylesheet>

iweb_fix.xslt

4 Kilobytes

This XSLT stylesheet uses an identity template to copy all attributes and nodes, changing only the ones overridden by other templates. Here, the only thing we want to override is the style attribute on the body_content <div>. In this case, we just concatenate the required declaration to the existing value of the attribute.

Unfortunately, when trying to run Mike’s page through this transform, it turns out the XHTML that iWeb generates is invalid. One of the (numerous) problems is that the <link> tags aren’t closed in the head. This makes the XSLT engine choke. Unlike the cause of the printing problem, though, this isn’t a simple browser incompatibility between how Safari and Camino interpret the overflow property. It’s just shoddy work on the part of the iWeb team.

Mike gave another suggestion: use Tidy to clean up iWeb’s mess. Since OS X 10.4 comes preinstalled with both the GNOME xsltproc utility and tidy, all that needs to be done is

This little fix is something that maintainers of iWeb-generated pages will have to apply themselves before uploading their websites. Perhaps like so: