A while back I took the new features I had suggested in my PBDJ editorial from last year, all the input from last TechWave's enhancement section discussion and all of the suggestions from a long thread a while back in the future_directions forum and I entered them into the ISUG enhancement request system.
I've gone back now and captured all of the data for all of the enhancments in that system in the attached spreadsheet. I then split them up between those that got an average score of 4 or higher and those that didn't.
For all of the enhancments that received an average vote of 4 or higher I've gone back in and re-calculated the average vote to the first decimal place. ISUG rounds to integer values, which isn't enough to really get a feel for how popular a request is.
I then split up the requests that got a 4 or higher up into a two categories: those that are primarily a benefit to the developer (i.e., improvements to the SCC interface, debugger, datawindow painter, etc.) and those that have some benefit to the ultimate end-user (i.e., additional datawindow styles or charting options, better handling of long text, etc.).
My reasoning is that while improvements that are primarily aimed at the developer will make the developers happy, the person that makes the purchasing decision is the development manager. And the development manager is going to be more interested in features that improve the product they deliver to the ultimate end-user (their clients). That is, if there is some improvement in the development product that then gets passed on in the products they create using it, it's easier to see the return on investment that justifies the purchase.
I then divided up the enhancements that have a benefit to the end-user between those that are related to the datawindow and those that aren't. My reasoning here is that improvements to the datawindow will have benefit across the product lines (Infomaker, PocketBuilder, DataWindow.Net and PowerBuilder) whereas enhancements to other system classes will have more limited impact.
Finally, the enhancements are sorted based on the average vote (to the first decimal place) and the number of votes.
I've provided the spreadsheet so you can see the raw data, but based on it what I would suggest as features that should be given high priority are:
1. Standard properties (tab order, enabled, etc.) on windows controls within the DataWindow.
2. Auto-height support for all bands in the DataWindow, not just the detail band.
3. Auto-width support for columns in a grid DataWindow.
4. Additional SaveAs formats for the DataWindow, including PNG, JPG, GIF and something that formats better in word processors than the current formats. (I'd add TIF to that list because it's the only image format I know of other that PDF that supports multiple pages. That is unless they want a seperate image for each page).
5. Additional Chart formats for the Chart DataWindow style, particularly Stock (hi-low-open-close). (I'd add Gantt to the list).
6. Ability to suppress group headers on page breaks. Support for a report header that is not repeated on subsequent pages.
7. Better support for large text blocks. Currently they cause pagination problems if the page break occurs in the middle of the text.
8. A list view presentation style (including small and large icon presentation modes). Would also support heirarchial data, so that the end-user can 'drill' down.
9. Support for a rich-text column edit style.
I didn't see anything in the non-DataWindow user-benefit enhancement requests that were anywhere near as important as these.
As far as throwing a bone to the developers, I'd suggest also considering:
1. Ability to 'remember' the last arguments provided to the datawindow in design mode so the developer doesn't have to keep re-entering them.
2. A "Pending Check-Ins" pane on the system tree, so the developer is aware of what they have checked out without having to search every PBL. It might also end up being the preferred pane to work in for those of us working on source controled projects, because all the items we're current working with would be centralized. To that end, objects that are not under source control in a source controled target should appear there as well (new objects we haven't added to source control yet). The pane would need to support Edit, Edit Source, Check-In and Undo-Checkout on the RMB menu.
3. Support the use of autoinstantiating user objects in DataWindow expressions, not just global functions.
Finally, with regard to the new rich edit control already planned, I'd highly recommend implementing some sort of spell checking, even if it just means hooking into Word somehow and indicating that the "native" support will only function correctly if the end-users have Word installed on their machines.