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!

Testing Responsiveness

Since my analytics data is telling me I've got a decent amount of users using mobile devices viewing my site, a high priority of mine has been responsive design.  Unfortunately, I don't have access to the variety of devices that would represent that of my users.  So, here's how I've been testing things:

• Google Chrome has a great tool set for mimicking devices and their dimensions.  Simply open the developer tools (right click and select Inspect Element) , and click the little tool/gear button in the bottom right.  In the Overrides section you can select from a number of devices and swap dimensions.

• Matt Kersley has a pretty sweet tool @ http://mattkersley.com/responsive/. It's also available on GitHub.  Basically, you enter a URL and the tool will show you what that page will most likely look like in a variety of devices.  The Responsinator is also worth checking out.

I've made a handful of tweaks to http://itstiredinhere.com, specifically the web accessibility page, and in no time with these tools have decent results.

I'd Like to Make a Shout-out To...

I've been on vacation, so things have been a little slow. In the meantime, I'd like to give a shout-out to:

• Bootstrap
  As mentioned in an earlier post, it's an awesome, easy to use front-end framework that's helped me build a clean and responsive framework.
• Font Awesome
  Font Awesome provides a great suite of font icons that are vectors. They scale great, are styled the same way your fonts are styled using CSS, and can be manipulated a number of ways. I highly recommend checking this out.
• Subtle Patterns
  I've actually never been a huge fan of backgrounds until sometime told me about Subtle Patterns. Now, I try not to overuse them.
• Google
  Google doesn't really need a shout-out. However, I think it's important to remind people of all the free resources Google provides, including:
  • Google Fonts
  • Google Analytics
  • Webmaster Tools

My Site is Online...Now What?

itstiredinhere.com is now online, and I can see all the traffic I created on Google Analytics...pretty cool.  What should I do next?

Getting incoming traffic

There's some low hanging fruit when it comes to getting more traffic.  One of the most important things is getting your site visible either on other sites, or to people that have a large network of people that might be interested in your site.

For starters, I've updated my LinkedIn and Google Plus profiles to link to my site.  Though this doesn't really seem to be targeting a specific audience, most of the people I'm connected with are in my field, and it's easy.

The other thing I did was add a link to my accessibility page on the Wikipedia accessibility page; it's the second item in the results after searching on web accessibility.  I've also submitted my site on a couple tumblr pages dedicated to sites built using Bootstrap.  The are several other places like this I can link to my site from.

Understanding and reacting to incoming traffic
I've now had a couple hundred users from multiple countries view my site, and here's what I've learned:

• Almost all of my users keep their browsers up to date.  As much as it might be cool to say my site not only supports all major browsers, it supports older versions of browsers, as well; my philosophy is, if hardly anyone will benefit from it, why spend time and effort on it.

• Most of my users are using iOS or OS X.  I'm interested in Bootstrap's support for responsiveness.  Since I've got a lot of iOS users, it makes sense to spend some time on this.

• Only one user came in using IE.  At least the user was using IE 9.  They were also from the home of Cable 10 and Stan Mikita's Donuts.

• Traffic was basically split between web accessibility and an app I'm building to determine how awesome you are.  This information makes prioritization easy.  I'll spend about 70% of my time on these 2 pages, and the rest on everything else, including doing things to help me better understand why I'm not getting traffic to other pages.

Getting Started

Things started out pretty simple.  I had a few static HTML pages I put together using Bootstrap.  I chose Bootstrap because it's proven and simple to use when it comes to producing clean web sites.  It also has nice support for responsive design/development, which I haven't completely taken advantage of, but plan to.

I decided to take what I had, and introduced PHP for things like common headers and footers.  PHP isn't necessarily my first choice, but Apache is the cheapest option when it comes to hosting.  It's actually nice for a change to do something other than Java, and after all, building itstiredinhere.com isn't necessarily about the language, its about everything else that's involved in building something, including people using it.  I use GoDaddy for hosting; it's not necessarily the cheapest, but I'm used to it, and so far I've got no complaints.

Now that I've got hosting, some content for my site, a general purpose defined, and a domain name, there are 2 more things I believe are no-brainers before making your site public:

1. Add Google Analytics.  It's free, and it will allow to collect the data you need to determine if people are using your site, and what improvements to focus on if you've got users. 
2. Version control your site with something like GitHub, which is also free.  As little content/code that you might have in the early stages, losing it all, or being unable to reproduce what your site looked like 5 days ago, become difficult to deal with without version control.

Now publish your site.  Don't wait until you've got the exact look, or all the content/features flushed out.  It is important, however, to start to think about how you expect your site to be used, and how you'll use the analytic data to prove your theories.

Here's some additional tools to help you build/maintain your site:

•  If you're using PHP, I recommend downloading an AMP package.  I use MAMP on my Mac; it's free and easy to use.
• Use an IDE that has support for what you're building.  A text editor that highlights HTML isn't worth using, when you can download something like Eclipse for free, which has code assist, and server integration.
• FileZilla is a nice free tool for uploading content.  At least in my case, I find it much easier to use than the tool GoDaddy makes available,

itstiredinhere.com

I've been working on itstiredinhere.com for about 3 weeks now.  It started out as part of a presentation I did on web accessibility.  I started to think it would be a cool idea to create a sandbox to work on things I'm interested in as a developer.  Prior to the last 6 months I've spent a majority of my time developing a business tier and exposing it via web services using Spring.  The past 6 months have been different.  I'm now work on a team that's responsible for basically everything, including the presentation layer, and I love it.  This includes a lot of CSS, HTML, and JavaScript.

I'll be using itstiredinhere.com to do the following:

• build a CI environment
• strengthen my knowledge of CSS3 and HTML5
• practice JavaScript TDD techniques
• constantly work on SEO
• gather analytics
• discover new concepts and integrate with new API

I'll use this blog to document my progress.