Fog Creek Software
Discussion Board

Dialog Box usability

Hi, I have a situation here. In one screen which involves editing a grid populated from a database, i need to show the SQL which populated the grid. So i have a menu option which says "Show Last Sql". On clicking it, a dialog box comes up with the last Sql.

My problem is that the user may want to save the Sql or print the Sql. I have never seen dialog boxes with print or copy toolbar buttons. Is this allowed or a major violation ?. How can i give the option to Copy the text, Print the text  etc.? It should be very easy and obvious. I already have a right mouse button option.

Whats the opinion of people here?. Thank you all

Saturday, March 13, 2004

I'd say that is not something that should be put into a message box. Rather, you should put it into it's own group box that just shows the SQL in a read-only text box and have a Copy to Clipboard and Print button. If its not something that will be used often put the group box on the bottom of the dialog and use a "Show SQL" button to expand the window and show it, changing the button text to "Hide SQL". If this is a large window then maybe shorten the grid and show the section. At any rate, don't use a modal dialog for something like that. Oh - and be sure to remember the user's last setting on showing/hiding the SQL group box.


Saturday, March 13, 2004

Perhaps instead of popping the information up in a dialog box you can instead grow a text area and have the SQL populate there. 

Crystal Reports shows their SQL in a custom dialog box that's just a large text area.  At least you can copy the text out of it, but it's really quite inconvenient as it then blocks all of the data.  Ask yourself if the users would rather see both the SQL and data at the same time.

Saturday, March 13, 2004

Thank you,

I am not showing my dialog in a message box. Its a custom dialog box with quite a large text area. Right now i am allowing copy text through the rigjht mouse.

My specific question is :Will putting pushbuttons in dialog boxes (As a toolbar) violate usability?

Saturday, March 13, 2004


I see two things here:

1. Trivial: it's "Show last SQL statement", not "Show last Sql".  Capitalize all three letters of the abbreviation; and SQL is not a noun, it's an adjective - you need a noun to make the phrase make sense.

2. To the main point: in my opinion, what you need is not a dialog but another form.  If your users need to save and/or print the statement on a frequent basis, to me it's causing them extra work and is a usability problem to make them first copy the statement to somewhere and then print it vs. just putting that functionality into the form that displays the statement.

My vote would be for you to create a sizeable toolwindow that has Save, Print, and Close buttons on top.

This raises another question: I'm Joe User and I just saved the SQL statement from the toolwindow.  I close the app entirely.  Then I say to myself, "Hey! I want another look at that last sQL ( :) ) statement."  Does your app allow your user to re-run the SQL statement s/he just saved? If not, prepare for whines.

Karl Perry
Saturday, March 13, 2004

At least I think it's an adjective in this usage.

Karl Perry
Saturday, March 13, 2004

I've seen a lot of dialogs lately that allow highlighting and copying (check out the File/Properties in IE - you can highlight and copy the URL). I think it's better to present this as a dialog instead of a text box, making the point that it's not editable.

Or, as you suggest, just have a "copy to clipboard" button on the dialog - even more useful, IMHO.


Saturday, March 13, 2004

Slightly OT, but Philo, when you get a moment, see if you can ask the IE team why you can select and copy everything in the File > Properties dialogue, EXCEPT the page size... That's both weird and annoying!

Andrew Cherry
Sunday, March 14, 2004

Philo, I have to disagree with you on this.

The requirement is that the user be able to save and/or print the SQL statement.  With a dialog box, there are several steps required:

1. Highlight the text.
2. Press Ctrl-C or choose Edit/Copy.
3. Open another editor (assuming it's not already open) or switch to the other editor.
4. Press Ctrl-V or choose Edit/Paste.
5a. Press Ctrl-S or choose File/Save to save the text, or
5b. Press Ctrl-P or choose File/Pastse to print the text.

With a text box with Save and Print buttons, the steps required are:

1a. Press Save button, or
1b. Press Print button.

Isn't the object of software development to make life _easier_ for the user?

The text button could also contain as many other buttons on its toolbar as the situation requires.

Karl Perry
Sunday, March 14, 2004

Thanks Karl,

I am probably making it into a form window with toolbar buttons

Monday, March 15, 2004

Why do you even want to implement the "Print"
functionality in the dialog. As long as you have a button which saves "Save SQL" it should be enough. They can load it in notepad or better still a syntax highlighting editor and print it out. No point in the taking kitchen sink approach and cluttering up the UI for what will be a rarely used feature.

Just use an edit control with the "non-editable" flag set which allows one to select text and cut and paste it to the clipboard without being able to edit it.

Also when you implement "Save As" allow the user to append the SQL to the existing one. It is a pet peeve of mine that a whole lot of programs always assume that you either want to overwrite or not overwrite a file while saving...not thinking that many a times especially for text files append is also a valid option

Code Monkey
Monday, March 15, 2004

*  Recent Topics

*  Fog Creek Home