Announcing the Loupe Platform

To address the user experience problems we discussed in our last post - Incremental Changes Only Take You So far - we sat down with our friends at Rocketmakers who help us with our user experience and stepped back to start from scratch. We laid out our key user personas and what they want to accomplish with Loupe on a whiteboard:

Transcribing so you can read it more easily, we came up with:

• Operations: Monitor many application environments & do triage of problems.
• Product Manager:
  • Look at events to find defects (issues) and assign to team.
  • If shipping applications, want ot monitor usage (version, adoption, users)
  • Know how my apps are doing in Production & QA
• Tech Lead:
  • Look at events to find defects (Issues)
  • Diagnose events & alerts to resolve
  • Diagnose alerts for my apps in Production & QA
• Developer:
  • Diagnose Issues assigned to me to resolve.

From this we saw that these individual goals broke into three areas:

• View: Users want to navigate through the raw data Loupe captures, namely sessions. They know what they’re looking for and don’t want anything to obfuscate their view of the data. This is pretty much what Loupe Desktop does.
• Resolve: Finding, triaging, and tracking runtime errors with applications. This error management has been in Loupe Web UI and is focused on improving quality across releases.
• Analyze: Dig through data for larger patterns - who is using the application, what versions are in use, application adoption metrics and other information to guide software development.

All of these still run off the underlying data provided by integrating the Loupe Agent. That means as a developer you integrate with the Loupe Platform and then take advantage of the features you want when you’re ready for them.

Loupe View

View is the most direct equivalent to Loupe Desktop, our Windows client. It is designed to directly expose the core data of the Loupe platform without redaction or aggregation. In essence it delivers on the mission of being a great centralized logging system. It’s simple, direct, and fast.

Incorporating an improved version of our web Log Viewer you can quickly browse the list of sessions, find one you’re interested in, and read through its log.

For this first iteration of Loupe View we’ve leveraged telemetry from Loupe Desktop users to identify the main ways they drill in to identify a session and replicated those paths for the web. During our beta we’re keen for feedback to ensure we’ve met or exceeded the usability of Desktop for this purpose - the downside of relying on telemetry is that it only includes the opinions of those who opt into our CEIP. To try to match the performance of Loupe Desktop (which only works over the last 25,000 sessions or so) we’ve employed a different, more web-native approach to presentation and filtering that we’re keen to prove out.

Loupe Resolve

The functionality previously under the Issues area underneath each application, along with most of the top-level dashboards (with significant revisions) is now under the Resolve module. When you want to track runtime errors and make sure they’re fixed for good, you want Loupe Resolve. Narrowing the focus has let us improve the top-level dashboards because they don’t have to serve multiple user perspectives.

We know from telemetry that approximately 55% of Loupe repositories never take advantage of our error management, and for those that do they only care about it for around half their applications. With this new release we’re making Loupe Resolve opt in. This means it won’t analyze data for all sessions that arrive, just the sessions where you care to track runtime errors and fix them. Lets face it - while every application deserves some diagnostic logging there are a number where you don’t care to track down each error because it doesn’t matter. Eliminating this analysis reduces the operational load of Loupe for larger customers (and our SaaS platform), reduces database size, and improves performance for when it counts.

We’ve also made Resolve more selective: just because a session arrives at your server doesn’t mean it’s worth analyzing. You can setup a filter rule to only analyze data for an application if it’s on the latest major version, or only for release versions (not development ones). The whole goal is to ensure that if we’ve dug through your data and found an error, it’s worth your time to look into it.

Loupe Analyze

Loupe knows a lot about how your application is being used in the field - who the major users are, what versions they’re running, what platforms they’re running on, etc. These characteristics are important when trying to make product roadmap decisions. What if you ended support for a particular version? Dropped support for Windows 7? Should you optimize for High DPI? How broadly is your latest version being adopted, or are organizations holding out on an older version?

Loupe has had views to help make these decisions under the Usage area under each application but our telemetry has shown few users find it. Making it a top-level module makes it easier to find when you want to analyze usage patterns. It also gives us a lot more freedom in how the information is presented because we know if you are in this area that’s what you’re interested in.

Like Loupe Resolve, Analyze will be opt-in: By default we won’t be doing the extra aggregation work for applications so you can chose if it’s worth having this information available or not. You will want to turn it on for your main applications and likely never enable it for small utilities and other secondary applications where you don’t need input to make the right decisions.

We’ve been surprised at what feature requests we haven’t gotten that would fit in this area. By making it a first class citizen in Loupe we’re hoping to surface those great ideas from our user community and give them the attention they deserve.

Where the Names Come From

Once we recognized the power of modularization we needed a name for each module. We looked around at several products with complicated navigation needs and caught a pattern emerging from the best. Looking carefully at what they do we saw they chose action verbs related to what you the user want to accomplish with the module. We think this is key: The names aren’t about a taxonomy of the data (e.g. Sessions, Events, Issues) but instead what you want to achieve.

We threw around a number of possibilities but I like what we settled on. It’s an approach that we know we can grow when we develop additional functionality and we’re hoping it’s intuitive for both new and veteran users of Loupe.

If you look at our main marketing site you’ll see we’ve split our messaging into each of these areas with the module naming being prominent to help users identify the content they’re interested based on the problem they think they’re solving.