OK, we got an early release of the LiveGrid out to Rico. Bill has blogged about some of the usability issues.
The really nice thing about LiveGrid is that it will load in the same amount of time regardless of the number of rows in the table. This has some interesting implications when you are trying to load a thousand or even a hundred thousand rows into a table.
I will go a bit over the evolution of the LiveGrid with scrolling, because I think it is a good exercise to look at the evolution of software products and see how their design was shaped. Since this is a fairly simple component, the basic structure was created during our first evening.
Darren James and I started off one evening just getting the basic table, scroll bar, and Ajax working. This was really pretty straight forward. The scroll bar was created as a separate component from the table. It was basically a div that was calculated based on the size of the expected table size (this meant that we had to render part of the table and specify the number of rows in the entire contents). Then we added the onScroll event: we basically took the scroll position mapped it back into our expected row offset, retrieved the appropriate contents from the server using AJAX and just swapped out the table contents using the tables innerHtml (we later changed to do cell level replacements). This got something running pretty quick and provided on demand contents. It was a little lacking in performance during row or page level scrolling.
Realizing that we needed to do some buffering of requests, we loaded the AJAX response into a buffer and queued any new requests while one was processing. In order to not waste time processing stale requests, we only remembered the latest request. As you might guess, this resulted in a very significant improvement in response time to the user.
We then changed the buffer size so that it would be some percentage larger than the viewable part of the table. The ratios were made available as parameters in options to allow developers to easily alter performance characteristics. This allowed full page scrolling to be very responsive - except when we crossed border boundaries of the buffer.
The next step was to specify a formula for calculating a threshold to decide when we should prefetch more content for the buffer. This allowed buffer loads to happen before the user scrolled off the current buffer contents and would have to wait for an ajax returned the response. This was also stored as a percentage of the viewable table size and can be overridden through the options. The resulted in some nice row and page scrolling.
Now we had a pretty nice scrolling behavior. However, the thumb drag had some awkward refreshes. To reduce these we decided to only refresh the table when the user paused the thumb drag. This was easily done by only refreshing a contents if there were no unprocessed buffered requests (meaning we did not get an onScroll even since the current request was processed. We also decided to reduce the time for loading content, during thumb drags, by only fetching the viewable contents during these actions. Once the user starts doing local page or record scrolling, the padded buffer would be used again.
There were several more aspect that I will try to cover in the next few days.
Not a bad start. There is definitely room for improvement. We can do a few things to improve the response and refresh time. And are also plenty of features that we can add. Some of which include:
· Sorting
· Filtering
· Basic Editing
I think the LiveGrid shows the possibilities of allowing users to quickly navigate through large contents of data through a web interface. I will generate some visuals in the next couple of days to show the details of how the grid works.
Comments