Find vrs Find & Replace

Bike
#1

Any thoughts on the worth of having separate modes for “Find” and for “Find and Replace”. The current macOS interface has two modes. Find is Command-F and only shows find text area. Find and Replace is Option-Command-F and shows both find and replace text fields.

It seems more reasonable to me to always show the full find and replace UI. My logic being that if I want a completely “distraction free” screen then I don’t want to see any panel (I’ll close it)… so the somewhat simpler look of “Find Only” doesn’t really help. And on the other side I always default to Command-F to “Find” and then it’s a pain when I decide I want to replace to remember the separate command to bring the full interface up.

Am I missing something? Reasonable to always show full Find and Replace?

Jesse

1 Like
#2

Sticking to macOS defaults seems to be the reasonable solution. You don’t want users to get confused with different implementations from the norm.

macosxguru

1 Like
#3

Would it be too much effort to mock up two examples?

#4

This is what I’m currently working with:

Screen Shot 2022-02-09 at 11.35.32 AM
Screen Shot 2022-02-09 at 11.35.32 AM856×184 29.9 KB

The choice would be for the default behavior on Command-F to not show that second row.

1 Like
#5

I generally agree, but in this case the default find UI has all sorts of things I dislike.

  • The “Done” button jumps around when hide/show replace option
  • The visuals look wrong, it’s using “mini” sized controls and things just don’t look right, especially on white background
  • Search options are not visible unless you open context menu. So for example you might be doing case insensitive searches and not know it.

Second as I begin to dig into Apple’s own apps, seems that many already implement their own versions. For example:

  • Pages (all of iWork actually)
  • Xcode
  • Safari
  • Even “Notes” which uses the standard interface has removed the keyboard shortcut to show the Replace UI and mapped it to something else.

This further digging is making me thing it’s OK to just always show “Find and Replace” in full.

1 Like
#6

I am a proponent of elegance, clarity and simplicity in user interfaces.

Your example above is fine by me for the default find UI.

#7

You are right. There doesn’t seem to be a consistent implementation of that. Your current iteration would be fine.

macosxguru

1 Like
#8

I’d vote for two separate UIs. I use CMD-F regularly, to help navigate my complicated list of projects. Having a replace field alongside a ‘search’ field would be confusing/distracting, since when I’m in ‘search mode’, replacing text doesn’t really have anything to do with my intention.

#9

I think it might not be so bad in Bike for a few reasons.

  • First the find is at bottom of screen. So the “replace” row is at bottom of window and I think easier to ignore then if interface is at top.

  • Second when you close the Find & Replace panel I clear any text in the replace field. So that whole replace row is in light ignorable colors by default (since field is empty and buttons are disabled), no bright black pixels.

  • Third I can’t come up with a good alternative design. If there are two modes then I feel like I also need to show a “[ ] Replace” checkbox like macOS Text Edit does. But to me that adds almost as much visual distraction as the separate replace row. Also I will have multiple bottom panel options in the futures and I want “Done” to always be in upper right corner of panel… and replace looks odd unless it’s in upper right.

Anyway please try the next Bike release and see how it goes.

#10

One more related note.

I also have in mind a separate navigation find mode that would be separate from the find and replace that I’m implementing now. The goal is to implement something like Cannon Cat’s Leap feature.

It’s tricky because what makes it really work on Cannon Cat is they have dedicated keyboard keys. But I think something similar can be done without. Once (if… I haven’t actually started work on it yet) that feature is in place I think it would be the preferable way to navigate using “find”.

#11

FWIW I’d be very happy with the TaskPaper style of:

  • CMD-F for Find and Replace
  • CMD-SHIFT-F for search

It sounds like that’s maybe what you have in mind with that “separate navigation find mode”. It’s CMD-SHIFT-F that I use all the time in TaskPaper, and that’s the thing I care more about.

:100:

#12

Ah, that’s actually a third kind of search compared to what I’ve talked about here. That’s also planned, but again won’t make it into 1.0. And I agree when doing that style of “filtering search” replace doesn’t make any sense to put in UI.