Auto-Truncating Article Titles (don’t do it)
Designing for the web isn’t easy — especially when you’re trying to wrangle lots of content. Many many readers enter a site not through the front door but via a direct link to an article, and building in spaces to promote other content is critical. Making it look great is important — but content must always trump appearance.
I ran across a perfect example of this today while reading an article on the National Review Online. Their article pages have a sidebar item called the “NRO Live Blog Feed.”
As you can see, every item is exactly the same height, which makes for a nice-to-look-at series of links.
Unfortunately, this means that they have to auto-trucate titles if they go over a certain length. Why is this a problem? Take a look at the second item:
The link text reads “Gingrich’s Claim that He Gave Depositions in Both Divorces Likely…”
But when you click to read the article you discover…
The actual title of the piece is “Gingrich’s Claim that He Gave Depositions in Both Divorces Likely False” (emphasis mine). This is a very different story.
I would venture to guess that most of us skim these link lists without clicking through to many (if any) of the articles linked — nevertheless we treat these titles as content.
Had I not clicked through to the article, I would have left the NRO’s web site thinking that Gingrich had given both depositions (even though I honestly have little knowledge about the depositions that the title is referring to). Even if I don’t recall the details of the title, I would have left with an erroneous impression that I came across a positive piece about Newt Gingrich, which is absolutely not the case.
People read titles, even if they don’t read the articles. Make sure they represent your message.
Auto Focusing on Search Fields (don’t do it)
I’ve been a Dreamhost customer for a long time; I think it’s by far one of the best hosts in its price range. Service, support, and especially their control panel have kept me a happy user.
That having been said, there’s always something, right?
Dreamhost’s control panel does a great job of making it easy to find just about any feature they offer, and often makes tasks that, in other control panels, can otherwise be a daunting puzzle (like changing a domain’s DNS records) pleasant ones.
Unfortunately every time you load a new page, it automatically places the cursor in the search field.
Why is this a problem?
Like a lot of people, I do a lot of page navigation with my keyboard. The space bar pages you down, the down arrow moves you down in smaller increments. Shift-space pages you up. Command-up brings you to the top of the page, command-down to the bottom. Backspace/delete takes you back to the previous page.
None of these work if the cursor is already engaged — if it’s already focused on an HTML element that allows for typing, like, say, a search field.
The result being that when using Dreamhost’s control panel my behavior looks something like this:
- Click to open new page.
- Hit space bar to scroll through my unfortunately-long list of domains.
- Realize the search field is engaged and that I’m typing spaces into it.
- Be irked.
- Hit tab (or click on any non-link part of the page) to dis-engage the search field.
- Go about my business.
On some web pages (like the google.com home page) it’s perfectly fair to make the assumption that the first thing people will want to do is type. But not on most.
t.co links: driving me crazy, but not in the way you think
I think by now most users are aware that Twitter is taking every URL in every tweet and converting it into a t.co link. It’s not hard to imagine how this is a win for Twitter (they get to capture tons of data), and on the surface it seems like it could be a usability win for users as well (the fact that a URL of any length now only counts as 20 characters in a tweet is very useful). Unfortunately the way it’s been implemented by Twitter leaves a lot to be desired, and in general is a net loss in usability for users.
If you’re a Twitter user I probably don’t need to go into detail here, but I’ll list a few of the drawbacks just for posterity:
- The actual URLs are often obscured so you can’t see the address of site you’ll be taken to if you click it.
- Even if Twitter makes the URL visible, it truncates it and strips the “http://,” which renders the text unidentifiable as a link once it’s taken out of the context of Twitter (or even if it’s simply copied and pasted into a new tweet).
- It feels creepy that Twitter feels the need to control their environment this way.
Ok, that third one isn’t a usability issue, but for me it matters. I think less highly of Twitter and the product and their brand because of how intrusive the t.co experience is.
Anyway, there’s one other big reason I hate t.co links, and it’s something you might not have noticed. Take a look at my browser history:
Those t.co links should not be there.
The way Twitter has implemented their redirection (from the t.co URL to the target URL) somehow prevents the target link from showing up in Webkit’s browser history, and this breaks my browser history. There are pages of content that I have visited, and would often like to search for again, that simply don’t show up. Twitter is breaking a crucial feature of my browser.
If it were possible to opt out of Twitter’s URL shortener none of these issues would be a problem, but you can’t, so they are.
Edible City Updates
We’ve been busy working on a nice little set of updates for Edible City and we’ve finally managed to roll them out! We’re hoping this new version can make the site even more useful and usable to hungry people in New York City.
New Data
Probably the most interesting new feature is the new data presented by the site. The biggest of these is the addition of Markets data set. Both NYC Greenmarkets and the many independent markets and fleas that are popping up are great places to sample indie food vendors and acquire great locally produced food to eat at home. Greenmarket schedules differ by market and season, and Edible City can help you find nearby markets that are open where and when you need one. Markets have a new icon, a little market stall, so they stand out from the trucks.
The second batch of new data comes in the addition of the Menu tab on the Food Truck information panes. We’re integrating menus into the site so that users can get an idea of what each truck serves without having to leave the site. These are being integrated on a per-truck basis, so we’ll be adding more and more menus throughout the summer.
The third piece of data added to the site is the local weather report. This may seem trivial, but the fact is that many trucks can change their schedule without notice in the event of extreme weather (as this spring has shown) and so a report of rain means that users will know to pay more attention to the list of recent tweets in the truck information panes.
Finally, we’ve also added a note to the truck information panes that tells you whether you can call ahead to order, so you can cut down on time in lines.
Visual Updates
We’ve put a lot of effort into the user experience for Edible City, and now we have also refined the appearance of the site. We’ve added texture and dimension to the utility bar at the bottom of the page, enlarging it somewhat so that the logo feels more grounded.
We’ve also replaced the drop-down select for the trucks list with a custom list. This allowed us to improve the basic usability, and add indicators as to whether the trucks in the list are currently on the map. On the iPad, the list remains a select element because of the way it handles scrolling.
UX Updates
Recently, we added Spots, which gives us the ability to directly link to spots around the city that we want to highlight, such as neighborhoods or special events.
We’ve also put a fair amount of time into fixing bugs in the site, some of which affected the visibility of tweets and truck details. As well, we’ve improved the interaction between the various types of panels, so that the flow between panels is much smoother.
Finally, a nerdy note on the code: we’ve restructured the style sheets in line with the principle of 320 & Up, a mobile-first initiative. This means the styles are ordered for smaller screens first, with styles for larger screens added later via media queries. In our testing this has improved loading on mobile devices, because the HTML can be rendered more quickly.
We’ll be continuing to add more data to our system throughout the summer, as well as work on the codebase to improve the user experience. Enjoy!
Scientific American Wins!
Last year Scientific American ambitiously decided to redesign both their print magazine and the magazine’s web site at the same time.
The entire redesign effort was headed by the illustrious Roger Black, who then selected Happy Cog and Monkey Do as partners for the web design.
We had a great time working with @sicam’s editorial team and we’re so pleased (and not at all surprised) that they’ve won a National Magazine Award! Huge congrats!
Sometimes a Gawker site will push you to a different Gawker site, and I’m guessing it costs them lots of pageviews. (go to Vimeo to comment and such »)
“Mobile” versus “Small Screen”
I got to be a guest on The Big Web Show a little while ago. It was a lot of fun — Dan and Jeffrey are great hosts. We talked about a lot of things, but one thing came up that I’ve been meaning to really sit and think about recently: The mis-use (or misconception) of “mobile” styles.
As we try to become more responsive with our designs, a lot of attention has been focused on providing “mobile” styles. We’ve all been adding viewport meta tags to our templates and @media screen and (max-device-width: 480px) to our stylesheets.
It’s very tempting (and scope-friendly) to tell a client that we can adjust their site for mobile users, when much of the time what we’re actually doing is simply adjusting a design for small screens.
A simple example of this is our own HTML5 Reset site. It has a very simple design; it’s only one page, but I’ve built in a few responsive elements that can help make my point.
In the video below, watch the image as I resize the window — first it will tuck into the column, then it will scale, then it will become full column at the smallest size.
These responses aren’t really about solving a user’s problem, they’re mainly aesthetic (except for the last transition — I don’t ever want the image to become too small to make out).
I’m making these changes for the benefit of small screen users — not mobile ones.
How mobile is Mobile?
Media queries and the idea of viewport size and scaling are still relatively new concepts, and adding them to our toolbox has been a lot of fun. But I think a lot of us have been leaning on them as a crutch to provide simple answers to complex issues, namely: How do we (and how do we get our clients) to think about providing for the newly-significant audience of people using mobile devices?
An actual “mobile” site is a specific beast, one that needs to be tailored specifically to the tasks and users it serves. A mobile user isn’t just defined by their device, they’re also defined by their context; mobile users are out and about, they aren’t in front of their primary computer — they are literally mobile.
The gist of the argument is that legitimately mobile users have very different priorities than a desktop user; they require more focused experiences. I’m sure you know what I’m talking about (if not, you should start following @lukew right away).
Perhaps simply adjusting a design for a smaller screen and calling it “mobile” does a disservice to both mobile users and developers. Making link targets bigger and image sizes smaller does help the mobile user, but it only addresses the surface issues of usability and readability. It doesn’t address their need to do things easily and quickly.
Anyway…
The whole point of this post was to say two things:
1. A “small screen” user is not necessarily a mobile user.
2. A “small screen” device is not necessarily a mobile one.
But if your users have a legitimate need for a mobile experience, maybe media queries aren’t going to be enough.
Gawker Watch: Withdrawing New Features
We, along with many others have been watching the world’s reaction to the new Gawker designs with great interest, and — more pertinently — we’ve been watching for Gawker’s response to the responses.
Well, today I’ve just spotted what seem to be a couple very clear pullbacks from the new design:
- They have added an actual scrollbar to the right column. While the area was scrollable, it’s easy to guess that the lack of a visible scrollbar mis-led a lot of people into thinking that the half a dozen or so visible stories were the only ones available, despite the fixed “see more stories” link at the bottom. Back in the day, AOL users didn’t know how to scroll at all, but still today I don’t think it’s unreasonable for users to expect a scrollbar when there’s more content to be seen.
- Relevantly, they have pulled the “sticky footer” from the bottom of the browser window altogether. I applaud this, as sticky footers interfere with a browser’s natural “page up” and “page down” commands, but somehow without them the new design feels less thoughtful and innovative. They were trying for a somewhat app-like experience, and removing the sticky footer backs off from that significantly.
Has anything else changed?
Softly Clicking
Dan Cederholm’s CSS3 button is a nifty animation demo showing how you can achieve a great button effect using only a small bit of markup and new-ish CSS3 rules.
It looks terrific, and has a smooth click effect that degrades nicely on older browsers.
But (all the time with the but) it’s kind of soft.
When you click, you get a slight delay before the button sinks to the page, like it has weight, or some sort of spring pushing back against your finger (or mouse, as the case may be.)
(Actually, scratch finger. It doesn’t quite behave properly in mobile Safari.)
At first I thought that this demonstrates an interesting weakness in using CSS3 transitions: they are applied in both directions. That is, you get the same timing and transition when the translation is applied on :active, and when it is removed on mouseup.
But then I got an idea. I saved the demo page locally, and then copied the transitions from the button rules to the :active rules, and made the time 0 seconds, to make the transition instant.
.btn:active span { -webkit-transform: translate(0, 4px); -moz-transform: translate(0, 4px); -o-transform: translate(0, 4px); transform: translate(0, 4px); -webkit-transition: -webkit-transform 0s ease-in-out; -moz-transition: -moz-transform 0s ease-in-out; -o-transition: -o-transform 0s ease-in-out; transition: transform 0s ease-in-out; }
And it worked! Turns out the transitions on the :active state override the transitions on the normal state (as they should) and so we get an instant click with a soft reset. Secondly, you don’t have to click-hold to see the full transition to pressed, as in the original. And finally, it now works in iOS.
Try it here and compare to the original demo.
The Gawker Redesign, Reviewed
It’s been in the works for a while now, but it looks like the Gawker media blogs have finally released the new design in the wild, across the entire blog network.
The reaction so far is predictable. And hilarious (hilariously NSFW.)
Lifehacker posted Nick Denton’s manifesto on the new design last November, and previews were floating around at that time. Denton talked a lot about traffic statistics, branding and advertising, but also more specifically about the design and UX. The design goal was to evolve beyond the traditional blog: to feature content outside of the usual timeline, to aggregate and classify the content more effectively, to showcase more than just text-based content, and to use visual content is a more arresting fashion.
It’s hard to understand why this demands a manifesto, because there isn’t much that is conceptually new here. Traditional media have already expanded beyond the basic blog feed, with front page feature areas, modules, that display different slices of information, slideshow templates, and video showcases.
What is new is The Box. It’s not necessarily new to the web, but it’s probably new to blogging, and it’s certainly new and shiny to the exclusion of almost every other detail of the new design.
The pages still scroll, but the top and bottom navigation bars and the side borders create the impression that you are in an App, and not on a traditional site. Content loads via AJAX without a perceptible reload as well. The viewport scrollbar only works on the main story, leaving the right content list and navigation in place.
It’s clear that the design is meant to shift the control of the browsing experience from the user to the editor. The top and bottom buttons point to the next story, or to different slices of the content lists, or allow the user to scroll to the next batch in the list. In fact, there is no visible way to scroll the list of stories on the right, aside from the button. The mouse-wheel or trackpad scrolling does work when hovering over the list, but it’s frustratingly inaccurate.
The most puzzling thing about The Box is the fixed width, however. It makes the whole model seem simultaneously claustrophobic and antiquated. It’s as if the design wants to take over the whole viewport, but isn’t confident enough to stake out the entire width, so it apologetically hems itself into the middle of the window.
The Box is about as interesting as it gets, though. The visual design is flat and somehow drab. The logos are drab, and the buttons are grey and lifeless, too full of text to be immediately decipherable. The color palette seems to be limited to mostly greys, with a single complementary color for the links per blog. The typography is even less considered. There is little variation in type size and little attempt to anchor and arrange type in any way aside from left and right justification.
The body copy, byline, comment metadata, and comments are all basically the same. It’s as if it were laid out using Netscape Navigator 2. Even a minimalist can understand using font sizes to create a sense of hierarchy.
And here we are, making the visual elements more arresting:
A video is sandwiched between the top bar and the page headline, offset by a somewhat drab logo. Some space might help here, or perhaps a larger video size, or even a better poster frame for the video.
And then there is this:
Most of Denton’s manifesto revolved around advertising, and the site does not even accommodate a standard banner unit in any meaningful way. (The ad in question is the grey box in the lower left, a skyscraper obscured by the brilliant ClickToFlash.)
It’s as if the actual content of the site was not considered, at all. Even the ads, which seems out of character.
The strange part about this is that the Gawker network had already developed strategies to keep featured content visible and some nice visual designs. The top row of stories with large thumbnails from the prior design, as seen now on The Awl, were much more compelling than the new right hand list. Each blog had its own character, whereas now they are all uniformly, blandly, part of the same network. The new design fails at almost every visual goal set in the manifesto.
It will be interesting to see how The Box inevitably evolves in the next few months.
1.
