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: 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.

Conversion Rate Optimization Case Study: Iron Plane

CRO Case Study

This client came to us for a one-month trial of our DIO services.

Within one month, we increased visits to the "book a consultation" page -- the main way they capture leads -- by 619%, and decreased the homepage bounce rate by 20%!  

Now, the analysis. This is what their homepage used to look like:

Screenshot 2018-03-08 14.35.57.png

Our notes, scanning down the page:

  • Phone and email links were not clickable. 
  • Click to book an appointment...with who? Once we arrived at that page, there was no indication who you were booking with and what would happen when you booked. 
  • No About page in the main menu, yet heatmaps showed very high clicking level on the About page link in the footer.
    • Don't hide the information that users want, and don't hide who you are.
  • What is "MAGEBUTTON" in the main nav? 
  • Why are their partners more important than their portfolio? 
  • Full Service Magento eCommerce Agency + "MAGENTO SPEED OPTIMIZATION" is not a very distinguished and clear value proposition. 
    • The value proposition should answer, "Who are you, what do you do, and why should I contact you versus another Magento agency?" 
  • The "MAGENTO SPEED OPTIMIZATION" text is part of a rotating banner-like design. Research shows that this is ineffective and harms conversions – see http://shouldiuseacarousel.com/
  • "View our Services" is not a unique or principle call to action here. I need more "proof" about who you are as a company and what you've done before I view your services, especially since it's already pretty clear that you do Magento. 
  • No visual cue indicating to the user that they can scroll down for more information. Heatmaps showed a lack of scrolling activity.
  • No "social proof" i.e. logos or certification badges about who they are and why they would be someone good to reach out to.

Our revision:

This is what our revision to the homepage looked like, wherein we sent 50% of the website traffic to our version and 50% to the old version.

Screenshot 2018-03-08 14.28.31.png

Note that this could definitely be reworked to be a bit more visually-appealing, but that's not the point. The point is to learn, put hard numbers behind the changes we made, and then worry about visual appeal. We have best practices we follow, but sometimes they are wrong – that's one reason why we do these A/B tests. 

Here's what we did: 

  • Adjusted what we saw in our analysis above.
  • Made the hero area shorter so users would get a visual cue to scroll down the page. 
  • Added important "social proof" in the form of logos and certification badges to the hero area.
    • Normally we wouldn't clutter the hero area, but they were throwing $5,000 per month of ad traffic at the homepage, and this was an emergency that we had to turn around ASAP, and had to help the client understand how they were needlessly throwing away money down the drain.
  • Add the About page to the main nav.
  • Added more human content ("who are you?") to the About page; a form of social proof.
  • Reworked the value proposition to be more compelling and differentiating, focusing on their high level of certification (another form of social proof).
  • Changed the main CTA in the hero area to lend a greater impact the business, with more compelling copy than "view our services."
  • (Not pictured) got rid of unnecessary and unprofessional-looking content on homepage.
  • (Not pictured) Beefed up portfolio page to show images of projects rather than icons.

Results:

  • 619% increase in visits to the "Book an appointment with our CEO" page.
  • 20% increase in visits to their portfolio and case studies.
  • 20% reduction in bounce rate to the homepage.

Screenshot 2018-03-08 14.31.19.png
Screenshot 2018-03-08 14.31.26.png

     

     

    HelpSystems.com: Responsive Drupal Website Redesign and Digital Impact Optimization

    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 >> 

    Conversion Rate Optimization Case Study: 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.

    Drupal Migration Case Study

    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

    Drupal Performance Testing Case Study

    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.