I’m in the process of redesigning a SQL query builder UI for a application that I use, well it’s a third party app but has a plugin model so I writing my own to replace the standard one. One area I am not very good at when it comes to application design is the UI.
I would be really interested to see/hear how other people would layout this dialog, to make it a little bit better, or do you think that it is good as it is.
I am using WPF for my new design so I can be pretty flexible with the UI.
This is the current SQL UI:
alt text http://img190.imageshack.us/img190/9492/sqlq.jpg
Just for clarity when you select a option from the Tables menu, it adds the table name to the “from Tables” text box, same with the Columns drop down into “Select Columns” box.
Who exactly would use such a UI? Since it’s basically just a pre-defined SELECT statement template, I would expect such a tool to be used by people who know how to write SQL statements from scratch (since that’s essentially what they’re doing). The addition of available columns and tables and stuff like that is nice, I guess.
If the tool is meant to be used by experienced SQL users, the tool looks much too restrictive. For example, it appears that one would have to write his own JOIN clauses as WHERE clauses, making outer joins bothersome. It’s much less useful than an open textbox.
If the tool is meant to be used by inexperienced users who might not know the ins and outs of relational database management systems, this thing is laughably awful. Too much needs to be done in spite of the restrictiveness of the tool. Too much knowledge of SQL is needed to understand what the form needs. It’s more useful than an open textbox, but not much.
Ways to improve the tool depend on the end users. If they’re experienced with SQL, the tool should be more of an open textbox where they can write whatever they want, including JOINs. Look at how Microsoft’s Server Management Studio allows users to build queries: very nonrestrictive, with the ability to view tables and join them by dragging one column to another. That’s a very natural way to approach queries in a visible, organized manner.
If the users aren’t experienced with SQL, the tool should do a lot more for them. For example, if the user picks two tables, it should automatically join them so that he doesn’t have to understand how joins work. Also, the comboboxes on the side should be able to work in any of the open text boxes, not just one specific text box each. Because you need column names in the SELECT part as well as the WHERE part.
Just think about your userbase, and tailor to the tool to them.