Maintaining Better Desktop Apps With Centralized Logging
So you have a desktop application that’s beginning to feel a bit outdated. But the desktop isn’t the real problem; it’s managing the application once it’s released that causes trouble. With a web application, you only have to worry about one version at a time, running in a single environment (whether that’s a server, group of containers, etc.). When something does go wrong, you can often access the servers running your program if you need a closer look (even if it’s annoying to do).
With desktop applications, you have to keep track of more variables:
the OS/specs of the user’s computer, whether they have updated their software, and more.
And you need to know all of this about software running on individual computers that you can’t access easily.
Luckily there is a solution: a centralized logging system. By putting your logs online, you can improve the quality of your software and your users’ experiences.
Wait, Aren’t Desktop Applications Dying?
When reviewing the features coming in .NET 6 (which we will be writing quite a bit on .NET 6), one item caught my eye: .NET MAUI Blazor apps for the desktop. I’ve seen many examples of a technology or application ported from the desktop to the browser. It’s not every day you see browser-based technology brought to the desktop.
Microsoft has shown they want to keep their desktop application development tools relevant. Just look back at .NET 5. Along with new features to optimize applications running in docker, they brought in two popular desktop development frameworks with WPF and WinForms. Bringing Blazor to the desktop is just another way they continue to broaden the options for desktop developers.
If that’s not enough, just look at any app store. Count how many of those applications started as web services. Netflix, Spotify, YouTube, pretty much any social media or e-commerce service has a dedicated native client for phones, and many have desktop equivalents as well. If every application would optimally be a web service, why would these versions exist? A lot of people like having a dedicated application instead of a browser tab. And many dev teams like making applications that can access the whole device, not just a piece of it.
So, instead of counting desktop applications out, consider that they are here to stay for a while. It’s not the platform that needs to update; it’s the tools you use to support the platform.
How Centralized Logging Helps Desktop Application Development
The ways that centralized logging helps application developers are similar for both desktop and web applications. But for desktop application development specifically, the advantage centralized logging has is that the alternatives are worse. With a web app, you can potentially identify application problems with tracking tools like Hotjar, or access application logs on each server. These solutions are generally not as efficient as centralized logging, but usable in a pinch.
The tracking tools available for desktop applications are more limited, and accessing logs can be tricky if the application runs in multiple locations globally. You may need to remote onto individual user systems or ask a user to email the logs while solving a problem. A significant inconvenience for a user that was already frustrated in the first place.
But besides worse alternatives, there are three ways centralized logging will help you maintain better desktop applications:
1. Know What Happens With Your App in the Wild
List of recent errors for application for review on Loupe Server
Centralized logging ensures your dev team knows what is going on with the application once it leaves their desk. If you are not relying on Centralized Logging to get your production errors, you likely depend on user feedback.
This can get tricky.
Many application users will not contact the developers when they run into an issue,
especially for applications with a free trial, where there is no initial investment put in the first place.
It’s often easier to ignore the problem or move to a different application entirely.
That means when a user does give feedback on a problem they have encountered,
they may have been the 10th user to have the problem.
Or the 100th.
It would be better for the application if the development team knew the first time the problem showed up.
With centralized logging, your developers can see these problems pop up the first time they occur (even better when a centralized logging system is combined with log monitoring). This way, they can begin troubleshooting problems as soon as they occur, fix them sooner, and improve the application for future users.
2. Give Ops and Support the Support they Need
Loupe allows you to browse full application sessions, giving context for what happened before and after an error
When a user does contacts support, the process will go smoother if the team already has access to their log data. For the user, it means they don’t have to root around their directories looking for a log file to email the support staff. For the support staff, it means getting an accurate portrayal of the event that occurred every time.
It can be hard to remember every action you took in an application, especially when things have gone wrong and you’re frustrated. Small details like how many times you clicked a button, which options you chose, etc., can be hard to recall, but essential for the support team to help the user. With a centralized logging system, users don’t need to remember the fine details because the logs can act as the record. That can be a saving grace for the support staff and let them resolve problems faster.
3. Get More than Just Error Data From Your Logs
Screenshot of a graph showing version adoption over time
There’s no rule about using logs only for active troubleshooting. Logs can reveal unexpected user behavior in your application. Regularly viewing the log data helps you learn what parts of the application are most used and what experiences need improvement. In fact, this is a way we use our own logs. Earlier this year, analyzing our own Loupe Server log data revealed a problem with our user trial experience that we wouldn’t have been able to pin down otherwise. It wasn’t a dramatic error that helped us solve the problem, but viewing user navigation patterns found in our information logs.
Logs can also include extra data like the user’s operating system, device specs, etc., that can help you decide what platforms to target for your application. And with some logging systems, you can track the version number of your application. This lets you see the adoption rate of your newest releases and see if your new release reduce or increase problems with your application. This information helps you determine the quality of your software and figure out what features to prioritize for the next release.
Modernize How You Develop Desktop Applications
Desktop application development is here to stay, but the expectations from users and developers alike are changing. With the rise of remote working options, users may use a desktop application on the PC in their office or laptop at home. And the same situation may apply to you. You may not be in the office every day to grab the logs from a user’s PC, and remoting to personal laptops or asking for log emails will get old.
It’s a critical time to consider tools that allow us to be more mobile. And just because you create desktop applications doesn’t mean you can’t use web-based software to make the job easier. If you are developing applications with .NET or Java, you can try out Loupe Server. It’s our Centralized Logging SaaS for viewing and analyzing all your log data from every application you make. You can learn more about our free trial in the link below.