5

I have an interface showing requests being sent to an external server, they are visualized in a table. There are configurable rules that determines how many retries the request is allowed to do before it expires. So, when they hit the maximum number of retries, the request is expired. But how should I count the retries? Do I visualize how many retries has been started or how many retries has been completed? i.e.:

A request is sent with 0 retries (of a maximum of 5), it hits a rule and will start over. So, now it is going on to the first retry i.e. 1/5... But, this also means that when it hits the rule the fifth time, it will say "Retried request: 5/5 retries". Would you assume it should be Expired at that time? Or would you assume it is on the last retry and if it wont work THEN it will be expired.

Or should I count the the number of retries it has completed and not the number of retries it has started? That would make it say: "Retried request 4/5 retries" and later on: "Expired request: 5/5 retries"

I tried to make myself as clear as possible, otherwise please ask questions :)

2
  • 3
    Especially if the maximum number of retries may vary, I'd be tempted to go with "Successful" or "Failed: 3 retries left" -- the idea being that the number of attempts left is more significant than the maximum originally allowed, and that it's (slightly) easier to spot when this hits zero than to realise that "5 of 5" means it won't try again. (This is what we did with some fax-software I wrote many years ago).
    – TripeHound
    Aug 22, 2016 at 13:03
  • Feel free to include a small screenshot as well of the interface to help us better understand the context. Jun 18, 2017 at 22:00

7 Answers 7

1
  1. The user might initially not need to know about having 5 attempts left. It's up to you to decide that based on the context
  2. I suggest writing out all the states of the label so that you can see the transition a user is going through. For instance this might work:
    • Attempt failed, 4 left
    • Attempt failed, 3 left
    • Attempt failed, 2 left
    • Attempt failed, last attempt!
    • Your last attempt failed. In order to try again .....
  3. Make sure to include what happens when they are out of attempts and provide a possible path forward
0

I think you have answered your own question. A request has a beginning and an end.

That end can either be successful or not. If something is successful then no one really cares, i.e. the job is done :-)

It is only of interest to the user if something has not worked, so in your case the end is not what you are expecting, so count that as one attempt.

If you have 5 failed attempts you now time out and it is very important that this is communicated to the user, e.g. "Request failed 5 times and has now timed out."

0

If it is status information for an ongoing process, it should be worded in present tense. Also, most time is spent waiting for the response to the request, and not between the failed request and the next retry.

"Sending", "Retrying (1/5 retries)", ... "Retrying (5/5 retries)" with a grand finale of "Failed (5/5 retries)" after the final attempt timed out or failed in some other way.

If your users like to know what's going on, showing the reason for the previous failure is also an option.

0

Show the remaining retry count and this acts like a Heuristic and you simplify the cognitive load of making a decision. That way the user will never get confused and at the last he would be left with 0 retries.

0

In my opinion this is getting confusing with no need, because of the wording.

Instead of saying "you have one opportunity to send and X retries", put it simpler "you have Y opportunities to send it".

Like the PIN number does in some phones where there are only 3 attempts. When you miss the first one a message appears that says: you only have two more attempts left.

In the last attempt instead of saying one more, to avoid any confusion it could say: this is your last attempt.

0

Try to understand user's mental model. Trying is in user's hand, success is not.

There are three cases,

  1. An attempt is made and it is successful, it is counted on success
  2. An attempt is made and it has failed, it is counted on receipt of failure.
  3. An attempt is made and it has hit timeout, the point of timeout is considered.

That is why timeout is important. Also, until there is some response or timeout, the request is in a transient stage. You do inform the user that it is in a transient state and not complete. You can give something like Retrying...

Having said that, it would be great to look at how a simple ping window works for windows. There is a clear indication what happened with each request. While the request is underway, the there is a way of telling the user by blinking the cursor that something is happening in the background.

You can take a queue from this, and show the completed/transient stages in your application.

enter image description here

0

I would not show the 'retries' wording until the first request fails. After that first failure, similar to what others have mentioned, I would show '5 attempts remaining' and count down.

1
  • Great! Do you have any reference or proof supporting your answer? Nov 10, 2017 at 7:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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