Screen Resolution Statistics

When it comes to researching user's screen resolution, I'm a strong believer that vertical positioning matters most when considering key issues such as location of identifying elements like site name and h1-type headings, and elements that satisfy business rules such as ad location. The B&A article, "Blasting the Myth of the Fold" addresses this issue well, and I'm in agreement that "the fold" matters little if the above issues are dealt with. But the issue of browser width is still one that is heavily dependent on audience, and knowledge of what your web analytics tool records about actual users.

When you have a site that has not gone public yet, however, you will have the need to address the issue of resolution in the absence of real data for your site. So where do we turn? We benchmark. Here are a few of my sources for researching this kind of information:

  1. Start with sites that provide a log analysis service across a broad range of sites and publish their aggregated stats. Example services that provide this data include The Counter, W3Counter, and Net Applications.
  2. Compare for sanity against individual sites, especially other sites in your industry, or sites you may already publish. W3Schools publishes their stats, for instance, but that audience is heavily skewed towards technical users.

If you have to provide a few sites as a benchmark sources like these may be helpful. Base your browser width decisions on your understanding of who will be accessing your site, just as you would consider user research when deciding what features to provide in your product.

For a bit of information about the estimates you get from aggregated sources, see this Wikipedia entry on Usage of Web Browsers.

Undressed theme

Sorry for the lull in activity this past few weeks. I'm doing my last days at my current job and getting ready to transition to a new gig in a week.

After the last 2 months with this site, I've assessed some of the functionality I went out with, and am doing some cleanup. I launched with all the blades out and am now pulling them back in to only expose the essentials. The goal will be to simplify the navigation, and let the screenshots take prominence. There will be some reconfiguring of database searches and sort options as well, now that I've found what the typical flow will be for this site. I'm also going to remove the design/interface submission options for now, and may go another direction with regard to that.

Anyway, for now, I've stripped out the graphics and will get a slightly more low-fi design up in the next few weeks.

Screenshots now in RSS feeds

I've added screenshots to the feeds finally. This has been on my to do list, but I finally got off my ass and spent a couple hours this morning figuring how to get Drupal to do it after a user made some demands. There are a bunch of things that aren't working for me on this site that I plan to fix, but I went with the idea of getting things up fast versus getting them out right. The experience will get better over time, I promise.

For the record, I don't plan to implement every suggestion that comes along, but this has been on my list. If you do have suggestions, please do make them, but know that I'm more receptive to a friendly tone.

OmniGraffle Web Design Template Updated


I updated the OmniGraffle Web Design Template.

This web design template is for people who do wireframes and storyboards. The template was created for OmniGraffle Professional provides the basic layout for a design deliverable including the following master canvases: document title, section title, wireframe (portrait and landscape), storyboard, and blank. The wireframes were created at 950px wide with guides following the Blueprint CSS Grid system. Wireframes also have 2 small hairline marks around the 600px point to mark the approximate fold. Go grab it here.

Google Design Principles

Luke Wroblewski summarizes the fundamental principles that guide Google in designing user experiences, as told by John Wiley in a WritersUA presentation.

  1. Useful: focus on people -their lives, their work, their dreams.
  2. Fast: every millisecond counts
  3. Simple: simplicity is powerful.
  4. Engaging: engage beginners and attract experts.
  5. Innovative: dare to be innovative.
  6. Universal: design for the world.
  7. Profitable: plan for today's and tomorrow's business.
  8. Beautiful: delight the eye without distracting the mind.
  9. Trustworthy: be worthy of people's trust.
  10. Personable: add a human touch.

Hat tip to Frank for the link.

Hold the front page

The Economist reports on some research undertaken by Fang Wu and Bernardo Huberman, a pair of researchers at Hewlett-Packard’s laboratory in Palo Alto, California, to compare two strategies used on news sites: one based on the previous popularity of a story, the other on its novelty. The researchers based their study on analysis of articles posted to digg, and the article provides some insight into the digg algorithm and the half-life of an entry (about 69 minutes before an entry gets demoted from the home page).

They summarize with some editorial advice:

[W]hat it means in practice is that if you run a website, you would be wise to learn more about exactly how interest in your stories cools off, if you want to display those stories in a way that will entice the largest number of people to read them.

Apple's Design process

Michael Lopp, Senior Engineering Manager at Apple discussed Apple's design process at a presentation given at SXSW. Business Week summarized the points, excerpted below.

Pixel Perfect Mockups
This, Lopp admitted, causes a huge amount of work and takes an enormous amount of time. But, he added, “it removes all ambiguity.” That might add time up front, but it removes the need to correct mistakes later on.

10 to 3 to 1
Apple designers come up with 10 entirely different mock ups of any new feature. Not, Lopp said, "seven in order to make three look good", which seems to be a fairly standard practice elsewhere. They'll take ten, and give themselves room to design without restriction. Later they whittle that number to three, spend more months on those three and then finally end up with one strong decision.

Paired Design Meetings
This was really interesting. Every week, the teams have two meetings. One in which to brainstorm, to forget about constraints and think freely. As Lopp put it: to "go crazy". Then they also hold a production meeting, an entirely separate but equally regular meeting which is the other's antithesis. Here, the designers and engineers are required to nail everything down, to work out how this crazy idea might actually work. This process and organization continues throughout the development of any app, though of course the balance shifts as the app progresses. But keeping an option for creative thought even at a late stage is really smart.

Pony Meeting
This refers to a story Lopp told earlier in the session, in which he described the process of a senior manager outlining what they wanted from any new application: "I want WYSIWYG... I want it to support major browsers... I want it to reflect the spirit of the company." Or, as Lopp put it: "I want a pony!" He added: "Who doesn't? A pony is gorgeous!" The problem, he said, is that these people are describing what they think they want. And even if they're misguided, they, as the ones signing the checks, really cannot be ignored.

The solution, he described, is to take the best ideas from the paired design meetings and present those to leadership, who might just decide that some of those ideas are, in fact, their longed-for ponies. In this way, the ponies morph into deliverables. And the C-suite, who are quite reasonable in wanting to know what designers are up to, and absolutely entitled to want to have a say in what's going on, are involved and included. And that helps to ensure that there are no nasty mistakes down the line.

Thanks to this article, I heard someone in my office referring to dream features as ponies.