Keeping Things Simpler with Web Analytics

Ace Frehley, Peter Criss, Paul Stanley, or Gene Simmons probably come to mind when thinking of KISS—what about Kelly Johnson? No? Kelly Johnson was the 20th century aircraft engineer who coined the KISS principle/phrase Keep It Simple Stupid.

The principle suggests that systems perform best when they have simple designs rather than complex ones. Today, it's commonly applied to software design and implementation. So, whether you've heard it several times during your career, or are hearing it for the first time, it's a concept that should help keep you and your team focused and effective.

Web Analytics

One way to keep things simple in your web site/application is by knowing how people use your site—the combination of browsers, operating systems, and devices being used to access your site, and where traffic to your site is coming from. Having this information allows you to understand and focus on what really matters to your users—the things you should be spending money, time and effort on.

The mainstream collection of web analytics has been around since the mid 1990s, so I'm not delivering any earth shattering information. However, there are still many people who contribute to the web that either have never heard of web analytics or have implemented web analytics and aren't benefiting from the collected data.

Google Analytics is the most popular web analytics tool, and it's free. It's what I've used to gather the following 21 week snapshot of data for one my sites that focuses on web accessibility, http://itstiredinhere.com. Although, the data below represents the most basic features many web analytics tools offer, it's data that can really help with prioritization.

What combination of browsers and operating systems do I need to support?

This is the question most developers are scared to ask their product owners with fear the response will be, All of them! This answer is usually either too open-ended or not well-informed.

The operating systems your users are using probably won't be that interesting or surprising—especially, the top 3. I've got usage data for 7 different operating systems and 32 different OS versions. Supporting all of them would be silly since the top 9 versions make up 93% of the usage. Here's a breakdown of the top versions of the top operating systems used by people accessing http://itstiredinhere.com:

OS Versions	Total User %	Weeks 1-7	Weeks 8-14	Weeks 15-21
Lion	31	35	28	12
Mountain Lion	9	8	11	14
Snow Leopard	2.5	3	.7	3.9
Maverics	.75	N/A	N/A	5.8
Windows 7	21	16	22	42
Windows XP	4	6	3.4	.7
Windows 8	2.5	2	3	2
iOS 6.x	12	15	9	1.3
iOS 7.x	.7	N/A	2	4
iOS 5.x	.2	.2	0	0

The overall percentages might seem to describe your users. However, I've broken down the data into 7 week intervals to help find trends, which can sometimes prove to be more valuable than just the overall numbers. Here are some trends in the data that might be worth following:

• Mountain Lion usage increased, while users using Macs with Lion installed decreased. Overall, it's always nice to see outdated software use decline. I expect to see Snow Leopard, Lion and Mountain Lion usage continue to decline with the free release of Mavericks, which can be upgraded from all 3 of the latest OS X versions.
• Windows 7 usage increased, while Windows XP declined. The decrease in Windows XP is especially exciting, because it's an old operating system that supports old versions of Internet Explorer. Support for Windows XP is ending on April 8, 2014, so its demise is inevitable.
• iOS 5 usage has basically fallen off the map, while iOS 7 looks like it could to be taking over. The data for iOS versions is a good example of why looking at the overall data could be misleading—iOS 6 looks like the dominant iOS version, but its usage significantly declined since iOS 7 was released.

While the days of box model CSS hacks are gone, mixed support for HTML 5 and CSS3 cause most of the cross browser support headache today. A top contributor to this problem is the continued use of older versions of browsers, so you can't do things like blindly upgrade to jQuery 2.x if you've got a substantial number of users still using IE 7 or 8. Out of 12 different browsers being used to access my site, here are the top 4:

Browser	Total User %	Weeks 1-7	Weeks 8-14	Weeks 15-21
Firefox	41	46	33	31
Chrome	33	26	41	43
Safari	13	14	12.8	11
IE	6	6.5	5.4	7

While Firefox and Chrome frequently get updates automatically, it wasn't until last year that Microsoft started silently upgrading IE. Along with the fact that major version upgrades are sometimes dependent on the version of Windows, users are still using IE 7 and 8, which are 7 and 4 years old respectively. The same versions of IE can also act differently in different versions of Windows. Here's a breakdown of the versions of IE used to access my site, and the versions of Windows they're running on:

IE Version	8	7	XP	Total User %	Weeks 1-7	Weeks 8-14	Weeks 15-21
10.0	x	x		3.6	3.5	3.4	4.5
8.0		x	x	1.2	1.4	1	.7
9.0		x		.8	.8	.3	2
7.0			x	.7	.9	.7	0

One of the interesting things about the data above is that IE 8 is used more than IE 9. IE 8 was bundled with the release of Windows 7, and unlike IE 9, IE 8 is supported by Windows XP, which after over 10 years is still one of the most popular operating systems today due to its ease of use and lack of bugs. Fortunately, the drop of Windows XP support could mean a huge decline in IE7 and IE8 usage over the next year. So, based on my data, I'll only spot check the earlier versions of IE, especially versions 7 and 8.

We've got to have a mobile experience!

A quality mobile experience has become a necessity for web sites and applications. Unfortunately, many companies don't know where to begin and how to define scope. Whether it's mobile first or not, one popular approach is to implement a responsive design—and it's got to look good on all devices, right? Most likely not.

Web analytics will not only help you figure out which devices to focus on, but will also inform you how important a mobile experience is to your users now and how it might be trending in the future. Almost 20% of the people coming to my site are using a mobile device, so investing in a mobile experience is important, but knowing which devices they're using is important. A total of 13 different devices have have been used to access my site—here's data for the top 3.

Device	Total User %	Weeks 1-7	Weeks 8-14	Weeks 15-21
Apple iPad	9	11	7	3
Apple iPhone	4	5	4	3
Samsung Galaxy S3	3	3	5	1.3

Whether you decide to use a responsive framework or do all the CSS media queries and scripting yourself, you'll soon realize that it's easy to get carried away with trying to make your site look perfect in every device. I'll focus on the top 3 devices devices for now, and continue to keep an eye on my mobile traffic.

Traffic

Knowing from where people are accessing your site is important. 35% of my traffic comes from another site. Here's a breakdown of the top 8 of 31 referring sites:

Referring Site	Referred Traffic %
Twitter	29
Google	27
blog.paciellogroup.com	11
itstiredinhere.blogspot.com	8
webteacher.ws	7
Facebook	7
webaxe.org	5
webaim.org	5

If your site is public, the more ways your site can be accessed online plays a major factor in search engine results prioritization. Additionally, you can use referring traffic data to forecast/prioritize. For example, your site will most likely not be the next Facebook, Google, or Twitter. However, if these are some of your top referrers, it's in your best interest to understand what's trending with these sites, like mobile usage.

Remember, the simpler the better

Web analytics can be free, easy to implement, and can offer a lot more than the data above. As you familiarize yourself with the data, you should begin to realize how powerful it is. If something isn't important to your users, it shouldn't be important to you—it shouldn't be something you spend a whole lot of money, time and effort on. Don't forget to Keep it Simple Stupid.

Tools/Resources

• Learn more about Google Analytics
• VirtualBox is a nice tool for cross-platform testing
• Download Windows/IE VMs for testing
• Use the Dimensions Google App for responsive design testing

HTML 5 Semantics and Web Accessibility: Heading Structure

Has a designer or developer ever tried lecturing you about why you need to be using proper HTML semantics? If so, did your mind start to wander about 30 seconds into the lecture (is it starting to wander right now)? Do you read the HTML specification to help you fall asleep at night? As long as your site looks good and is maintainable, no user is ever going to know or care if your markup is semantically correct.

Actually, some users with disabilities will know if you're not, they depend on it, and probably can't use your site if you're not using clean, valid, and semantic HTML. Having valid semantic markup helps your site avoid many common accessibility issues. However, in some cases the HTML spec offers several different implementation options or is simply unclear. In these cases thinking in terms of accessibility can help provide direction.

HTML Headings as "Defined" by the Specification

The <h1> - <h6> heading tags are among the most useful and important HTML tags regarding semantics. They define the overall structure of the pages in your site. I hesitate to say they're also among the most misused tags, because the HTML 5 spec is a little ambiguous.

Web Accessibility and Headings

WCAG 2.0 has 2 main guidelines specific to headings. In a nutshell, your content needs to be logically organized into sections. These sections need to have headings, and the headings need to represent/identify the content they're associated with.

To further understand the spec and how thinking in terms of web accessibility can help, check out HTML 5 Semantics and Accessibility: Heading Structure.

Bootstrap 3: Migration and Accessibility

Bootstrap 3 was released a few weeks ago. Ever since the version's release candidate, I've been happy with where it's been heading. As opposed to me copying and pasting all the great things in the new release, you can check out the details on their Blog. I'd simply like to highlight a few things I experienced while upgrading http://itstiredinhere.com/.

Painless Migration

Overall, migrating from 2.x to 3 for me was painless. The worst thing about the moves from 2.x to 3RC1 to 3RC2 to 3.0 were updated class names and and subtle changes to the gutter sizes/padding of some major containers. So, depending on how your site utilized the grid before, you could be faced with some required design/implementation changes. There shouldn't be too much complaining regarding the grid changes, though, because it's more flexible by giving you way more control over the responsive nature of your site. You're now able to use x-small, small, medium, and large grid .col-* classes either on their own or combining them for a custom experience.

Also, I found myself less frequently needing to add more and/or overriding media queries. I think that's resulting from a combination between understanding more about how Bootstrap works and the enhancements in the new version.

Lastly, I no longer need to include a separate Bootstrap responsive CSS. Responsiveness is now core to Bootstrap; extra work is only needed if you don't want your site to be responsive.

Accessibility

There are still accessibility issues when it comes to color as I blogged about earlier in Web Accessibility and Color Doesn't Have to Be Grey. Again, Bootstrap uses LESS, and is all about customization to make it your own. It would just be nice to be accessible out of the box.

A new utility class .sr-only has been added for visually hiding content, but not from screen readers. The new method uses clip to hide the content as opposed to positioning it offscreen, which has been proven to not be foolproof. The new class definition looks like this:

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0 0 0 0);
  border: 0;
}

To further understand this method check out the new hidden content section of my accessibility page.

Give it a Try

Read about it, download it, and have fun with it. Bootstrap 3 is awesome!

Web Accessibility and Color Doesn't Have to Be Grey

For an endless number of excuses, dealing with or even understanding the importance of color to web accessibility can easily fall low on the priority list. However, it's a very important aspect of web accessibility and, actually, not that difficult to understand and adhere to.

There are 2 main parts related to color in WCAG 2.0 Guideline 1.4 - Distinguishable - use of color and contrast.

Use of Color

Use of color is the more straightforward of the two. Most trivially, there shouldn't be text that reads something like "Click the green button below to accept changes" or "Red messages are errors, yellow messages are warnings" anywhere on your site if there's nothing other than color that distinguishes the green button from other buttons or the errors from the warnings.

Contrast

Contrast is where things might seem a little grey, but again, it's quite simple to be compliant...especially with all the available tools. The level AA color contrast ratio is 4.5:1 and 3:1 for large text. The level AAA ratios are 7:1 and 4.5:1. I use the WebAIM color contrast checker to determine contrast ratio.

Still confused about contrast ratios? Let's take a look at Twitter Bootstrap. Let me start by saying Twitter Bootstrap is an awesome framework, and I tell everyone how awesome it is. I don't believe it makes any claim about following WCAG guidelines, so in no way shape or form am I about to criticize it. Some of Twitter Bootstrap's default styles have accessibility issues. Here are some of their ratios:

class/sample	color	background	ratio	pass/fail
.muted	#999999	#ffffff	2.8:1	fail
.text-warning	#C09853	#ffffff	2.7:1	fail
.text-success	#468847	#ffffff	4.3:1	fail (only passes large AA)
.btn-success	#ffffff	#51a351	3.1:1	fail (only passes large AA)
.label-warning	#ffffff	#f89406	2.3:1	fail
.alert	#C09853	#FCF8E3	2.5:1	fail
.alert-info	#3a87ad	#d9edf7	3.3:1	fail (only passes large AA)

Use the NoCoffee vision simulator Chrome extension to see why contrast is important by maximizing the contrast loss. The samples in the table above should be, if legible at all, more difficult to read than the rest of the text on the page. Also, notice how the larger text is much easier to read, which is why the guideline have different ratios for large text.

If you wish to download Twitter Bootstrap and like the default styles, but would like to tweak them so they're accessible, you can customize the download with more accessible colors at http://twitter.github.io/bootstrap/customize.html.

Further Explanation

Check out the newly added color section in the It's Tired in Here web accessibility page.

Fine Tuning Your JavaScript with jsFiddle and jsPerf

You're bored, want to learn, interested in a new method or API, and/or just need to settle an argument...use jsFiddle along with jsPerf!

If you've been using these tools for seemingly forever...congrats (you may stop reading). Otherwise, start fiddling; and if you're fiddling around with 2 or more functions that do the same thing use jsPerf to test and compare the performance of each one.

My use case started with the need to compare a few different implementations for traversing up a DOM tree using jQuery. First I set up the HTML body in jsFiddle to resemble the DOM used on our site, then I added the 3 different snippets with alerts to verify they all end up with the same result.

Here's the fiddle

The next thing I did was set up the 3 snippets without the alerts in jsPerf to compare the performance.

Here's the jsPerf page

I'd go into more detail here, but it should be pretty self-explanatory once you go to the pages above.

Cool CSS3 Polaroids from ZURB

Although, it's a fairly old post from ZURB at http://zurb.com/playground/css3-polaroids, I thought this was a cool way to display images in the image section of my web accessibility page.  There's no JS and completely using CSS3's transforms with the additional touch of the cool Google font Permanent Marker.

I did have to tweak their implementation a bit by not using CSS generated content in the :after pseudo-element, since many screen readers have problems reading that.

Also, it doesn't look as nice in IE...even IE 10, because it has problems rendering that font.  Not sure who to blame here; I'll dive deeper into this at a later date.

Wikipedia: Beware of the Bot

In an earlier post I mentioned using Wikipedia as way to get traffic to the It's Tired in Here Web Accessibility section.  I've learned a few things since then about Wikipedia.

It worked! I got a lot of traffic from my link on the Web Accessibility Wikipedia Page page...and fast.  It's typically the first result from searching for web accessibility.  It brought in about 200 unique visitors to my site in under a month.

Unfortunately, it didn't last. One day i noticed my link was gone.  I thought maybe someone didn't like the content.  So, I created a Wikipedia user and added it again.  I received an email indicating I had violated the rules for using the external links section, that the url was flagged, and XLinkBot had deleted it.  

Understandably, Wikipedia doesn't like people promoting things, or in general adding a ton of external links.  However, after looking through the Web Accessibility page I saw that aside from the W3C and government/legal specific links, there wasn't much as far as real examples of issues, how to address the issues, and understanding why the guidelines are important.  Some of links also point to very outdated content, a portion of which that aren't even that accessible.

My take on it is that there's a big mess Wikipedia is trying to prevent from growing.  Consequently, they're making it difficult for better content to be added.  The lesson learned is if you're really trying to drive users to your site, you have to be diverse and creative.  Also, beware of the bot!