New Tool for Determining Browser Viewport Size

Nine years ago I had become fed up with trying to explain to clients, users, friends, co-workers, and strangers that screen resolution, browser chrome, and browser size combine to create some unique viewport sizes. What this meant was that whether a user had a display at 640x480 or at 1,024x768 was irrelevant if both users had their windows set to the same size. Factor in toolbars, scrollbars, add-ons, and other configuration settings and you had a wide range of viewable space for your web site design that was only loosely related to the actual screen resolution of your end user. I distilled all this down in an article, Real-World Browser Size Stats, Part II (part I described the code I used), written back in 2000 that provided statistics on the viewable area in a browser per screen resolution setting.

Since then many others have started reporting on screen resolutions but few have taken it a step further to report on actual viewable area within the browser. Too many of them, like this chart on the W3Schools site, list the screen resolution trends but neglect to mention that once you pass 1,024x768, users are less likely to surf full screen. Human Factors International even cited my article, but got the conclusion wrong (claiming that as users got more screen real estate they opened more pages).

Today Google has gotten a little closer to getting the point. In a blog post introducing this new tool Google mentions that users were looking at Google Earth, but just not downloading it. After some testing they found the that download button was displaying off screen to the right (outside the viewport) for some users. So they built a tool to help show the breakdown of viewport sizes of users visiting the site as a contour visualization. After seeing some value in this tool for web developers in general, they modified it a bit to make it possible for a user to interact with the page under the contour map. As the mouse moves across a page, a small block of blank space is left around the cursor so that the user can click links or fire hover actions.

Contour map of viewport size statistics.

Head on over to browsersize.googlelabs.com to try out the tool for yourself. When you get there you will see a sample site is already loaded up. The percentiles used in the overlay are pulled from the latest data of visitors to Google.com, so don't think that they numbers necessarily apply to you (my own experience is that for targeted sites they may not). Type the address of your web site (or any site you want to test) into the search box and submit. Give it a little time to load and you are ready to start looking. You can now see what parts of your site are visible (or cut off) at what viewport sizes.

Beware, however, that this tool isn't foolproof. For liquid sites or for sites that float in the middle of the page you may find the numbers don't mesh up as you'd expect. In those cases you can scale your browser window down (width and/or height) to at least get an idea of how it might appear at a specific window size. The numbers on the contour map also don't correspond to known screen resolutions, so you'll need to compare them to other numbers just to be certain you have your data points right. The tool also doesn't account for scrolling, which we all know users do. Instead it shows you how a page might look simply at first load. Because this is a freebie from Google Labs, consider the documentation sparse (which isn't a criticism).

Amazon.com as viewed using the Google Browser Size tool.

Read More

More News in the URL Shortener Market

Back in October I commented how the list of URL shorteners has gotten even shorter (or shortener, as I liked to call it). As bit.ly rose to the top thanks to Twitter, Tr.im and Cli.gs called it quits. Things have changed a bit since then.

Recap and Updates

Tr.im

Tr.im took back its statement of impending doom when the blog was overrun with support, was approached with an offer from bit.ly (which they declined), announced it was going open source three months ago, and has been silent since.

Cli.gs

On December 1, Cli.gs was acquired by Mister Wong, and continues to provide its URL redirecting/forwarding service. What else it will ultimately provide is anyone's guess.

What's New

The market for shorteners is not dead, however. The argument can be made that bit.ly survived simply because Twitter standardized on its platform for tweets, known for their 140 character limit. Some of the big boys now have an interest in this game, and have considerably more resources to bring to bear to bolster what might otherwise be a losing proposition.

Goo.gl

Yesterday Google announced its own URL shortener, Goo.gl. In this case, it is not a stand-alone service, it can only be used from the Google Toolbar (for your web browser) or from FeedBurner (their RSS aggregator). They do not exclude the possibility of opening it up to wider use in the future. Google claims the service will provide stability (big fat data centers), speed (big fast data centers), and security (URLs will be sniffed to look for spam/malicious sites).

fb.me

If you think Google was ahead of the curve, you're wrong. They were responding to Facebook. Facebook announced yesterday that it was testing its own shortener, fb.me. While Facebook cites the change as a way to stay more open and connected, they are interested in the analytics data they can glean if they own it. Facebook is also smart enough to make sure existing links, such as http://www.facebook.com/aroselli, will work at the new address, http://fb.me/aroselli (it's worth noting that you need to be my FB friend for these links to work — sorry). Right now Facebook is using this feature to automatically shorten URLs shown in the mobile interface.

bit.ly

But the day didn't end there. Bit.ly decided they, too, had an announcement to make for their new bit.ly Pro service. Because bit.ly has traction already with its analytics service, because it's integrated with Twitter, and because it's a stand-alone service, bit.ly doesn't need to worry too much about losing its position just yet. This move, however, entrenches it laterally. They have partnered with AOL, Associated Content, Bing, Clicker, The Daily Telegraph, foursquare, GDGT, Hot Potato, The Huffington Post, IGN, kickstarter, Meebo, MSN, /Message (Stowe Boyd), MTV Networks, The New York Times, OMGPOP, oneforty.com, The Onion, slideshare, someecards, Stocktwits, TechCrunch, The Wall Street Journal Digital Network and blogger Baratunde Thurston (baratunde.com). The example they give is nyti.ms. The example I have already seen out there is Foursquare, which you may have seen in updates from friends. My recent check-in came through in my tweet as 4sq.com/8XoZwz. Just in case you don't believe me, bit.ly provides the analytics on that link.

Uh.oh

While all this develops, I still echo my concern about URL obfuscation and link rot. It's too easy to hide the true destination of a link when you mask it using a shortener. Google may think it can defeat that, but I am suspect of that claim over the long term. Links may also go away, but the shortener doesn't know it and may not pick up the redirection instructions before they are shut off. Over the next couple years we'll see just how much link rot abounds on the web as we find ourselves constantly following shortened URLs to broken pages or porn sites.

I will repeat myself from my first post on this topic: If the Mayans had it right, this could be the End of Days we're all expecting in 2012. Prepare yourselves for the Great Linkpocalypse.

Update: November 18, 2013

"y.ahoo.it URL Shortener End-of-life Announcement"

Read More

Telling Clients They Are Wrong

If you have spent time as a solo web jockey or your job has you interacting directly with clients, you've probably been faced with the client who asks for something you feel is wrong. If you're new to this, it may seem like a dangerous situation to be in, when in reality it's a great opportunity to establish yourself as an expert and demonstrate you considerable knowledge with well-formed arguments and supporting data/examples. Sometimes the client just isn't quite getting it and it gets a bit adversarial.

I have spent a good deal of time coaching friends, employees, partners, and so on (designers, developers, architects, etc.) on the best ways to deal with clients who have trundled down the wrong path and need some correction. Usually these people feel a great deal of trepidation in realigning the client for fear of losing the business or, worse, being overridden and forced to create something with which they don't agree (but will bear their names).

Conveniently, I don't have to reiterate all the options and steps you can take. Somebody has done a pretty good job of outlining them for me. You can read the full article, How To Explain To Clients That They Are Wrong, to get all the details. You can also read a little behind-the-scenes at the author's blog. It may be worth keeping this client perspective in mind, as mentioned in the article:

...[M]any clients still regard creative digital agencies and freelancers as either kids living in their parents' basement or shady professionals out to take them for every last penny.

For those of you who just want the distilled version, here you go, with some of my own tips peppered within...

First, determine if the client is even wrong or this is just a knee-jerk reaction on your part. As freelancers, it's easy to let your ego get the best of you. Remember, the client knows his/her business, you know the technology or design rules.

Next, speak the client's language. Ask the client what the business benefit is of the request. Don't try to snow the client with techno-babble or designer-speak. If you can get the client to verbalize the business goal, you are off to a good start. If the client cannot verbalize it, perhaps the client will realize that the request is couched in vanity instead of a tangible reason.

As part of all this make sure you come off as the expert. Dress well. Speak well. Spell well. Brand yourself well. Grammarify well. Make up new words well. Be confident, support your opinions with examples and facts, and be prepared to offer alternatives (hybrid solutions even). And don't be late (to meetings, on deadlines, to bed).

Don't hide from the client or the issue, address it quickly, in person (or perhaps on the phone, but not via email) and with supporting documentation (sign-off letters, email verification). I am a fan of the direct approach. Like a Band-Aid, just tear it off, it will be over more quickly. The article I am referencing is a little less aggressive about being direct, but if you are honest and humble (add some humor) then you should be fine.

If the client is insistent, you may need to back down. The client is the one paying, after all, and if you can document that you have attempted to prevent the client from shooting his/herself in the foot, then you will be fine. Consider making the client sign off that he/she is going against your recommendation. If that's too aggressive, just send an email verification. If you are familiar with A/B testing, now is a great time to propose it. If you aren't, you should go buy a book. In the end, spend some time looking at the results of the change to see if it ended up being more effective.

If you've gotten this far, then you should also go read the comments at the original article. There are some good ones in there, sprinkled among the self-aggrandizing ones.

Read More

How Many Disabled Users?

There is an article over at Practical Ecommerce titled Accessibility: How Many Disabled Web Users Are There? by Joe Dolson. It is refreshing to see more traditional sites dealing with accessibility, especially when it can so significantly affect their bottom line. As an indication that the author gets it:

I often hear business owners claim that their sites aren't used by people with disabilities, so they don't need to pay attention to web accessibility. But there's no basis for such claims because the merchant can't possibly know this information. The tracked profile of a user with a disability, via a typical analytics package, is identical to anybody else using that browser.

The author is smart enough to discard data that doesn't necessarily impact web usage — such as leg amputations, for example. While presenting the information below, the author reminds us that the Baby Boomers are getting older, and crossing the 65-year-old age barrier (see below):

The most commonly discussed disabilities affecting website accessibility are sight and hearing impairments. These specific impairments encompass 6.8 percent of the population age 15 years and older — and climb to encompass 21.3 percent of the population when you look specifically at the population over 65, according to the 2005 report. Eight-point-two percent of this same population is listed as having difficulty grasping objects — which affects the use of a mouse.

A conservative estimate says 1 out of 10 of your users could have an impairment of some sort. For every day that passes, that's another user who has aged or deteriorated in some way, making that number climb over time. That's 15.5 million potential customers. Perhaps this is a better way to present the information to your ecommerce customers.

Follow-up Information

Just three days later the author posted a follow-up article on his own blog titled United States disability statistics: Measurement and sources. The author explains that while his official article still gets to the point about supporting disabled users, this post is intended to provide more detail on the numbers. The authors closing comments explain how the data is good enough for some general numbers, but lacks a little detail on specific issues:

In general, my assumption is that the data may include some individuals who struggle with reading due to dyslexia, dependent on the exact phrasing of the questions, but not all, and presumably includes no or very few individuals with color blindness.

The author (still Joe) is kind enough to provide links to the PDF versions of the U.S. Census Bureau reports he used as his data sources. Since I am also a fan of providing links to the raw data, here you go:

• Americans with Disabilities: 2005
• Disability Status and the Characteristics of People in Group Quarters
• 2006 ACS Content Test Evaluation Report Covering Disability

Read More

Tables as Consumed by JAWS

There is an interesting article over at the WebAIM blog titled JAWS Ate My Tables.

The article describes how JAWS (version 10 in this case), a screen reader, decides whether an HTML table is used for layout purposes or as a data table. It turns out that JAWS does not lean on the th element or other markup clues. JAWS will look for the attribute DataTable=true|1 as an indicator that the table is used to hold data, but this is invalid HTML and certainly isn't supported by me or any WYSIWYG editors in use in CMS editors.

Instead, JAWS looks for the presence of at least 2 rows and 2 columns AND at least 4 cells in the table are between 200 and 16000 square pixels in size to determine if a table is a data table. This means JAWS ignores other markup used for accessibility or indication of the table's purpose. JAWS also analyzes the rendered size of the table, so a data table that has been enlarged by a low-vision user could be treated as layout only.

ARIA does allow authors to specify a table for presentation only (role="presentation"), but this doesn't work to force a table to be treated as data only. I suggest you check out the post and some of the user comments, and then accept that JAWS just isn't handling tables properly.

Read More

Video Accessible to Keyboard Users

Trenton Moss over at Webcredible has posted an article, Accessible online video for keyboard-only users. The concepts within are very simple, but require developers to take an extra step or two, which may account for why we see so few sites with these features implemented.

One key issue is that developers must not only code client-side script for mouse interaction, but also for keyboard interaction. Since IE behaves differently than other browsers, it must also be written twice (or at least forked). Another factor is the reliance on Flash players, which sometimes won't let you tab into the control from the rest of the page (again, depending on the browser). Regardless of whether the control is in Flash or just HTML with script, then the developer must provide a focus state for each control (so users can tell which is selected) and use a logical tab order.

The author gives the example of making the video slider accessible to keyboard users, perhaps allowing users to directly type in a time stamp so the video will jump to that point. This also benefits users who can rely on a mouse by providing a quick way to jump to a known point in the video. Volume sliders would benefit from this sort of update as well.

Read More

Bulletproof @font-face Syntax (reprint)

Paul Irish has gone ahead and created a block of CSS that we can reliably embed into our pages that will import .eot and .ttf/.otf font files. In his article Bulletproof @font-face syntax, he breaks down the various options and their support, providing arguments for and against each. In the end, he provides what he considers the best method to declare your @font-face styles in your CSS:

@font-face {
  font-family: 'Graublau Web';
  src: url('GraublauWeb.eot');
  src: local('Graublau Web Regular'), local('Graublau Web'), 
         url('GraublauWeb.otf') format('opentype');
}

If you can support (generate) WOFF or SVG typefaces, then he provides a slightly expanded block of code that can support Chrome 4 and Firefox 3.6 (neither of which has been released yet):

@font-face {
  font-family: 'Graublau Web';
  src: url('GraublauWeb.eot');
  src: local('Graublau Web Regular'), local('Graublau Web'),
    url("GraublauWeb.woff") format("woff"),
    url("GraublauWeb.otf") format("opentype"),
    url("GraublauWeb.svg#grablau") format("svg");
}

Read More

10 (Obvious) Usability Crimes

Having stumbled across the article "10 Usability Crimes You Really Shouldn't Commit, I can see that the suggestions are pretty obvious, and the number 10 is probably more arbitrary than based on some natural break in severity. However, there are some things in the article I have been repeating for years that people just don't get. And this article uses He-Man graphics, which makes it even cooler.

I'll list the 10 items, but they are much cooler in context and with the He-Man photos, so go there anyway.

1. Form labels that aren't associated to form input fields;
2. A logo that doesn't link to the homepage;
3. Not specifying a visited link state;
4. Not indicating an active form field;
5. An image without an alt description;
6. A background image without a background color;
7. Using long boring passages of content;
8. Underlining stuff that isn't a link;
9. Telling people to click here;
10. Using justified text.

Read More

24 Ways Is Back Over 24 Days

If you were paying attention any of the last few years, you may have noticed that the 24 Ways web site is set up to run as an annual advent calendar for web geeks. Each day the site posts a new article dealing with some aspect of the web, ideally giving something useful to everyone who might be reading it.

You can find daily updates right on the home page, or by following them on Twitter (@24ways) or following the RSS feed in your favorite aggregator (full content of each article is in the feed).

Authors you should recognize will be posting throughout the month (Jeff Zeldman, Eric Meyer, John Allsopp, Jeremy Keith, Christian Heilmann). You can also look back at articles from previous years (2005, 2006, 2007, 2008) to see how many of those old tips still hold true and how many might have changed over time and use.

Because I lost a few days at the beginning of this month, I'll use this post instead to highlight the first four days of articles. It changes daily, so be sure to go check it out each day for the rest of the month.

Working With RGBA Colour

Drew McLellan kicks off the2009 season with a look at some of the tools CSS3 provides for applying levels of transparency to color values, enabling you to avoid weighing down a site design with heavy PNG images.

Breaking Out The Edges of the Browser

Remy Sharp takes us by the hand and guides us through our first steps into the web applications side of HTML5 with a look at web storage and offline applications. You'll need a nice modern browser and some Kendal Mint Cake.

Have a Field Day with HTML5 Forms

Inayaili de León introduces some of the new form field types available in HTML5, and then goes on to look at some more advanced CSS3 techniques which can be used to keep your forms looking sharp and ship shape.

What makes a website successful? It might not be what you expect!

Paul Boag challenges us to think about what makes sites successful, which has interesting implications on how resources are spent.

Read More