4 deleted 118 characters in body
source | link

Unless the load times are extreme, use the first method because it gives the user feedback on the operation when it's complete. Besides, the second method raises some usability questions such as reconciling the output with the fact that the user could be moving all around the page and opening up different output windows/widgets. Also, by going asynch, the user might disregard the operation as unimportant.

Asynchronous interaction is great if the user can see the results of the different interactions independently, otherwise one interaction can mask another. For instance, in a dashboard situation where each request goes to a different widget and is processed in parallel, asynchronous interactions are fine. Some interactions can take longer than others, but the ones that are ready are displayed and the widgets that are loading will show a progress animation.

Here's an example:

mockupmockup

download bmml sourcedownload bmml source – Wireframes created with Balsamiq Mockups

If you want to adopt a similar UI for your situation, then the 2nd technique can work for you.

Unless the load times are extreme, use the first method because it gives the user feedback on the operation when it's complete. Besides, the second method raises some usability questions such as reconciling the output with the fact that the user could be moving all around the page and opening up different output windows/widgets. Also, by going asynch, the user might disregard the operation as unimportant.

Asynchronous interaction is great if the user can see the results of the different interactions independently, otherwise one interaction can mask another. For instance, in a dashboard situation where each request goes to a different widget and is processed in parallel, asynchronous interactions are fine. Some interactions can take longer than others, but the ones that are ready are displayed and the widgets that are loading will show a progress animation.

Here's an example:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

If you want to adopt a similar UI for your situation, then the 2nd technique can work for you.

Unless the load times are extreme, use the first method because it gives the user feedback on the operation when it's complete. Besides, the second method raises some usability questions such as reconciling the output with the fact that the user could be moving all around the page and opening up different output windows/widgets. Also, by going asynch, the user might disregard the operation as unimportant.

Asynchronous interaction is great if the user can see the results of the different interactions independently, otherwise one interaction can mask another. For instance, in a dashboard situation where each request goes to a different widget and is processed in parallel, asynchronous interactions are fine. Some interactions can take longer than others, but the ones that are ready are displayed and the widgets that are loading will show a progress animation.

Here's an example:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

If you want to adopt a similar UI for your situation, then the 2nd technique can work for you.

3 deleted 118 characters in body
source | link

Unless the load times are extreme, use the first method because it gives the user feedback on the operation when it's complete. Besides, the second method raises some usability questions such as reconciling the output with the fact that the user could be moving all around the page and opening up different output windows/widgets. Also, by going asynch, the user might disregard the operation as unimportant.

Asynchronous interaction can beis great if the user can see the results of the different interactions independently, but it doesn't seem to buy much in your case since your load times are quick and your UI seems like "linear". Asynchronousotherwise one interaction makes more sensecan mask another. For instance, in scenariosa dashboard situation where there areeach request goes to a series of operations that can rundifferent widget and is processed in parallel and whose outputs go to different widgets (think of a dashboard). These widgets, asynchronous interactions are updated as the data becomes available and and you have a natural compromise with variable load timesfine. If you are considering modifying your UI so it's more dashboard-like Some interactions can take longer than others, thenbut the 2nd method makes more senseones that are ready are displayed and the widgets that are loading will show a progress animation.

Here's a mockup. I just used a combo box to make its connection to the widgets obvious, you can obviously use any UI that suits youan example:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

If you want to adopt a similar UI for your situation, then the 2nd technique can work for you.

Unless the load times are extreme, use the first method because it gives the user feedback on the operation when it's complete. Besides, the second method raises some usability questions such as reconciling the output with the fact that the user could be moving all around the page and opening up different output windows/widgets. Also, by going asynch, the user might disregard the operation as unimportant.

Asynchronous interaction can be great, but it doesn't seem to buy much in your case since your load times are quick and your UI seems like "linear". Asynchronous interaction makes more sense in scenarios where there are a series of operations that can run in parallel and whose outputs go to different widgets (think of a dashboard). These widgets are updated as the data becomes available and and you have a natural compromise with variable load times. If you are considering modifying your UI so it's more dashboard-like, then the 2nd method makes more sense.

Here's a mockup. I just used a combo box to make its connection to the widgets obvious, you can obviously use any UI that suits you:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Unless the load times are extreme, use the first method because it gives the user feedback on the operation when it's complete. Besides, the second method raises some usability questions such as reconciling the output with the fact that the user could be moving all around the page and opening up different output windows/widgets. Also, by going asynch, the user might disregard the operation as unimportant.

Asynchronous interaction is great if the user can see the results of the different interactions independently, otherwise one interaction can mask another. For instance, in a dashboard situation where each request goes to a different widget and is processed in parallel, asynchronous interactions are fine. Some interactions can take longer than others, but the ones that are ready are displayed and the widgets that are loading will show a progress animation.

Here's an example:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

If you want to adopt a similar UI for your situation, then the 2nd technique can work for you.

2 added 256 characters in body
source | link

Unless the load times are extreme, I recommenduse the first method because it gives the user feedback on the operation when it's complete. Besides, the second method raises some usability questions. How does such as reconciling the user know whenoutput with the data is loaded? Iffact that the user is interacting withcould be moving all around the page while the load isand opening up different output windows/widgets. Also, by going onasynch, then s/hethe user might forget aboutdisregard the load, or think it wasoperation as unimportant anyway.  

Asynchronous interaction can be great, but it doesn't seem to buy much in your case. You said since your load times are quick and your UI seems to belike "linear". Asynchronous interaction makes more sense in scenarios where there are a series of operations that can run in parallel and whose outputs go to different areaswidgets (think of a dashboard). Then, These widgets are updated as the data becomes available and and you have a natural compromise with variable load times. If you are considering modifying your UI so it's more dashboard-like, then the 2nd method makes more sense.

Here's a mockup. I just used a combo box to make its connection to the widgets obvious, you can obviously use any UI that suits you:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Unless the load times are extreme, I recommend the first method because it gives the user feedback on the operation. Besides, the second method raises some usability questions. How does the user know when the data is loaded? If the user is interacting with the page while the load is going on, then s/he might forget about the load, or think it was unimportant anyway.  

Asynchronous interaction can be great, but it doesn't seem to buy much in your case. You said your load times are quick and your UI seems to be "linear". Asynchronous interaction makes more sense in scenarios where there are a series of operations that can run in parallel and whose outputs go to different areas (think of a dashboard). Then, widgets are updated as the data becomes available and and you have a natural compromise with variable load times. If you are considering modifying your UI so it's more dashboard-like, then the 2nd method makes more sense.

Unless the load times are extreme, use the first method because it gives the user feedback on the operation when it's complete. Besides, the second method raises some usability questions such as reconciling the output with the fact that the user could be moving all around the page and opening up different output windows/widgets. Also, by going asynch, the user might disregard the operation as unimportant.

Asynchronous interaction can be great, but it doesn't seem to buy much in your case since your load times are quick and your UI seems like "linear". Asynchronous interaction makes more sense in scenarios where there are a series of operations that can run in parallel and whose outputs go to different widgets (think of a dashboard). These widgets are updated as the data becomes available and and you have a natural compromise with variable load times. If you are considering modifying your UI so it's more dashboard-like, then the 2nd method makes more sense.

Here's a mockup. I just used a combo box to make its connection to the widgets obvious, you can obviously use any UI that suits you:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

1
source | link