Journal tags: interaction

23

sparkline

Spaces

It seems that small interface changes are rolled out to Twitter on a fairly regular basis. This morning, for example, I was greeted with a new “Everyone” tab. I was also disappointed to discover that an interface improvement that was introduced a few weeks ago has now been removed. As interaction tweaks go, this was a very small thing but it’s something I appreciated very much. Let me explain…

When I’m reading a long-ish page on the Web, rather than move my cursor over to the scrollbar, position it just so and click to scroll down see the next screenful of content, I’ll just tap the spacebar. In just about every browser I know, this will scroll the content by one screenful. This flow is interrupted if a website “helpfully” puts the focus into a form element when the page loads. This isn’t an issue on, say, Google because Google doesn’t have more than one screenful of content. But it is an issue on Twitter. When Twitter loads, the What are you doing? input box is automatically given focus. If I want to scroll down below the fold, I must either use the scrollbar or click out of the form element and then use the spacebar. I can understand the rationale behind this. Chances are most people want to get into that form element and start typing …at least on the front page.

The interface improvement that Twitter introduced a while back was to take that automatic focus away if I was on any page other than the first. In other words, if I was clicking back through older pages to catch up what my friends have been doing, the focus was no longer automatically given to the form element. Brilliant! This awareness of context reminds me of what Eric wrote when they were adding print stylesheets to A List Apart:

These print styles are only used on articles, which are the pages that are most likely to be printed.

Perhaps through oversight or maybe through deliberate choice, Twitter now places the focus in that form element on every page. What a pain! And what a shame that a great example of context-sensitive interaction has been removed.

I hereby invoke my bitching ‘n’ moaning mojo: c’mon Twitter, do the right thing.

While I’m at it…

Oi! Flickr! What’s up with the automatic focus in the search form on search results pages? Explain that to me. ‘Cause from where I’m sitting, it’s just downright annoying.

Outgoing

As a web developer, I get annoyed by interaction design implementations all the time: Why is that a link instead of a form button?, Why doesn’t that scale when I bump up the font size?, Why am I being asked to enter this unnecessary information?… Usually I can brush off these annoyances and continue my journey along the threads of the World Wide Web but there’s one “feature” that has irked me to point of distraction and it’s all the more irritating for being on a site I use habitually: Upcoming.

As an Upcoming user, I have a default location. In my case it’s Brighton. This location is important. My location determines what content gets served up to me on the front page of the site—a useful way of discovering local events of interest.

The site also has a search feature. The search form has two components: what I’m searching for and where I’m searching for it. The “where” field defaults to my location, which is a handy little touch. If I want to search for something outside my current location—say the Future of Web Design conference in London this April—I can enter “Future of Web Design” in the “what” field and delete “Brighton” from the “where” field, replacing it with “London”. That works: I have now narrowed down my search to the location “London.”

Here’s the problem: if I now return to the front page I will find that my location is London. That’s right: simply by searching in a place, the system assumes that I now want that to be my location. You know what they say about assumptions, right? In this case, not only has it made an ass out of me, it has, over time, instilled a fear of searching.

I’ll be in San Francisco at the end of this month so I’d like to see what’s going on while I’m there. But once I’ve finished my searching I must remember to reset my location back to Brighton. Knowing this makes me hesitant to use the search form. No doubt the justification for this unexpected behaviour in the search is to second-guess what people really want: do as I want, not as I say. But when I search, I really just want to search. I suspect the same is true of most people.

Normally I wouldn’t rant about an obviously-flawed feature but in this case it’s a feature that can be easily fixed by simply being removed. Here is the current flow:

  1. The user enters a search term in the “what” field, a location in the “where” field and submits the search form.
  2. The system returns a list of search results for the specified term in the specified place.
  3. The system changes the user’s location to the specified place.

That third step is completely unnecessary. Its omission would not harm the search functionality one whit and it would make the search interface more truthful and less duplicitous.

I’ve already mentioned this on the Upcoming suggestion board. If you can think of a good reason why the current behaviour should stay, please add your justification there. If, like me, you’d like to see a search feature that actually just searches, please let your voice be heard there too.

Please Leonard, Neil, I kvetch because I care. I use Upcoming all the time. It would be a butt-kicking service if it weren’t for this one glaring flaw… even without a liquid layout.

Update: Fixed!

The tyranny of mouseover

If I click on a link, I am initiating an action. If I fill in a form and press a submit button, I am initiating an action. But if I move my mouse over a page element, I am not initiating an action. Chances are I’m on my way to initiating an action (like clicking a link or pressing a button) but if I brush past a link on the way, that does not mean that I want something to happen in response.

Most browsers display the value of a title attribute as a tool-tip after a suitable pause. Generally this works pretty well as long as the tool-tip is relatively small and self-contained. Ever come across an instance of a title attribute with a large amount of text? It just feels wrong. There are economies of scale when it comes to displaying information triggered by a mouseover.

All of this is by way of introduction to the topic of those bloody annoying Snap previews that are quite literally popping up all over the place.

I’m not alone in my annoyance. Lorelle VanFossen has put together an excellent list of the problems caused by these rude and intrusive interlopers. As well as listing the accessibility issues for low-vision and motor-impaired users, she makes the very valid point that these pop-ups actively destroy the act of reading:

There’s a small author-part of me that hopes what I write resembles some action-packed-page-turning-thriller and that people are glued to their screens eagerly embracing every word I write. I’d hate to have that experience be interrupted by an annoying pop-up window of any kind. Destroys the interaction of the reader with the written word, doesn’t it?

The way that the developers at Snap view web pages reminds of the Far Side cartoon:

Blah blah LINK blah blah blah blah blah blah blah blah LINK blah blah blah blah blah…

Lorelle’s frustration is particularly acute because the Snap previews showed up on her Wordpress.com blog because Matt thought it would be cool to roll out this “feature” to 10% of Wordpress.com users.

Luckily, Lorelle and other hijacked blogs can turn the feature off. As pointed out by John Gruber, Jason Kottke and Michael Heilemann, the rest of us can also deactivate these annoying things. I should also point out that you can deactivate them directly from a preview by clicking on the “options” link in the pop-up and setting either a local or a global cookie to switch off the previews.

But this is like opt-out spam. I shouldn’t be confronted by these intrusive and annoying pop-ups to begin with. Offering them as a feature to users who want them strikes me as a perfectly reasonable implementation. This is the perfect example of something that should have been implemented like a Greasemonkey script: give users the choice and the power to activate this flashy feature. But don’t foist it on us and then claim it’s our responsibility to disable it.

If you haven’t seen the Snap previews in action, you can find them on TechCrunch and Vitamin, to give just two examples. Their presence on TechCrunch isn’t really surprising given that the site is devoted to pointing out all that is flashy and pointless on the web. But the gang over at Vitamin really ought to know better.