And if there were two driving wheels in your car, a one for turning right and an other one for turning left you would say there is no two driving wheels in your car.
A filter is different from searching. It only works on the current directory, it alters the view after it has been generated. You can also use it on a search.
Don't know about others, but I find the functionality useful and use them for different purposes. Searching is when I want to find random messages, where I don't know where or from when there are, the filter is for bulk processing and narrowing the current working set, beside the conversation level.
It is more like the steering wheel and choosing forward/reverse, sure both are for choosing the driving direction, but they operate at different levels and are used in different situations. I mean you could use the steering wheel for forward/backward if you want to. Using the gear to change the direction less than 180° is quite difficult, but not impossible.
Thing is, the 'filter' box can work as a filter and as a search box. It's even a simple heuristic if it should behave as a filter or switch to the search - if there is no result for the text entered in the textbox then switch to the search.
There is zero need to have two search boxes, it's just Mozilla wanted to copy-paste the idiotic solution of MS Office with a top-most search function. That's all.
Do you ever only use one of find and grep? I think they are very similar as the search and the filter bar. I mean you can replace find with tree | grep, not sure about the other way around, but it's probably also possible.
> There is zero need
I do, so it is not exactly zero and I would be annoyed to have them gone, because it is a huge time saver when handling thousands of messages.
> if there is no result for the text entered in the textbox then switch to the search
If the filter starts to draw in messages from other directories, that would be stupid and kind of defeats the point of having a filter in a first place. If you want that why don't you use the search?
> it's just Mozilla wanted to copy-paste the idiotic solution of MS Office with a top-most search function
I don't care where the search bar is placed and I think that functionality did already exist before the current UI, either via ^K or in a menu. I (maybe) do agree with you, in that I don't like putting widgets in window frames (that's for the WM) and prefer classical (CUA-like) menubars.
Can you please criticize the functionality itself? I can't comprehend why you don't see the point of a separate filter. Do you mostly keep messages in the INBOX?
Maybe my original word choice wasn't optimal, because you can consider filtering a subset of searching, but I do consider them to be different. If you rather you use a different terminology, that's fine, but I don't think it will change my point.
It's not a CLI. More so, redundant functions eats the screen real estate, which isn't getting taller on a non-mobile platforms.
> I do, so it is not exactly zero and I would be annoyed to have them gone, because it is a huge time saver when handling thousands of messages.
You sounds like I'm advocating to removal of both the search and the filter boxes.
> If the filter starts to draw in messages from other directories
sigh
You input something in the combined search|filter box:
If you got the result you need from this folder then you just do your thing.
If you did not got the result you need then press Enter which would start the search in the whole mailbox, just like the search textbox works now.
> I don't care where the search bar is placed
Great for you, but I care. TB interface was already far from understandable by both computer illiterate and computer literate and this is just another illogical placement what doesn't add functionality, yet wastes the space.
BTW, did you provided the support to anyone by the phone? Can you be sure what the person on the other side inputs in the right textbox? I can, somewhat, if there is only one. If there are two then 70% of time they would use the wrong one even if telling you it's the right one. I provided enough L1/L2 to know it well.
> Can you please criticize the functionality itself
Yes, there is no functionality need in the two separate textboxes for, essentially, one function: searching.
> Do you mostly keep messages in the INBOX?
Thanks, no.
> because you can consider filtering a subset of searching, but I do consider them to be different
Yes, they both are the methods to find some message/s what you can't just scroll to. And those 'quick filter' buttons near the current filter textbox are quite nice, btw.
My problem is what that search textbox is a clear import from the MS Outlook[0] and it was did only to mimic the other product, without a second of actually thinking if this is even needed.
Just imagine: what if instead of that search box that space would be used for... a filter/search combo textbox, along with a quickfilter buttons, just like today, but not wasting the space for nothing in the window titlebar.
Also I finally noticed what there is even a special combo to invoke the filter so it also can be used to differentiate the usage right away: ctrl+shift+k - filtering, ctrl+shift+f - searching the mailbox.
Just for the sake of it I did a poor man's mock-up:
And, uh, just one more thing: when you do search in TB you are brought to a separate tab with the search result. There is zero need to the search input to stay in the current search box. It's literally useless.
[0] if never even saw it then just search for the screenshots.
EDIT: and about 'heuristic' - there also two ways to do it:
1. just have a toogle buried somewhere, to enable/disable autosearch
2. just do the search automatically, with a low priority and find a way to notify the user what this are results from the other folder. Can be as simple as '--- results from the other folders ---' line.
It is not about the invocation, search and filter bar differ in the same way as find and grep. Even if they are similar, they are still different enough to not benefit from unifying.
>> I don't care ...
I mean that as: I don't object to a different placement of the global search bar.
> My problem is what that search textbox is a clear import from the MS Outlook
I don't know the history and which program's search box predates the other. Note, that the search bar predates the current UI change, see below.
> not wasting the space for nothing in the window titlebar
As I have written earlier, I also don't like UI in the titlebar. But neither do I like yet another omnibar.
I think I should start again with describing how I perceive the functionality:
There is a global (across accounts, folders) search UI, which is a whole different "window"/tab, with different kinds of logical search parameters. The result view is displayed paged, with time, account and folder graphs, but can be converted to a standard message list view.
This can be used when you have no clue and just focus completely on searching random content. The global search bar is just a "button" to open this UI and prefill the search box.
Suppose you have an already existent curated working set of messages. Then you want to select a few and operate on them. This is what the filter bar is for. You don't need to change your focus to a different UI element, it is just a way to pre-select your working set or temporarily restrict your view to focus on just some messages.
Note, how a lot of functionality is in adjusting the UI to support the state of mind of the user.
Enhancing the filter to work across folders is maybe a feature, I don't have a use for that yet. It doesn't makes sense with the current placement, because that indicates, that it is in the current folder frame. I wouldn't implement it like you, I would probably add a checkbox, but that's an implementation detail. But then getting rid of the search bar/functionality is just that, removing functionality.
The alternative way seams to be to merge the filter into the search bar, but that either amounts to the same or means adding a filter to the search to limit it to a specific folder, but this already exists.
> You sounds like I'm advocating to removal of both the search and the filter boxes.
That's because trying to merge them and removing the other, results in getting rid of one of two useful UI-flows. Currently it is also possible to first search and then use the filter on that. This also won't be possible when you merge them.
> Did you provided support to anyone by the phone?
Not yet for TB, but I give you that this might result in confusion. I don't think dumbing down the UI to solely improve tech support over the phone seams worthwhile.
> ctrl+shift+f - searching the mailbox.
That's yet another thing entirely. This invokes a server-side search as opposed to the two client side functionalities we are discussing now.
Interestingly the height is less then any of your mockups. Maybe that is, because I don't have any scaling factor. My display is 1366x768, that results in a maximized window size of 1365x707. So this amounts to 32.5%, yes that is quite some space. I think in practice I tend to just mentally fade out anything above the menubar.
As I got curious, I reinstalled version 102. I remember feeling disappointed about the upgrade, because there was suddenly a lot of useless whitespace, but I didn't remember anything concrete. Here is how it looks: https://ibb.co/n8P2CjB4
That only occupies 25.5%, which seams better. I am surprised how you can now select more then one item in listviews for example in the folder pane and the subscription window. This is a huge deal, because selecting hundreds of folders individually to subscribe to them is just really annoying. I think I definitely like this UI more and don't know why there was this huge UI regression. It also seams to startup faster.
Note, that in both images I have the tab bar, which seams to be missing in all your mockups.
How are the numbers on your computer, as it seams even worse then on mine? Do you still have the same objections to the old UI?
> this is just another illogical placement what doesn't add functionality, yet wastes the space.
Do you have a proposal for placement without merging/removing functionality?