>You asked for and I provided an example of an interface that did not result in the reaction you experienced. I also stated that it would not work for a situation that calls for free form query capability. A "wizard" is just a cute word for an application . . . only as useful as it's underlying design. Not all wizards are user friendly by default, no matter how simplistic they may seem to a developer. Ask a user what they should pick as the appropriate field delimiter ( a choice in commonly used Wizards) and they will most likely panic.<

>>Actually, I think it might work in a free form. The key (and the reason I use the term wizard) is that what are usually labeled wizards work in a very procedurual fashion. They ask a user for information. Based on that the next question is asked, and based on that to the next.


The advantage of this over the "do anything in any order" that is the standard user interface these days is that it is a way to lead someone by the hand through a very complex process. So by the time we are using your method we would already know the fields, and output format. I actually think what you are suggesting might indeed be generalizable. And I agree that asking for a delimiter would cause the user to panic. This is meant to query against databases, not exported data or spreadsheets. Basically the utility I'm envisioning will only work for something which has an ODBC driver. <<

I was thinking of the VFP import Wizard, which is similar to most import/export Wizards. The only purpose for this reference was to point out the problem with assigning too much value to the term "Wizard" for you solution. Having to know the fields and output format is the part of this concept that limits it if you have a client who expects to query data on the fly for needs unanticipated during a design phase.

>>I was not criticizing. You gave a very useful suggestion -- one that might be more broadly applicable than you realized. <<

Sorry if I sounded defensive. It is very hard to manage tone when communicating this way. I've thought of several approaches to broadening this concept but each one fell apart at some point in the design.

>>I don't have a detailed interface in mind yet. (I may yet buy rather than build). But if I design a wizard, I'd imagine the first step to be picking the output fields, order to sort them. whether to group them , calculations, detail or summary (if grouped). (Note: I've already got the order wrong. Something like this, like any application, would require careful specs.) Picking what databases to connect to would be implicit in this since the application would have to know behind the scenes what tables live where, and how to connect to them. A user friendly setup would be an important part of designing something like this.<<

And that is the trick in expanding this - generally, the easier it is for the user the harder the development.

>>Once you have that, then we could start asking for conditions. Since we would already know what tables the data was coming from we would be able to offer just one or two additonal steps for simple queries. Advance queries would have to be broken into a number of steps. By always making sure each step was small and simple we might well be able to make use of extremely user friendly interfaces such as you've described.

Of course the price for all this user friendliness is that the user would have more steps in order to spec his or her queries. To avoid this we would use the ability to save and restore queries (both programitically and interactively) so that developers could set up commonly used canned queries, and users could save their most used queries.

I'm looking at QBF to see to what extent it already has this, and will report back when done.<<

Gar - you are certainly on the right track for a friendly query UI, wether you build or buy. I'm hoping someone else has already done it . . . paying for the r&d is another minor issue the users will not want to understand.