New answers tagged

-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 ...


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 ...


16

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 ...


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 ...


8

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 ...


4

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 ...


58

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 ...


1

Common requirements: I have identified common requirements/patterns for the "dialog" concepts I came across. OK and Cancel buttons Close icon in top-right corner (same action as "cancel"?) Hitting "escape" closes the prompt (same action as "cancel"?) User can move popup around using drag n drop Confirmation dialog must be enforced by ticking a checkbox ...


0

I think in general the users will give you the best answer, and in the case where you don't have any information to go on, then consistency and conformance is the safe default option. As for your questions: how far can you take this design? can you provide some screenshots to see what the difference in styling and behaviour is? I don't think the windows ...



Top 50 recent answers are included