50

Why do most programs separate Find and Replace dialogs? Obviously, I'm talking about apps like text editors and word processors, apps that are used for editing content.

It just seems strange, at best, to completely separate functions that are basically two sides of the same coin, and can get downright frustrating when they're implemented as separate windows instead of tabs in the same window and you decide to replace some of the already found matches.

From the interface design perspective, I don't see how the inclusion of another text box and two more buttons required for Replace (all other options are usually the same for both Find and Replace) causes such a clutter in the interface and cognitive overload that it requires a basic Find version for "non-power users".

The only program I can think of that combines these two is TextEdit. (Ironically, there's a question on Apple StackExchange about where the Replace function is hiding in TextEdit, but that's because it's named just "Find" instead of something sensible like "Find or Replace".)

  • 8
    Atom also combines them, and does a great job – paj28 May 17 '16 at 7:28
  • 1
    Isn't this a Mac vs Windows vs Linux convention? As far as I know do most of the apps on my Mac (like TextMate, OmniGraffle, Pages etc.) combine them. – jazZRo May 17 '16 at 11:24
  • 6
    Visual Studio Code has an interesting approach on this. The Find and Replace dialog are combined into one, but the Replace section is folded by default when hitting Ctrl+F (as opposed to when hitting Ctrl+H). Folded Find & Replace dialog | Unfolded Find & Replace dialog – Thiht May 17 '16 at 12:12
  • 1
    I thought combined was standard for Windows; I remember it being so in Microsoft Office and Notepad back when I used it (XP and previous) – Izkata May 17 '16 at 14:05
  • 2
    I'd argue they are "basically two sides of the same coin". There's a world of difference between searching for something and replacing something. One is non-disruptive action, something you may need to do an observation, remind you of something or simply check it's there. As such, it's an action that completes itself.The other changes the whole process and search is just a small part of this process, an additional step you may or may not need, but as such, just a step. The real action is REPLACE. – Devin May 17 '16 at 17:18
60

An interesting question, and one that I think many of us might have pondered before without really diving too deep into the possible issues. From a purely design perspective, I can think of a number of plausible reasons:

  • Convention: the first person did it this way, and then everybody else followed because "that's how it's done".
  • Safety first: separating a destructive action (replace) from a non-destructive action (find) is important so that people don't accidentally wipe out information without getting a confirmation first. I assume that 'Undo' wasn't always available or that there are other implementation details I am not aware of.
  • Ease of design/implementation: perhaps it is easy to create the find and replace functions separately as different modules (because not all programs need both), and then it will be easy to do the user interface design when you add or remove one or the other feature.

In the end, if it is such an issue to the end-user one would expect that these software will have changed it, so perhaps people are used to it (much in the same way we still use QWERTY rather than DVORAK or Colemak keyboard layouts).

  • 44
    Indeed it is the second reason that is most important : why to introduce a non required risky function ? I totally agree . – DrWael May 17 '16 at 2:18
  • 13
    Regarding safety: I am frequently using an application which does not make that distinction, and it always makes me nervous. I always double-check that the "replace with" checkbox is deactivated before I click OK. – Philipp May 17 '16 at 7:47
  • 5
    Suggestions such as the Safety one, whilst sensible, may be more 'benefit of hindsight' than actually 'the reason for it existing this way'. It's easy to look at something that does exist and then interpret meaning from it, but I wouldn't be surprised if it is purely convention (as you suggest first) and nothing more. They did it that way once without thinking about it, and that's just how it's done now. – JonW May 17 '16 at 8:28
  • 8
    Notepad++ has combined Find + Replace into their Find in Files tab and it scares the bejeezus out of me every single time I go to use it. I always make sure that the Find criteria and Replace criteria match before pressing any of the buttons on the right. A swift Enter, Enter, can easily ruin my day. – MonkeyZeus May 17 '16 at 14:30
  • 2
    I think the second reason is the most plausible. I'd NEVER allow a destructive action to be confused with a non-destructive action. – Devin May 17 '16 at 17:14
17

Both Find and Find and Replace are related functionally as you mention. But both actions seem to be orthogonal in terms of what user need (mindset) they cater to. You will know in advance either you want to find something or you rather want to substitute occurrences of something. In the latter case it just happens that you need to find occurrences of the thing you want to substitute, but this is a secondary concern or even not important in some cases.

Therefore, presenting only one option called Find and Replace will confuse users who simply want to find something. They won't interpret this action as the one that let's them accomplish what they need. Likewise, having Find that offers replacing will not seem like the appropriate action if they need to substitute something in the doc.

  • 1
    "You will know in advance either you want to find something or you rather want to substitute occurrences of something" Do you? I often find myself in the situation that I first search someting, and then late decide that I want to eplace it. This happens both with papers for publication, as well as souce code (compute programs). Most IDEs don't have seperate find/replace dialogs anymore, and I find it moe and more inconvienient if a text editor doesn't have them combined. – Polygnome May 17 '16 at 18:16
  • @Polygnome Most IDEs? Neither Visual Studio nor IntelliJ don't have a separate search dialog. I mean sure you can use the replace dialog to also search (that makes sense), but there is a simple search box as well. Always slightly worried when using the search/replace one that I'll incidentally replace something in hundreds of files while I'm just searching. – Voo May 17 '16 at 20:30
10

If you can expect your users to be power text editor users, for example programmers, then it makes sense to combine these dialogs into one, or, even better, make it a toolbar and show real-time results as you type. This is an expected feature for development tools nowadays, as it speeds up the editing process greatly. IDEs (integrated development environments) usually do a pretty good job at this, for example all JetBrains products or Qt Creator by The Qt Company.

An example by JetBrains:

JetBrains search and replace screenshot

  • 6
    Atom does the same, it's very nice. – cat May 17 '16 at 11:04
  • Their find modal to search text in multiple files has a different shortcut than the find & replace modal while they are almost identical. I assume this is done for safety reasons. – jazZRo May 17 '16 at 11:14
  • 1
    It seems as if you're trying to present a counter example; but JetBrains IDE:s have different "Find" and "Find and Replace" dialogs. It is even apparent in the image; there are only replace actions available; no option to find. – Odalrick May 17 '16 at 12:29
  • 2
    Actually, the up and down arrows serve as the "Find" button here. – user69458 May 17 '16 at 20:28
  • 1
    This would really qualify from mentioning that there's a separate search dialog as well. This is more an example of how it is convenient to also be able to just search in your search&replace dialog, not that you should remove the find dialog. Because that'd be a horrible decision in my opinion (I don't want to worry about pressing the wrong button when just searching for something and deleting a piece of text in thousands of files). – Voo May 17 '16 at 20:28
3

I see this as new behaviour. Without an old install of MSOffice to test I can't be absolutely sure, but in the past find/replace dialog boxes were often modal, and covered quite a lot of text. For find only tools this isn't necessary - they tend to have 2-4 controls of which only one is a text box (wide). Replace requires at least another text box and button, usually more ("replace all" etc.). Also buttons may need clearer labels in replace as the consequences of errors are larger - bigger again. So a find tool can fit in a status bar or tool bar at a width you can take in at a glance. Replace is just too big for this. That also hints at why new versions of word put "advanced find" in with replace despite using a sidebar which is big enough (the space appears to be used to show the locations of found items).

There's a trend towards non-intrusive "find" tools, e.g. in the status bar. Examples: Libreoffice; Firefox; Adobe Reader (the latter two are specifically included as an example of the new method, where "replace" isn't used)

MS Word (and possibly the rest of Office, though not Outlook while writing an email) uses a rather different sidebar "navigation" box. This provides different capabilities to the legacy find/replace tool (tabs in the same dialog box, the find bit now called "advanced find"). The find/replace tool looks rather old-fashioned now, but probably can't change much without breaking power users' workflow (touch typists who like keyboard shortcuts and remember how many times to hit tab).

  • I don't see how this answers the question. Why are find and replace separate operations? – David Richerby May 17 '16 at 17:26
  • 1
    Firefox and Adobe Reader aren't very good examples for OP's use cases because web pages and PDFs, other than ones that integrate forms, tend to be read-only, so in most cases it doesn't make sense to have a replace dialog, separate or combined, anyway. – JAB May 17 '16 at 21:41
  • @JAB on the contrary as I said I included them specifically as an indication of the fairly new discreet way of implementing find features. From memory this started in browsers (which of course are very widely used) before spreading to other software. So: find copies browsers, replace doesn't - or at least that's my speculation. – Chris H May 18 '16 at 5:51
  • @DavidRicherby I clearly skipped over a point which I took to be obvious. On re-reading I take your point. I've added to the first paragraph which should fill in the blanks in my logic. – Chris H May 18 '16 at 6:34
2

Find is sensible with a non-modifiable document. Replace is not. Historically, was "replace" greyed-out or not displayed in read-only mode? Maybe back when there was only space for one copy of the document on the 720k floppy disk?

These days, it's normal that the document's text is always modifiable and it's the file that is not, So it is "Save" that is greyed-out, to indicate that "Save as" is required. (You also often get a warning when you open the file read-only).

A mistaken global replace of something with (say) the null string, is a bit catastrophic, especially if "undo" is not capable of reverting a global replace in one click. So maybe it still makes sense to have a completely different menu entry for the option which is intrinsically a lot more "dangerous".

0

There's a lot of history to text editors. e.g. vi which is one of the oldest separated these out as there is a defined split between viewing a document (find) and editing a document (replace).

In technical terms they're quite different things, like GET vs POST for the web, and text editors are typically quite technical tools.

Word Processors less so but I assume they took inspiration from Text Editors.

I suspect also, but I can't find the data, the find operations are done much more often than replace operations.

  • In all fairness, vi is one of the oldest visual text editors. Plenty of text editors came before it; remember edlin, which traces its roots at least back to ed? – a CVn May 17 '16 at 15:46
  • 1
    @MichaelKjörling vi traces its roots very directly to ed, via ex - vim has options for compatibility not only with the original vi, but the original ex. The main / command in all of those is arguably more "seek" than "find" - it's a way of selecting which line to edit - although there is also the highly influential g/re/p. – IMSoP May 18 '16 at 9:02
  • @MichaelKjörling "Edlin was created by Tim Paterson in two weeks in 1980," (WIkipedia on Edlin). Vi goes back to 1977: "Bruce Englar encouraged [Bill] Joy to redesign the editor, which he did June through October 1977 adding a full-screen visual mode to ex." (Wikipedia on Vi). Edlin most likely traces its roots to the bottom of a bottle of tequilla. – Kaz May 18 '16 at 22:23
  • @IMSoP @Kaz Fair point, but mine still stands: there existed text editors long before vi. – a CVn May 19 '16 at 7:58
-4

It's this way to prevent you from doing disastrous things. Replace should be disabled and never used.

If you worked with XCode and Swift for a while you will realize that the missing refactoring methods for Swift are actually a blessing. They force you to think ahead of naming stuff right, so you won't need refactoring/renaming.

For normal (non Swift) IDEs you could argue that replace is evil too, as you better perform a refactoring method than randomly changing all matching strings in the project.

Warning: This answer is soaked with sarcasm but might contain a little truth.

protected by Community May 18 '16 at 10:44

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.