Created attachment 38389 [details]
Examples of a Find/Change window, in dreaded Ascii art

I like the idea generally, although I'd like to think of a nicer title than
"Find/Change"... docs team, any suggestions?

"Change" encompasses replacing (e.g. for a text editor), formatting (e.g. for a
word processor), transforming (e.g. for a drawing program), transposing (e.g.
for a music program), and whatever else a particular application might let you
do with found items.

"Change" is slightly ambiguous in that it's also a noun. "Modify" would be less
ambiguous, but it has more syllables. "Find/Change..." is also familiar to
people using Quark XPress, Adobe InDesign, FrameMaker, PageStream, or AppleWorks.

Is the goal to create a Find and Replace-type dialog that is common to many
applications, no matter what is being found and replaced or changed? I am
assuming that this is so in my comments below. I have a few comments on this bug:

Comment 1
---------
Here are the relevant definitions of the three verbs from the American Heritage
Dictionary (AHD) (see http://www.bartleby.com/61/):

Change
1a. To cause to be different: change the spelling of a word. b. To give a
completely different form or appearance to; transform: changed the yard into a
garden.

Modify
1. To change in form or character; alter. 

Replace
2. To take or fill the place of.

The verb change, even with this restricted definition, is quite ambiguous - it
can refer to practically any kind of change. Consider also that there are 20
other meanings of change as a verb and noun listed in the AHD. So, I think we
need to avoid this verb for reasons of ambiguity and also to avoid potential
confusion for translators.

The verb modify accurately describes the drawing application and music
application activities listed by Matthew. The activities referred to are changes
in form or character. 

The verb replace accurately describes the text editor activities listed by
Matthew, that is, replacing one word with another. This is not a change in form
or character. There is more of an argument that the verb modify could be used
for wordprocessor activities, such as finding a particular paragraph style and
replacing it with another style. However, to justify the use of 'modify' rather
than 'replace', you would have to assume that the primary usage of this
functionality would be to perform formatting changes, rather than to replace
text. I think that this assumption would be incorrect.

So in this case I recommend 'modify' for the drawing application and music
application activities listed by Matthew, and 'replace' for the text editor
activities and wordprocessor activities.

Comment 2
---------
It seems to me that the proposal here attempts to use one verb to cover two
different tasks. Perhaps it is convenient at present to do this. But is this a
good enough reason to sacrifice the clarity and accuracy of UI labels for the user? 

Perhaps the 'Find and Replace' and 'Find and Modify' dialogs could be designed
to look similar, but have different titles.

Comment 3
---------
Avoid using the forward slash in the UI. See in the GDSG, the Punctuation row in
the Top Ten Topics to Watch Out For section:
http://developer.gnome.org/documents/style-guide/improving-6.html#top-ten-topics.

> Is the goal to create a Find and Replace-type dialog that is common to many
> applications, no matter what is being found and replaced or changed?
No. As shown in comment 1, the window's contents vary between applications. As
shown in comment 0, the goal is a common *name* for the menu item and window.

> The verb change, even with this restricted definition, is quite ambiguous - it
> can refer to practically any kind of change.
Good! That's the idea.

> Avoid using the forward slash in the UI. See in the GDSG ...
Unfortunately the GDSG does not give reasons for that recommendation (or mention
slashes anywhere else), so it is not as obvious as it should be that the GDSG is
about documentation (where understandability is more important) rather than GUIs
(where brevity is more important).

So the goal is a common name for the menu item and window. As I said in my
comment above, I think that we are talking about two different tasks here, and I
think the clearest and most precise solution for the user is that these tasks
have different names to distinguish them from one another.

You seem to be saying that it is a good idea to use the verb 'change', because
it is a catch-all verb that can cover all of the tasks in question. While use of
a verb like this is expedient in the short term (from a development point of
view), I think in the long term users will suffer because the verb change does
not clearly and precisely express what the task does. 

Ambiguity in GUIs has the following effects:
- Increases the amount of time that the user must invest to comprehend the
label. This contributes to a negative experience of the GUI for native English
speakers using an English UI, and especially for non-native English speakers
using an English UI. Users find in very frustrating to use an unclear UI.
- Increases the amount of time that the translator must invest to comprehend and
translate the label. 
- Increases the likelihood of error by the translator.

I disagree that brevity is more important than clarity in GUIs, and I cannot
think of any situation where this statement is true. 

My understanding is that slashes are avoided because, again, they are ambiguous.
A slash can mean any of the following:

- Or ("and/or")
- And or ("find/replace")
- Divide by ("51/3")

I think Change is more abiguous than Replace, and replace reasonably describes
the implementation and the text matching and replacing that actually happens if
not always ideally fitting with the users mental model of what is happening.  

I seriously would not like this idea to be accepted and another inconsistency of
questionable value to be introduced.  I strongly believe this behaviour must be
justified not just as better but as significantly better to payoff for the
inconsistency.  I do not particulary like extra punctuation in dialogs, the
spaced needed for internationalisation means you cannot rationalise it as a way
to save space by writing "Find/Replace..." rather than "Find and Replace..."

If the change were made to the HIG a change would need to also be made to the
GTK stock items (and then there will be the many other applications we cannot
change like Mozilla Composer).  
As an aside I wish, I wish that all GTK applications used stock items and we had
a stock find and replace dialog because then you would more easily be able to
easily make this change for yourself with a quick change the to the strings
(maybe you could create a locale en-XX for this purpose, I dont know). 
Certainly I've found myself wanting to have override strings here and there and
make my desktop as a whole more consistent.  

> I think the clearest and most precise solution for the user is that these
> tasks have different names
That's not realistic, because there could be dozens of such tasks in the same
application. Find+Replace, Find+Alter Color, Find+Delete, Find+Change Case ...
Even now when there are only two, people who enter search criteria in one window
then realize it's the wrong one have to re-enter everything. That's mean.

> I disagree that brevity is more important than clarity in GUIs, and I cannot
> think of any situation where this statement is true. 
It's true in every part of a GUI, with the possible exception of online help
(which is nearly documentation anyway). That's why the HIG recommends "New"
instead of "New Document", "Copy" instead of "Copy to Clipboard", "About"
instead of "Version Information", and so on. Brevity is even more important than
the clarity of proper grammar; that's why we have the grammatically incorrect
"Save changes to document 'Aba' before closing?" instead of "Do you want to save
changes to the document 'Aba' before closing?", and the grammatically incorrect
"Help" (which falsely implies providing help) instead of "Get Help".

> If the change [sic] were made to the HIG a change [sic] would need to also be
> made to the GTK stock items (and then there will be the many other
> applications we cannot change [sic] like Mozilla Composer).
If the HIG can no longer be changed for fear of inconsistency (see also comment
3), please file a bug asking for its Bugzilla component to be closed. Thanks!

I don't understand the comment "Even now when there are only two, people who
enter search criteria in one window then realize it's the wrong one have to
re-enter everything." This suggests to me that users cannot figure out from the
menu item text what action the menu command performs. This supports the idea
that the menu item text should accurately describe what can be done in the
dialog. As far as possible, users should know from the menu item text what the
menu command does, not from inspection of the dialog.

It seems to me that the best way to ensure clarity for the user is to evaluate
what the text in the menu item should be on a case-by-case basis, rather than
applying an across-the-board, blanket solution.

I don't accept the points made to support the idea that brevity is more
important than clarity on the UI. I do accept that conciseness is important in
the UI, but only if it does not mean that the accuracy and clarity, the
precision, of the UI is compromised.

So I have no problem with "New" rather than "New Document". The user can deduce
"Document" from the fact that they are working in an application that creates
documents, and there is only one type of new thing that they can create. The
"Document" part is implied. 

Similarly "Copy" instead of "Copy to Clipboard" is justified by a presumption
that users are familiar with what a clipboard and do not need to have the
clipboard part spelled out. I think that is a fair presumption.

The About dialogs provide more information than just version information, so I
do not think that the argument that "About" is used because it is shorter than
"Version Information" is correct. "About" is actually a more accurate
description of what is in the About dialog than "Version Information". Also
there is a long-standing convention to support the use of the word "About" here.

I do not agree that either of "Save changes to document 'Aba' before closing?"
or "Help" are grammatically incorrect. The former is a contracted sentence,
rather than grammatically incorrect. No meaning is sacrificed by shortening the
sentence, and the user benefits by not having to process extra text. 

The argument that "Help" is in some way incorrect seems to be based on a
presumption users might read the word "Help" as a verb. There is usually a
mixture of verbs and nouns in the menubar, and "Help" in this case is a noun, to
be read as "this is the menu for commands related to Help". Again, there is also
long-standing convention to support the use of the word "Help" in this context.

> This suggests to me that users cannot figure out from the menu item text what
> action the menu command performs.

No, the realization happens many seconds later. "Oh, hang on, I don't just want
to *find* this thing I've typed, I want to change it to something else." It's an
unnecessary mode. In Gedit I could use Replace all the time, because Enter in
that window defaults to Find. Unfortunately I can't habituate to that, because
in other Gnome programs Ctrl+R doesn't produce a window that works the same way.

Thanks for the points about "fair presumption" etc. They apply just as well to
"Change", which I guess is why popular non-Gnome programs use "Find/Change".

Since reporting this bug, I've learnt that the Find/Change windows in Quark XPress and Adobe InDesign do indeed let you find/change the formatting of text, without necessarily replacing that text.
<http://www.creativepro.com/story/feature/17932.html>
And InDesign CS3 lets you find/change objects without involving text at all.
<http://www.creativepro.com/img/story/20070327_indesign_fg06a.jpg>
<http://urlx.org/help.adobe.com/5fcad>
As unwittingly demonstrated by Scribus, using "Replace" in the name for this window wouldn't make sense: nobody "replaces" a font size, they *change* it.

Again, I am not proposing that every application should have a Find/Change window as complex as these, but that the window be called "Find/Change" across Gnome-compliant applications, so that even people wanting to do a simple text replacement can find that function regardless of application.

Interesting idea. I can see how it would work particularly well in office applications.

That said, I think I'd like to see a real world example before updating the HIG to allow this kind of pattern.