Looking deeper than the numbers in analytics

Today I spent some time putting together a few Google Analytics reports for someone who was thinking about a site redesign.  The purpose of putting these reports together was to inform them about how the site was performing and what the visitors are taking in from the site TODAY.

In this case I think some of the findings will act as a surprise to the client and while I won't share those exact findings I will share what reports I ran and the reason why I think those reports are important.  However, before I do that it's important to disclaimer that in looking at these numbers it's not the actual numbers themselves that are important, but rather what the numbers tell us.  If you're trying to compare number pre-redesign to number port-redesign then sometimes you'll be comparing apples and oranges, instead look at the outcomes and trends of those numbers. Is your goal being achieved, and by goal is the information you feel is important reaching your customer efficiently?

Here are the analytic reports I ran and what they represent.  I suggest running them at least for a 9 month period, one year is even better.

• All Pages (Behavior – Overview – full report/top 100): this report shows you the most popular pages by page hit and unique session.  This indicates the top pages within the site of interest to the public regardless of intent by administration, meaning this is where people are finding value and usable information TODAY. If these items don’t line up to the clients initiatives and focus points then there is work to do on surfacing those items and bringing further awareness to them. Maybe those items are buried in deep links, maybe they aren’t ready content but rather in pdf or downloads, maybe they are deep slides in a deck that no one sits through. Whatever the case evaluate the worth of the content and find a way to bring focus to it WITHOUT hiding the information that user are accessing today.
• Landing Pages (Behavior – Site Content – Landing Pages): this report shows where people are first entering the site, this accounts for direct links from OTHER sites and bookmarks people have made.  This can show areas of the site which SHOULD have emphasis put on their physical design and their content because these are the first “touch-points” for people into the site.  Remember not everyone comes in through the front-door, sometimes they come in through the side door because it’s closer to the kitchen and their hungry.
• Technology Overview (Audience – Mobile – Overview): this report shows you the types of devices hitting your site at a high level.  For the majority of sites you don’t really care about the ration of iphone to android users, but you do care if the majority are cell phone or desktop because it matters to how you structure and how much text you place on a page.  Mobile viewers don’t want to scroll forever, they want clear navigation and less fluff than their desktop counterparts.  Mobile visitors want their information more raw and easily searchable, remember their on the move and moving fast, they won’t wait for rotators, scrolling text, or bother to look for information buried within documents or PDF’s it has to be right at the surface.
• New vs Returning (Audience – Behavior – New vs Returning): this report shows you the number of NEW people coming to your site, these people haven’t seen your site before and so are new to it’s navigation, content and layout.  If your site is too complex then they are likely to move on, if it’s not intuitive then their likely to miss interacting with an element or scroll right over it. Whereas returning customers may be overly familiar with your site and need to be shown or pointed out when/where information has changed. Often times they are accustomed to certain paths to data so if something changes you need to make allowances for these learned behaviors and accommodate for them so the user isn’t frustrated and lost when something does change.

As I mentioned these might not be the only things you look at and there's lots of more data you can go through, but if all you have is basic reporting then these might act as a starting point to direct your design work when looking at a potential redesign effort.

I'm always curious what others think so please comment what you look for and how you interpret analytics when evaluating a site.

Thoughts on methodology

Below are a list of steps and pieces of advice I can give anyone going through a web redesign or creation project.  Does it mean that you'll be successful 100% of the time, NO.  However, if you fail to follow them and just trudge through a project willy-nilly I can guarantee failure 100% of the time. This list is something that I'm striving to implement and abide by myself, so please feel free to comment and add your two cents on what should and shouldn't be done during a project.

Step 1: Ask 7 Questions

Recently I developed 7 simple questions to start any web redesign or creation project with. They are very high level and force the owner to think about their project and what they hope to accomplish with it. They also re-enforce that only through defined measurable goals can you evaluate success.  I'll list them below, but know that it's designed to be an interview style questionnaire so not a "fire this off and get a response" type document.

1. Are you trying to re-brand/re-engineer an existing site? What is it’s current URL and technology, do you currently utilize any type of content management system?
   If you do not have an existing website for this project then you may skip questions #2 & #3
   
2. Have you gathered information from current “public” users of the site as to their complaints of the current site? If so would you share those with us?
   
3. Are you utilizing Google Analytics? What google analytics reports have you leveraged to research viewing habits of your site? Have any google reports made an impact on the decision to redesign, if so which ones?
   
4. Who is the primary audience for your site? Does it have a sectional audiences? If so, what are those sections and audience combinations, what is the approx. percentage of your site dedicated to each of those sections?
   
5. How much staff will you have available on a bi-weekly basis to perform regular review of the site as it’s developed? This review team must include someone from executive management (ideally this would be the PIO) should also include a representative from each of the CORE areas within your organization.  Information Technology staff may be included at your discretion but this is primarily to establish that we are hitting the mark on the needs of the content owners.
   
6. How much staff will you have available to maintain the site once it goes live? How do you plan on coordinating changes to the site between divisions and up to your PIO for approval? Who will do the actual site changes, IT staff or general users?
   
7. How will you measure if the site is successful? What metrics will you be looking at? Do you have established goals, conversions or events in google analytics already? Is that something you’re looking to implement to gauge success, if so what are the details for those?

Step 2: Take another look for goals

#7 from above asked the owner how they would measure success so you probably have a good idea of how you should be looking at the project, but rarely does the owner look at the entire picture. So put on your analytical hat and look for yourself.  While digging through the site look for these items and ask these questions, any of which could be something to measure.

• Where is the real data of the site? Is it in web pages or is the real data buried in PDF or word documents on the site. buried data is useless data in today's mobile world.  Look at the download count of those documents, then talk about exposing that data via actual web pages instead. If it's critical data it should be surfaced in the web browser not some 3rd party extension or application. Once this is done compare the page hit count to the download count, Likelihood is that the page count will be much higher and that means the customer message is reaching more people than before!
  
• Are there any forms on the site? Are those PDFs or Word Documents? Again forcing a user to download and print a form means lost audience and lost interactions. Even online PDF forms are troublesome to use within some browsers because of compatibility issues. Forms should be exposed in the web page just like important data. The ability to fill out a form within the browser is key to more submissions and having the ability to track the success, plus it means it's already in an electronic format that can easily be integrated with other systems.
  
• If documents need to be in downloadable fashion which documents are important to track specific download information for? Identify those and track their downloads so they can be quickly reported.
  
• Are there areas of inefficiency? For example do they maintain copies of information in two separate areas of the site? Do they utilize roll-up areas correctly or are table of content type pages maintained manually required additional effort when child content changes? Look for opportunities to modernize and automate, often times this means changing the behavior of the webmaster or web author, this is the trickiest work of all but preach the time-saving and you can usually get them to come around.
  
• Identify information bloat, it's a common condition that companies treat their website as a giant dumping ground with the attitude that everything needs to be on it.  The truth is "less IS more", analytics can usually show you the pages that have no or extremely no hits and unless those are areas of focus for the customer then maybe they don't need to be there.  Everything on the website should be desired by the visitor and direct to the intention of the website owner. If something doesn't pass either of these tests then maybe you should go live without it and that one time a year someone asks for it through the contact us form just email it to them instead.

Step 3: One bite at a time

When eating an elephant take one bite at a time 

- Creighton Abrams 

Gone is the day when someone could come to you with a 10-20 page website and you could mock everything up, present it, get approval, code it and put it on the web. Now most sites have hundreds, if not thousands of pages, and the number of functional components sometimes out number the employees. Trying to dump an entire site into the lap of a customer for review is a recipe for disaster, instead it's a good idea to give them manageable bits. Decide on a road-map for deliverables in small bits, identifying areas which can be isolated and completed independent of each other or as a result of one another being completed.  This becomes your project plan and development calendar.

My suggestion is to start by establishing the Framework, meaning the overall visual style of the homepage and inner-page. Include things like the header, footer and heading styles. These can all be mocked in Photoshop or whatever other graphics program you have. They create a foundation onto which all the other content can be laid.

Then move on to either functional areas or logical areas of the site. So for example "About Us", start a cycle of...

• Discovery
• Design
• Review
• Coding/Content Migration
• Accessibility Testing
• User Testing
• Sign-off

Those astute of you may see a Agile sprint here and you'd be right.

I know none of this is ground breaking or should be at least to most anyone but the reality is most developers in the web just plow headstrong into the project with the thought that planning and cycles slow things down.

Step 4: Pieces make a whole

Even though you got sign-off as you went along there is still a level of testing and sign-off needed once all the pieces are together to endure. Traditionally this is known as the "soft launch" and is a crucial phase of the process because it allows you to sample out the website to potential visitors and find real errors prior to it going live to the masses. During this time you also begin to collect metrics on the goals you placed into the application. this early collection lets you know if the metrics you designed are what you need or if maybe you are collecting too much information and need to scale back prior to launch.

If custom development was involved in your build this phase also will also act as a first sign of any "scaling" issues you may encounter. Soft opens are common place in many industries and we should learn from their best practices to help our go-lives be as successful as possible.

Step 5: It's not over when it's over

Reflections aren't just for mirrors or ponds.  It's important 6 months and a year later to revisit your website and compare your metrics to your anticipated goals.  If you had previous numbers under the old site then now is the time to compare those, don't expect day 1 numbers to be the same as day 365, it takes a while for users to get used to even the most user-friendly site revamp.

If you didn't have metrics on the previous site then don't despair, you can still compare month to month values on the new site to see user adoption as people got used to your new site. Also remember that your website should not remain static, it's a living thing and should be fed and cleaned up after regularly.  Feeding should include new content to keep people visiting your site to see whats new, it can be blog posts, news articles or customer reviews.  Cleaning of existing content should also be done to make sure content doesn't become incorrect or outdated with changes in your business process and mission.

Big Migration equals big headaches

So lets say you have a single site with 50 pages and you are looking to move from Content Management System X to DNN/Evoq.  Easy enough, bring up one site on one monitor and the DNN/Evoq site on another and spend a couple days copy/pasting.  Oh if life were only that simple!

We're looking at moving sites with hundreds to thousands of pages so a manual copy/paste of content just isn't going to do it.  So now I'm writing, from scratch, a migration tool to try and move content from SharePoint 2013 to DNN/Evoq.  I knew going into it that this wouldn't be easy, business make their fortunes writing these types of things, but I have pulled almost every rabbit out of the hat in making this go and I'm coming to one conclusion.

Content Management Systems don't want you to leave so they don't make it easy for you to go.  Now granted in this case getting information out of SharePoint isn't proving nearly as hard as putting information into DNN/EVOQ.  You see the web-based CMS's are designed for you to do everything through the browser and I'm trying to script and code.  Just not what they were made for.

So here is where I have been and where I might go.

1. Export from SharePoint and "call" the "create page" from the DNN/EVOQ API to create the pages...  this failed because it's very difficult because it's not just one API call to create a page and it's not documented AT ALL.
   
2. Export from SharePoint and "insert" into the database directly for DNN/EVOQ.  I'm a database guy so this should have been easy.  Problem is the database seems to be uber-normalized and a single change can sometimes need multiple rounds trips to the same table. So doing it reliably without wrecking the whole system is very tricky
   
3. Export from SharePoint and "create" a "Export" package that DNN/EVOQ can process using their own "Import" wizard to bring in just pages and content.  so far this looks like the most bulletproof method and I'm making baby steps toward it.  I've got the actual file that holds all the "page" info and am just running into trouble with DNN/EVOQ parsing it during the "import" pre-check.
   
4. This may be where I end up, I just found a project that utilizes the new DNNPrompt API.  This API actually has a command called "New Page" and can be called from powershell.  I know that the #3 solution will probably lead to further enhancement and give me more options, but this powershell route MAY be a stopgap to just get going.  If I can't get the parsing of my package to work then this may be where I end up

So the journey continues and should I figure out a path I will be posting my solution so hopefully it will help others regardless of if you're moving toward DNN or Evoq we all need a way to bring in our data and not all of us are blessed with small sites that manual effort is enough.

Let me know your thoughts and if you've come up against this before. Looking forward to hearing your horror and success stories with migrations large and small.

Google translate the monkey executives can't get off their back

Often times we are asked about "translation" or someone just says outright, "put google translate on my site".  They'll even go so far as to reference a law that says they need it in order to comply.  The truth is "translation" isn't about a technology or piece of software, but rather similar to accessibility it's about a set of best-practices and recommended features for your site.  

Certainly as a developer it's much easier to put a few lines of JavaScript into a theme file or include it in the header and just check off the "translation" checkbox, but are we really meeting the goal?

I think it's too much time under the business analyst hat that has me always looking deeper into not only the headline of requirements but why they exist at all.  So when someone tells me they "have" to have their site translated I push back and ask "why". Then when they reference a law or a statute or a policy, i read it and actually ask them if translating the website alone will mean compliance.

Take for example this sentence from a document a user recently brought to my attention...

From: Code of Federal Regulations (Title 29 Part 38)

Excerpt: A recipient should ensure that every program delivery avenue (e.g. electronic, in person, telephonic) conveys in the appropriate languages how an individual may effectively learn about, participate in, and/or access and aid, benefit, service, or training that the recipient provides.

Now if you read that sentence you'll see that translating the website is only a very small portion, in fact it's only a small portion of "electronic". You see because, and I'll use the google widget as an example, these "silver bullet" widgets only translate the visible HTML it means they miss any text "burned in" on images. It also won't cover any PDFs or office documents someone may download.  Let alone emails you may try to exchange with a potential "aid recipient".

Now take into account the fact that your call center and walk-up services also either must have access to or be trained in interpreting and you've now got a picture of what following the true spirit of the law means.  Think of it this way, how well will your baseball be in the field if you only man first base and the pitchers mound and leave all the other positions empty?

Now for those who need further proof to demonstrate that there is no "magic pill" that solves the issue and in fact they can make things worse by trying to have an automated system translate "meaning" and "intent" here are a couple links from federal sites which cover the topic very well and should hold weight with management, at least more so than the blog ramblings of a developer.

 

Lost in Translation - A quick piece about how automated translation is seen as a "silver bullet" but really the problem is much larger.

https://digital.gov/2012/10/01/automated-translation-good-solution-or-not/

 

Dept. of Labor (Machine Translation) slide deck: a comprehensive look at the pitfalls of automated translation and a set of best practices and suggested approved alternatives and additives to automated translations.

https://www.dol.gov/sites/dolgov/files/OASAM/legacy/files/062414Machine_TranslationWebinar.pdf

Of course, I'm always interested in your views on it and your experiences in handling this request.  Please comment and let me know your story and how it went.

Think bigger when thinking about Content Types

This post will be less from a technical perspective and more from a architectural one. I'm talking about a lesson learned and it remains one I'm still struggling with today.  With defined content types it's easy to think of the visualizer first then create a content type to support it and then for rinse and repeat.  Let me give you an example...

1st need (codename: current focus): I need to be able to put 3-4 high priority items on the front page, preferably I'd like to bring attention to them with a graphical header and a bit of text.  Then when clicked on take them to a page with more information. Ideally the client would like to see something like the bootstrap "card" presentation style.

2nd need (codename: article): I need to be able to host a blog/news section on the site. It should include the ability to have a listing index in a multitude of presentation styles and have the details of the "article" be either a pdf/word document or a link on another website or possibly even no further information at all.

So naturally when I started working on these I saw it as two different things, it was easy since it our current solution each was handled through different mechanisms the thought was to continue that thinking by keeping them separate.  Upon further reflection though I realize that they are in fact the same content item and the only difference is how they are exposed to the user.  This is exactly what EVOQ/DNN is headed with liquid content and it's the mind-set you have to wrap your head around.

I can use a single Content type and then just have multiple visualizers, one to show the items as "cards" and the other as a "listing". The trick is going to come down to filtering and tagging when it comes to what is shown where, but the data itself lines up the same on both.

Thus my plan is to build a "Article" Content Type which holds these fields:

• Title [Textbox, also becomes Content Item Name]
• Description [Multi-line plain Textbox]
• Article Date/Time [Date/Time] (this way people can post/pre populate articles)
• More Information Type (this determines where the title links to in the "list" visualizer)
  • Event Details [HTML]
  • Webpage [URL]
  • Document [Asset]
  • None
• Rollup Image [Asset]
• Optional Elements
  • Article Image [Asset]
  • Article Image Location (Top, Bottom, Left, Right)
  • Expiration Date [Date/Time] (this way you can prepopulate when the article should be removed from view]
  • Featured [checkbox]

Then I'll create visualizers that expose the "rollup" versions using various looks like..

• 3 wide cards (roll-up image on top)
• 4 wide cards (roll-up image on top)
• Cards (masonry/pintrest board layout)
• Article Listing (media markup, roll-up image on left)
• Article Listing (media markup, alternate sides roll-up image)
• Article Detail

Meeting Visualizer Troubles (can you hear me NOW)

Background: Government is filled with meetings, we have meetings to talk about upcoming meetings and meetings we just had sometimes we even have meetings to discuss how to avoid other meetings. So I knew that one of my content types was going to have to be "Meeting" or in my case I was going to call it "Event" so it sounded more generic.

In my world a "Event" has certain "must-have" elements...

• Title [Textbox, also becomes Content Item Name]
• Description [Multi-line plain Textbox]
• Begin Date/Time [Date/Time]
• Is it all day? [Radio button yes/no]

Then it has additional optional information...

• End Date/Time [Date/Time]
• Physical Locations (zero or more reference objects of type PhysicalLocation described below)
• Required elements
• Address Title [Textbox, also becomes Content Item Name]
• Street Address1 [Single Line TextBox]
• City [Single Line TextBox]
• State [Single Line TextBox]
• Zip Code [Single Line TextBox]
• Optional Elements
• Street Address2 [Single Line TextBox]
• Rollup Image [Asset]
• Virtual Location Information [Multi-line plain textbox]
• More Information Type (this determines where the title links to in the "list" visualizer)
• Event Details [HTML]
• Webpage [URL]
• Document [Asset]
• None
• Agenda [Asset]
• Minutes [Asset]
• Event Documents [Asset(s)]

This seems like a good starting place and I'll be adding onto it as I go. Now onto my issue.

Issue: Often times there are multiple committees and/or subcommittees as well as we need to display these in a way that my users are accustomed to I need to be able to seperate the "Upcoming" meetings from the "Previous" meetings.

Solution(s):

For the "committee" and "subcommittee" portion I'm going to leverage the "tag" portion on the content item.  Users should be able to start entering the committee and subcommittee name into the tag box and after the first entry of a given committee it will auto-prompt them.  Now this is a little prone to user error, but it gives great flexibility for the names to be added to and deleted over time. The I can just throw visualizers on the page and use the default "filter" to limit which committee is show on a given page.  This should accomplish the need to separate out committee schedules in a way that's fairly easy for the users to manage and me to control.

That was the easy part, the other part is much more complex since the visualizer ONLY allows you to filter by "TAG". Even the advanced URL filtering has trouble doing logical assessments and is more adapt at doing things like "beginswith" or "endswith" type evaluation.  Here I need a "time" evaluation to limit what is showed.

Having nothing at hand I had to get creative and the answer was in creating TWO visualizers, one for "future" events and one for "previous" events. This wasn't ideal but it would work if i could get the visualizer itself to determine which results to show vs not show.  The problem was NOTHING in the documentation for date filters showed a way to compare a datefield to "NOW" or "TODAY". It existed in the Shopify version of liquid but not in the EVOQ version. So after MUCH searching and trial and error I found a couple crumbs that when combined showed me an UNDOCUMENTED ENUM.

By using the code below I'm able to get the current date/time in a formatted manner and assign it to a variable that I CAN then use in an IF statement.

{% assign xNow = 'now' | date: "MM/dd/yyyy" %}

You can add hh:mm:ss to formatting filter to get the time as well, but in my situation I only needed the date.

So now my if statement looks like this to get me my "Upcoming" events.

{% assign xNow = 'now' | date: "MM/dd/yyyy" %}
{% assign xbeginDate = beginDateTime | date: "MM/dd/yyyy" %}
{% if xbeginDate >= xNow %}
...
...
..
{% endif %}

And I'll be darn it works!  Hopefully this saves you some time looking through tones of other sites.

Saving my users through Structured Content

When I first started with EVOQ for my main workplace I decided that I would utalize the Structured Content engine heavily.  Now anyone familiar with DotNetNuke knows that there are a ton of options available for "liquid content" type template development to make life easier on users.  What you may not know if you haven't looked at EVOQ is that it's one of the main features of the commercial product.

For my users both keeping the website consistent and accessible has been a major chore, Occasionally, I get an extremely smart user who can do one of those two, but never both.   Now in the world of enterprise you strive to be both, but in the world of government it's an essential.  Lawsuits get brought and horrible press is written about sloppy websites or websites that ostracize a portion of the population like the blind or the physically limited. This is why I see Structured Content as a super important tool in the fight against user errors, it allows the users to essentially fill out a form with their data and then for me to control how that data is displayed.

Now many people will say the main benefit to this type of system is that you're creating a "Headless CMS" so you can redistribute the content through a myriad of interfaces like Alexa or Facebook messenger or name a end-point.  While this may seem like a great idea and your management may see all the great possibilities for this, the truth is you probably have enough trouble managing your development load already and real people don't want the "same" message in multiple platforms.  Think of it this way, just because you can get pizza delivered by car, boat, plane, bicycle, rickshaw, drone and para-glider does it mean that you want the EXACT same pizza delivered at the EXACT same time by ALL those methods? The answer is no, and if someone says "well most people only subscribe to us on one platform, not all of them", while that could be true for some it's probably not true for MOST.  If you like a brand you probably follow them on Twitter, Facebook, Instagram and check out their site from time to time.

So I'm looking at the Structured Content engine for having the control, not the capabilities.  That however, is not to say that I don't need capabilities in that control and there is the rub.  I need to be able to have all the control and commands I would with this flexible data as if i was writing an application to display it. More on that to come...

So what do you think? Do you have problems like this with users? How do you keep them from ruining the site? Does this sound like a path you would or will take?