GNOME Bugzilla – Bug 85606
Need a stock design for "Find" dialogs
Last modified: 2020-12-04 18:19:59 UTC
Where should a close button go in a utility window. Examples: The current galeon find dialog uses [close][previous][next] the current history dialog uses [clear][close] gedit find uses [clear][find] The problem as i see it is that we have the jumping close button which is not in the same place for all dialogs. however putting close to the far right would seem to disagree with our recommendations for button orderings in the alert dialogs. (for example in a search dialog i would assume that next would be the default/affirmative action the user would want to do and therefore should be to the far right)
I'm going to resolve this by simply forbidding any buttons other than Close and Help in the bottom row of those abominations that have a Close button. The HIG is actually missing advice for the kinds of windows where this has been a problem. I'm estimating the FIX will be two commits away.
You're going to forbid gedit's Find dialog from having a [Find] button?
Created attachment 12906 [details] A screenshot of how gedit's find dialog should look by Greg
Murray, no, he is proposing that the gedit find dialog layout change as seen in the attached png.
Gregory, on what basis are *you* going to make this decision? Personally I find that the extra buttons in that example seem to be associated with the Entrys that are next to them. Specificically, can you explain what's bad about the current gedit Find dialog, which has just [Close] [Find]? What's wrong with just saying that [Close] should be at the far left?
The button labelled Close has already been confused with Cancel according to articles and comments elsewhere. Allowing it to be where the Cancel button would be in a dialog only adds to the confusion. Further confusing the matter is that we have window frame close buttons on windows with OK/Cancel. On Windows such a button cancels the dialog, but that is certainly not obvious. It's all the more confusing for GNOME because we have instant-apply dialog-like windows; for a dialog closing by frame button is cancelling, for an instant-apply window it's just closing. The Close button in the window (not the frame) is a concession to those who (erroneously) believe it is necessary for accessibility. Ideally the button would not be there at all and this problem would not exist. As it stands, were are forced to have the confusing Close button. Allowing it to move from the bottom-right corner would create more confusion. Placing other buttons, like Find, to the left of the Close button would almost surely look odd to everyone and it could place an important functional buttons where Cancel would be. There has been some mention of making this the spot for a Revert button which would be similar to Cancel and, I guess, therefore copacetic. No positions in the bottom row of the window remain, so some other place must be used. Two rows of buttons at the bottom of the window would surely be worse. A row at the top (or in the middle) violates every convention. Only a column of buttons remains an option, and on all platforms (afaik) such a column is on the right-hand side of the window. The best option remains to rid the window of the Close button leaving the window manager as the mean of closing the window. Given that, I believe Find windows (and others) can use the bottom row for more important things.
Just for the record, "those who believe it is necessary for accessibility" are the physically-impaired people we quizzed on the matter... I know users don't always know what they want, but in this case they're certainly in a better position to judge than I am. "On Windows (the Close button in the window frame) cancels the dialog, but that is certainly not obvious" : indeed, which is why well-designed Windows apps (of which there are a few, honest!) removes the Close button from alerts and OK/Cancel-style dialogs. (I forget if the User Experience guidelines explicitly recommend this or not). Out of interest, since I don't remember seeing any off-hand, can you include some pointers to the comments from people who got Cancel and Close confused? I can certainly imagine people being confused if Close and Cancel appeared at the same time in the same window, or if OK and Close appeared in the same window, but neither of those should ever happen.
So, if we ignore the more "radical" solutions, i.e. removing the "Close" button altogether or moving the action buttons to another place, what is the best solution? I see basically three different possibilities: 1. Mandate that a Close button should always be in the lower right corner. Action button would be placed left of it: [Previous] [Next] [Close] [Clear] [Close] [Clear] [Find] [Close] 2. Mandate that the "most positive" button button is always in the lower right corner, and a Close button should be placed to the left of all other buttons (except Help): [Close] [Previous] [Next] [Close] [Clear] [Close] [Clear] [Find] 3. Ignore the problem for now: [Close] [Previous] [Next] [Clear] [Close] ? Since in a dialog with a Close button there shouldn't normally be any affirmative button, only "action" button, I would prefer solution 1.
Its probably best to have a standard placement for [Close] given its inclusion for a11y reasons. Having a standard location will make it at least somewhat easier for physically impaired users (esp. for sight, but not enough to use a screenreader) to get to it. I think the odd man out here is the Find behavior. Its a somewhat unusual case of something sort of like a dialog, but we want it to remain persistent for repeat use. Otherwise "Close" would just be a "Cancel" button, which we know exactly where to put. As a consequence, unless somebody catalogs a bunch of similar cases, I'm going to re-title this bug that we need a stock design in the HIG for "Find" behavior.
2 threads in July about this: http://mail.gnome.org/archives/usability/2003-July/msg00000.html http://mail.gnome.org/archives/usability/2003-July/msg00005.html (Mea culpa! Mea maxima culpa!)
There was a thread on the usability list discussing a standard find bar which seems a little more to happen than a standard find dialog http://mail.gnome.org/archives/usability/2005-February/msg00127.html
should this be a request against Gnome/GTK/libegg rather than the HIG? How would someone go about trying to come up with an API for this? (Leaving the UI bikeshedding for later, I have some ideas on that myself naturally. I've been mocking up a find and replace dialog for my own application, programming to learn so I have given this some thought.) To take a completely naive, quick and dirty stab at the problem, some of the things needed would be: a find input, a replace input, actions for find, replace and replace all, a boolean? for the seach direction, a find next function (even if it doesn't go in the dialog many applicatoins want it so it makes sense to provide for it) What else? the mockup in comment #3 but I notice it includes the option "Wrap around" which is not necessarily something all developers would want to include but some will so it should probably be offered in an API and different user interfaces would show (or preferably not show, it in differnt ways). Match case seems to be something that only really makes sense for European languages and is a pain in the ass to implement for even some of them, so while if it gets inlcuded in an API it is another thing that would need to be optionally disabled from the user interface. Would the API need to care about how special characters and line breaks are replaced or would that be something that would need to be worked by developers as an optional add on to the user interface? If this is not the appropriate place to discuss it please send a private mail and a pointer to the appropriate forum.
Created attachment 45561 [details] [review] find and replace dialog mockup in glade For what is is worth (not much I expect) I've created a mockup of a Find and Replace dialog in glade (which I already created for other reasons) screenshot in png format to follow. Note that while it is largely the same as what Greg suggested I've used a single table for the layout and the Find and Replace buttons line up correctly with their respective Text entries (the labels before the text entries could be potentially removed). I think this makes the dialog read much better and follow the standard flow left to right, top to bottom and then close when you're done. The layout is fairly standard but I think it is well thought out. The mockup could accomodate additional checkboxes if developers wanted to have different features visible. There is also room underneath the Replace All button where additional buttons might go (I was thinking of a button to insert special characters like tabs, line breaks or even regular expressions but if you look at OpenOffice.org writer it adds quite a few extra buttons just to give an idea of what different developers might want to do to a standard dialog).
Created attachment 45562 [details] screenshot of find and replace mockup I've now attached a screenshot of my find and replace mockup. my glade file can obviously be viewed in Glade 2 but if you want to give it a test run and you have pygtk on your system you could try running the following (change the version number as appropriate of course): /usr/share/doc/pygtk2.0-2.0.0/examples/glade/glade-demo.py find-replace.glade to demon I'm going to check to see if there is a request for a standard find/replace dialog in GTK and if not file a new request for it.
> I'm going to check to see if there is a request for a standard find/replace dialog in GTK and if not file a new request for it. http://bugzilla.gnome.org/show_bug.cgi?id=301632
If a section on Find dialogs is ever added to the HIG, please don't forget to mention the Find bar. Currently, Gnome app developers are re-implementing Find bars in various inconsistent ways.
Setting target to 3.x, and adding uipattern to whiteboard as this sounds like exactly the sort of thing we'd want to address with one or more UI patterns in our (proposed) 3.x UI pattern library.
forgive me if this comment is not relevant for the HIG, but I think it's important to consider not only the layout of the Find dialog, but also where it's positioned, or replacing it by a Find bar. I mention this, since some window managers place the dialog right in the center of the screen and when you are searching, usually the dialog hides the results, so you have to move the dialog around in order to see the results.
I think that the latest guidelines cover this - see the page on dialogs.