998343 - Replace should be inline on the findbar

Status: NEW

(Thunderbird :: Message Compose Window, enhancement)

Description

[Patrick Cloke [:clokep]]

This is pretty much the same description from bug 530629, but about integrating the replace box in a better manner than a modal dialogue. JosiahOne couldn't find a bug for this so I'm filling it. Please dup it if we just missed it!

+++ This bug was initially created as a clone of Bug #530629 +++

STR

1 in msg compose, you just want to find a certain word
2 press Ctrl+F (which is the shortcut for finding things in almost any other app, and will normally bring up the find bar, as they have ctrl+H for replacing)

actual

- we show bulky "Find and replace" dialogue
- it's very complex if you just want to find something (many buttons, many checkboxes and inputs)
- it covers the text / the composition window
- it is modal (i.e. you can't select and copy / drag and drop anything from the underlying compose text)
- it can't do useful stuff like "highlight all"

expected

- just show find bar as usual: unobtrusive / non-covering, dead-simple, efficient, versatile (e.g. highlight all)
- add another field for the replacement text with replace and replace all buttons

Comment 1

[Magnus Melin [:mkmelin]]

It might be really hard to make a reasonable UI where all the options would fit. I don't recall seeing the replace bar in other applications that do have find barish UI. The modality of the dialog should be changed though.

Comment 2

[Thomas D. (:thomas8)]

(In reply to Magnus Melin from comment #1)
> It might be really hard to make a reasonable UI where all the options would
> fit. I don't recall seeing the replace bar in other applications that do
> have find barish UI. The modality of the dialog should be changed though.

In partial agreement with comment 1, I think it's important not to lose any options while we redesign this as a Find & Replace bar. Bug 530629 Comment 66 is a good start but still very incomplete. But with some consideration and careful innovation, I think it's very possible find the right mix of ux-efficiency, ux-discovery, and ux-minimalism.

Comment 3

[Thomas D. (:thomas8)]

Proof of concept - Proposed UI (inspired by Josiah's Bug 530629 Comment 66)

[Find in page   ][^][v] Highlight All  Match Case  Whole Word | Replace ^ (Find/Replace feedback)   x

[Replace with   ][Replace | v] [Replace All] [Wrap around v]
                 +---------------------+     +------------+
                 |• Find and Replace   |     |Wrap around |
                 |  Find, then Replace |     |Forwards    |
                 |  Replace and Find   |     |Backwards   |
                 +---------------------+     +------------+

Short explanation:

1) clicking on [Replace v] button expands the findbar to become a 2-row bar; button changes to [Replace ^] where you can collapse the replace bar again.
2) (Find/Replace feedback) can be used to display both types of feedback
3) [Replace | v] is a dual/split menubutton
- clicking on Replace main button part executes current flavor of Find & Replace
- clicking on [v] dropdown part opens Replace flavors as radio list (currently present, but implemented with bugs)
  - Replace flavors are (pls note, first click on Replace always executes only "find", regardless of flavor):
     - • Find and Replace (default): Find next instance and replace immediately (cursor remains after first replacement)
     -   Find, then Replace        : 1st click: Find & select next instance; 2nd click: Replace selected instance without advancing, i.e. cursor after replaced instance (full control over find & replace process).
     -   Replace and Find          : Replace current instance and immediately find & select next instance (that's the uncontrolled, hence unfortunate flavor mostly found in Word & Co.)

4) [Wrap around v] is a simple dropdown box to chose direction of searching/replacing.

Comment 4

[Thomas D. (:thomas8)]

KDE KWrite has a Find and Replace bar, see screenshot here:

http://docs.kde.org/stable/en/kde-runtime/fundamentals/find-replace-inline.png

A basic Find and Replace bar as an example how to code an addin for Dojo Rich Text Editor:

https://www.ibm.com/developerworks/library/wa-master/findreplace-toolbar.jpg

Otherwise indeed, not many examples to copy from. But we can be the first to innovate ;)

Comment 5

[Thomas D. (:thomas8)]

Attachment: XUL Demo 1: Find and Replace Bar

(In reply to Thomas D. from comment #3)
> Proof of concept - Proposed UI (inspired by Josiah's Bug 530629 Comment 66)

I figured that an interactive XUL demo will provide a more tangible impression of the proposed UI. Although I didn't go to the extent of coding up all the search behaviour...

I think this preserves all of our current Find & Replace options in a nice and tidy way. Please look for tooltips everywhere; they also change dynamically on the Replace button next to the Replace input box.

To view the XUL demo in FF, you need to enable Remote XUL for bugzilla.mozilla.org (or "file://" for running xul files on your own machine, iirc):

http://www.twofold-software.com/site/2011/07/enabling-remote-xul/

Comment 6

[Thomas D. (:thomas8)]

^^

Feedback welcome from everyone :)

Comment 7

[Richard Marti (:Paenglab)]

This looks good. But I wouldn't integrate to much, like the dropdown on Replace. I think the button alone is enough. With the arrows above you can jump to the next/previous match and click then on Replace. Or you can directly click on Replace all. Also the second menu-button with Wrap around/Forwards/Backwards is in my opinion redundant. Wrap around is already set and a text is shown when this happens. Forwards/Backwards can be done with the existing arrow buttons.

I know this needs a click more (arrow for next and then replace) but we should leave the UI as simple as possible here and I don't think this is a function which is often needed on huge messages where a lot of replaces are done.

Especially the three Replace menuitems aren't on the first look clear what they are doing.

Comment 8

[Thomas D. (:thomas8)]

Thanks Richard for instant feedback, which is helpful for discussion and clarification.

Personally, I think we should not rip out any existing functionality just for the sake of pseudo-simplistic design. Which for a lot of users will not actually make it simpler, but harder (less efficient). And it will make TB less useful/versatile for all types of users, especially advanced (where I suspect many simple users won't even use TB, they'll just stick with their web-based mail...). Please trust me, I spend a lot of time planning, evaluating and polishing the UX before I post such proposals, including consideration of UX-minimalism...

(In reply to Richard Marti (:Paenglab) from comment #7)
> This looks good. But I wouldn't integrate to much, like the dropdown on
> Replace. I think the button alone is enough. With the arrows above you can
> jump to the next/previous match and click then on Replace.

Well, that kind of button-hopping between "Find next" and "Replace" would be very inconvenient for users and also error-prone, hence strongly violating ux-efficiency (and ux-error-prevention). Even for just a few replacements, it's very annoying and I would hate to do so because you have to focus very much on clicking the right buttons in the right order - compared to just clicking on the same button repetitively without any mouse movement whatsoever, so you can focus on your text rather than focus on clicks. Imagine having to do such button-hopping for a long message with multiple occurences of search word. More importantly, it would also be ux-inconsistent with the rest of the world, where "Replace" *always* includes "Find Next". Pls try this e.g. in M$ Word for multiple clicks on "Replace" to see what I mean. Worse for keyboard-only users. They'll have to exactly remember the access keys or tab around for each single replacement, instead of just repetitively pressing Enter at their own speed.

> Or you can directly click on Replace all.

Definitely not until we have "Whole word only" option (bug 998801), otherwise it's a blind flight, highly error-prone.

> Also the second menu-button with Wrap
> around/Forwards/Backwards is in my opinion redundant. Wrap around is already
> set and a text is shown when this happens. Forwards/Backwards can be done
> with the existing arrow buttons.

No, there's a misunderstanding here, even for "Find", but more so for "Replace".

We certainly don't want to remove the currently implemented options where we offer users to just find matches
- starting from cursor position only up to the end of the msg ("Forwards")
- starting from cursor position going back to the beginning of the msg ("Backwards")
- going through the entire document ("Wrap around" or "Complete")
(All of these options are realized in current UI, where "Forwards" is unchecked "Backwards").

These options cover a lot of legitimate usecases where it matters in which area of the text phrases are found or not, which is much harder if not impossible to find out without allowing users to set search direction. Getting a clear alert, including error sound, that "The text you entered was not found" is just so much more reliable and discoverable than that little flashing feedback. All major word processors, even some small text editors offer a choice of search direction.

The "Reached end of page, continued from top" feedback is very subtle (at a distance from find box, light grey text color, not even playing a sound) and easy to overlook because it just blinks for one second after the last match. If you happen to be a bit too fast on that one, you will not even see anything. This might work well for a web page where the visual layout of the page might give you some indication where you are, but not for messages where the text looks same everywhere, and it actually matters if you're through or not because you're in design mode and taking authoring decisions based on that.

While for "Find", this might be still considered an inconvenience, removing "Forward" and "Backward" direction would be a major loss of currently implemented functionality for "Replace".
Pls try it in current version of TB:
"Replace All" actually observes direction, and hence can be used for the partial text scenarios described above (replace all only before cursor position, or only after cursor position, depending on "Search backwards"):

STR

1 draft composition with text: foo1 asdf foo2 asdf |foo3 asdf foo4
2 cursor before foo3 (important!)
3 Ctrl+H for "Find and Replace" dialog, enter find text: foo / replace with: bar
4 Remove checkmark for "Warp around" (important!)
5 Click "Replace all"

Actual Result = Expected Result:

-> only results between cursor and end of msg are replaced (foo3 and foo4). Same for "Search backwards", only the other way round.

Scenarios where replacing is required only for parts of the text before or after cursor can easily occur. If anything, I'd suggest that we take a cue from Word and an implicit or explicit way of searching and replacing for text *selection* only, *in addition* to current directions.

> Especially the three Replace menuitems aren't on the first look clear what
> they are doing.

Well, they are the very same options we already have, with one addition which fills a usability gap in the current implementation ("Find, then Replace").

Let's have a look at the dropdown options under "Replace" button (Tooltips in brackets).

Find, then Replace (Check found phrase and replaced phrase)
Find and Replace (Check replaced phrase only)
Replace and Find (Check found phrase only)

I think everybody can understand the words "Find" and "Replace". Agreed, "Find, then Replace" vs. "Find and Replace" might not be immediately obvious from just looking at it for the first time; but after just trying once, you'll know how it works (and you might just find that you love it). Regardless which one you pick, they'll all do the trick, just in a different order and with varying degree and focus of control (verification of changes). "Find and Replace" vs. "Replace and Find" are pretty clear I think.

In fact "Find, then Replace" offers a very efficient, yet fully controlled way of replacing text:
Users can simply continue clicking on the "Replace" button:
  Every 1st click -> find and select next occurence (so you can check what you are about to replace)
  Every 2nd click -> replace selected occurence (without advancing to next occurence, so you can check
                     the result of replacing before proceeding).
So there's full control about both the found text and the replaced text, with the ease of use of just clicking on the same button ever again, or even just repetitively pressing Enter.
This is a new and innovative way of replacing; it might seem unusual at first but after a short while, you might not want to miss it because it's so transparent (hence more efficient because it needs less attention). That's why I would actually consider or even recommend to make that the default (differing from my comment 3). It's also very similar to what most word processors do, with the small change that we let you look at each replacement before proceeding. Which removes that uneasy feeling when Word has just replaced a word on page 1 and instantly proceeds to the next find on page 2 so you do not even get half a second to verify if the replacement went right and how it looks now.

Also, pls consider we are not forcing users to make any of these choices as we offer preset defaults for both of them. Many users might just be happy with our defaults so they might never get into the dropdown. That's what dropdowns are for: just ignore them if you are happy with defaults or don't care, use them if you need something else. Options are very few on each of the two dropdowns, so it's not like we're creating complex choices here.

Comment 9

[Thomas D. (:thomas8)]

I hope you noticed the dynamically changing tooltip on "Replace" button which (for interested parties) which describes the currently selected option (Replace button tooltips in brackets):

Find, then Replace ("Find, then replace the next occurence of the search phrase")
Find and Replace   ("Find and replace the next occurence of the search phrase")
Replace and Find   ("Replace this occurence of the search phrase and find the next one")

I'm open for suggestions to improve/reorganize/merge/simplify/shorten the wording of tooltips... ;)

Comment 10

[Thomas D. (:thomas8)]

Also, "Search and Replace" is certainly a somewhat advanced feature so it's actually *more likely* to be used by advanced users, and also *more likely* to be used for longer texts. For a short text, even I as a power user will often prefer just using "Find" and then replace directly in the text...
A simple user writing a 10-line-message will never use "Search and Replace"...

Comment 11

[Thomas D. (:thomas8)]

...Comment 6

Comment 12

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #3)
> Proof of concept - Proposed UI (inspired by Josiah's Bug 530629 Comment 66)
> [Find in page   ][^][v] Highlight All  Match Case  Whole Word | Replace ^ (Find/Replace feedback)   x

"Whole word" option is Toolkit's
Bug 269442 - Add Find Whole Word/ Find Exact String Option to Find Toolbar

Comment 13

[Thomas D. (:thomas8)]

This is the toolkit tracker for find bar:
Bug 565552 - "Find in page" needs to be improved