The Mission: Mobile Site!
Here at CodeGuard things tend to move pretty quickly. We’re made up of a team of highly driven individuals that like to build things that we know will positively impact our users and build them fast! We soon realized that not only do we move fast, but our users do too. More and more we realized that we were getting a lot of traffic to our website from mobile devices, and our users were increasingly requesting features that were optimized for mobile (if not built to be on mobile first – desktop second).
We have been steadily optimizing the CodeGuard website into a responsive design for a while now, but it became clear to us that it was time for a different strategy: A mobile-first design. It’s not that there is anything seriously wrong with a responsive design. RWD (Responsive Web Design) is an increasingly popular way to serve mobile users a version of your site that can fit their devices and allow them to access the same content that they would on a desktop website. There are some major caveats though. When you serve the same exact content to desktop and mobile visitors in the same exact way, regardless of what device they are on, you risk slow load times and giving your mobile users the content that maybe they don’t want to see.
For example, a restaurant may have large images of their food at the top of their desktop website but a user visiting that same website from their phone may not want to be served large images that are slow to load. Maybe all they wanted was to find that one tiny link that says “Directions” so they could get to that restaurant. If you don’t think about what your users want from you out of your mobile experience then you are bound to give them an experience that is unsatisfactory. One needs to think about why users are visiting your site from a mobile device, and here at CodeGuard we set out to find those answers and create a multi-device mobile-first design that best suited our users needs.
The Timeline/Deadline: Two Weeks?!?!?!?!
As always, we strive to push ourselves to new limits at CodeGuard. We gave ourselves two weeks to plan, research, ideate, wireframe, design, prototype, develop, test, and launch a completely new mobile homepage for CodeGuard.com – all while still taking care of the other on-going projects that we had going on at the time.
So how did I get the idea to try a mobile-first design? A lot of my inspiration for this project came from one spectacular event I went to in Atlanta called “An Event Apart.”
Not only were the speakers amazing at what they presented on, but the community that showed up was really fun to interact with and meet. I highly recommend that you attend one in your city if you get the chance! It was here that I got a lot of inspiration and ideas for how to re-imagine CodeGuard’s mobile experience. I learned that a mobile-first design where you started from the smallest screen size and worked your way up was the best way ensure that your site would look good on any screen size. I learned that you should let the content decide where the layout “breaks” into a new layout and not the device it is on (which is a great way to make sure your design is device agnostic) and I learned a bunch of creative and inventive ways on how to best optimize your content and layout for these small screen sizes.
With this newfound inspiration I took to researching good design and development practices. For my design research I sought out to answer the questions: How is navigation typically laid out on mobile websites? Who does it well? What do I like about this mobile website? What do I not like about this other mobile website?
Development planning was a slightly larger task. Because we were going with a mobile-first design this meant that we were going to be creating a separate mobile website – while still maintaining our desktop website for a time period. I did a lot of research on this topic, and going to An Event Apart helped me reach this decision in the end. The cons involved us supporting two codebases for a short period of time, and figuring out a graceful solution for how we would handle device detection and redirects when they landed on our homepage, but the pros far outweighed the cons in the end. We would be able to start fresh with our content and give our users the content we know they want, instead of just serving them what is the same on the Desktop site. We would also be eliminating a lot of potential “code bloat” by starting over with a new codebase that is purely optimized for mobile from the start, instead of the other way around. It also has the potential to be much faster than our existing website.
In the end we decided to create our mobile homepage as a stand alone static website built on a front-end tool called Middleman while creating our html/css using haml and sass, but I’ll get into more detail on how I developed the site in moment!
So to begin, what was our goal with this new mobile homepage? What did we want to accomplish? What do we want our users to see? What do we think they want to see? To answer these questions, we decided in the end that our goal would be to “start a relationship with the mobile user.”
I started sketching wireframes on my whiteboard at home and broke up the homepage into a few sections that I thought would help us achieve this.
The top section would answer the question that every homepage – mobile or not – should answer, “Who are we, and what do we do?” Right away there were some challenges though, because the way our current homepage does this is by having some text and then a large video. While everyone here at CodeGuard loves our homepage video, it takes up a lot of space when translated directly into a small viewport size. Space is already very precious on a mobile website. I tried to keep the navigation and logo area just a small strip at the top of the screen so that it only takes up about 10% of the screen on load, and then the rest of the 90% of the screen can be all content answering the “Who are we, and what do we do?” question.
Our video could have easily taken up all of that 90% though, so I had to think differently about displaying it. The end result is that it is hidden until requested to be watched. This ended up saving us precious bytes as well, since we are not loading it until it is asked for (but I’ll get to speed optimization and other development wizardry later in the post).
The next section would answer the question, “What can we do for you?” I went back and forth with this section on whether I wanted to show a story of how CodeGuard works, or what our three main features were. I decided to go with our three main features (Backup, Monitor, Restore) in the end, hoping that if people liked what we had to say there, they could find out the “behind the scenes” stuff on a different page.
The third main section (one that cannot be seen in my whiteboard sketches because I added it later) is a client testimonial section. We can tell our mobile users all day long about how perfect we think we are for them, and how important our services are (and they are!), but hearing it a second time from a source other than us is always a good thing too!
The final section of our mobile homepage is a section where the user can enter their email address and get a special discount code emailed to them that they can use on any plan. We liked the idea of our mobile users checking out our website from their mobile device, or wherever they may be, but also getting the opportunity to browse our desktop site at a later time. We thought the email would be a great way to remind the user that they visited us, while also giving them a great incentive to try us out!
After deciding on all of this it was time to hit up Photoshop. Below I’ve included a few screenshots of things that I was designing, scraping, re-designing and polishing throughout this phase.
The Testing/Finishing Touches:
I saved the last two to three days of my two week deadline for testing because I wanted to be as thorough as possible. The most popular mobile browser being used today is Safari, followed by Android default browser, and then Chrome. The fourth most popular was Opera Mini (my personal mobile browser of choice at the moment) but the drop off from Chrome to Opera in use was so severe that it was almost not worth testing for (but I did anyway). The Android default browser had the most issues to work out, mainly around the video functionality and pop-up messages surrounding the form, but overall testing was not nearly as painful as it was when I was doing responsive design testing. This made me believe even stronger that I had done things right this time around, and had approached this project the right way.
With help from our Director of Engineering Jonathan Manuzak, we were able to solve all server redirect details quickly and get our mobile website out and in front of our eager users. Two weeks went by very quickly, but with all the planning and research that went into this project I was very confident that we were doing things very right. I think that we stayed true to our goal in the end while never forgetting our users in the process. In two weeks we were able to critically think about the content our users want from our homepage and give it to them in a way that is easy to use, fast to access, and fun to interact with. But don’t take my word for it, go see for yourself! Visit codeguard.com on your mobile device of choice and make sure to let us know what you think!