2

Back story

I am working on a monitoring view of a network management system. The system allows the user to deploy a network object in a client environment. Once done, this monitoring view shows the current state of the objects starting from "creating" network resources for that object deployment.

The different states we have are: Creating, Created, Deploying, Running, Sub-optimal, Error, Deleting and Deleted

The monitoring view consumes data from two different systems(using individual APIs) switching from one system to another based on the current state of the network object.

Let's say system A(sA) gives states Creating, Created, Deploying, Deleting and Deleted. and system B(sB) gives Running, Sub-optimal and Error.

A few of these are stable states and a few are transient states between stable states. The above states are represented clearly with color codes, labels, and timestamps.

The issue:

When the UI moves from consuming states from sA to sB, there may be a delay in connecting to sB. In this gap what is the best way to show the transience.

We can not show the state Deploying as the network object can also fail deployment and had gone to Error state. But this state is given only by sB.

The Question:

Is it okay/correct, to include states for such delays such as "Fetching status.." or "loading status.." or something similar while the UI is moving from sA to sB? [note that we do not need or want the user to know that there are two separate systems where the status are being consumed from.]

or

just leave it as it is?

// Update //

This is what we have right now, all the available status(in the order of their occurrence) and how they are represented. Now I need to introduce a state(or do i even need to ?) which is shown when there is a lag between changing, fetching the next status (PS: from another system or even the same system)

enter image description here

  • 1
    Isn't "Fetching status.." telling users that there might be two separate systems? – Alvaro Mar 13 '17 at 11:50
  • 1
    Is it? We are only saying "Fetching status.." not from which system or so.. – Ahmed Baig Mar 14 '17 at 6:23
  • 1
    The spinner with "Updating..." seems to be OK (it doesn't imply it's having to talk elsewhere for the update), although as Anthony's answer says, you probably should only show this if the update takes more than a brief time (see also my answer to a different question). If the update fails, then show an Error state. – TripeHound Jun 12 '17 at 15:23
0

I'm assuming that when the system is first loaded, the status is instantly shown?

If not, do you have a way to show that the status is being fetched when the person first sees the screen where the status is shown?

I would recommend something as simple as a spinner, to show the user that something is being done to change the status.

This depends on how long it takes to change the status, though. If there's a 0.2 second delay between showing a status from "sA" and showing one from "sB", there's probably not much need for one.

But if the delay is 5 seconds, for example, showing something as simple as a spinner reassures the person that something is happening and that they should wait.

0

When the status of an entity progresses from Created to the end of life cycle, its very important to display the actual status.

"Fetching Status" | "Loading Status"

Having a buffer status will prevent unintended actions/decisions on entities by users based on Statuses.

  • So how do you then represent if there is a situation when the status of one object among many is not available due to any sort of a disconnect or delay. – Ahmed Baig Mar 13 '17 at 13:26
  • I could see that there are some statuses with a loader, aren't they already serving the purpose ? – D K Mar 14 '17 at 6:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.