A personal perspective piece

For the non-IT folks out there that complain about the Unemployment System not working let me just add my 2 cents.  System capacity isn't like a garbage can, if you need more capacity you can't just go to any store and buy a larger one.  Most systems are custom built and built for a single detailed purpose, so we do our best to build them for a given capacity PLUS a given excess.  If garbage cans don't work think of your gas tank, you don't have a 200 gallon gas tank in your car even though you typically only need 16 gallons for the normal 2 week period. To pay for more capacity then you typically would expect to use or an educated guess would tell you might be needed in an emergency would be foolish and a waste of money.

For anyone who doesn't follow the details of the news conference the last time the unemployment system was hit hard previous to COVID-19 was 9/11 and after that they increased it's capacity to handle roughly double that traffic. 

Seemed like a reasonable assumption that things would never be worse than a double 9/11.  So flash forward to today and the system is handling almost 3x what planned for in that educated estimate.  The system is handling 10x the normally daily volume, often time processing more than a week of normal application volume in a single day and over a month of normal application volume in a week.

As an IT specialist for the state that isn't involved in the project directly I can tell you every developer and system admin is dedicated and take the systems performance very personally.  I've been in their shoes before with other systems and you feel like it's your child and it's letting people down. It's gut wrenching and the thing that keeps you up at night wondering what you could have done and what you should do now to fix the problem.  When the underlying issue is that there isn't always a quick fix for these types of problems and the timeline for the real solution will likely take longer than the reason for the problem in the first place.

I know there are those of you suffering and trying to stay afloat and all the IT staff I'm sure share my sentiment that we are doing all we can for you.  You are our friends, our family and our neighbors we take pride in servicing with you and share in your struggles.  All of this was said not to pacify you or to excuse the performance but rather to let you know that your voices are heard and we are working on making things better.

The power of preview

Throughout our hunt for a replacement CMS for SharePoint it appears that we may have been spoiled and not known it, further more it appears we've created dependencies on that spoiling to the point that we can't think of how to work without it.  It turns out sometimes you don't know how good you have it until you're forced to try something else and realize that your old beat up car had some killer features that new cars don't have today.

I mean think about it, you're old 80's junker had an ash tray! Did you smoke? Maybe/maybe not, but regardless I bet you probably used that ashtray for loose change more than you ever did for ashes.  Cars today don't have ash trays, so where am I supposed to keep my change?  I could use the cup holder for it, but then when i put my soda down it jingles or doesn't sit right. So yes, There are alternatives for how to do things but they aren't as good as the original.

When I first started working with SharePoint I often asked why we needed to go through an Approval cycle for documents, images and pages.  Now I've decided files and images, yeah approval for those is somewhat very niche (versioning yes but approval not so much), but pages ohhh has "draft" status ever been helpful.  The usefulness of being able to make a change and the user see exactly how that change will appear once it's published to the world, now that's POWER!  We can make entire sites look different and the anonymous public will never know until the user gives us the magic "OK" and then we publish and the whole world sees a massive change at once.

I know in previous blog entries I talked about "headless CMS" and the concept that data and visualization should be separate, but the fact is we care about how things look so being able to "preview" how something is going to look before hitting that magic "publish" button is HIGHLY useful. Furthermore being able to do that and not have to have double the resources just to enable you to have a full mirror system for "content development" only to then redo your work in as the separate PROD environment is a huge maintenance and cost saver.  Not to mention the ability to make quick turn around changes to non-critical content items.


So preview is an important piece of the process but it goes beyond being able to preview what data will look like in different visualizations stand-alone, you have to be able to view those different forms within the context of the final product.  For example, lets say you have a article collection.  If I add an article I should be able to see what that article will look like in the roll up, on the article detail page, in a slider (if thats an option), etc... and I should be able to see those "previews" with the rest of the current page content around it.  Because viewing one listing item not within the context of the others doesn't give an appreciation for how it will actually look.  Nor does seeing the article without the site styling or header and footer applied to it.

Most content editors are visual and they want to know exactly how something is going to look to the visitor, so give them that capability.  If people didn't care about how the final output looked then we wouldn't have LCD screens on our digital cameras where we can review photos before we decide to keep/print them or not.  Remember how life was back in the real film days?  Don't make your website become a "surprise" roll of 35mm where you're not sure if the pictures are gallery worthy or if you have 36 closeups of your thumb.

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