Google Analytics, 4 of 4: Summary

Over the past few weeks, I’ve explored how to incorporate Google Analytics into the the planning, execution, and continuous improvement of web projects. While I’m still concerned about the extent to which web traffic analysis and visitor tracking/identification invades user privacy, I feel better informed in my opinions after going through the process of adding analytics to a single site for myself, from technical implementation to analysis to dissemination of findings.

Something that does give me some comfort is better understanding all the ways in which users can “opt-out” of participating in Google Analytics.  While troubleshooting the addition of Google Analytics to my site, I was able to confirm that not only were the browser extensions I use effectively (to my own eyes) blocking the tracking and sending of data to Google Analytics, but that a content inspection policy in place for my home network was also filtering this activity.

While I may not use it for purely personal projects, I can see myself using Google Analytics in the future for my employers and clients due to its ease of use and potential insight it delivers. I’d like to work with it more on a site with heavier traffic, since web analytics seems more appropriate for data on a larger scale (and with less “iffy” sampling methods) than what’s in place for this project. In the future, I would also really like to work on projects where Google Analytics are employed as part of a larger investigation into a website’s usability. I think it would be interesting to compare findings from Google Analytics with what’s learned using other user testing methodologies.

Since a proper Content Experiment wasn’t carried out on my site and I received so few visitors, I wasn’t able to pull out any clear indications of what to do in order to improve the site’s goal conversion rate.  The goal I chose to track progress towards required users to submit a recipe to the website’s recipe repository.  I’ve been thinking about this goal and something I realize about it is that it does require some significant effort and thought from the visitor. I kept this in mind while analyzing the data and it helped to temper my expectations. In cases like this where users are asked to complete a significant task, I think even more effort should go into understanding user motivation, so an appropriate reward can be offered.

Google Analytics, 3 of 4: Content Experiments

My third post is about how I completely misunderstood Google Analytics Content Experiments and learned to still be okay with myself. After very briefly / braindeadly looking over explanations about what Content Experiments are and reading through the vue-analytics documentation, I with way too much certainty assumed my incomplete set of marching orders and set to marching. I then wily-nily started creating new elements and alternate pages, adjusting my GA event trackers, all while imagining all the sweet insights I was about to rake in based on the experiment I’d set up for visitors to unwittingly walk into. But I did it all wrong. (It’s okay, I forgive myself.)

What even are “Content Experiments”?

Content Experiments are similar to A/B testing. A/B testing, also known as split testing or bucket testing, is a form of statistical hypothesis testing comparing two versions of a single variable. Content Experiments use a similar model, A/B/N. In this model, you aren’t dealing with just two versions of the same page, you are testing up to 10 full versions of a page, each with a separate URL.

The Google Analytics console offers a wizard of sorts to set up your page variants and generate code which must be added to your website in order to enforce the direction of traffic to your variant pages based on your specific configuration. Heh, this may sound simple enough but I learned it all too late.

Screenshot of the Content Experiments wizard

Screenshot of the Content Experiments wizard

Experiment Objective

This tale starts off well. I think my planning steps were pretty solid even if my implementation was flawed. Good intentions and all, fwiw. Since my overall objective for the site is to get users to actually contribute a recipe to the repository, the Content Experiment objective I planned was to get users to click on a “Contribute” button, fill a form, and submit it.

The variable I decided to isolate was the location and color of the “contribute” button. Once able to divide traffic into visitors who accessed the submission form via one button or the other, I figured I’d have (what I now realize are extremely uninteresting and not useful ) metrics on whether blue or coral button pushers are more likely to submit a recipe.

Screenshot of Karl Sayagin home page showing different buttons

What color button pusher are you?

I set up my event trackers and goals, thinking that what I was orchestrating was a Content Experiment™.

I did whaaat?!

You may by now note the mistake I made. My set up involved two different components on a single page, both of which take you to the same submission form. Er, actually, each button takes you to a different submission page which looks exactly like the other (how incredibly boring, right?).

It would have been more appropriate for me to create two different submission forms, add them as variants within the google analytics console, and add the necessary code so that visitors would be delivered to one or the other at random.  Something I could try would be to give submitters the option of crediting themselves when they add a recipe, since some people may prefer not being anonymous.

The cold hard truth

By the time I had realized my mistake, it was too late to set Content Experiments up properly for the purposes of this assignment. Despite not being properly set up as a true Content Experiment, since I’d added event trackers to the two different “contribute” buttons linking to different pages, I was still able to gain some insight into the performance of these two different buttons.  Based on this test, for each button there were two users who clicked on them and ultimately submitted a recipe (two-to-two).

Screenshot of GA Dashboard showing success of different contribute buttons

The button in the top-right corresponds to ‘contribute-1’ and the main button below the quote corresponds to ‘contribute-2’

 

Google Analytics, 2 of 4: Goals and Events

Defining my goal

Something that drove creating the Carl Sagan, “Karl Sayagain”, tribute site was a desire to collect recipes in the same way one might collect stories or jokes, meaning from other people, with prompting. For a previous version of this project, I requested recipes from people and added them all manually. This batch of recipes serves as the “starter” for the current project, which finally includes a form that can accept contributions and make them automatically available to display.

Setting this goal up on my site

I defined “submit a recipe” as a goal in Google Analytics and since I also hope that visitors refresh the page to see recipes others have submitted (and potentially their own), I defined another goal of “refreshing the page”.

The vue-analytics plugin makes it breezy to install google tracking for general tracking but a little bit more work is required for event tracking. Fortunately, the documentation covers how to do this pretty well and I didn’t have much trouble getting this set up.

There are four parameters which can be associated with event “hits”: eventCategory, eventAction, eventLabel, and eventValue. For the purposes of tracking events leading up to the goal of “submit recipe” I used just the first two parameters, eventCategory and eventAction.

I also added events to the two “Contribute” buttons on the home page. For this event I used the third parameter, eventLabel, to distinguish traffic to one or the other in the collected data. As always, naming things is hard and were I to go back I’m sure I would take a more considered approach to this task.

Defining this goal in the Google Analytics console

Back in Google Analytics, I created four goals with the type “event”:

1. Get new recipe (refresh page)
2. Submit recipe
3 Use main button to get to contribute form
4. Use button in nav bar to get to contribute form

How the Funnel worked out

According to Google Analytics, my conversion rate for the goal of “submit recipe” is 22.58%! This isn’t too bad, I think, but it is a little worse for my knowing which of those numbers are my own (I’ve learned my lesson here). A few (well, 3) people completed the goal of submitting the recipe, but since the path to the contribute forms is just one click away, the “funnel” isn’t especially exciting.

Confession: Only three of those goal completions are legit

Google Analytics, 1 of 4: Installation and Initial Findings

This is the first in a series of posts about my experiences using Google Analytics to track traffic. The website I added tracking code to is a small Vue.js web application built as a tribute to Carl Sagan.

Installation

On recommendation, I used the vue-analytics library to add Google Analytics tracking to my site. The plugin automatically can automatically load the Google Analytic script and when passed your VueRouter instance, can even perform page tracking without having to set this up more manually.
vue analytics configuration

Main.js: Code to import the vue-analytics plugin and load/configure Google Analytics tracking scripts

After acquiring and adding a Google Analytics ID to the the vue-analytics configuration for my site, I needed to ensure it was properly installed and sending data to Google. A browser extension I use called Ghostery gave me my first confirmation that Google Analytics was working. Vue-analytics also has a great debug mode which earned its salt during installation and later troubleshooting.

Expectations about Demographics

After adding Google Analytics tracking to my website, my plan was to share a link to my site with my family and friends, as well as with the greater Seattle University Web Development Certificate Slack channel. I expected visitors to primarily visit from in from Washington, where I currently live, and North Carolina, where I grew up. I also expected a wide age range from early twenties to late-sixties and for most of my visitors to be female.

Google Analytics Console

Google Analytics is a freemium web service offered by Google which used to track much of the traffic on the web (wasn’t able to locate any official figures but estimates by market researchers put it way up there). The capabilities it offers are extensive and I’ve barely scratched the surface. And it’s all for “free”!
The journey of getting up and running with Google Analytics involves navigating the creation of dashboards and views, as well as picking up terminology and concepts standard across the web analytics industry along some specific to Google’s implementation of their services. On initial property creation, a default, unfiltered view with “all web site data” and a number of dashboards are available by default, which can give you a head start analyzing your data even without further customization.

Initial Findings

The collection of a few days worth of data confirmed my hypothesis that the majority of traffic to my site would come from Washington and North Carolina. While I was surprised that all of the visitors to my site were male, I also don’t believe this to be true.
100% of site visitors were classified as male

100% of site visitors were classified as male

 That’s it for now — more to come!

Accessibility Practicum: Captioning an interview with a former coal miner

My good deed of this week was to download a video from Internet Archive and upload it to YouTube with some corrected close captioning.

The video I chose is of an interview with a man from Hazard, Kentucky about what life was like in the early 1900’s and what it’s like for him today. The man has a pronounced regional accent and I was curious about how well YouTube would be able to automatically generate captions for it.

I appreciate and use closed-captioning, especially as subtitles when watching foreign language movies or when my very noisy dishwasher is running. However, I was surprised when trying to actually create them how little I could remember about their common conventions.

I had a lot of questions

I wasn’t sure about punctuation, whether I could leave it off when transcribing more conversational speech.

I wasn’t sure if I needed to “set the scene”, accounting for any visible or audible change, with something like stage directions.

I didn’t know if speakers’ names should be used when multiple people are speaking.

Recommendations to affix the speaker’s name to transcribed text felt awkward when I tried them out.

I didn’t know where to draw the line when making corrections. While I did end up making some, I was concerned about removing mannerisms of speech which typify regional Appalachian dialects.

While researching these questions, I couldn’t find easy answers

The captioning process

The automatic captions provided by YouTube are better than nothing and it took less than an hour for the closed-captioning file to be created. The accent of the primary speaker in the video I uploaded was fairly heavy but the speech-to-text generation required less editing than I’d anticipated.

The closed-captioning editor embedded into YouTube was intuitive to me as someone who had never used it while still feeling like it probably rewards more advanced users.  Despite this, I found the editing process pretty tedious and it was difficult for me to stay consistent. Getting all super focused so you can listen to the same clip over and over and agonize over having a caption appear at the right millisecond can be fun but there’s not getting around that creating captioning is labor-intensive, which of course translates into it being expensive.

Accessibility Evaluation: Arts & Letters Daily

I conducted an accessibility evaluation on the human-curated, arts and humanities news aggregator, Arts & Letters Daily. To conduct this evaluation, I selectively used the “Web Accessibility Checklist” from the A11Y Project. This checklist incorporates principles and guidelines from WCAG 2.0, WAI-ARIA, and Section 508. These are my notes.

Header and Footer

The header does not explicitly include an ARIA banner landmark but since it’s in an HTML5 document and the header is a child element only of the body, this role is implicit.

There’s a language tag! Good.

This site does not use “main” or “articles” landmark roles to wrap the focal content of of the site and represent independent items of content. Wrapping the three columns with the main tag and assigning each article blurb an article role would likely contribute to this site’s accessibility.

A div element is used to contain the footer content. A better option would have been to either use an actual <footer> element, which in an HTML5 document can be mapped an ARIA landmark role of “contentinfo” or explicitly assign a landmark role of “contentinfo” to the div.

This site is all text save for a logo in the header, without any ALT text. That should be there. Who’s that supposed to be in the logo anyway?!

Site Logo

Site Logo

 

Navigation

An ARIA role landmark is not provided for the navigation menu. A semantic HTML5 <nav> element could be used in place of <div id=”leftnav”> in order to make this role implicit or a landmark role of navigation could have been assigned .

Main Content

Semantic headings are used but there are some issues. For one, heading levels were chosen in order to produce desired font size rather than to represent hierarchically organized information. Also, two are skipped, h1 and h2.

Curiously, no headings are used to mark the blurbs of content which are what the site’s all about really. This negatively impacts the experience of tabbing through in the normal display, since the only thing you can tab to and from are the “Read more” links which close each blurb.

Arts and Letters Daily, normal display

Normal Display

Blurbs on this site are arranged into three categories, yet they are not wrapped in HTML5 <sections>.  This is a lost opportunity to improve accessibility.

An alternate way of displaying content is provided. With this view, content is listed under dates with each blurb falling under a heading with the category. This arrangement of content seems like it would be easier for assistive tech to interpret than the table-view.

An alternate way of displaying content

Alternate View

Links

Focus is a CSS pseudo class used to apply styling to an element currently targeted or activated by an input device. Many elements have focus by default but this state can also be added to any HTML5 element. In addition to being able to uniquely style the targeted element, elements with focus can be tabbed through, which greatly contributes to accessibility.

So, one of the elements that get focus by default are anchor tags, which explains why the “more” links are what are available to tabbing in the normal, table display. These links are not underlined but are otherwise distinguishable as links.  But not to give them too much credit, there really should be a way to get focus at the beginning of each of these blurbs, not just the end.

The “More” links are semantically unclear and text should be provided to give greater indication of where they go, especially since they all point to external locations.

JavaScript

How a site implements JavaScript is also an accessibility concern. This site uses some inline JavaScript which is discouraged but I found that when I completely disabled JavaScript, no functionality was lost.

Color Contrast

The contrast ratio for background and text color was 6.09, a score of AA for normal text and AAA for large or bold text.

aldaily.com has a contrast ratio score of 6.09

Contrast Ratio Score

Color blindness

I viewed the site using filters simulating different types of colorblindness. There isn’t a lot of meaningful use of color on this site and the palette is very spare, so there isn’t any problematic use of color.

 

 

 

Usability Test: Emerald Downs Racetrack and Casino (Mobile Version)

Previously, I conducted usability testing on the Emerald Downs website as accessed using a desktop browser. This week, I performed the same usability test but using smaller form factor devices, tablets and smartphones.

Demographics

For my mobile test I enlisted the help of three user testers. Two tests were conducted in person and one remotely.

Age, gender, educational attainment, and parent status of user testers:

  • 60-65 yo female, High School, with kids, low vision, uses a wheelchair for mobility
  • 25-30 yo female, Masters degree, with kids
  • 35-40 yo male, Bachelors degree, no kids

Devices and Applications

I used Mobizen for audio and screencapturing on my own mobile device, a Motorola Droid Turbo 2, to administer the in person tests. For the remote test, I spoke with the user on the phone while they accessed the site on an Amazon Fire device. As there was no screencapture and I was unable to observe their interactions with the site, what data could be collected was limited. I enlisted this person anyway because they fall into a demographic not represented by anyone else I had recruited so far.


Usability Test – Preliminary Portion

After starting the session by introducing the usability test and asking some preliminary questions, I gave user testers a couple of minutes to orient themselves on the homepage of the site (asking they not click on anything). I then requested they put the device down and describe their general impressions of the site, what it’s for, and what types of events are held at Emerald Downs.

Usability Test – Task Portion

For this portion of the test, I asked users to complete three tasks:

  1. Locate where events are displayed on the site and describe what information is available
  2. Determine whether Emerald Downs is a good place to bring kids. Are kid-specific events held?
  3. Imagine you have a free weekend coming up and would like to see some live horse racing. Locate this weekend on the calendar, find out what events were being held that day, and figure out at what time the gates open.

Usability Testing Script (Mobile Version): mobile-testing-script


Observations – Overall impressions of the site

All users commented on the site being visually appealing, with one user calling it “fancy” and another “colorful and interesting — the people in the photos look like they are having a good time”. Two users mentioned that the design looked “modern”. All were able to identify the site as belonging to the Emerald Downs Racetrack but only one volunteered “Casino” in their description of who they thought the site belonged to. When asked to list what kinds of events are held at Emerald Downs, all users included horseracing and live music.

One user complained about insufficient contrast between background and text color on the site and hard to read fonts. They cited the poor contrast as being why they misread “Responsible Wagering” in the menu as “Responsible Watching” and joked they thought this meant you weren’t allowed to heckle the horses or blow raspberries at them.

White text on grey background

White text on grey background

Observations – Task One

There are two primary links from the home page where users can access the event calendar, one in the main menu bar and another in a sectional block midway down the page. A user who spent more time exploring this main menu bar when initially surveying the site accessed the calendar through a link there under “Visit” while the other two users selected the turquoise block (see image below — what do you think about the contrast?).

White text on turquoise background

White text on turquoise background

Two users, including the one who accessed the calendar through the menu were surprised or thrown off by arriving on a view listing events rather than one displaying a calendar grid layout. All users selected the “Previous Events” and “Next Events” although only one user verbalized having understood that these links actually display the previous and next weeks worth of events.

page turners

Next events? Next week’s events?

I observed two users show signs of frustration at having to use these links to view more events instead of being able to scroll to see more. One user looked for but was unable to find a link to access the desktop version of the site.

All users noted the legend at the top of the calendar view and two users voluntarily “sorted” by these options. One user who did so said that it “doesn’t do anything”. (These links do actually work, but the feature isn’t accurately named — they filter results, not sort them.)

sort vs filter

Sort vs. Filter

Observations – Task Two

Two of my user testers have children but only one has kids of an age where they currently face having to take them out for fun now and again. All users scrolled through the events and were able to call out ones they thought would be kid friendly. One user mentioned they thought daytime would be best for kids, since the site hosts gambling and has a nightlife scene with live music and dancing.

yeehaw family fun

Family fun at Emerald Downs

One user located the clubhouse menu under “Dining Options” in order to find out what food was available. They located the menu but noticed pricing wasn’t provided, which they thought should be.

Quick Pix Cafe - no prices?

Quick Pix Cafe – no prices?

Observations – Task Three

All users were able to find an upcoming weekend to set their imaginary trip but two seemed or mentioned being bothered to have to click through each successive week to reach the weekend they wanted.

When attempting to locate an upcoming Saturday or Sunday, only one user complained the weekday wasn’t provided alongside the date. This user (who I ran through the test with remotely) actually had someone near them pull up a calendar on another device in order to collate weekday information. I suspect the other users may have offered this complaint as well had I asked them specifically to pick a Saturday or Sunday.

Only a weeks worth of events are displayed at a time and users have to click through each week successively in order to arrive on the one that they want. One user who seemed to enjoy clicking and scrolling through each week to see what was happening didn’t mention being frustrated by this but the others said that they thought there should be a way to go directly to a date or that it should be faster to get to a given date.


Recommendations

Based on data collected from conducting this usability test with three users, I’ve identified the following pain points and list them along with recommendations on how to overcome them (these correspond to observations in bold from users):

Contrast
* Adjust text and background color where needed to make text easier to make out by those with low vision
Fonts
* Adjust fonts where needed to those easier to make out by those with low vision
Event display options
* Provide the option of viewing events on a grid displaying monthly calendar
“Previous/next page” labels in event listing
* Change labels from “Previous Events”/”Next Events” to “Previous Week”/”Next Week”
Link to desktop version
* Add one
Sort vs. filter using event legend
* Change label from sort to filter
Menu Prices
* Include them
Calendar navigation
* Provide an alternate way for users to access a given date, by either clicking on a calendar grid or using a dropdown
Information on date cards
* Provide the weekday next to month and numeric day


Additional comments about accessibility information on the site

One of my users requires the use of a wheelchair for mobility and has low vision. They estimated spending 30 hours using the internet each week, exclusively through a touchscreen tablet. I spent extra time asking questions of this user outside of the given tasks in order to find out what they thought about the site.

In addition to the standardized tasks, I had them explore the site for information about wheelchair access. The first thing they did was go to a page set up for “Parking” and found a section there specifically for “Patrons with Disabilities”. From there they went to the “Admission” page where ticket information can be found, finding there another more expansive section with information for those with disabilities.

Main menu

Main menu

Aside: Prior to running to asking the user to complete these extra tasks, I made myself do them. While I was able to (eventually), it took me considerably longer and included more “dead ends”. I believe it’s very possible web users with disabilities develop highly-tuned information seeking patterns and skills which allow them to navigate more readily to this pertinent type of information (know exactly where websites “hide” this information). The more I think about how this particular user responded to the task, the more logical the choice to start at “Parking” and then head to “Admission” seems. Perhaps they were imagining the visit and stepping through it chronologically — first you arrive in the parking lot, then you show/buy your ticket…

When asked whether they thought Emerald Downs would be an easy or stressful place for someone with limited mobility to visit, they said ” it seems like they’ve done all they can to make it as easy possible”.

Usability Test: Emerald Downs Racetrack and Casino

Site URL: https://emeralddowns.com/

Purpose

Horse racing facilities rely on the attendance of racing enthusiasts as well as interested members of the general public to keep going.

One way Emerald Downs can connect with potential visitors to their physical site is through publishing a calendar of races and other events on their website.

I conducted user testing to find out how well Emerald Downs is doing this.

Methods

I enlisted the help of three user testers. Two tests were conducted in person and one was conducted remotely. All sessions were recorded using Kazam, screen capturing software which also records audio.

Due to time constraints, usability testing focused only on how well the website implemented calendars and event listings to support the goals of website visitors in planning a visit to the Emerald Downs.

The first portion of the test asked the user to visually explore the site’s homepage using their mouse without clicking on any links. The remainder of the test had users complete three tasks:

  1. Locate the events calendar and take a look at what’s happening on a few different days. Describe the types of events you see.
  2. Determine whether Emerald Downs is a good place to bring kids. Are there any kid-specific events coming up?
  3. Pick a weekend day in the events calendar when you would like to view some horse racing. Find out what races are being run that day and when the gates open.

Following the completion of tasks, users were given an opportunity to share impressions and remarks about the site.

Demographic Summary

Users are not horse racing enthusiasts but based on response to opening questions are interested in attending live horse racing events. One person has attended a couple of horse races in the past, although not at this location. One user has an infant and the other two have no children. All users reported making heavy use of the internet when planning activities and events to enjoy with family and friends.

Usability Testing Results

The first portion of testing asked users to explore the homepage without clicking any links. All users were able to quickly determine the purpose of the website, although only two verbally recognized the dual-role of this facility as a racetrack and casino. One user focused almost exclusively on the top menu bar when asked to figure out what kind of information was hosted on the site. Unlike the other two testers, this user verbalized having noticed sections of the site set aside for specific rather than general audiences like “Horsemen” and the press.

The main navigation bar includes options for specific audiences (horsemen, the press, etc.)

The other two users set about the task of determining the contents of the site more by scrolling the length of the website from top to bottom. One of these users, along with the user who relied more on the main menu bar, mentioned the presence of social media icons and aggregated social media data.

Task One

The purpose of the first task was to determine how users would access the calendar, given multiple links to choose from. Two users selected the calendar option from the main menu bar, while the third user opened a link featured in a calendar graphic. The link in the main menu bar directs users to a calendar view of events while the link selected by the third user directs them to a listing of events. This user complained about arriving on a page with a calendar view. Despite there not being an clear option to “toggle” between a list and calendar view, this user selected “Calendar” in a page menu which directed them to a page displaying the calendar view.

Task Two

The second task builds on the first, asking users to find out whether the racetrack is kid-friendly. Users were asked to determine the answer to this using the calendar and any other portions of the site. Here is where I noticed the most variability in how users attempted the tasks, and where I personally feel my expectations were the most challenged by what actually unfolded.

The two users without children carried out this task fairly quickly and didn’t seem as invested in the task as my one user with an infant, which I wasn’t too surprised by. This user, who when asked what kind of information they look for online before attending an event or visiting a location provided a much longer list than the other two users, was very quick to go directly to the “Admissions” page, where there is a statement about the racetrack being “kid-friendly”. This is not where I would have gone first. The other two users scrolled and clicked the calendar. One was contented by the presence of ostrich and zebra racing events to know that the track is kid-friendly, while for the last user speculated that maybe the track wasn’t very kid-friendly, since it’s also a casino and the site hosts a lot of evening entertainment targeting adults.

Task Three

The final task was very open-ended, and asked users to pretend to plan a weekend day sometime in the next few months to visit the track for some live horse racing. They were asked to locate this date on the calendar, determine which races were being run, and find out when the gates open. Users were then asked to look for any other information they would normally look for before visiting a place for the first time.

All users were able to quickly locate a “live race” day using the calendar’s legend. At this stage of testing, two users commented on not being sure what was meant by “simulcasting”. One user speculate it meant “virtual” or “simulated” racing.

“What do you mean by, ‘simulcast’?

When one user opened the page for a particular date, they were confused to not be able to find any information about particular races being run that day but were able to find the time when gates would open. The other users happened to open pages on days when “stake races” were ran which include the race name as well as the gate time. Figuring out the gate time requires taking a given time and calculating a time thirty minutes prior. None of the users expressed any frustration about this.

Users did not seem to mind calculating the gate time

Two users, including the one with an infant, went immediately to the “Parking” page when asked to look for additional information to support planning for their trip. The user without a child who sought out the parking page also located the “Dining Options” page under “Visit” in the main menu. They did not spend much time on this page, which doesn’t display menu information in a traditional way.

User Testing Script (PDF)

Usability Analysis: Official Website of the American Association of Poison Control Centers (AAPCC)

I conducted a usability analysis of the official website of the American Association of Poison Control Centers, a voluntary health organization founded in 1958 to represent the nation’s poison control centers, of which there are 55 at present. The website is a top ranking result in multiple search engines based on keyword searches for “poison control center” and the like.

Analysis of the site was undertaken with an audience of the general public in mind. The primary landing page is the focus of the analysis, with some venturing off onto other pages.

 


Is the purpose of the site self-evident?

Does the AAPCC give the user some indication of what to expect on this website?  “Taglines” are a common way for websites to offer a short description of their purpose and mission. Due to print and web conventions, users know to look for these near persistent branding elements, often at the top of the page.

This is somewhat accomplished here. Emergency. Information. Prevention. appears directly below the main title.

The frontpage of the AAPCC official website

While little is done visually to make this text distinctive, this single line of text does pop out more for being separated from the wall of text below, chunked in such a way as to be none too inviting. This same tagline appears in the footer, where more has been done to help it stand out.

The user can also guess at the purpose of the site by surveying the top-level menu items in the primary navigation bar.

The site’s main navigation bar

On the landing page, this navigation bar does not appear until the user has scrolled vertically the length of their screen, from top to bottom. The menu options are:

  • Alerts
  • Prevention
  • National Poison Data System
  • Our Work

Additionally, a brand logo appears in the left corner of the navigation bar with a number for the AAPCC hotline. “Alerts” and “Prevention” echo the site’s tagline, letting the user know that site serves as repository containing information on poison control topics, including on how to prevent poison-related  incidents. The hotline number at the top left gives immediate access to users who need to call someone in the event of an emergency. “Our work” is slightly less obvious from the wording, although users who guess this location contains “About Us” type information would be correct.

Suggestions:
  • Make Emergency. Information. Prevention. more prominent in the header. This is too good a tagline to be wasted like it is here.
  • Drop the use of “Our Work” from the main menu and use the more common “About” or “About Us”.

 


Is it easy for users to quickly locate what they came for?

Who are the visitors to AAPCC, what are they looking for, and can they find it right away? I honestly don’t know the answer to this but, being that there’s a good chance some users in time-sensitive, emergency situations might seek information on this site, some attention should be given to making sure they specifically are able to find what they need.

These users may want to use the website as a stepping off point to another information resource, perhaps a number to dial a human being or the location of a physical address. As such, it’s important this information be displayed prominently for them.

The logo in the left hand corner of the navigation panel has a number for the hotline as does the footer at the bottom of the page.

The site’s footer

Unfortunately, if the user wanted to select this number in order to copy or dial it, they’d discover it’s an image. This hotline number, as well as the URL for PoisonHelp.org, appear in numerous places on the page but little is done to make them stand out visually; they aren’t even hyperlinked. So, if a user came to this site seeking this critical information, they are at less of advantage due to how these objects are presented on the site.

To its credit, their customized 404 page is great – it prominently displays the hotline phone number for people to call.

The site’s 404 page

Suggestions:
  • The large header is fine but I think hiding the main menu from users until they scroll down the page may be disorienting for some (and also hides the hotline number prominent in the logo)
  • The wall of text on the header image should be edited for brevity and reformatted to be more easily scanned
  • URLs and phone numbers should be hyperlinked
  • Buried in the wall of text is Text “POISON” TO 797979 to save the poison control contact information in your smartphone. This is really neat and not displaying this in a way that catches peoples’ eyes seems like a lost opportunity to engage visitors.

 


Do navigational elements support search and “follow your nose” browsing?

Do the navigational elements on AAPCC’s site function as a useful tool for those exploring the site? For users who may want to call someone, the website does a good job of displaying the hotline number in multiple places, with room for improvements, as previously noted.

For those actually wanting to locate information within the site, they are provided up-front with a search bar (in the footer; uses conventional styling) and a few main menu options already discussed.

I didn’t spend much time assessing the search, since it was pretty disappointing right off the bat. I tried to locate a list of the poison control centers and couldn’t pull up that page in my results. What does come up in searches are a lot press releases and pages which I hadn’t noticed were accessible through any other obvious links on the website. This seems odd, and I’m not sure whether leaving these pages in the search index was intentional or not.

One of the primary reasons I can think of for why someone might visit this site would be to locate the closest poison control center. One’s hardpressed to find this information here though, located all the way at the bottom of the homepage. User is presented with a dropdown to select what state they would like to search in.

Search option located at bottom of page

Once the search is ran, the user is directed to a new page with a table listing control centers for the state. The table is really buggy – a search for centers in Arizona produced a list including one in Illinois! Also, when the triangle “sort” features are selected, the user is directed to a “member log-in” page. This kind of behavior can be frustrating for users to encounter.

Buggy listing of centers

Suggestions:
  • Fix the buggy table
  • Create a main menu option for users to locate their closest poison control center
  • Develop a widget where people can type in their zipcode and return nearest center
  • Display locations on an interactive map

 


Does thought into usability seem to drop off the deeper into the site you go?

Were pages further down given the same attention and thought as the AAPCC’s homepage? I didn’t have enough time to analyze the entire site for this characteristic. It really feels like the most attention was paid to the front-page of the site. Going off the “Prevention” and “Alerts” pages, very much carries over visually, which provides continuity between pages for the users. The headers and footers are the same (although fixed rather than “sticky” past the homepage) and font and colors are the same. There’s persistent navigation elements that can use to get back to where they started from or go elsewhere. So, I think some attention was paid here.

The articles on the “Prevention” and “Alerts” page would have benefited from being displayed in a way optimized for the nature of their content type. Instead, they are presented in the same way, alphabetically organized in a grid (and with some styling issues).

The Alerts page

The Prevention page

This tactic for displaying information seems lacking. The menu board design of these pages doesn’t entice me to explore further and definitely doesn’t make me feel like I’ve been “alerted” or more informed about prevention.

Suggestions:
  • Organize alert and prevention articles to allow users to quickly determine which ones are relevant to them (there are sidebars on other pages – they could maybe be employed here?)
  • Add publication dates to the articles to help users determine their currency
  • Conduct a full content inventory of available articles broken up between “Alerts” and “Prevention” and reassign to more appropriate categories — alerts / prevention don’t actually fit the content they bucket (the Partners page appears under Prevention; Current Annual Report Highlights appears under Alerts)
  • Add tags to articles to ease discoverability
  • Fix little styling issues

Usability Analysis: Halfbakery.com

Halfbakery.com is a communal database on the web for sharing and commenting on so-called half-baked ideas. The site’s appearance hasn’t changed in the almost two decades it’s been up, which seems audacious considering how quickly web design trends change. Bakers, which is what contributors to the site are called, would likely be against any changes to the familiar aesthetic of the site. Somehow, this strangely compels my desire to analyze the site even more, maybe because it feels like fair game!

I evaluated the site for how well the site’s page layout, organization, and main menu contribute to it’s user experience for new and returning users.

Criterion

Page layout and organization

  1. How does this site perform against the school cafeteria segmentation rule?
  2. Are colors, font-sizes, headings, etc. used to effectively group different sections of the page?
  3. How well does the front page function as an entry to the site?

Menu

  1. Is it easy for the user to carry out various expected tasks using the available menus?
  2. How do the menus approach the job of representing all the different locations in the site?

Findings

Page layout and organization

Based on the school cafeteria tray segmentation rule, which I just made up, this site doesn’t perform so well. Determining how content is broken up on the page relies on the user’s ability to make out the eddies of flowing text, all sized the same.
This site does have plenty of whitespace which for being all text save one croissant in the top left corner of all pages (and limited illustration elsewhere), is to its favor. While whitespace is used to visually break up logical sections, the kind of “nesting” which Krug notes as saving information consumers from strain since the early print days is not as effectively used on this site as it could be. As you can see in the screencapture below, there are “gutters” to mark sections but it requires some effort to make the sections out. They don’t pop out at you.
screenshot of the bagel music overview page on halfbakery.com

Screenshot taken April 8th, 2018

The ideas on this site are organized by category. The front page assumes a utilitarian pose in presenting the user with the top-level categories along with the two most recent idea entries posted to that category. Ideas posted that week are in bold but a key isn’t provided to explain what the symbols next to the ideas mean. But, this site has the luxury of serving mostly return visitors, so this seems okay.
Louise Nevelson or Michal Johansson can get away with using monotonous colors to treat space, but for us mere mortals it’s probably better to use contrasting colors in order to create divisions. The divisions can be flexible; they don’t have to restrict us. They just need to keep our food separated.

Menu

Menu options are grouped into three comma separated lists: idea, meta, and account. This arrangement is well thought out and considering how few menu links there are, I think presenting them this way is acceptable. Considering the retro status of this site and it’s design, underlining the links to mark them as hyperlinks also gets clearance. Again, this site caters mostly to return users. I think it has earned the right to put new visitors through a little bit of pain. That said, the proof of this site having been around as long as it has is in the incredibly rich meta pages, which lay answer to many questions a new visitor might have about the site.