Mind Your Own Busyness with Telerik BusyIndicator for WinUI

Get familiar with busy indicators, especially the RadBusyIndicator—a crucial member of the Telerik UI for WinUI Suite. Plus, learn how to create custom AnimationStyles for it.

I have just finished reading a blog post on reasons why you should stop using loading spinners. I even attended such lectures led by UI and UX gurus. The truth is that a loading spinner is still one of the most-used indicators in UI design that your app is not asleep but still working. Otherwise, why would the latest (and most modern!) native UI platform of Windows (i.e., WinUI) contain such control at all?

Even the blog post that I mentioned had an example of recommended alternative containing a spinner itself! I am telling you—I was ready to judge from the second I saw that, but the next sentence after the sample made me think … and in depth. Yes, today’s best practices suggest using a Skeleton UI, yet just like the mentioned example, they are also combined with a busy indicator or some other effect that resembles it.

Since we cleared up that a busy/loading/progress indicator is still a thing nowadays and the UI platform that arises the greatest interest is WinUI, could you have guessed what we will be talking about in this blog? If you have not read the title, of course. 😂

Today, we will be talking about the advantages of a busy indicator—a special kind called RadBusyIndicator (for WinUI)—plus related good practices and animations.

Why Use a Busy Indicator at All?

A paper from Jakob Nielsen in 1993 cites the three main reasons for providing loading indicators for users. Number one, they reassure the user that the program or product has not crashed but is just working on something—loading data, resolving a problem, etc. Second, loading indicators coupled with a type of progress bar indicate approximately how long the expected wait time is. And finally, they provide something for the user to look at, other than a blank screen.

There are times when an app just is not able to comply with the guidelines for speed. Of course, an instant response is the best. But sometimes, for the good things (or features) in life (or app), you simply have to wait.

Yet, there is one important thing that is intentionally started at a new line in my blog—you should always try to make the wait more pleasant if you cannot shorten the line.

In the scope of software solutions, the visibility of system status is one of the most important rules of UI/UX design. The goal behind it is obvious—minimizing user tension. Therefore, timely feedback should be provided about what is happening with the app. Users do not have to be kept guessing what is happening. What is one of the most common forms of such feedback? Right—a loading indicator.

Which Busy Indicator to Use for My WinUI App?

Like I mentioned earlier, the good things in life and apps are worth waiting for. In this train of thought—have you heard about our Telerik UI for WinUI RadBusyIndicator? If the answer is yes but you were busy lately and have not tried it out yet, shame on you! Kidding, of course—we are about to try it out together.

Let me introduce it to you in bits. Here is all you need to know.

The RadBusyIndicator is displayed on the UI thread. If this thread is blocked, the control will not be shown. It is meant to indicate to the user that there is a long-running background task/process by allowing you to display an animation while the asynchronous operation is completed.

The control comes with a bunch of predefined animations that can be easily set. To fine-tune its behavior, you can use any of the following properties, which I believe, are self-explanatory—Content, ContentTemplate, ContentPosition, IsActive, AnimationStyle (nine built-in types here), IndicatorAnimationStyle.

Oh, you can access the RadBusyIndicator control through an alias pointing to the Telerik.UI.Xaml.Controls.Primitives namespace:

xmlns:primitives="using:Telerik.UI.Xaml.Controls.Primitives"

What Makes a Loading Indicator Good?

Good loading indicators always give some type of immediate feedback. They notify users that the app needs more time to process the user action and, if possible, predict (approximately) how much time it will take. They have two main advantages:

• Reducing user uncertainty (the app reassures users that it is still working)
• Offering a reason to wait and reduce users’ perception of time (the app makes users pay less attention to the wait itself by distracting them—in a good way, of course)

Last, but not least, and not accidentally off this list, a good indicator should always come with a good animation. To ensure that your users do not get bored while waiting for something to happen, you should give them some distraction, and give it to them right (or don’t give it to them at all 🎶).

Nice animations can distract your visitors and make them ignore long loading times. This is where the real deal of the blog post begins. Let us head out to the next section where we will learn how to create a custom animation for the RadBusyIndicator.

How to Make a CustomAnimation for the RadBusyIndicator for WinUI?

Besides the out-of-the-box animations, our busy indicator for WinUI supports creating your own animations and integrating them with it. To do so, you need to create a style that targets the BusyIndicatorAnimation type and define a ControlTemplate that contains the animation. You can then set the already-defined style to the IndicatorAnimationStyle property exposed by the RadBusyIndicator.

After Googling for some loading indicator designs, I made the one that appeared a lot the object of the following demo. I will keep it a surprise for now. Ready? Start!

My cheat sheet in the process will be the Custom Animations article of the control. 🤫

As stated there, the RadBusyIndicator hosts its animation in a control which is part of its ControlTemplate. So, to apply a custom animation, we will need to define a style for this control and set a new ControlTemplate containing the custom visuals that will be animated. Two requirements that we will need to meet: give the root element of the new template a special name—“PART_LayoutRoot”; and define the storyboard that will take care of the animation and name it “PART_Animation”.

I will begin with creating the elements of the custom animation—drawing the paths of my indicator, the RotateTransform associated to it and the Storyboard which will control the angles during the animation of this rotate transform.

As you can see, I extracted the style to the Page’s resources—it is better and tidier in my opinion. You can do it as well in the Application’s resources, or in the scope of the RadBusyIndicator’s instance.

Good news! The hard part is already done. And now the easier: defining our loading indicator and integrating the animation with it. Guess what—it is a single line of code:

Oh, my! Where are the good practices that I wrote about above? I should put some content to my loading indicator, and why not something more than just a string:

And since I cherish your willingness to spare some time and read my blog, I want to give this sample a little more of Me. I will add a button that changes the theme so that we can see our animation with the dark theme as well. Here is the full XAML and the result of our little experiment:

Why is it spinning so fast? Because I made it to, and because I can’t wait for the summer to come. 😎 And how did I manage to make the spinning sun yellow while the app is still running—through the system’s theme-related settings.

Bonus Section—Loading Indicator General Good Practices

If you are wondering when, how and what type of a loading indicator you should use, read on. If not, head out to the next section.

A busy indicator should be used for any action that takes longer than about 1.0 second. After a few seconds, the user’s attention begins to wander, and they may eventually wander away from your app.

There are two main types of indicators: indeterminate, offering looped animation, and determinate, which often use a percent-done animation. The one you choose depends primarily on how long the process will take. Of course, there could be combinations of both types of indicators.

Looped Animation

Looped animation indicators should be used only for fast actions—this type does not give any information about how long the user will have to wait. They are recommended for actions that take between 2-10 seconds. For anything that takes less than 1 second to load, it is distracting to use a looped animation, because users cannot keep up with what happened and might feel anxious about whatever flashed on the screen.

For this type, it can also be helpful to add additional clarity for the user by including text that explains why the user is waiting (e.g., “Loading comments…”).

From a development perspective, it can be tempting to use looped-animation progress indicators for all types of delays, including long ones, exactly because it does not require estimating the duration of the action.

However, for actions that take longer than 10 seconds, a Percent-done animation should be used.

Percent-done Animation

Percent-done loading indicators are the most informative type of wait-animation feedback. They show the current progress, how much has already been accomplished and how much is left. They deliver important information about (approximately) how long the wait time is. This information gives users control (that is, they can decide whether to wait or not); it decreases uncertainty about the length of the process and may reduce the perceived wait time.

A percent-done indicator may be used for actions that take less than 10 seconds if the action involves processing a series of documents or registries, because the user understands that the system is working with a set number of records. As with looped-animation indicators, it is good to include a text explanation of the process—for example, “Updating document 3 of 50.”

A percent-done indicator makes users develop an expectation for how fast the action is being processed. As a result, changes in speed will be noticed and will impact user satisfaction: If the progress moves quickly only to hang on the last percentage remaining, the user will become frustrated and the benefits of showing progress will be negated.

All Together

David Allen once said, “You can do anything, but you cannot do everything.” 😵 Therefore, it is recommended to always aim to set your efforts on what is most important and not let yourself feel discouraged about not take the chances, e.g., to:

Try out Telerik UI for WinUI

Another thing that is crucial is the understanding of mutuality. When an effort is mutual—in our case, from both our side and yours—it is always guaranteed to lead to the best possible results for both sides. You know we will not tire from encouraging you to share your feedback and help us shape the future of Telerik UI for WinUI together, right? Suggest or recommend anything that is important to you—your input will be a great factor in the future components and APIs of the roadmap.

You are more than welcome to:

• Get in touch by email – Drop us a line, for anything related to product or just to say hi at TelerikWinUI@progress.com
• Visit the Feedback Portal – Share any feature request (or bug report) that you might have
• Head to Telerik Forums – Receive any technical help with the product

In case you missed it, here are some of the updates from the R1 2021 release. Aaand last, but not least, stay strong and healthy and mind your own busyness (and business of course! 🤓).