Brandon Rosage

Giving readers a sense of volume on the web

Thu, 02 Feb 2012 13:46:00 -0800

My Ushahidi teammate Heather Leson participated in the Mozilla Festival’s November “Touch the News” design challenge, in which her team was asked to improve the news reading experience on an iPad. The challenge focused on using location, time of day and the user’s available time as important variables to the problem at hand.

I find these kind of exercises fascinating because they force talented people to solve a problem that their day-to-day work often doesn’t explicitly present. But through these exercises, those people often discover design solutions that bring new value back to the products they’re working on day to day.

From Laurian Gridinoc’s recap of the exercise, it seems that her and Heather’s team zeroed in on readers’ desire to reclaim a sense of volume on a website.

For example, if a user visits The Boston Globe website during their 15-minute commute, how can the website’s user interface help them glean which stories they’ll have time to read?

Gridinoc said:

We thought that reading time instead of number of words would be a good indicator of not only volume but also time needed to engage in a satisfactory manner with an article.

They created some really interesting wireframes and, I think, did some really great work. But I think they missed an opportunity to better reclaim the sense of volume that print publications offer. And it started with using “reading time” as the indicator of that volume.

The first objection I have to “reading time” is that there’s no real universal value you can assign to a given story. You can tell the reader how many words the story contains or even suggest how much of their screen the story occupies (via scrolling indicators). But you can’t tell them how long it’ll take them to read it — at least not with a valuable degree of accuracy.

Not time, but volume

I’m reminded of Apple’s contradictory decision in iBooks to mimic the print book reading experience by displaying a stack of pages at the edge of each current page without also displaying fewer pages to the right as you make your way toward the end of the book.

Where my mind goes in trying to solve iBooks’ problem is the same place it goes in tackling the “Touch the News” problem: Let’s do our best to naturally show readers what they’re up against.

Print publications are fantastic at this. The medium’s fixed physical constraints, like weight and volume, go a long way in aiding the reader in determining what they’re up against. So how can we bring that same intuitive sense for volume to the web?

I think an easy and logical place to start is with the front page.

Heather and Laurian’s team started here, as well, but focused on attaching horizontal bars to the summary of each story. The bars represented how long each story would take to read. Each summary’s bar responded to an interactive vertical bar at the left of the page, which was to be manipulated by the reader to inform the website how much available reading time they had.

In my opinion, trying to add value by asking readers to do something they didn’t have to do before is one step forward, two steps back. But I also question how intuitive these bars would be in aiding readers to easily view a page and know what they’re up against.

They’re on to something, though.

Again, the standard is currently set by print publications’ user interface. The user can tell a lot by the thickness, weight and size of type on the item. Pitting bar graphs against that type of experience is a losing proposition.

Instead, I think a winning first step would be to accurately show the contents of the website (not simply the length of the highlighted stories) on the front page.

So in the case of The Boston Globe, where let’s assume most readers are arriving to read that day’s stories, the challenge is to show:

How many stories are available today.
How much content is packaged in each one.

Showing volume on screen

If we decide upfront that we cannot display the headline for every story published in the past 24 hours, we must still represent them in order to offer a sense of volume.

In print, each story is represented by a headline and its contents. And in the event a story is teased, it’s represented at the very least by a headline. The total number of those stories is then represented by the sheer thickness of the publication. So both aspects of the aforementioned challenge are addressed relatively elegantly in print.

To address the first challenge (show how many stories are available today) on screens, I’d reject the assumption that a story must always be represented by its headline.

Why not a simple icon? Stories that are less important (but must still be represented as part of that day’s overall content) can be reduced to a dot, just as they’re reduced to later-page thickness in a print publication.

With this visual language, anytime we wish to communicate that there’s a story to read, we see a dot. The stories we wish to highlight as “most important” may have large headlines, summary text and photos paired with them. But we know it’s a story because there’s a dot.

This still frees us to exact some editorial control over what stories are most visible. But it also frees us to display the volume of content without being obligated to list hundreds of headlines.

You can imagine a front page communicating that there are 10 stories of varying size and importance — but all represented with a dot. The most important stories are summarized at the top with three elements: Large headline, photo and summary text.

On that same page, below these top-level stories, is a second level of summarized stories; this time with smaller headlines, no photos and short summary text.

The next level down, only headlines.

And at the bottom-most level, only dots.

By visually scanning the front page, the reader can take in the number of stories and which ones the editors deem most important.

This addresses one half of the challenge, I think. But how to show the relative volume of each story when they’re reduced to a summary (or even a dot)?

As I said, I think ‘estimated reading time’ is a poor metric for calculating volume in the context of reading. And to help the reader determine the investment they’d like to make in a story (whether in time or attention), I don’t think we can avoid showing volume.

Word counts are too clumsy and difficult to interpret. Number of pages is obviously out the window on the web. And time is entirely relative to the reader.

So how do we show them, visually, the contents of a story? I’d suggest leveraging the dot — the shared visual element among all stories — as an interaction point with which the reader could select and see a quick popover snapshot of everything included in the story.

A thumbnail or preview, if you will.

I consider this a modest attempt at tackling what I think are the key challenges to giving reader a sense of volume on the web: Showing them how many stories are available and how much content is packaged in each one.

I’d be curious to see some designers riff on this start to solving the problem of communicating volume on screens.

One Web, Many Devices

Tue, 31 Jan 2012 16:47:00 -0800

One Web, Many Devices:

I’ve linked to Jeremy Keith’s work quite a bit in the short life of this website. His talk in September at the Update conference, “One Web, Many Devices,” embodies why I find his ideas so compelling.

I often find myself reiterating ideas Keith espouses, because they don’t just bang the “long live the web” drum. His message displays a care in our craft that goes beyond just user experience and delightful technology:

But there is another level …where you’re not just thinking about the user right now today and their flow, but where you start to think about all people. Start to think about our species and ask yourself if your creation is going to contribute to the betterment of our species.

I think publishing on the web, there’s a net gain for our species, there’s a net gain for our planet because we’re contributing to the stock as well as the flow. It’s not just for today. It’s for future generations as well.

“One Web, Many Devices” is seminal. Watch, listen or read it.

Fixing iOS' orientation and scale bug

Mon, 09 Jan 2012 17:48:00 -0800

Fixing iOS' orientation and scale bug:

The Filament Group’s Scott Jehl developed and shared a brilliant band aid this week for iOS’ frustrating orientation scaling bug.

The fix arrives via Javascript, which listens to iOS devices’ accelerometer to detect when a user is about to rotate their device. When the script detects an orientation change coming, it temporarily disables user zooming — for only the moment it’s appropriate. User zooming is restored once the device is either oriented close to upright, or after its orientation has changed.

So. Damn. Good.

Recall that web developers have wrestled with iOS in this respect since its launch, wishing to deliver their ‘responsively-designed’ web pages scaled to 100 percent. Using meta name="viewport" content="width=device-width, initial-scale=1.0" allows us to do this.

And it’s been important to deliver this experience to users without invoking maximum-scale=1.0 or user-scaleable=no (which prevents any scaling weirdness) because such a solution creates a whole batch of new problems. The biggest problem it introduces, in my opinion, is stripping users of the common and powerful ability to scale the web page as they see fit.

At the end of the day, we want users that are holding their iPhone in portrait view to see our web pages displayed 320 pixels wide — which they do. But we also want them to be able to rotate their device to landscape view and see the web pages adapt to 480 pixels wide.

Yet Mobile Safari continues to behave differently. When users move from portrait to landscape, our web pages display at a width larger than 480 pixels. Users have to double-tap to bring the scale back down to 100 percent.

See Jeremy Keith demonstrate this behavior, which is strangely gone when viewing web pages in iOS apps’ web view:

I’ve implemented Scott’s fix here on BrandonRosage.com, so you’re welcome to test and sample the behavior here.

Until Apple addresses this bug (or offers a logical reason for Mobile Safari’s behavior), Mr. Jehl is the only person on the planet who can rightfully call Mobile Safari his bitch.

'My hometown is better than yours'

Thu, 05 Jan 2012 13:45:00 -0800

'My hometown is better than yours':

I’ve been owning up recently to what I think has been a lifetime of excuse-making for the Northwest’s nutty weather. I thought I was being too forgiving and dishonest. But this takes it to a whole different level.

Deliver content-first HTML without sacrificing a navigation-first layout

Wed, 04 Jan 2012 15:53:57 -0800

One of the best design patterns, in my opinion, to come from the past four years of user interface design on mobile devices is the shift toward displaying content first and navigation second. Having so much less screen real estate than on the desktop has been fantastic for interfaces designed for reading and consuming; though it’s brought tremendous focus to utility apps, too.

But if it’s important in the design of your web product to build a responsive website that doesn’t rely on alternative URLs or subdomains to serve up an entirely new interface, it can be challenging to offer intuitive navigation to desktop users (where it’s displayed at the top of the page) while pushing that navigation to the bottom of the screen for small-screen users.

The brilliant speakers at this summer’s An Event Apart tour, like Luke Wroblewski, Jeremy Keith, Jeffrey Zeldman and Eric Meyer, synthesized some terrific approaches to this problem using nothing but CSS. No browser sniffing, no server-side code.

Smart semantic HTML is, again, rewarded.

There are a few approaches with CSS that address the need to re-order sibling elements. As I tackled this issue in Ushahidi’s SwiftRiver and Crowdmap user interfaces, I begrudgingly settled on the more bulletproof CSS 2.1 solution, ignoring a more elegant CSS3-only solution.

CSS3’s smart solution

Let’s assume I have two primary elements in my document’s body: Content and navigation. My HTML might look like this:



My content.



Navigation item 1
Navigation item 1

By writing our markup first for small-screen devices, we don’t need to do anything out of the ordinary with our CSS here. Content will display first and our navigation will be available after that.

But for larger screens, where we want navigation to appear first, we could target the larger viewport with a CSS media query and insert the following CSS3 properties to reverse their display order:

@media screen and (min-width: 615px) {
    body {
        display: box;
        box-orient: vertical;
        box-direction: reverse;
    }
}

An old school, better-supported solution

The method I used on the control panels for Ushahidi Core and Crowdmap isn’t as intuitive as CSS3’s “box-” properties. But more browsers support it.

Assume the same HTML markup and media query, but leverage different display values and the caption-side property:

@media screen and (min-width: 615px) {
    body {
        display: table;
        caption-side: top;
    }
    nav {
        display: table-caption;
    }
}

The problem this solved on Crowdmap and Ushahidi Core was the need to:

Write HTML markup that listed a report’s full story and comments before its metadata (e.g. date, categories).
Display a report’s metadata before its full story and comments on large screens.

Crowdmap’s control panel displaying a report’s full story and comments first on a small-screen device

Crowdmap’s control panel displaying a report’s metadata before its full story and comments on a large-screen device

Jeremy Keith put together a great write-up on these methods, as well as some use cases for leveraging the same CSS properties to display the elements horizontally.

So simple. So powerful.

A plea for progressive enhancement

Wed, 04 Jan 2012 13:05:06 -0800

A plea for progressive enhancement:

Stephanie Rieger wrote a fantastic walk-through of the Barack Obama campaign website’s failure to function or display effectively on multiple devices — another example of designing and developing for the most capable browsers first, and nearly last.

She also explains how she approached a similar challenge using progressive enhancement to build a bulletproof product.

Brilliance should lead to humility

Tue, 03 Jan 2012 09:34:00 -0800

Brilliance should lead to humility:

Regarding my piece yesterday about a lack of modesty in the developer community, a family member responded with a much more suitable term: Humility.

He points me to a fantastic piece by Derek Ouellette in which he describes the danger of getting wound up by your brilliance in a specific area:

To summarize this, Dickson writes:

“True experts ought to be more conscious of their limitations than most. Knowing a lot in one area should, in theory, underline just how much there is to know outside of your specialty.”

Experts should know this more than the rest of us because they are experts. But the lesson is one we should all remind ourselves of regularly. Next time we get into a discussion with someone about something we believe in contention to something they believe, remember that what we know about that subject (even if we are experts in it) is far out weighted by what we don’t know.

I know I jab my fist in the air nearly every time I solve some complex scripting problem and declare, “I am a genius!” Sure, I’m joking. But I’m also guilty of later thinking that whatever smarts I used to solve that problem would be good for everyone.

They’re not. What I’m good at isn’t “the new literacy.”

Learn to code, but don't get a big head about it

Mon, 02 Jan 2012 18:56:00 -0800

Like iOS and Mac developer Guy English, I’ve noticed a growing sentiment in the web development community that “writing code” or “programming” is somehow approaching a level of importance similar to writing a novel, essay or research paper.

WordPress founder Matt Mullenweg, for example, is fond of saying, “scripting is the new literacy.”

Unlike Guy English, I’d like to echo his response to this sentiment with a “me too.”

There’s a dusting of ego in the air, I think, when developers are suggesting that the near future will demand that most everyone know how to “write code,” just as they need to write English.

Guy English:

Writing software is a craft. I’m quite good at it. Brent and Jalkut are also very successful at our craft. But it’s a craft. It’s something we’re really good at but, in my opinion, it’s not something that everyone needs to care about.

Without a doubt, improving our world’s infrastructure through scripting will be one of the most important efforts of our lifetime. Designers, developers — people that write code — are, and will continue to be, in enormous demand. Their scripting literacy will be, in many ways, as valuable to them as their English, Spanish or German literacy.

But elevating that value to the level of general literacy (something we expect of everybody), rather than recognizing its place in our industry, is a mistake. I’d hate to see our community be disregarded as behaving too self-important.

UPDATE: I wrote a follow up to this piece regarding “humility,” a much more applicable term for this matter.

iOS apps strike me as a weird fit on Apple TV

Mon, 02 Jan 2012 10:16:00 -0800

iOS apps strike me as a weird fit on Apple TV:

While I understand iOS developer Steven Troughton-Smith’s intent here was primarily technical achievement, I can’t help but wonder if Apple TV critics’ clamoring for App Store support on the device is misguided.

I’ve yet to hear a desirable use case for third-party apps on Apple TV when, in my view, a simple directory submission process for content creators (like the iTunes Podcast directory) would fill in the device’s current gaps.

Why not just open the door for users to add content sources to their menu? In effect, allow users to replace or add to the sources currently listed under “Internet,” like Wall Street Journal or NBA?

It’s a TV-watching tool, after all, no?

/ via cnet

That's one way to do 'responsive design'

Sun, 01 Jan 2012 16:08:00 -0800

That's one way to do 'responsive design':

I’m simultaneously annoyed and pleased with Microsoft’s desktop-only design effort on its “Bing Magic Holiday Calendar.”

Annoyed because it’s more of this poisonous “the web is only worth building for with desktop browsers” approach to web design and development.

Pleased because, if you’re going to disregard a significant swath of web browsing devices, I credit Microsoft for owning it.

Don't assume Javascript support: How I use jQuery to change markup on the fly

Fri, 30 Dec 2011 18:03:00 -0800

One of the core design principles I start with when tackling a web product is that it not assume Javascript support. The product must be able to provide its content and functions to users in a manner appropriate to their device’s Javascript support.

Surely, we can present the content and functions differently depending on the device’s support. But if their browser doesn’t support Javascript, their experience with the product shouldn’t be crippled.

It’s a principle I defend through the product’s design and development until there’s a justifiable reason to concede that it’s not appropriate for the given product. In my experience, those situations are rare.

I’m embarrassed to admit that I lose sleep discovering products that are designed upside down in this respect — assuming support for every technology they desire to use, only waiting for enough pressure (read: money) to attach a “fallback” solution for devices with no Javascript support.

Building a bulletproof Crowdmap and Ushahidi Core

In my renovation of the Ushahidi Core and Crowdmap control panels this winter, we knew the products were used on a wide variety of devices and conditions. So while we designed a fair amount of visual interaction that leverages Javascript, we also designed comparable interactions for use cases that don’t include Javascript support.

Crowdmap with no Javascript support:

Crowdmap with Javascript support:

There’s no fallback. Instead, the products “fall forward,” using Javascript support to rearrange the furniture and layer on the more dynamic interactions that capable devices allow.

In the case of Crowdmap’s long streams of report summaries, each report had to:

Display links for performing actions on it (e.g. approve, verify).
Display a link to view all of its details, including categories and location.

Each report’s data is displayed dynamically, so we have to assume any number of reports with a range of content present on any single web page.

My approach to these streams, as it pertains to the “don’t assume Javascript support” principle, was to write the HTML assuming the lowest level of support. So each report summary’s links for performing actions and viewing details is a typical anchor tag located below its summary content.

When Javascript is supported, however, we let it go to work. It changes the link’s markup so that they interact with CSS to display buttons to initiate the list of actions as a pop-over and to optionally reveal the report’s details as a slide-down drawer.

Perhaps one of the more time-consuming challenges was to nail down an efficient way to repeat the aforementioned Javascript function on each report, so that each report moved and received only the markup unique to it.

Most of the approaches to similar problems that I uncovered through search either assume you’re only moving one element on a page, moving identical markup or attempting a complex combination of copying the data, removing it and pasting it again through jQuery’s detach() method.

For those tackling a situation similar to mine, I used jQuery to write a relatively short and sweet solution using the jQuery.each() function.

I effectively identify my selector at the declaration of the function and wrap it around three functions important to my product:

Communicating where the report’s links markup is and making it a variable (e.g. articleTools).
Appending said variable to its new location within the report’s markup.
Conditionally adding a class to the buttons’ container in the event that there are more than one buttons. This ensures the buttons’ corners are rounded appropriately.

It’s simple and works great. And it reinforces the idea to me that supporting many browsers and devices is easy if you design mindfully from the start.

Leaving the newsroom for the web

Wed, 28 Dec 2011 17:11:00 -0800

As an outgoing journalism student from a four-year university in 2007, I considered myself extremely fortunate to have a full-time job at a legitimate newspaper. The fact that I was paying the bills with my writing, editing and design skills meant I was winning at life.

So in hindsight, it makes sense that I was crippled with fear and self-doubt as I drove away from the newsroom that October, having just told the publisher that I was leaving. I was walking away from one of the few jobs available in the only industry I knew to pursue a career for which I had no formal training. It was the first back-breaking decision I had made strictly through intuition, ignoring common sense and the opinion of nearly everyone around me.

The newspaper business is an institution, after all. It’s an exclusive and often pretentious club of smart people who share strong, universally admirable values, like honesty, truth and the importance of being informed.

I had earned myself at least a stool propped against the outer wall of the room where those smart people worked every day. And yet here I was, giving away my seat and driving away to take a swing at the web.

And while it’s cliche to say today, in hindsight, that it was one of the smartest decisions I’ve made, I think the wisdom of the decision was more plainly visible in 2007 than it is today.

Creators of many types — journalists, writers, designers — are largely grasping to solve the same problem: A cluttered, confusing and unnecessarily complex world. I consider myself among them, trying to clarify, improve and inform the world around me through my medium of choice.

What I think contributed so heavily to the scary environment journalism students faced in 2007 was a total lack of control and access to their medium.

We had no control over the medium that carried our work, limited by the high cost of print publishing or radio and television broadcast tools.

And we had no access to the people or paperwork necessary to distribute our work. Where licenses, partnerships or press passes were necessary, few or none were available to new media outlets.

The only path to making a dent in the world with our skills and values was to cut our teeth doing great work within the constraints of other people’s products. Surely, no one was being oppressed or abused. But there was far more energy, talent and vision among young professionals than the media landscape’s existing outlets were able to utilize.

We were prepared to write, photograph, film and design the world around us better (we thought) than the people before us. But there were so few outlets to do it.

Whether it had traction at that time or not, the Internet (and particularly the web) was an obvious playground for that energy, talent and vision. No one controlled it, and yet anyone could try. And accessibility was a paramount principle in its design.

We were empowered to be creator, editor, designer and publisher.

It was a place where, if I thought I had created a brilliant piece of video, I could publish it without review. If I wrote a compelling story, nothing stood in the way of me sharing it with an audience. If I thought I could do a better radio show than Rush Limbaugh, I had no excuse for not setting out to prove it.

As a designer and developer of web products, I’m acutely aware of the web’s clumsiness relative to the comforts of traditional print, broadcast television and radio. But it was perhaps even clearer in 2007 than it is today that the web presents a boundless, thrilling landscape of opportunity to solve the problems that the industry we were so desperate to give ourselves to in 2007 is so poorly suited to tackle.

The wisdom of pursuing the web in 2007 wasn’t so much about technology or trends. It was simply about choosing the best way to solve our problem.

The Arc Non-profit organization. The Arc of Washington State...

Wed, 07 Sep 2011 21:06:00 -0700

The Arc

Non-profit organization.

The Arc of Washington State hired me to carry their website through a major overhaul from an out-dated, FrontPage-powered, user-hostile experience to a visually elegant, easy-to-manage, task-centered experience.

After first leading The Arc’s team through a content inventory and information re-architecture, I provided visual design mockups that captured more than six page layout types in wide- and small-screen display.

I also developed the website using HTML5, CSS3, jQuery and WordPress, and facilitated the migration of the organization’s existing content from its old system to the new.

Don’t Stop Printing Custom screen printing...

Wed, 07 Sep 2011 20:18:00 -0700

Don’t Stop Printing

Custom screen printing business.

**PROJECT CURRENTLY IN PROGRESS**

The rock stars at the “Don’t Stop Printing” T-Shirt design and screen printing shop hired me to implement their brand refresh on the web, making it dead-easy for customers to see cost estimates and start their order.

The project called for web design, web development (HTML5, CSS3, jQuery and ExpressionEngine), and full-service video production.

Andrea’s Photography Photographer’s website. Olympia...

Sat, 30 Jul 2011 00:00:00 -0700

Andrea’s Photography

Photographer’s website.

Olympia photographer Andrea Baker needed a web presence and fresh branding to match her deep portfolio and creative reputation. My work included developing Andrea’s branding, with various implementations of her logo mark and type. I designed her an elegant website that provides a unique display on varying screen sizes. And I developed the website using HTML5, CSS3, jQuery, Flickr’s API (for photo gallery management) and ExpressionEngine (for content management). The products allow Andrea to showcase her work and services, while mirroring her collection of photographs that are available on the world’s largest photography community.

Mary Webb Business consultant’s website. Mary Webb, a...

Sat, 09 Jul 2011 00:00:00 -0700

Mary Webb

Business consultant’s website.

Mary Webb, a worldwide business consultant and brass personality, worked with me to build a new brand and accompanying website for her consultancy. The project required me to complete logo design, copy writing, photography, video production, web design and development to create a digital presence unlike any other in her industry.

Web development required command of HTML5, CSS3, jQuery and ExpressionEngine. Video production included filming, conducting interviews and post-production using Final Cut Studio.

MaryWebbConsulting.com packs candid videos about Mary, fresh photography and brief communication about her services.

Derricott Law Attorney’s website. Olympia lawyer and small...

Thu, 23 Jun 2011 00:00:00 -0700

Derricott Law

Attorney’s website.

Olympia lawyer and small business advisor, Mark Derricott, hired me to create a personal and engaging website for his law practice. Mark’s website serves as the front door to his business and personality, but also as a super-quick contact tool that allows residents to ask questions via Facebook or email directly from his homepage.

His website uses HTML5, CSS3, jQuery and ExpressionEngine to offer dynamic user interactions, a responsive layout and web-based content management.

Einmaleins.TV Internet broadcast network.

Wed, 20 Apr 2011 00:00:00 -0700

Einmaleins.TV

Internet broadcast network.

Careers.wa.gov State government jobs website. The Washington...

Mon, 14 Mar 2011 00:00:00 -0700

Careers.wa.gov

State government jobs website.

The Washington State Department of Personnel tasked me with leading the design and development of its new recruiting and hiring website for state employees, “careers.wa.gov.” The project sought to develop a user-centered information architecture, bring an inviting visual design and integrate the NEOGOV human resources web application.

The project called for bi-weekly meetings of the inter-agency team, including my leading the team in architecting the website’s content. I completed four rounds of design revisions and the development (using XHTML, CSS and Javascript) of every page.

I also worked one-on-one with NEOGOV’s lead developer to design, develop and document a custom implementation of its human resources application as it was used on all Washington state agency websites, including careers.wa.gov.

The Garden Gnome Small business website.

Tue, 01 Feb 2011 00:00:00 -0800