Our goal at CodeGuard is to provide a simple backup and restore service that anyone can use. One of the ways we achieve this is through an effective account dashboard. This helps you see how your account is performing at a high level to help you better manage your CodeGuard backups and restores. Three of the main features of the CodeGuard account dashboard are the issue highlighting, backup success graphs, and Actions menu.
If we’re having trouble connecting to your site for any reason, such as your SFTP password changing or firewall rules on your server blocking our connections, we will let you know by highlighting the line with the website URL or database name that was affected. If the backup issue occurred in the most recent backup, the line will be highlighted in red. If there was a backup issue in the last 7 days, but the most recent backup was successful, it will be highlighted yellow.
Backup Success Graphs
The backup success graphs show the percentage of successful backups over the last 7 days. This tool helps you get an overall snapshot of the health of your backups for all websites and databases on your account. If you experience an issue with one of your backups, the graph will be less than 100%, but it will climb back up to 100% once we’re able to back up your website successfully for a week.
The Actions menu contains all the main functions of your CodeGuard account right at your fingertips. You can quickly access the restore page to kick off an automatic restore when something goes wrong. There is also an option to edit your website or database settings to make updating your connection credentials a snap.
Getting the most out of CodeGuard
With these tools, you will be able to make sure that you are getting the full value of your CodeGuard account. If any issues arise with your backups, you will receive email notifications with additional information and troubleshooting steps. If you need any assistance with getting your backups up and running, our support team is here to help, so let us know what we can do for you.
For our premium plans, we offer a branded portal option. You can add your own logo and even choose a different color scheme than the default CodeGuard Green. Many of our design agencies and hosting partners use this branded portal to make it their own. When their clients log into their CodeGuard account, they see their logo and colors. With the recent updates to the website, we brought this feature up to date as well.
How we did it
Using Sass, we used variables for the colors used in all of our main Sass files. In the color scheme files, we define those variables to be the color specific to that color scheme. When a user has a custom color scheme chosen, we read from that color scheme’s Sass file where the color variable is defined.
How to access this feature
If you are signed up for a premium plan (Ronin or higher), you will have access to this feature in the “Branding” settings. Click the “Settings” dropdown in the top right of your screen and choose “Branding”. Here, you can set up your own branded portal using your own logo, custom subdomain or custom domain, as well as set up your custom portal color scheme.
If you have any questions about setting this up, let us know!
The simplification of life is one of the steps to inner peace. – Peace Pilgrim
One of CodeGuard’s main goals is to simplify the backup and restore process so that anyone could do it. With our website redesign, we aimed for just that. The biggest change we made to the app was to the navigation.
Our top level navigation remains at the top of your screen, but we’ve combined some of the items making it simpler. The website-specific navigation has been moved just below the top level navbar. The less frequently used support and language option items were moved to the bottom of the screen to get them out of your way. We also put the On Demand Backup button right at the top of your screen to make requesting backups that much easier.
It’s all for you
Providing top of the line backups is our bread and butter, but it doesn’t do any good to our customers when they can’t find their way around our site. We are really excited for this change and think that it will help you find your way around our system easily and quickly.
When we began the making changes to our website’s look, we were faced with the question of how to make this transition seamless for our customers. We explored a few different options and ended up choosing one that involved splitting most of our views into two parts. One part contained all the code from our old theme, and the other contained the code from the new theme. Which code is served depends on the color_scheme attribute on the user viewing the page.
What worked well?
One great benefit of this method was that in order to switch between views, all you need to do was change the color scheme attribute on the user you are testing with from the back end. With this method, we were able to test on production without causing any problems for our existing users. Until we were ready to roll this out, no non-admin user had access to the new theme. Rolling the changes out was as simple as running a command to change all users’ color_scheme attributes to the new theme. We were able to do this in batches for a slow rollout until all users were using the new theme.
What was difficult?
We ran into a few instances where changes to the new theme would affect the old theme if the files weren’t properly split into new and old theme sections. It was important to test each change using the new and old themes to make sure that everything was still functional for the existing users. It was a bit more challenging to do code reviews on changes that other teammates made. When adding the new code to the file with the logic for displaying the right part, it made it look like the entire file changed, so using a tool like GitHub’s file comparison tool was unhelpful.
Is this how I should do it?
This was the method that we chose, but there are other methods out there for rolling out a website redesign. Some will create a separate development site to do all their testing and then simply replace the old site files with the new ones when they’re ready to launch. Another way is to slowly make changes to the site and roll them out to production until all changes have been made. Any way you do this will have its own benefits and challenges. I would suggest figuring out your goals for the roll out and weighing the pros and cons of your different options.
Style guides are a best practice for website design. They ensure that all aspects of the website are consistent by making sure that there are no questions on how to style any aspect of your site. This is especially important on websites that have a team of people working on it making sure that everyone is on the same page. This will keep your website from looking like a Picasso painting and more like the Vitruvian Man.
How did you do it?
We implemented our own style guide when the site was first built. During our recent interface changes to our app, we updated and improved our style guide. The CodeGuard style guide consists of a table of contents, a list of components, examples of these components with sample code, and any notes needed about each element. Our development team frequently references this guide anytime changes are being bade or new tools are being added.
Keep it consistent!
Keeping your website consistent is a key to a great user experience and a good looking site. You can make your style guide as simple or complex as you need it, but the more information available on it, the more benefit you will get out of it. For ideas on how to create an awesome style guide, check out these great examples:
The next part in our series of redesign tips and techniques is discussing the prioritization of the changes that you will be making to your website. There are three things to think about when going through the prioritization: Audience, Impact, and Difficulty. Taking these factors into account will help you quickly identify where to begin the actual redesign process.
Audience, Impact, Difficulty
Identifying the audience simply means asking “Who will be looking at this or interacting with this? Will it be all or most of your customers? A subset of customers? Admins only?” Once your audience is identified, what will the impact of this change be? Is it something that is related to the functionality of your product? Is it a page or tool that is used daily? Maybe it’s just a setting that doesn’t get used very often or only by a subset of customers. Lastly, consider the difficulty. How much time and resources will it take to complete this item? Is it something that can be done quickly in an hour, or will it take a week to finish?
How to prioritize
Once you’ve identified the three factors above, you will want to put each item in order of its prioritization level. The first items should be the ones that affect the most customers and have the highest impact and the lowest difficulty. These get you the most bang for your buck, so to say. Where you go from here might depend on your own situation. Below is a chart of how we prioritized our changes based on these factors:
The key to prioritization is to help you get the most important changes completed first. Those with the highest impact on the most customers that can be done the easiest are the best place to start. Creating your own chart like ours above and labeling your changes for the three factors will help tremendously. As new issues arise during the redesign process, having this system in place will keep you on track and let you know if this is something that should be addressed immediately or put off for later on in the project.