GNOME Bugzilla – Bug 100821
[ui-review] Replace dialog usability
Last modified: 2012-07-30 17:37:30 UTC
From the ui-review: o Replace dialog - plans to remove the 'Start From' part and implement a 'wrap around' checkbox - s/Case sensitive/Match case - Button order possibility - [Replace All] [Replace] [Close] [Find]
- plans to remove the 'Start From' part and implement a 'wrap around' checkbox -> DONE - s/Case sensitive/Match case -> DONE - Button order possibility - [Replace All] [Replace] [Close] [Find] -> Waiting for a decision from HIG guys
Created attachment 12907 [details] screenshot of search dialog as proposed by greg merchan
paolo: greg did this mockup of a find dialog that is much nicer. Specifically the close button remains in the lower right corner where it should always be (well thats assuming you agree with the presence of close buttons but thats whole other can of worms).
yep, I saw it, but I really don't like it for the following reasons: 1. Buttons on the left side of a dialog are not so gnome-ish. 2. They are not alligned with the close button (and it is not so easy to allign them) 3. The buttons do not have icons (quite easy to fix) 4. This solution does not work well for the find dialog where you have only a Find button (+ the Close one) BTW, before changing the dialog again I will wait a final decision from the usability guys.
First, an overall retort. I think I made that screenshot with glade in under a few minutes, so some of what you see is because of that. > 1. Buttons on the left side of a dialog are not so gnome-ish. I presume you mean the right side. ;-) They may not be gnome-ish, but they are familiar from both Windows and MacOS. There are some other kinds of dialogs (iirc) where we might need them, so I think we need to carefully expand what's gnome-ish. > 2. They are not alligned with the close button (and it is not so > easy to allign them) I'm not sure they should be! The existence of the close button is the real problem here, but I think I can fix the alignment. > 3. The buttons do not have icons (quite easy to fix) They really shouldn't. Icons in buttons like this may be considered a bug for all of GNOME/Gtk. > 4. This solution does not work well for the find dialog where you > have only a Find button (+ the Close one) Don't have one of those. :-) If the window isn't the kind that stays open, it should have two buttons: Find and Cancel. If it is the kind that stays open, then include a "Find Previous" button. I may code new mockups in a little while, after some more coffee.
I have a comment about the wording of the new "Wrap around" check box. I don't think the wording is clear enough about what the option does. If I correctly understand the function of the check box, I suggest using the wording "Include wrapped words".
If "Wrap around" is on, then clicking "Find" again (or "Find Next") would return to the beginning of the document if the word is not found between the current position and the end of the document. "Wrap Search" ? (I'm still confused about the distinction between "find" and "search".)
FWIW, Mozilla uses "Wrap around".
General comment: Please work with Abiword, Galeon, etc. to standardize the Find/Replace dialogue.
Oh, it looks like I picked up a completely wrong meaning of the "Wrap around" option. I think using the word "wrap" in this context is misleading because to me it implies word wrapping. How about coming from the other angle with wording like "Search from cursor position to end of document only" and then the check box would be unchecked by default?
wrt the "wrap around" checkbox... do we need it at all? What about leave "wrap around" always on without a checkbox and instead pop up a dialog when the end of the file is reached whit something like: "Reached the end of the document. Restart search from the beginning?" (You get the idea, of course my english should be improved ;-)
> "Reached the end of the document. Restart search from the beginning?" for me the answer to that question would always be YES OF COURSE! which makes that extra prompt really really annoying In my not so humble opinion you should always wrap around the search, but you should provide a status bar message telling the user that is what has just happened. (Your written English is fine by the way). http://bugzilla.gnome.org/show_bug.cgi?id=100821#c9 A standardized stock Find and Replace Dialog for Gnome would be interesting all right (Galeon is an intersting case, it has buttons for Next and Previous rather than a Find button and a checkbox to change the direction). The current setup in Gedit is pretty good, I dont think I'd change it unless it was for a consistant and starndardised stock Find and Replace dialog that others would also use. However I do prefer how others layout their search dialogs even if it does bend the Guidelines more than a little. (Abiword, Mozilla Composer, most Microsoft software (and OpenOffice almost fits in too but it has a very complicated overloaded layout)) [ ] [Find ] [ ] [Replace] If I were trying to convince you to change I guess I would try and argue that this layout has slighly better affordance, as the actions are right beside the text boxes, but short of a solution that benefits more than just Gedit I'd leave well enough alone.
Copying from bug #149762: Use two back/forward buttons in Find dialogue ----------------------------------------------------------------------- Reporter: gbz@hey.shacknet.nu Please adopt the design made by e.g. Epiphany regarding Find/Search dialogue. I.e. separate [ <- ] and [ -> ] buttons for backward and forward directions respectively. It is much more intuitive than having to use a checkbox to toggle backward direction. ------- Additional Comment #1 From Alan Horkan 2004-09-13 16:29 ------- arguably this is a duplicate of bug 100821 http://bugzilla.gnome.org/show_bug.cgi?id=100821 > "It is much more intuitive than having to use a checkbox to toggle backward direction." please dont use the word "intuitive" all over the place willy nilly It is an intersting idea and it certainly works well but to assert it is iherently better and more intuitive without offering proof or a bit more explanation is a bit much. I suppose having two buttons does make it easier to navigate using only the keys. However in an application like gedit that also has a "Find and Replace" dialog I think having Next Previous buttons would clutter things and make it more confusing (and if you were do make the change in just Find but not Replace it would be inconsistant) That is just my humble opion. Maybe Paolo will like the idea.
*** Bug 149762 has been marked as a duplicate of this bug. ***
*** Bug 150010 has been marked as a duplicate of this bug. ***
I had an emacs detox about six months ago, and weaned myself onto gedit for day-to-day editing habits. Since then, I've had to put up with the following annoyances daily. Today, I just wanted to make sure they're noted for when someone gets round to sorting it out. 1) Find dialog - pops up into the middle of the screen, often obscuring the text it has found/highlighted. More often than not, I have to move the dialog out of the way to see what's going on. Also, on task-switching back from another application, the window manager puts the focus in the main window rather than the find dialog, which is still conspicously floating on top, inactive. Ugly. The best way I've seen this done is in Firefox, where Ctrl+F pops up a 'find bar', conveniently docked at the bottom of the main window. Also, it should try to center the text it finds, for context. I hate having to scroll the window for each search hit so I can see the following few lines. 2) Search/Replace - If I copy a block of code down, and want to replace all occurrences of a certain string within the new block, it's not easy. Ctrl+R to open the dialog, fill in the values, Alt-F to find the first occurrence, Alt-R a few times to replace all the occurrences, and after replacing the final occurrence the cursor whizzes off to some other part of the document and I have to find my way back (without bookmarks - but that's another story!). What's needed is a 'final replace' (like the '.' key while doing S+R in emacs) that just replaces that occurrence, leaves the cursor there and closes the dialog. However, gedit has done me well over the last few months. And I'm now off emacs. Hopefully one day I can find the happiness in gedit that I once found in emacs. Thankyou, Paolo et al.
Ross: a firefox-like search UI is definatelt being considered, see http://bugzilla.gnome.org/show_bug.cgi?id=153641 and there even is an experimental cvs branch where the search bar is implemented. However a search bar is not without problems either: among other things it must be sorted out how it interacts with printing, we must make it look nice when the output window is displayed, etc. About your request number 2, I think I see what is going on: Alt-R replaces the word and also automatically searches for the next occurance of the word so when you dismiss the dialog after replacing a few "foo" with "bar", the cursor is moved to the next occurance of "foo" in the document... not sure which is the better behavior: we could make the Replace button not automatically move to the next occurrance, but thet would mean having to hit both Alt+F and Alt+R for each word you want to replace.
There should be a way to search and replace inside the selected text only. This avoids having to agonize over what is currently being replaced as Ross is doing; for example when you only want to replace words inside a few paragraphs or code inside several functions. I think this happens quite often.
A redesign has taken place in the meantime. If there are still specific issues in 3.4 or 3.2, please file new separate bug reports for each issue respectively. Thanks!