I am helping to design a new application at my company. We're currently using JBoss 5, JSF 1.2, Richfaces 3.3.2. The application is to implement a web based application to replace a very large spreadsheet that my users have been using to manage their work. The spreadsheet has a large number of columns, about 90. For better or worse, they have gotten used to working with their data in Excel, they love Excel and are all really good using it.
I am trying to provide them with an efficient interface that allows them to quickly navigate through their data and view and update multiple rows & columns on one screen. I have too many columns to display on one screen. I can try to group them into tabs and make a big editable datatable, but I think this seems like a klunky interface; they would need to navigate from page to page and from tab to tab - I think this will drive them crazy. I can also export their data to Excel, let them manipulate the data in Excel and import it back in. They would be able to quickly update their data, but this seems like a bit of a hack and a possible validation nightmare when I read the data back in.
I've seen some ajax based spreadsheet type jsf components, but I don't have any experience with them.
Has anyone had a similar situation with their JSF app? What was your approach? I'm basically trying to provide them with a JSF solution that's as close to Excel as possible. This may be impractical, I'm not sure.
Any thoughts or feedback will be greatly appreciated. Thanks.
Spreadsheets can be a really horrible way to work with resources. Sure, everything's right out in the open, but the problem is everything is right out in the open.
Spreadsheets are bad enough as spreadsheets. But taking them onto the web is worse. Not only do you have real estate problems, but the dynamics of working over a web connection mean that trying to do everything in one big clot of information can be downright punishing.
In a previous incarnation, one of my major job requirements was to take stuff that had originally been developed on spreadsheets and/or MS-Access databases that had grown too big and/or too distributed to work there anymore and move them to a more Enterprise-friendly environment. Typically, that meant webapps, although other options were sometimes required as well.
Your best bet would be to sit down with the users and see how they actually interact on a day-to-day basis with the spreadsheet and see if you can't come up with a list of business activities that work with selected parts of the spreadsheet and see if you can't translate them into more web-friendly processes. As an incentive, you'll be able to make it possible for users to get stuff done without hop-scotching all over the data map, and you can provide the extra editing and validation services that webapps can do so much better than spreadsheets can.
This would definitely be a radical change, but if done properly can pay off for both you and the users alike. I do recommend adopting an Agile approach, however. Any time you take something of this magnitude and try to overhaul it, the waterfall approach can lead to delays, unhappy users, and even project failure. Do it in small, easily managed bites and always be prepared to accept feedback from the users as you implement stuff. One thing I discovered a long time ago is that if you provide an enhanced feature to users, they'll find new and unexpected ways of using it, so allow for this.
Customer surveys are for companies who didn't pay proper attention to begin with.