Avoid client timeout on WebAPI call

If a WebAPI service takes a long time to complete, the caller, the client side, may timeout waiting for a response. There are several options to solve this issue, you can increase the timeout limit on the client side and web server side, or use a more persistent connection method like WebSocket and SignalR.

Here I propose a different way to avoid the timeout issue that allows the clients side to proactively check the result instead of passively waiting. The idea is pretty intuitive – since the client side times out on waiting for a response, why don’t just disconnect and check back the result later? So the solution is to disconnect with the client side as soon as the request is received and a WebAPI service is provided to enable client to check for the status of the processing. This way the client does not need to keep the connection open until the processing completes or times out. It can simply calls back every 5 seconds to check the result of the processing.

Here I am going to provide some sample code on how to achieve this. First, we create a Task class

public class Task
{
   public string TaskID;
   public Request Request;
   public Status Status;
   public Result Result;

   public void Execute(){
   // Do all sort of calculation and processing here
   // When done, sets the Status of the task to Finished.
   }
}

We then create a class to store tasks and to handle creation, retrieval, and deletion of tasks.

public class TaskManager
{
   private static List<Task> _TaskList = new List<Task>();
   // Create a new instance of Task object
   // and start a new thread to run this task
   public static Result CreateNewTask(Request request){
      var task = New Task(){
                TaskID =  System.Guid.NewGuid().ToString();
                .....
                };
      _TaskList.add(task);
      Thread thread = new Thread(task.Execute);
      task.Status = Status.Processing
      thread.start;
   }
   // This is also useful for purging tasks
   public static void RemoveTask(string taskID)
   public static Task GetTaskByID(string taskID)
}

Up to this point, we have our ‘backend’ built. Now we are going to create a WebAPI method to accept the request from the client side and a method for client side to check a task’s status:

[HttpPost]
public Result ProcessRequest(Request request){
// Submit a request which will be created as a task
// Return the TaskID back to client
}

[HttpGet]
public Result CheckStatus(String taskID){
// Call this every few seconds to check result
}

In this post I shared an idea to avoid client side timeout when calling WebAPI. We chose an approach that enables client side to check the result actively. Although it makes the client side a bit more complex, it is a reliable way to handle WebAPI calls that run a long time and also provides much more flexibility to the client side.

Design error message

Displaying error message is one of the most basic functions of an application, but can also be easily overlooked because we are often focused on the core functions of the application. There are numbers of ways to present the error messages, but in my opinion there are basically 3 objectives we want to achieve with error message and as long as the design can fulfill those, it is a decent one.

Objectives of error message

The 3 objectives of error message are to make it easier for the users to:

  1.  Know there is an error
  2.  Know what is having error
  3.  Know how to correct the error

In my past projects, form page and listing page are 2 most common pages that display error messages. I will share some ideas on each of them below.

Error message on form page

On a form page, I have pretty much used the following 3 ways to represent error messages:

Error message on top or bottom

Good for a simple form. For example, login page.

2-18-2015 12-33-30 PM

Error message next to a field

Useful to help users to find the fields that need to be corrected, but if the correction instruction is long, page’s layout will suffer.

2-18-2015 12-33-40 PM

Error messages all displayed in a single block on top

Useful when instruction for correction is so long that putting it within the form will break the layout. Combined with highlighting the problematic fields can help users find the fields quickly and view all instructions in one place.

2-18-2015 12-33-48 PM

I feel these 3 ways are sufficient to cover all scenarios. I can just pick one of them based on the actual situation.

Error message on listing page

Listing page is a page that contains a list of records. This page type is different than a form page because the page is often long and each record often has its own action buttons, e.g. edit, delete, which could trigger error message. Because of this, there is one more thing needs to be accounted for – whether we need to maintain the current view of the user.

allows user stay or return to where she was

Consider a page with a very long list of records. When operating on one of the records, an error occurs and the page scrolls to the top or bottom where an error message is displayed. After reading the error, the user will have difficulty to find where the original record is.

2-18-2015 12-35-03 PM

It is a good practice to always consider whether to maintain the user’s current view for it is very likely the user will continue to work on the record or the records next to it after seeing the error. In order to maintain the view of the page, I use an in-page pop-up window to display the error.

2-18-2015 12-35-30 PM

But of course there are other ways. For example, you can add a link in the error message to allow the user to go back to the problematic record.

2-18-2015 12-37-55 PM

There are downsides, however, the pop-up dialog requires the user to click the close button in order to continue, and the ‘link’ approach scrolls the page back and forth. But I will say they are decent designs as they fulfill all 3 objectives of error message.

Listing page does not always require to maintain the view. For example, many listing pages offer action buttons such as a Batch Deletion button. Users can select multiple records and delete them at once. In the case, displaying the error message next to the action button is more common.

2-18-2015 12-38-25 PM

In this post I shared my thoughts on the error message’s objectives, which can be a starting point to develop a good error message design. Also I shared a few designs from my past projects. Hopefully these can inspire and help people on their own projects.

Easily display loading animation with jQuery

Giving users a proper feedback is one of the most important design items toward a good user experience. Showing the user a loading animation such as a loader or spinner after a request is submitted is something we see quite often. So how to add a loading animation to your own web site? Hopefully the following tutorial can give you a jump start.

First, find a loading animation that suits your need. This Ajax loading GIF generator is a good option to find a decent GIF image. Or you could go for a pure JS and CSS loading animation like the ones in the Collection by Tim Holman.

Then put the animation on the same page where you want to show it and hide it.

Lastly, use the following codes that show the animation whenever an ajax call has been initiated and hide it when finished.


$(document).ajaxStart(function () {
 $YourLoadingAnimation.show();
 }).ajaxStop(function () {
 $YourLoadingAnimation.hide();
 });

References:

jQuery API – ajaxStop

jQuery API – ajaxStart