Probably something you have been burned with in the past, while working with the potentially large sets of data, was the efficient display methods. Ever since I started playing with the WPF and the powerful binding it brings, I have faced poor performance when binding substantial result sets to a ListBox for example.
Then, the virtualization comes along: being able to allow platform to render just the required number of results that are visible at the specific point of time provides much better results. I must admit that it was a cumbersome process at first, but the results were impressive and that made me understand the virtualization sooner than expected.
Now, since the problem with the performance is solved, we are good to go! But not so soon. Lately, I've hit another wall: filling the source with the data usually is what takes time and while pushing the hard work to another thread may give some more responsive UI, I have been (once more) challenged to look for a solution. The problem this time was the relatively slow response from the server and the data arrival was delayed due to many factors (net congestion, busy server, bad scaling, etc) so for the larger result set it would have rather disappointing results.
It may sound like a myth, but everyday Joe really does have kind of fate in the desktop apps when it's about speed. Things open instantaneously, response is short and in an event when there is a 1 second delay - it does not look nice. Trying to explain that the 10-year old MS Access app was much simpler, not scalable and insecure - doesn't improve the situation. Speed and response still remains an issue.
While that same everyday Joe "expects" the desktop app to fly, he/she has a completely different opinion when using the web based apps. The delays are expected (there were delays from the start), poor response even improves lately mostly due to the higher bandwidth or some AJAX here and there, but in essence, there are no complaints and things magically *work*.
One interesting point that we have had discussed within the team was how to tackle our problem of the slow server response while maintaining the UI speed and responsiveness? So, we thought about doing exactly what the web apps do when there are large result sets: page it!
Now, this was a challenge in the WinForm apps and the already familiar DataGrids (which are de-facto standard for the business desktop apps from the "battleship gray" era) were never designed to do so. Users always expected to see "everything" in a single shot, being able to sort, group, filter and whatever-else with a single mouse click. Adding paging to any of the DataGrid variants (third-party mostly) simply does not seem natural.
In WPF it seems like a good opportunity to re-arrange the user's opinion. While using some new ways of presenting the data that is far, far better (and different) from the battleship-gray style, we have a unique opportunity to bring results paging into the desktop apps. And the end-users seem not to complain! For them, a WPF app seems like a completely new experience and they are "easier" to accept new stuff. That is, provided that it still allows them to do their job.
