Not sure what accessibility changes will have the most benefit to your existing software? Are you in the build process and need to make sure accessibility has been appropriately considered? Use this checklist as a starting point.
A common misconception held by digital product owners is that software development has evolved to the point that you can “build it and leave it”.
This misconception has been bolstered by the rise of software as a service platforms like SquareSpace and Wix that offer effective, simple marketing websites that require little-to-no development support post-launch. However, larger website, web app, and mobile applications are much more complex pieces of technology compared to a basic marketing site, and must be treated as a long-term investment if your organization is to be successful.
That means you can’t just release your product to the world without a plan for continuous support, maintenance and enhancements to the software.
For example, when Apple announced iOS 11, nearly 200,000 apps or 8% of all apps at the time would have become obsolete on launch day. Imagine if you had released your new mobile app just 6 months prior, and didn’t prepare for this type of inevitability from a development or financial perspective. Any user or revenue growth you’ve achieved to that point may have just imploded as you scrambled to fund a major overhaul of your application ahead of iOS 11’s debut.
The reality is that, when you’re planning out a new digital product, you must have a plan in place to keep your application up-to-date. This plan can be thought of as “digital hygiene” for your product.
Let’s explore the concept of digital hygiene, and learn two simple ways to put it into practice.
We’ll use everyone’s favourite as an example: the dentist. When it comes to your teeth, if you forgo brushing and flossing, skip your bi-annual scaling, and throw out that retainer, you’re bound to end up with many more problems, and a lot more work. Work that’s costly, painful, and no fun to deal with.
As your dentist will tell you, great dental hygiene is dependent on having a routine and sticking to it. It prevents major problems. Digital hygiene for your software is exactly the same – if you’re only checking in every 6 months to introduce updates and bug fixes, you might find that parts of your website, web app, or mobile app require major overhauls just to get back to “normal”. We want to avoid that, just like we want to avoid major dental surgery.
So what can you do to support your digital hygiene and avoid trips to your developer’s office for digital surgery? You can get your feet wet with two simple steps:
For complex software like web applications and mobile apps, software versioning is a common (and best) practice. Versioning is how development teams schedule the release of application functionality, improvements, and bug fixes based on the needs and priorities of the product’s users, required effort, development timelines and other factors unique to the build.
Software version release scheduling isn’t an exact science; trying to force a rigid release schedule will just cause more headaches than it will solve. Rather, it’s more important to be proactive about what needs to be adjusted, fixed or added to your software in the short and long-term, and pivot where necessary based on user feedback and the results of application monitoring. To that end, we can use standard version release cycles as a way to understand types of post-launch improvements:
Version 1.2.3 represents a Major Version Release
These are significant changes to functionality or components that require an important update, which may include a major upgrade to the underlying software framework (Java, React Native, etc), or to account for an OS that is no longer supported. Major version releases may also tie in major new feature inclusions or functionality changes that alter the application in a significant way.
Version 1.2.3 Represents a Minor Version Release
Minor Releases include the introduction of new features to your application that will require configuration changes and updates to components. They will require an update procedure, as the new version may introduce changes not compatible with the configuration of older versions.
Version 1.2.3 Represents a Build Release
Build Releases don’t encompass new features or functionality, but are reactive bug fixes or security patches that were uncovered through your software team’s maintenance or flagged by users. These are quick to implement, and will be rolled out as required – usually with appropriately scale-adjusted testing compared to Major and Minor releases.
Software versioning is crucial from a development perspective when it comes to monitoring changes to source code. Your development partner will likely make use of version control software such as git, which is a ‘log’ of all changes made to your application’s source code that can be rolled back at the flip of a switch.
Version control means that your devs have the ability to run back the clock and undo any abnormalities that pop up after the launch of a new version of your application: a best practice known as disaster recovery. So, if Version 1.2.4 of the application outlined above is launched and it is causing issues for users of a certain OS, it can be rolled back until that issue is resolved. Usually these issues are caught during pre-launch testing, but it’s best to not assume that will be the case.
Versioning is still just one aspect of effective, post-initial-launch application hygiene. Monitoring is another. In order to maximize the benefits of version releases, you also need to ensure your product team is monitoring your application. Application monitoring generally takes two forms:
Taken in tandem, these activities will ensure that your digital product team is proactive, not reactive, to indicators of software health. It’s like scheduling regular checkups with your dentist to clear away plaque rather than waiting until your teeth hurt to discover and fill a cavity.
This approach also ensures you’re able to effectively mitigate significant negative impacts to your end users that may arise from normal software issues that may pop up over time. There are dozens of metrics you can monitor for depending on the maturity and scale of your product, but here are a few critical items that should be addressed at the bare minimum.
Uptime monitoring is an automated check for the availability and response time for your application, typically occurring every 1-5 minutes. Uptime is measured in percentages representing the period at which your application is working and available. The industry standard target for uptime is 99.999%. We use Uptime Robot Pro at Paper Leaf.
Latency represents the length of time your application requires to complete an action taken by the user. This response time gives you an overarching view of bottlenecks within your application, and areas of improvement for reducing the amount of time it takes for the app to access resources to complete tasks.
Having high volume for your application is great, but from a scalability and UX perspective, you should be aware of how that volume affects your application’s performance. If you know that there will be significant intervals of high traffic during particular events or dates, such as a short period of door-to-door voter surveying, your maintenance team can ensure that your servers are scaled to meet expected demand spikes. Other tools, such as load balancers, can be implemented beforehand to smooth out performance if your application experiences unexpected demand spikes.
Tracking, logging, and responding to frequently occurring errors experienced by users of your application is critical to good user experience and reducing user churn. Whenever your automated monitoring software pings a failed request, your maintenance team will be notified and have the opportunity to check frequency, severity, and make informed decisions about where to focus their attention on bug fixes. The goal is to start to identify high-risk errors quickly – to the point where issues are resolved before your users even notice them!
CPU and disk usage represents the amount of storage space or available CPU for your application and all associated files on your server. This metric is demonstrated as a percentage of disk space available on your server (i.e. 66% disk usage). As your application’s user base and complexity grows, it’s important to explore options for scaling to avoid slowdown and inefficiencies.
Software versioning and application monitoring are two arrows in your quiver when it comes to successful digital hygiene following your initial launch. In alignment with iterative or agile development principles, these processes help your application maintain optimal performance and allow you to respond quickly to marketplace unknowns, from OS updates and new hardware releases. Further, good digital hygiene avoids costly, huge redevelopment projects – aka digital surgery – while also helping ensuring you’re not losing your equity with your user base.