- The SAP Fiori tools components
- UX Guidelines
- Design Tests
Unfortunately, not everything in our extensions can happen at lightning speed. Sometimes we need to wait for an action to happen. This can be for a number of reasons, perhaps user's internet connection is slow, or we need to wait for the server to send back some information, or it simply takes some time to process things. In any case, we sometimes do need to show Loading indicator for an entire, or just a part of UI.
There are three main cases for loading and waiting.
1a: The entire extension is doing something behind the loader
Either during initial loading, or as the user interacts with the extension, sometimes it could be necessary to block out an entire screen while the extension is loading or waiting for an event. This is done mainly to prevent the user from interacting with the extension until loading is finished and everything is ready to be used, or to prevent the user from manipulating with pieces of extension while some larger actions are still taking place.
In any case, the loader should simply be placed over the active screen, with a clear message what is happening ("Sending data", or "Generating an application" or similar). We should avoid unclear messaging, like "Please wait".
1b: The entire extension is doing something as a separate page
Very much like previous case, this one simply utilises a blank new page to do the same thing, rather than to overlay Loader on top of existing interface. We should try to aim for option a, however, if that is not technically possible (or too costly), we can use option b.
2: A smaller segment of the extension is doing something
The user interface could be broken into segments, and some (or all) of those segments could be running on a separate service/track. For example, we could have multiple tiles representing various functional elements, and each of those tiles could be loading independently. Thus, one of them could be a little bit slow and it takes it some time to load. In that case, Loader should just be applied locally to that tile until it is loaded.
3: A single UI element on screen is doing something
This is usually a button, or an icon (acting like a button) that when pressed has a complex action to perform, so we can show the Loader on that particular single UI element. The element should be disabled as soon it is pressed to avoid various user interaction issues, like double-clicking. If possible, and if needed, we can disable all of the other elements in that form. In the example above, when the button is pressed to submit the form, the button goes into Loading mode, but input fields are also turned into read-only.
Loading messages, and then subsequent error or success messages can happen in multiple places. It all depends on the extension, and what can be technically done.
Single element which is loading should communicate below it what it is doing.
And of course, various full screen Loaders communicate in place right there and then. Furthermore, we can always utilise VS Code native toast messaging to deliver either success or error, or simply informative messages to the user.
All of the loading scenarios should have a certain timeout period, after which the loading simply fails and we inform the user about this. There is no point in keeping the loading indicator spinning forever. Each loader should be able to set appropriate duration before it times out, depending on the complexity of the action. An action that's supposed to be swift should timeout after 5 seconds, as that is plenty of time for supposedly swift action to complete.
Delay to show
Any element that has the Loading functionality should not immediately display the Loading indicator. It should wait 0.3 seconds (300ms) before Loading functionality is shown. This is to prevent visual blitzing in case the action is actually performed quickly (under 300ms). Unless we had this delay in showing Loading functionality what would happen in case the action is performed quickly is that for a split second we would show Loading, and then the action would be over. This causes a jarring user experience and feels more like a bug or a glitch, than a real feature.
In this example, there is a "Loading" message when the user clicks Send Email button. However, as the Loading message appears only briefly (and the email is sent quickly), it looks like a bug.
- No labels