1Our Team

We are seasoned industry professionals, all devoted to the best possible results and highest quality of service.

2Our Philosophy

We believe your web development, design, marketing and sales efforts should be continually improved over time. We believe we have the experience and skills to help you reach your true digital potential. We're here to help, to make you highly successful, and above all: to have your back!

3Our Trajectory

We've experience with a wide range of industries, and all manner of clients. Our case studies show just how effective we've been across the board, and how willing we are to achieve optimal results.

 

 

O8 UX Services

Case Study: Large-scale WordPress migration and digital marketing optimization for Ecumen

Ecumen Case Study

Drupal & Custom CMS to WordPress Multi-site Network

 

Project Components:

  • Content inventory

  • Content strategy

  • Wireframes & CTA’s

  • Manual migration of 28 websites

  • Key page redesigns

  • 3 key templates (2 custom)

  • Multisite hosting architecture (via Kinsta web hosting)

  • Digital Impact Optimization (ongoing SEO, UX, CRO improvements)

  • Continued ongoing maintenance, feature additions, and design refreshes

The Challenge:

Ecumen operates a variety of senior housing options and services, including cooperative senior housing, independent living, assisted living, long-term care, short-term rehabilitation care, home care, and hospice. In addition to their consumer services, they provide senior housing development, clinical consulting and senior housing management services for organizations outside of Ecumen.

Ecumen Services Offering (in no specific order):

  • Independent Living

  • Assisted Living

  • Memory Care

  • Care Center

  • Short-Stay Rehab

  • Affordable Housing

Ecumen had been working with an industry-specific vendor, who was increasing support, maintenance and hosting costs. Their primary motivation was to not only reduce costs but also “unify” their websites. Choosing WordPress as their primary CMS could house content and media while managing users throughout the multi-site network.

After only about a month from our initial discussion, we received a call from one of the top decision-makers requesting our immediate services with the contingency of a very tight timeline (2 months essentially to do a 1-to-1 migration) on all of their sites - including their main site Ecumen.org (which had an excess of 2,200 blog posts). 

Content Inventory and Historical Backup

Because of the Ecumen’s urgency to move forward, and without the assistance of their previous tech partnership (nor logins to the vast majority of their sites), we wanted to make sure we that physical backup of their current live sites. So we ran SiteSucker on all of the sites within their network and relaunched on our local servers. This provided us with the backup and reassurance of a historical backup of the site to reference.

Large Multisite Challenges

Before we could even tackle multi-site content migrations, we had to set up the network. Prior to this O8 had setup multi-site networks before, but not to this magnitude. First, we had to choose a server. After much discussion, Kinsta was selected as the server of choice. Not only for their focus on WordPress, but the ease and use of multi-site networks. 

Our Solution:

O8 was initially engaged by Ecumen in early 2019 to support the massive site migration and relaunch of 28 sites within 2 months. Our solution was basic. We had our team of eight Data Migration / WordPress experts migrate all the sites (in order of priority). To this end, the client wanted most of the sites to look the same, yet have their own branding. Given the tight timeline, it was decided that a 1-to-1 migration was needed (at least initially). So site-specific tasks were spun-up, reviewed, prioritized and assigned out to our migration experts. 

Once the content was migrated, QA took place. This took much longer than expected - primarily because of the difference between the old site and the new theme’s layout / structure. Not only were we making use of an advanced editor, inserting content into the new template had its own challenges - where we reloved by making use of customizations (CSS & JS), additional trusted plugins and some of our own custom code (in the form of a plugin). After the second round of QA was complete, the tasks were assigned back to Ecumen’s marketing team for review.

User Roles & Permissions:

Having a large multi-site network Ecumen wanted to hand much of the content control over to local site-specific users. O8 had to create a framework around site-specific roles and various permission, even as granular as text-only content. We achieved that by customizing the user role editor.

Site Redesign(s) & Responsiveness:

O8 was also tasked with re-architecting and redesigning the old sites, in accordance to their current brand standards.  This internal redesign was followed by an external visual/UX redesign to make the site more welcoming and user-friendly.

The Multi-Site Themes:

Ecumen.org Redesign (most locations theme):

Before:

After:


The Locations Revamp:

Not only did local listings not fully populate on Ecumen’s old site, but the results also needed multiple pages. This resulted in weakened user experience due to search difficulty, Our UI / UX designers came up with a solution that would not only integrate with Google Maps but could also be filtered correct bases on the locations desired services.

 

Before:

After (see below for a larger image):


 






 






 

Categories

Team

Categories

Case Study: UX, marketing, design for IgnitEd

Higher Education Institution

Drupal website restructure, UX review and marketing support for a major higher ed institution

www.ignited.global
  • The website restructure and redesign resulted in more than a 50% year over year increase in traffic from organic search

  • Conversion rate for registrations increased 113% as a result of paid search and social campaigns

  • Number of site pages indexed for search increased nearly 4x following site redesign/rearchitecture

 

“For us, as a small department, O8 has been critical to our continued evolution. I truly feel as though I have more people working on the success of my business than what is listed on the payroll. I trust their guidance and their willingness to accept feedback and pivot."

Tracy Couto

Le Moyne College

 

Project Components:

  • Content strategy

  • Page redesigns

  • Digital Marketing  (paid search and social)

  • Digital Impact Optimization (ongoing SEO, UX, CRO improvements)

  • E-commerce

  • Solr search

  • Ongoing maintenance, feature additions, and design refreshes

  • Emergency support

  • Web hosting architecture

  • Security and disaster recovery planning

  • Migrations of acquired brand websites

Challenge

Ignited is an online community and collaborative platform for business faculty developed by Le Moyne College. Its purpose is to encourage the sharing of business school curriculum, course materials, case studies, teaching notes, articles and studies with like-minded peers. Participants can submit their own research and scholarly articles for peer review. The Ignited website features hundreds of course resources, available at no cost for downloading and review by business faculty.

Ignited’s emphasis on ethical and sustainable business practices is a direct outgrowth of Le Moyne’s roots as a Jesuit institution. As a result, Ignited’s mission is to be the preeminent source of case studies and teaching resources, serving faculty, administrators, students, and alumni at Jesuit institutions around the world. In addition, Ignited’s resources are available to any business faculty looking to emphasize the contribution of ethical business practices as a way to bring about global transformation. 

O8 Solution

O8 was initially engaged by Le Moyne in the summer of 2018  to support the launch of Ignited, both for website and marketing support. 

Paid Media Campaigns

O8 worked with Ignited’s marketing team to develop, launch and manage social ad campaigns on Facebook and LinkedIn. This enabled the new site to gain targeted exposure among business faculty active in fields such as marketing, operations, accounting, and international, as well as those who had interests in topics like social justice, business ethics. and sustainability. 

 

 

 

LinkedIn

Facebook

 

Following the initial launch, the ad strategy shifted from social to paid search, which provided a lower-cost acquisition model. Beyond registrations, another key conversion goal was to encourage review of case studies and resource downloads by interested faculty.

The initial ad campaigns greatly raised the profile of Ignited, resulting in hundreds of thousands of impressions, thousands of site visits and contributed to hundreds of registrations.

Site Redesign

O8 was also tasked with re-architecting and redesigning the Drupal 7-based Ignited site from the ground up, updating the underlying site structure to make it more scalable and sustainable. Page URLs were updated to make them more meaningful to search engines as was the taxonomy of course materials. This internal redesign was followed by an external visual/UX redesign to make the site more welcoming and user-friendly.

Home Page

The home page redesign balanced the need to maintain key brand elements, navigation, and existing color palette while still providing a more engaging, interactive experience. The new design offers three different calls to action, which update if the user is already logged in. Featured Course Materials are showcased immediately below the hero space, using colorful imagery, similar to stories on news sites.

 

Before:

After:


Course Resources Page

The new design removed the detailed sidebar filters from the main page and brought the main curriculum topics into focus.

 

Results

During the marketing campaign, the registration form conversion rate rose over 113% (i.e., more than doubled) as compared to the previous period:

Following the launch of the redesigned site, the number of pages successfully indexed for search increased nearly 4x, as reported by Google Search Console:

Overall, for the one-year period of O8’s involvement, encompassing July 1, 2018 - June 30, 2019, organic users increased nearly 51% over the July-June of the previous year:

Sessions

Users

 

O8 continues to work with LeMoyne on new functionality and performance improvements.

Team

Case Study: Drupal 8 redesign for a Community College

Academic Catalog

From the client's perspective:

From start to finish Origin 8 has been an excellent company to work with. We came to them with a responsive design template with many dynamic elements and a goal to use Drupal 8 as the content management solution. Though we have considerable in-house experience in web development, we had little specifically in Drupal. We needed a company that could partner with us and handle the technical challenges of site development and programming to provide us with a flexible interface to keep our site maintenance cost and update time to a minimum. They met the challenge head on and helped us reach all of our performance goals.

Origin 8 set up a sprint-based project management process whereby we met online every two weeks to go over progress from both of our areas and set out the tasks for each person for the next sprint period. We wanted to do as much of the content entry as possible, so Origin 8 took that into account and turned things over to us as soon as they were ready for data entry and testing. Origin 8 documented tasks and progress in an online tool, so it was possible to see the status and thread of any task. The sprint process helped us stay on track too as the goals set each call were manageable within that time period.

In addition to their technical expertise, Origin 8 was also very easy to work with. They listened carefully to what we said and used that understanding to either implement that specific request or to suggest an alternative method that could either lower maintenance overhead or be better suited for future site developments.

See the review on Google >>

From our perspective:

This was a fantastic approach to incremental improvement and agile development of a Drupal 8 site that dramatically empowers stakeholders at the college. But really, our client couldn't have said it better.

Case Study: Drupal Redesign and Digital Marketing for HelpSystems

HelpSystems Drupal 8 website and digital marketing support

Complex multilingual Drupal website restructure & redesign for an established and renowned tech company

www.helpsystems.com

  • The website restructure and redesign resulted in a 140% increase in conversions year over year and a 15% increase in traffic, including a rise in mobile traffic.
  • Conversions increased across the board from contact form submissions to whitepaper downloads, and higher trial software and demo downloads.

"While our measureable goals are related to site conversions and leads – and those are increasing nicely – we are really pleased with how we are engaging with the market. A lot of people come to our site to get educated on topics like cybersecurity and IT operations management. This new structure helps these people get the information they need and connect with us if necessary." –Mike Devine, VP of Marketing

Read more >> 

Case Study: Conversion Rate Optimization for HelpSystems.com

Conversion Rate Optimization Case Study: HelpSystems.com

Using a scrollmap (a kind of heatmap) we found that users were not scrolling down the homepage of HelpSystems.com. Notice the major drop-off in scrolling activity denoted by the fast red-to-blue dropoff on the gradient.

Screenshot 2018-02-19 21.03.01.png

Further down the page were impressive client logos, constituting "social proof" – an important component in increasing trust, engagement, and key business goal attainment. 

Screenshot 2018-02-19 21.04.29.png

Simply moving the client logos further up on the homepage resulted in a 128% improvement in a core revenue driver – product trial downloads – which translates to thousands of dollars per year from a simple adjustment.

This took us a few minutes to spot, then 2 weeks to run a split test, bumping up logos for 50% of the traffic. In just two weeks and a few minutes of our time, they dramatically changed their business.

The results of this experiment are shown below:

HelpSystems-Optimizely-Results-DIA-Screenshot.png

This is a simple but powerful example of how important and impactful conversion rate optimization (CRO) can be.

Case Study: Drupal Website Migration

Drupal Migration

Migrating a website from one platform to another can be a stressful and uncertain time if it is not carefully planned and well executed. Whether it is migrating to Drupal from another platform like WordPress or upgrading to the latest version within the CMS, a good roadmap is necessary for smooth transition and minimal downtime.

Why migrate? There can be compelling reasons to upgrade a site, including adding functionality, and improving performance and security. Additionally, it provides the opportunity to review and refine content, and improve UI/UX design for a better user experience.

In this case study, our partner, a technology company, helps organizations manage computer security. The project required a site migration from Drupal 6 to Drupal 7 for which there was no automated migration path. The goal was to deliver just the minimum viable project to meet scope/quality, concrete deliverables, deadline and budget.


As usual, when we collaborate with a client for a migration project we begin by establishing objectives, and defining tasks, so that everyone is on the same page and resources can be allocated appropriately. The typical migration project consists of planning, preparing the site for migration, upgrading and testing. With the Drupal CMS there will platform-specific methodologies that need to be followed to ensure a trouble-free migration. Data handling in particular needs expert level attention.

Setting Objectives

In this instance, the minimum viable project required:

  • Migrated main website and 8 microsites from Drupal 6 to Drupal 7
    • All content and custom Content Types
    • All files, including the online document repository
    • All Users and Roles
    • All Taxonomy terms
    • All Views, including Views supporting per-page dynamic content based on keywords
    • All custom Webforms
    • Recreated and improved complex workflows needed by content managers and external partners
    • Implemented complex role-based access control
    • Customized SOLR search implementation in support of access control and workflow needs
  • Implemented a fully responsive theme based on existing design
  • Security improvements
  • Expanded content manager tools to support:
  • Extending the look and feel
  • Link checking
  • SEO impact evaluation

Biggest Challenges

  • Rebuilding the site theme, so that there was very little or no change to the look and feel of the finished D7 site. This required a complete inventory of all the customized page layouts.
  • Fully reimplementing the complex access control across the site, document repository and site search was the biggest challenge of the migration. The content management workflows required very fined grained control of both the access and the search index.


The completed project resulted in improvements in functionality, performance, usability, security, and mobile readiness, and positioned the company to maximize their website's potential as a sales channel.

When to Migrate?

The time to consider an upgrade is now, and if you are still not sure we can help with a quick evaluation, so you can make an informed decision. If Drupal is your choice, we can facilitate seamless migrations, including the just announced Drupal 8.

Contact us for a free consultation.

 

Categories

Case Study: Drupal Performance Testing

Drupal Performance Boost

Recently, a client came to us asking for help with performance problems. The reported problem was simple: the homepage loaded really slowly on mobile devices! As developers, we know that bug reports frequently hide a lot of complexity. Performance problems are no different, and they can fool us, too. Site performance issues can implicate as much as, oh, ALL of the code. So, when we see a slow page, what do we try to fix? In this situation we may be tempted to just use our favorite hammer and see everything as a nail, but the real challenge is how to address specific underlying causes and make changes that will make a concrete difference, instead of blindly hammering away.

The Project

The client's site is an online news outlet focused on a particular topic/community. It features news articles, polls, image galleries, and a few types of reviews of community resources. Its revenue comes from advertising, particularly from vendors that cater to this community of people. This brings us to our first set of complications: the client wants a dynamic, complex homepage in order to attract and retain eyeballs; and also wants to display as many ads as possible. It turns out ads are bad for performance! But I'll save the debate about the merits of the Internet ad-economy for another day.

The Basics

First things first. There are a few things for which we should do blind checks, right off the bat. This is a Drupal 7 site. Is site caching turned on? Are all Views being cached? Is the database being used as the cache backend, or something fast (like Memcache or Redis)? Are most users anonymous (using caching) or logged-in (possibly not using caching)? Before digging deeper, we did a sanity check for the low-hanging fruits that are known, common pitfalls with Drupal sites (Here are some additional recommendations: https://pantheon.io/docs/articles/drupal/drupal-performance-and-caching-settings/).

In this case, most visitors to the site were anonymous. There wasn't a lot of interactivity, and so there was not much chance that visitor behavior was triggering a bunch of costly operations based on varying queries. The site did have caching enabled, and was using a Redis backend caching. Redis is fast, so I'd expect it to be a pretty swift solution. I actually spent a little time digging into it, which was probably a bad use of time. If a speedy cache backend is in place and enabled, it's probably not the best place to start with optimization work and analysis. However, there were two Views that had caching disabled. I turned it on for those, and also enabled a sitewide minimum cache lifetime of five minutes.

Take a Step Back

Now is the time to take a deep breath. Don't start digging into the guts of Views queries or the MySQL slow query log. Don't send the client a recommendation to double the number of server nodes (well, unless the site is literally melting down at that moment). Depending on your professional background, you may be familiar with certain sets of performance problems to watch out for, and strategies to mitigate them. But now is not the time to start hammering away. Now is the time to measure.

Page Performance Hides a Lot

The web applications we write today are complicated. Content Management Systems and Platforms-as-a-Service can open up a lot of power to folks who do not have the time or resources to build that power themselves. But just because it's easier to deliver functionality doesn't mean the underlying process of building, sending and rendering that webpage is simpler. A lot of steps are hidden behind a slow page load. So, which one is going to give the most value per hour of optimization work?

The answer is to start using tools to measure what's happening. If you don't have measurements, you can't do good performance optimization work, and you can't demonstrate the value of your work, because you have nothing concrete to point to at the end of the project. What if the client says that the site is still slow? "Well, it's fast enough for me" is probably not going to fly.

In this client's case we have a hint where to focus our efforts: they specifically mentioned mobile device performance. It indicates that the client side may be the key to the problem. If your background is in PHP or other server-side stuff, all the tweaks in the world may not actually solve the problem. Without measuring to confirm where the bulk of the bad performance is occurring, we could waste a lot of time in areas that are relatively unimportant, or already well-optimized.

Measurement Tools

Here are a few measurement tools I used on this project:

  • NewRelic: NewRelic increasingly has competitors, but for PHP-based sites, it's still the best tool to start measuring both server-side and client-side performance, in the context of overall performance. NewRelic breaks both sides into several main components, and provides analysis of individual transactions/pages. It doesn't necessarily give you the "why", but at minimum it will give you helpful direction to the "what." Its Browser component conveniently breaks performance down by browser and mobile vs. desktop.
  • Chrome/Firefox developer tools/Firebug: Essential tools for doing a deep-dive into what is happening on the client-side of the website. Keep in mind that using these tools introduces a bias: you're measuring with one particular computer/browser. Don't assume that what happens on your late-model MacBook holds true for other (or even most) site users.
  • Google PageSpeed Insights: A client-side analysis that provides some recommendations, including a mobile-focused report.
  • WebPageTest: A client-side analysis that focuses a little more on the requests involved in loading the page.


What Did We Find?

NewRelic was super helpful in giving us an overview. We found:

Server-side processing did show some slowness. The APM component reported that average requests were taking around 1300ms, which is kinda slow for a site on a robust hosting platform that uses fast caching. My changes were eventually able to get these down to around 620ms.

More importantly, client-side performance was really slow. The Browser component reported that pages did not load completely in visitors' browsers until an average of 15 seconds. Some, especially mobile, visitors were taking 25 - 30 seconds to fully load a page. Whoa! This stood out as a clear, high-value target for optimization. I was eventually able get averages closer to 8-12 seconds. Still not great, but those numbers were somewhat inflated by ads on the site. Those ads are powered by 3rd party networks, which means each visitor's browser is waiting (at some point) for requests to and rendering of resources that we don't control.

What is Taking These Browsers So Long?

Another reason measurement tools are critical: your subjective experience on a particular browser is not representative. The site was loading much more quickly on my desktop browser than shown in the NewRelic averages. Google PageSpeed helped show why. It has a useful concept of the resources that must be loaded in order to display above-the-fold content. This is especially important in mobile browsers, where network speed and CPU are often not good. In the case of this client's site, a LOT of resources needed to be loaded and processed by the browser before it could show the content at the very top of the page. Fast on desktop, much slower on mobile. PageSpeed has related documentation with a lot of recommendations in this area: https://developers.google.com/speed/docs/insights/rules

In the case of this client, we found a variety of smaller problems that contributed to the mobile browser page load problem, and some solutions:

  • Blocking JavaScript that could be inlined. The browser waits while it loads external scripts in the HEAD of the browser (https://developers.google.com/speed/docs/insights/BlockingJS). Changing JavaScript to be output as inline code can cause problems. I turned this feature on specifically for the homepage, because I knew it needed to be as fast as possible, and was worth any possible debugging time. The AdvAgg module (https://www.drupal.org/project/advagg) has a feature for inlining JavaScript on particular pages.
  • Limiting the external JavaScript that was being executed. Several third-party JS tools had been added during prior development that were no longer used, or not very important. We stripped these out.
  • Combining requests to external resources. The site was making several requests to the Google Fonts API to load custom fonts. I reduced this to just one request. And then I realized: why make this an external request at all? I used this tool to download the free fonts and changed CSS to load them from the site's server: http://www.localfont.com/
  • Unnecessarily complex HTML. The site was built to be mobile-responsive. However, it exclusively used CSS media queries to selectively hide elements that were not used in the mobile layout. That meant that desktop-only markup was still loaded and processed by the mobile browser. Elements hidden by CSS rules do improve mobile speed, but not as much as omitting those elements altogether. A complex set of HTML elements needed to be processed and rendered before the top of the mobile page could be displayed. Unfortunately, once the site is built, this is not an easy mess to untangle. We didn't end up getting the budget to do the bulk of that work.
  • Many CSS rules were being loaded on each page. Only a fraction of those were needed to style the homepage.
  • Lots of resource requests overall. The browser needed to request around 200 resources overall. That's a lot!


Speeding Up Resource Requests

We reduced some of the browser requests for resources like JavaScript files and CSS files, but the site still required a lot of requests in the form of images. These images were deemed essential by the client as the site needed to be visually enticing. Luckily, these images were already being provided by Drupal's image styling system, so they were appropriately sized and compressed. It was still a lot of requests. So, the question remained, how do we speed that up?

The client was already using a Content Delivery Network (CDN): Amazon's CloudFront. This provides low-latency access to static resources (like images). However, a critical limitation of HTTP 1.1 is that the browser will only request between two and six resources in parallel (ie, at the same time). Even if images are small and cached in a CDN, the browser still is going to load them in small batches until all are loaded. With about 80 images on the page, this was a problem.

We made two changes to help with the situation: domain-sharding and far-future expiration. The HTTP 1.1 limits are on a per-domain basis. By serving static assets from several domains, we allow the browser to do more work in parallel. The CDN module (https://www.drupal.org/project/cdn) can support multiple CDN domains, so we changed CloudFront settings to add static1.domain.com/static2.domain.com/static3.domain.com to the client's CDN account, and enabled those in the CDN module's settings. The CDN module randomly picks among the domains in serving each resource. This is domain sharding. As a result, the browser could chew through those images more quickly.

CDN also supports far-future expiration. Your CDN typically looks for a header that tells it how long it can retain a resource in its edge cache. Images, for example, typically don't change once cached (or if they do, the filename also changes). They're great candidates for being cached a long, long time. That's far-future expiration: don't expire my resources from the cache until far in the future. Expiration for particular file types is best set via your web server's configuration files.

In the client's case, however, we did not have control over the web server configuration files. The CDN module far-future expiration feature rewrites resource URLs so that they go through a special menu path that ensures the file is sent along with special headers to define cache expiration times far in the future. This mode is a little problematic (it can conflict with AdvAgg in certain ways, for example), but in our case it was the best option.

CDN Gotchas

One problem with loading resources from a different domain than your website is that you can run into browser security problems. It is no problem to load images from a different domain, but browsers will complain about web fonts, and these fonts won't work. You need to make sure you have a proper Cross Origin Resource Sharing (CORS) setup with your CDN domains for those resources to work, which can be tricky. In our case, it was further complicated by a mix of HTTP and HTTPS requests to the site. I ended up excluding web fonts from the CDN setup using the CDN module's advanced settings.

Wrapping Up and Lessons Learned

In the end, we were able to demonstrate some concrete performance gains in our measurements and the client was happy. We didn't make any recommendations that would have substantially increased the client's monthly hosting bills, because we could tell that most of the problem was on the client-side.

Of course, some entrenched problems remained that we couldn't address in the short term. If you're building a site in which mobile clients need great performance while also viewing complex, visually-rich content, then performance measurement ought to be part of the development process from the beginning. A CMS, like Drupal, makes it easy to add lots of features and put them together on a page, but automatic feature-building tools like Views, Panels and various dynamic HTML plugins for galleries and carousels often tend to output complex HTML. Any one in isolation will be fine on mobile, but throw a bunch together without incrementally measuring performance, and you won't notice what a mess you're creating. Responsive design needs to be more than about just hiding some content and changing column sizes with CSS.

In cases where we are building the site from scratch, we do the due diligence to structure it with performance optimizations in mind and we keep monitoring it as it develops. Even after the project is complete we recommend periodic performance reviews through the life of the site so that it can stay optimally tuned, and ahead of the competition.