We are having a debate here in the office about how to give the user feedback that the app is busy. First of all, most of us are Windows desktop folks and so things like the busy cursor or the startglass cursor come to mind. Some of us don't really care for that as there is an implication from the busy cursor that the app is hung ("Not responding"). The startglass cursor is not available in Silverlight.
The app design is such that we have WCF calls to set/get the ObservableCollection<T> to which the various controls ItemsSource are bound, or the DataContext object to which properties are bound via {Binding Path=..., Mode=...}. As we all know, the results come back asynchronously.
The app's design has a tree on the left and content on the right - the tree on the left is broken into 8 different kinds of objects (8 top-level folders) and then all instances of that type of object beneath the folder.)
We have the following cases:
Case 1 - Application Load
On startup, the tree/menu folder outline is created and 8 WCF calls are made to get the data. The ObservableCollections fill in in some non-deterministic order, but you can see the + signs appear, or if expanded, the actual objects, beneath the tree nodes. Further, if you have the tree node selected, then a summary table view simultaneously fills in.
In this case, as soon as your object is there, you can select it and begin working with it, regardless of the loading order or state of the other objects.
In this case, there is no indication that the app is busy or communicating with the server. Some feel there should be, others do not.
Case 2 - Page refresh
So the summary page mentioned above contains a list with configuration info of all the objects of the type selected in the tree at the left. This is almost always a RadGridView. In a detail mode, you look at a single object which is just a Grid with a bunch of {BInding...} to display data in a form. In both cases, there is a table of events related to the object(s) you are viewing. The objects (or object) and the event are two separate WCF calls. The mouse could be a wait cursor over the entire app (overkill, IMO), or over the individual panels which are refreshing
Case 3 - Modal Dialog / Wizard
Alll configuration changes are done via modal popups/wizards. In this case, the Finish or OK button is grayed out until the WCF callback completes and then the window either goes away (on success) or displays an error (on failure). Given the modality of the dialog and the grayed out button(s), changing the cursor here is of questionable value.
Case 4 - Load-On-Demand
Trees which browse are built using load-on-demand, which uses the animated circular arrow. I think we are all happy with this scenario.
My questions here are what do others do in these situations? If the app can be responsive, I hate to put up a modal "working" (chasing dots, a/k/a loading panels). We could have a discreet version of this at the top right or something and leave the app responsive. Personally I do not care for the wait cursor on the mouse, probably because of the bad taste left in my mouth by unresponsive Windows apps like Visual Studio. I freely admit my bias here ;)
Pointers to best practices, blogs, articles, or personal opinions are all welcome.
Thanks for reading,
Tim
The app design is such that we have WCF calls to set/get the ObservableCollection<T> to which the various controls ItemsSource are bound, or the DataContext object to which properties are bound via {Binding Path=..., Mode=...}. As we all know, the results come back asynchronously.
The app's design has a tree on the left and content on the right - the tree on the left is broken into 8 different kinds of objects (8 top-level folders) and then all instances of that type of object beneath the folder.)
We have the following cases:
Case 1 - Application Load
On startup, the tree/menu folder outline is created and 8 WCF calls are made to get the data. The ObservableCollections fill in in some non-deterministic order, but you can see the + signs appear, or if expanded, the actual objects, beneath the tree nodes. Further, if you have the tree node selected, then a summary table view simultaneously fills in.
In this case, as soon as your object is there, you can select it and begin working with it, regardless of the loading order or state of the other objects.
In this case, there is no indication that the app is busy or communicating with the server. Some feel there should be, others do not.
Case 2 - Page refresh
So the summary page mentioned above contains a list with configuration info of all the objects of the type selected in the tree at the left. This is almost always a RadGridView. In a detail mode, you look at a single object which is just a Grid with a bunch of {BInding...} to display data in a form. In both cases, there is a table of events related to the object(s) you are viewing. The objects (or object) and the event are two separate WCF calls. The mouse could be a wait cursor over the entire app (overkill, IMO), or over the individual panels which are refreshing
Case 3 - Modal Dialog / Wizard
Alll configuration changes are done via modal popups/wizards. In this case, the Finish or OK button is grayed out until the WCF callback completes and then the window either goes away (on success) or displays an error (on failure). Given the modality of the dialog and the grayed out button(s), changing the cursor here is of questionable value.
Case 4 - Load-On-Demand
Trees which browse are built using load-on-demand, which uses the animated circular arrow. I think we are all happy with this scenario.
My questions here are what do others do in these situations? If the app can be responsive, I hate to put up a modal "working" (chasing dots, a/k/a loading panels). We could have a discreet version of this at the top right or something and leave the app responsive. Personally I do not care for the wait cursor on the mouse, probably because of the bad taste left in my mouth by unresponsive Windows apps like Visual Studio. I freely admit my bias here ;)
Pointers to best practices, blogs, articles, or personal opinions are all welcome.
Thanks for reading,
Tim
5 Answers, 1 is accepted
0
Hello Tim,
I think changing the mouse pointer on "busy" or "working in background" is OS (whatever it is) only territory. Showing rotating sand clock cursor on any web application will give the visitor wrong impression of overall system instability. So I think you have to leave cursor changing as an option.
It is better to show loading/busy animation only if it is necessary – when loading or processing actions distract user interaction with the application.
Case 1 - Application Load
If the application is usable at this time, no indication is needed.
Case 2 - Page refresh
It is better to show the indication over the individual panels which are refreshing.
Case 3 - Modal Dialog / Wizard
There are enough indications here that something is going on. No need for changing the cursor.
Case 4 - Load-On-Demand
It’s OK so.
Best wishes,
Valentin Likyov
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
0
Tim
Top achievements
Rank 1
Rank 1
answered on 07 Oct 2009, 02:06 PM
I tend to agree with you, Valentin, although I think when you said So I think you have to leave cursor changing as an option that you meant leave it out.
As general design goal, we use the 2008 MMC or Windows Explorer as the basis for our UI, since the application itself is a Windows administrative app. Windows Explorer does have the "Start Glass" cursor which says "I'm busy, but go ahead and do some things while I load stuff in the background." This is the same paradigm that Silverlight follows, more-or-less, except there is no start glass cursor.
I was really hoping for some comments from other Silverlight application developers... anyone?
Thanks,
Tim
As general design goal, we use the 2008 MMC or Windows Explorer as the basis for our UI, since the application itself is a Windows administrative app. Windows Explorer does have the "Start Glass" cursor which says "I'm busy, but go ahead and do some things while I load stuff in the background." This is the same paradigm that Silverlight follows, more-or-less, except there is no start glass cursor.
I was really hoping for some comments from other Silverlight application developers... anyone?
Thanks,
Tim
0
Hi Tim,
Actually we had an internal discussion here at Telerik about your inquery and the opinion of our designers was that if you are going to use your application in internet you should not use the standard "desktop" experience with the busy cursor, etc. There were two very good examples for a web interfaces. One was the google docs experience where is the concept of update panel - .e.g the whole part of the page that will be updated is replaced with a progress indicator - see "option1.png".
The other was the FaceBook "Links" where the progress indicator is displayed near the button that is doing the action. See attachment "fb1.png".
In general the progress indicators should be used only when needed and if possible should not stop the user to interact with the rest of the application while the update is happening.
Best wishes,
Valentin.Stoychev
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
Actually we had an internal discussion here at Telerik about your inquery and the opinion of our designers was that if you are going to use your application in internet you should not use the standard "desktop" experience with the busy cursor, etc. There were two very good examples for a web interfaces. One was the google docs experience where is the concept of update panel - .e.g the whole part of the page that will be updated is replaced with a progress indicator - see "option1.png".
The other was the FaceBook "Links" where the progress indicator is displayed near the button that is doing the action. See attachment "fb1.png".
In general the progress indicators should be used only when needed and if possible should not stop the user to interact with the rest of the application while the update is happening.
Best wishes,
Valentin.Stoychev
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
0
Tim
Top achievements
Rank 1
Rank 1
answered on 07 Oct 2009, 02:24 PM
Thanks again for the feedback. If it interests you at all, the application is not for general internet usage. It's really a Windows administrator's application, written in Silverlight and browser-hosted primarily for the zero-install benefit (assuming of course you've installed Silverlight.)
I'm still interested in what others have to say...
Tim
I'm still interested in what others have to say...
Tim
0
Eliza Sahoo
Top achievements
Rank 1
Rank 1
answered on 06 May 2010, 01:08 PM
For a work-around, you can add a Transparent image (separately stored in your media library) to your Form that can be shown in the Dialog or you can use solution model to dynamically add an image to the form before the form gets loaded. Make sure the transparent property of the Image has been set to true. Now, you can set the height and width of the image to the height and width of the Dialog to create the same illusion for showing a busy indication. But, this will not block the user intervention. User can still interact with the form’s contents. To Block the user Intervention, just attach a blank method to the image on its on-action event- just a blank method! So, when a user clicks on any of the form content, s/he ultimately clicks on the image and method attached with the on-action event will get fired, which will do nothing, but prevent user intervention.
For more information refer.