Live from Desktop Summit 2011: The second instalment of the "What's changed in OpenPSA 9" series.
After having talked about the refactoring effort and what it meant for OpenPSA's interaction with the Midgard storage backend, it's finally time to get to the management itself, and since the first thing that's likely to catch a user's eye is the user interface, we'll start with that.
If you've played around with the demo server, you will have noticed that the layout of the individual elements and their behavior has evolved quite a bit over the last year, even if the basic OpenPSA look and feel is still there. The focus of the UI changes was not so much to create an entirely new experience than to flesh out and polish the system that we have.
Up until the most recent 8.09 releases, tabular data was rendered by OpenPSA like in the days of yonder, that is to say straight HTML tables with some CSS slapped on to make them less of an eysore. While these tables had a certain simple charm to them, they were of course terrible for usability, especially once your data sets started to grow: Scrolling down would cause the column headers to disappear, and if you wanted to resize or sort columns, you were out of luck, because HTML tables lack these features.
jqGrid, OpenPSA's current grid implementation of choice, changes all that: In contrast to the old HTML tables which were in essence only specialized formatters, jqGrid approximates the behavior of desktop spreadsheet applications, which many potential users are already familiar with. Of course, proper integration of all possible interactions is a large task that is far from done, but there are already a number of interesting examples in the current o9 repository:
Load table data by AJAX: While not exactly groundbreaking, this is nevertheless a first for OpenPSA and can cut down the page load times considerably, especially when combined jqGrid's builtin paging support. Aside from the regular next/previous paging, it's also possible to load more table rows on demand when scrolling. We have implemented this for the paid invoices grid on the invoicing dashboard: Before, it would show you the six most recently paid invoices and nothing else. Now, it is prefilled with six rows, but by simply scrolling down, you can load as many additional rows as you wish, going all the way back to the first invoice ever created in your database.
Inline editing: On the invoice items grid, you'll see what an editable table could look like: To change an invoice item, just click into the row to start editing. Fill out description, quantity and price per unit, hit return (or click the little „save“ icon), and the appropriate DB entry will get created, causing the invoice's total to be updated accordingly. Adding new invoice items and deleting existing ones is just as simple.
Grouped Rows: Flat tables, especially ones with lots of rows, can get quite confusing, so we dynamically group rows with the same value in a particular column together. Since this happens on the client side, it is very easy to make it interactive. For example, on the task grid, the rows are by default grouped by project, but if you'd rather see all tasks for a particular customer or manager displayed together, you can just change the grouping by selecting the new column from a dropdown, with no new request to the server. Totals for the different groups are automatically recalculated, giving you more possibilities to manage and survey your information.
At this point, data grids are of course nothing revolutionary, but this is really a step that any application that is serious about targetting business users must take. Spreadsheets are the medium of choice in these circles, and with good reason. The sooner we can bridge the gap between web app tables and desktop spreadsheet applications, the easier will it be to actually get business users to move their business processes into the "cloud".
There have been no comments so far.