Find UI inconsistent...
-
Hello everybody!
While loving NPP and using it every day I noticed that the Find window UI is very inconsistent, so I’m proposing some mostly cosmetic changes that I think will make it much better.-
The “Close” button should always be in the very same position of every tab, visually separated from the other buttons, or even NOT in a tab but outside any tab, or removed altogether (the popup window close button is sufficient, i think).
-
The “Find in all open docs”/“Replace in all docs” should be in the same position in the two find/replace tabs, since they work similarly…
-
Find / Replace / mark should have coherent ui, since they are variants of the same operation, only find in files should be different.
-
Find /replace / mark should all have the “in selection” option, and the option should affect all the commands (why can’t find search in selection but only count in selection, and replace can?)
-
Shouldn’t find/mark be the very same function, only different buttons in the very same find dialog? Find all works as mark all, except one marks results and the other puts them in the search results…
-
Shouldn’t the up/down arrows in find next/prev reverse their directions when find backwards is on?
-
Maybe also find / replace / mark should have the very same tab, since they work both the same way? As it seems, the find next/prev and such both work the very same, in the three tabs, and what only differs is the replace / replace in all button…
-
I think “find in files” is not a clear name for the tab, it is very misleading if compared with the “find in all opened files” button in the find tab… Wouldn’t “Find in folders” a better name that would clarify the difference better?
-
The “transparency” box shouldn’t be here… It’s a setting, and it belongs to the “settings” dialog, in my opinion. A direct link to that option could be provided here, but it should not be here as a whole.
Looking forward to your opinions on that!
-
-
Also, I think a good UI idea for the find command should be:
First section: Find what (all the Ui that lets me choose what to find)
Second section: Find Where (all the ui that lets me choos where to find it: selection, file, all open files (, folder?)
Thisr section: What to do with what have been found: replace, mark, count, etc…This way of organizing the find ui would be MUCH more intuitive, and could easily be a SINGLE ui for all the find related functions instead of four different tabs.
Also, this could be used to run through find results decinding for each of them if I need to replace it, mark it or go to the next one… Much more ergonomic!
-
Interesting ideas…thank you for your posting.
- The “Close” button should always be in the very same position of every tab, visually separated from the other buttons, or even NOT in a tab but outside any tab, or removed altogether (the popup window close button is sufficient, i think).
Valid points; possibly the only argument for keeping it as a button is that it allows a user to customize a alt+__ keycombo to activate it. For myself,
Escor clicking the X button with the mouse is sufficient when wanting to dismiss the window (but as I have multiple monitors I always prefer the window to be open–on a secondary monitor).- The “Find in all open docs”/“Replace in all docs” should be in the same position in the two find/replace tabs, since they work similarly…
I don’t see a reason this needs to be so.
- Find / Replace / mark should have coherent ui, since they are variants of the same operation, only find in files should be different.
Not sure what is meant by “coherent” UI, unless you mean “combined”, but you state that below in points 5 and 7, so I’m kind of confused on what you are saying here in this point.
- Find /replace / mark should all have the “in selection” option, and the option should affect all the commands (why can’t find search in selection but only count in selection, and replace can?)
As to “why?”, the complexity of changing existing code is the only reason I can think of. I’ve had a look at these sections of the source code, and I do see the difficulty (but not impossibility) of making such a change.
BTW, have you noticed that if you make multiple selections that you can’t quite do count-in-selection or replace-all-in-selection correctly?–it will only count/replace in ONE of the selections. And you can’t even do a Count or a Replace All in a selection if the selection is rectangular. These aren’t UI problems (which is the topic of this thread), but I feel these deficiencies should be addressed.
- Shouldn’t find/mark be the very same function, only different buttons in the very same find dialog? Find all works as mark all, except one marks results and the other puts them in the search results…
“Find all in current doc” and “Mark all” are similar in the way you suggest, with the exception that marking can be done in a direction while "Find all"ing is always of the “entire file” nature.
- Shouldn’t the up/down arrows in find next/prev reverse their directions when find backwards is on?
I don’t think so. The “backward direction” checkbox remains for 2 purposes: If the user chooses to have a single “Find Next” button instead of “2 button mode” (although why someone would do that I do not understand), or for when someone presses the Replace button (the program needs to know where to look next, as the Replace button’s real function is “Replace and Find Next”).
- Maybe also find / replace / mark should have the very same tab, since they work both the same way? As it seems, the find next/prev and such both work the very same, in the three tabs, and what only differs is the replace / replace in all button…
It does seem logical that the Find and Replace tabs could be combined into one. The Mark tab has 2 functions (“Bookmark line” and “Purge…”) which would make it awkward to combine with Find/Replace, but perhaps if they were renamed slightly it would be clear that they only affect marking and clearing marks. Or perhaps it is reasonable sometimes when doing searches/replacements to also bookmark lines? Hmm…
- I think “find in files” is not a clear name for the tab, it is very misleading if compared with the “find in all opened files” button in the find tab… Wouldn’t “Find in folders” a better name that would clarify the difference better?
Perhaps what solves this “problem” would simply be moving the “Find in all opened files” button to the “Find in Files” tab?
- The “transparency” box shouldn’t be here… It’s a setting, and it belongs to the “settings” dialog, in my opinion. A direct link to that option could be provided here, but it should not be here as a whole.
It does seem awkward in the Find family windows; it is rarely changed (or even used, in my case). However, as long as there is screen real estate for it here, I guess it is okay.
Also, I think a good UI idea for the find command should be…
This is calling for greater change. My suggestion to you would be to write a plugin that implements this kind of functionality. That way, people could really see what you are suggesting, and they (and you) could actually use it if it is chosen not to be (functionally) integrated into Notepad++ core by the developers.
-
@Alan-Kilborn said in Find UI inconsistent...:
The “backward direction” checkbox remains for 2 purposes: If the user chooses to have a single “Find Next” button instead of “2 button mode” (although why someone would do that I do not understand), or for when someone presses the Replace button (the program needs to know where to look next, as the Replace button’s real function is “Replace and Find Next”).
I should have added a 3rd purpose for the “backward direction” checkbox: Setting the direction from the caret to mark text when using the “Mark all” command, when “Wrap around” is not checked.
Although…when I “mark” text, 99% of the time I want the entire document marked, and I get annoyed at Notepad++ for not doing the whole doc by default but rather making me tick the “Wrap around” box. Usually it is a go-back-and-tick-it-and-remark effort. :-(
Also a 4th purpose: Replace-all when “Wrap around” not ticked – the Replace-all needs to know which direction to move from the caret in this case.
-
-
The reason I see for these two buttons to be in the same place, is that they have the very same meaning: the operate on all the results of the search, one by placing the result in the result window, one by replacing the result with the replacement string.
-
By coherent UI I mean that since they do really work in the same way (tell the program what to search, how and where, and then execute an action on what is found) and the only thing that changes is what to do with the results, even if kept on different tabs, the UI should be similar, just as in the fact that the close button shouldn’t change position…
-
I didn’t know that find doesn’t operate in multiple selections… That is worse than I expected! :) I think that as a minimum this limitation should be clearly conveyed, for example by disabling the “in selection” checkbox if the selection is multiple or rectangular, or any other condition that makes it not work properly, just as it happens now when no selection is present; and I think that “find in selection” is a VERY MUCH needed functionality!
-
So you’re saying that “find all in current doc” does NOT respect “backwards” and Mark all does? If that is the case, then the UI should reflect this, and that is not the case now…
-
I discovered only now (sorry!) that if the find button is split then it does NOT change meaning when backwards is on… Again this is very misleading: then it’s ok that arrows do not change on the split buttons, but then the single “find next” button should have an arrow that changes direction when backwards, or change its text to “find previous” (I mean, something should clearly indicate that the function has changed…)!
-
Mmm, the mark tab should in my opinion have two buttons: Mark all (meaning all marks are removed and new marks are set) and “Add marks” (meaning add the results as marked items to the marked items list), this would make it much more clear and intuitive; or a “purge marks before marking” option could be added that the user can flag before clicking on “mark all”.
Also, I discovered only now that there are two different kind of marks: marks and bookmarks, and they are not the same, and the mark tab UI doesn’t at all make this clear, and it works strangely: if I leave “bookmark line” off, then marks are set and marks are purged, if I set it the BOTH marks and bookmarks are set and are purged, but this is very messy and unclear…
- That would be a solution worse than the current UI: then the “find in all opened docs” would be in a tab with the folder selection field, field that would be completely ignored if clicking on “find in opened”… That would be, if possible, even muddier! :)
added) So “Replace” is in fact “replace and find next”? It’s nice this works this way as it is ergonomic, but it should be clear from the UI…
That makes me think that this UI REALLY needs a complete overhaul, and that my idea is even more useful: the UI should have a three section structure: what (and how) to search, where to search, and what to do with the results.
As for writing a plugin to show a mockup of my proposal, I think I’m not able to do this, since (am I wrong?) npp is written in c/c++/c# and I don’t know these languages… Sorry!
-
-
4…I didn’t know that find doesn’t operate in multiple selections… That is worse than I expected! :) I think that as a minimum this limitation should be clearly conveyed, for example by disabling the “in selection” checkbox if the selection is multiple or rectangular
Or an even better solution would be to actually make it work right! :-)
4…I think that “find in selection” is a VERY MUCH needed functionality!
I agree!
5…So you’re saying that “find all in current doc” does NOT respect “backwards” and Mark all does? If that is the case, then the UI should reflect this, and that is not the case now…
It is a bit strange; you get used to it I guess (but that is not an excuse for a bad UI, if indeed the UI is bad – I’m non-committal)
6…the single “find next” button should have an arrow that changes direction when backwards, or change its text to “find previous” (I mean, something should clearly indicate that the function has changed…)!
Well, if one glances at the “Backward direction” checkbox’s state, one obtains this information. :-)
7…a “purge marks before marking” option could be added that the user can flag before clicking on “mark all”.
Ummm, there is already a “purge” checkbox option of this nature.
I discovered only now that there are two different kind of marks: marks and bookmarks, and they are not the same, and the mark tab UI doesn’t at all make this clear
I like calling marking “redmarking” because it tends to deliniate the two forms more, but it is a user-customizable color and can be changed away from red, so maybe that is why it isn’t called redmarking by the program?
and it works strangely: if I leave “bookmark line” off, then marks are set and marks are purged, if I set it the BOTH marks and bookmarks are set and are purged, but this is very messy and unclear…
The “Bookmark line” checkbox controls the bookmarking function; I don’t think it is all that bad.
8…That would be a solution worse than the current UI: then the “find in all opened docs” would be in a tab with the folder selection field, field that would be completely ignored if clicking on “find in opened”
From the name of the button (“find in all opened docs”) it seems pretty clear that it would ignore things like the folder selection field.
So “Replace” is in fact “replace and find next”? …That makes me think that this UI REALLY needs a complete overhaul
So a lot of these issues (including this one) are resolved by spending some serious time with these functions. If you didn’t know that “Replace” was “Replace and Find Next”, then you haven’t spent much time with this UI. Which maybe doesn’t give you much standing in complaining about it. Can it be better? Yes, definitely, but that can be said about practically any feature of any software.
my idea is even more useful: the UI should have…
Putting together a consistent and cohesive UI for these functions is not easy. Opinions vary; you can’t make everyone happy with everything.
As for writing a plugin to show a mockup of my proposal, I think I’m not able to do this, since (am I wrong?) npp is written in c/c++/c# and I don’t know these languages…
Haha, pass the buck, eh? :-)
-
@Alan-Kilborn said in Find UI inconsistent...:
6…the single “find next” button should have an arrow that changes direction when backwards, or change its text to “find previous” (I mean, something should clearly indicate that the function has changed…)!
Well, if one glances at the “Backward direction” checkbox’s state, one obtains this information. :-)
That is not clear enough, IMHO.
7…a “purge marks before marking” option could be added that the user can flag before clicking on “mark all”.
Ummm, there is already a “purge” checkbox option of this nature.
You’re right, I was missing it… That again shows that options aren’t clearly organized, since they mix “what/how to search” options with “what to do” options… :)I discovered only now that there are two different kind of marks: marks and bookmarks, and they are not the same, and the mark tab UI doesn’t at all make this clear
I like calling marking “redmarking” because it tends to deliniate the two forms more, but it is a user-customizable color and can be changed away from red, so maybe that is why it isn’t called redmarking by the program?
I understand this now, but it remains very muddy if glancing the UI, IMHO.
and it works strangely: if I leave “bookmark line” off, then marks are set and marks are purged, if I set it the BOTH marks and bookmarks are set and are purged, but this is very messy and unclear…
The “Bookmark line” checkbox controls the bookmarking function; I don’t think it is all that bad.
I instinctively would expect his to toggle between marking and bookmarking, not to toggle between marking and marking+bookmarking; a better name would be “Also bookmark line”!8…That would be a solution worse than the current UI: then the “find in all opened docs” would be in a tab with the folder selection field, field that would be completely ignored if clicking on “find in opened”
From the name of the button (“find in all opened docs”) it seems pretty clear that it would ignore things like the folder selection field.
That IMHO isn’t good ui design: if we follow your argument then the “replace with” field can be left visible and operational even in the find tab, where it does nothing…
So “Replace” is in fact “replace and find next”? …That makes me think that this UI REALLY needs a complete overhaul
So a lot of these issues (including this one) are resolved by spending some serious time with these functions. If you didn’t know that “Replace” was “Replace and Find Next”, then you haven’t spent much time with this UI. Which maybe doesn’t give you much standing in complaining about it. Can it be better? Yes, definitely, but that can be said about practically any feature of any software.
Sorry, but no: there is a specific functionality in the software which is Incremental search, and that made me instinctively think that replace button wasn’t incremental… That is not a clear ui, no matter how many times I’ve used the Replace button, as it has convinced me that the replace button is NOT what I needed and that I should find this functionality in another place…
In other words, a good UI not only eases using it, but also eases finding the correct tool for your needs.
my idea is even more useful: the UI should have…
Putting together a consistent and cohesive UI for these functions is not easy. Opinions vary; you can’t make everyone happy with everything.
I’m pretty sure that no choice ever pleases everybody, but while generally NPP has a good interface, that can please moste users, IMHO the find UI is the most confusing part of it.
As for writing a plugin to show a mockup of my proposal, I think I’m not able to do this, since (am I wrong?) npp is written in c/c++/c# and I don’t know these languages…
Haha, pass the buck, eh? :-)
Sorry, but while surely I’ll give my free time to OSS developement and testing (especially for a good OSS as NPP), my free time is limited and would be depleted long before I would be able to contribute usefully to NPP CPP code!
That said, I fully understand that this is an OS project, so that contributions are totally voluntary, and I cannot for sure ask or pretend nothing, and I’m absolutely grateful I can use NPP for free!
-
Why not spec out a complete redesign of the Find UI right here with mocked-up screenshots and text? That way you don’t have to program anything so the programming language isn’t an issue. Then, if someone that can program it agrees, they can try their hand at it?
You seemed to do a lot of saying “this is bad… that is bad…” but to this point haven’t provided a lot of specifics on what changes should be made. To be fair, though, you have provided some general ideas. I’d like to see that turned into some really concrete specs for a redesign.
Again, good discussion, thank you for that.
