Filter vs Find

feature-request

#1

Something I absolutely LOVE about Path Finder (which is now appearing to be dead and I’m moving over to TotalFinder), is the ability to FILTER by Name, Extension or Kind when in folders. This is far more useful than the usual search / find functionality that Spotlight offers because it allows you to quickly mask out folders’ contents whether it’s Applications, Documents, Downloads, etc. I use it everywhere and haven’t actually used the Spotlight finding functionality for a very long time now.

Search via an integrated find / grep functionality is also frequently useful over Spotlight as well.

Dropdown: https://cl.ly/462K0Z2d352m


#2

Totally agree, ‘the missing link’ to TF perfection ! I would gladly pay for that option or part of an upgrade.


#3

Try EasyFind from the App Store…a friend pointed me to this and it can be helpful.


#4

Although I understand the usefulness of this, I respectfully disagree that it should be added to TF. It seems whenever an app becomes successful at doing one or a few things, people start wanting to add this or that feature, and of course every person feels the feature on their ‘want’ list is the most important. Some developers fall into the trap of wanting to please everyone and begin adding these features, and what was once a small, fast, app that specialized in one thing and did it well, becomes heavier, bloated mess with a mish-mash of features.

Search features are not simple; there is a lot that goes into it behind the scenes. Adding that into TF would probably increase its size and complexity many times over. Other people feel strongly that TF should support FTP/webDAV/, folder synching, file compare and cloud access and on and on. TF starts doing this and next thing you know you are headed down the path (pun intended) to being PathFinder want a be, or Forklift. If I wanted Forklift or PathFinder, I’d being using it, not TF.

I want TF to remain light and fast and focus on the main reason I use it, dual pane side by side display, with a few extras like color sidebar thrown in. I believe if you polled most TF users they would agree, keep it light, just make sure what it does, it does well and without bugs. As reidrik.von pointed out, there are other apps that SPECIALIZE in searching, and other apps that specialize in FTP, and file compare, and folder synching, and so on. I would not want TF to become the new ‘kitchen sink’ finder replacement. I realize people feel that their one feature request is hardly the ‘kitchen sink’, but my point is, where do you draw the line. Today it’s search feature, tomorrow it’s file compare, next day it’s folder syncing… My humble opinion. No disrespect intended to anyone. Peace.


#5

@Michael1 Wtf? Sorry pal, but your arguments make no sense on so many levels there. You’re sitting there preaching about the Unix philosophy regarding an app whose sole purpose is really to just extend another app with various, rather unrelated features. It’s not like TotalFinder, PathFinder, or what have you are particularly good at one thing and one thing only. That’s simply not their purpose. Which is not to say that’s a bad thing, as the Unix philosophy is not always a good rule to adhere to.

On top of that, we’re just talking about a filtering feature for crap’s sake. How much bloat will that add to the app? A few subroutines? Maybe a library dependency? If you’re really concerned about bloat that minute, don’t use OS X as you’ll find many common apps far, far, far too bloated for your taste.

Even on top of that, what’s wrong with people asking for more features from TotalFinder? Isn’t it already aspiring to become like PathFinder, etc.? I mean, again, all these sorts of apps are doing anyway is just adding on a random, nice mish-mash of things to the existing Finder app. So what’s wrong with adding more? Especially with features like this which are so small. It’s not like the app has to load in all of its features into memory at once (duh)


#6

Well @your_average_daemon has most certainly hit on a lot of very important and valid points. I have to admit, I was trying to figure out how to reply to @Michael1’s remarks without sounding like a total rear and I’m grateful for the points that have been broached.

Being a developer myself and having a bg in cs, I can say that a filtering functionality is not going to add much in the way of bloat. I could see adding a lot of extra logic such as doing something special with FTP could add bloat (but Finder / TotalFinder already supports FTP via the default macOS functionality for FTP mounting… unless Apple removed it? Heck, I’ve not used FTP in Finder for years now anyway and use other apps to mount my SFTP shares, etc.).

The bottom line is that filtering is indeed a minimal feature. And honestly, you know what, I love Path Finder. Path Finder is amazing and blows away both Finder and the TotalFinder additions layer, but it’s been struggling it seems. I don’t think the developer has been doing too well thanks to a lot of deaf ears in their support department. That leaves the door wide open for TotalFinder in some of these key areas. Having the ability to grep through large lists of files in list view (or other views if you prefer) is critical and a “no duh” functionality that Apple should have included from the start due to it being such a small footprint and necessary function. File management, with this functionality, is a huge help when used visually vs in the shell.

Finder is definitely supposed to be a Swiss Army Knife. One can even argue from a UX standpoint that Web 3.0 is not about the semantic web, but rather going back to the Web 1.0 days of larger aggregate services - a la Amazon. The simplex “unix” way of compartmentalizing things is great only from a tool builder’s perspective, not a user’s perspective. We can have a very long discussion about this very topic and it is interesting, but yes, compartmentalization is being overused at present and is being misrepresented. (Interesting side note: it’s also a problem with American and Western sciences; specialization vertical approaches are not as effective and proving to be a downfall vs lateral horizontal understanding and/or team building, etc. Again, another long and interesting topic! :smiley:)


#7

BTW @reidrik.von not really wanting separate finding functionality. Just wanting superior organization and manipulation of content within Finder for the filesystem directly in such a way as to move things around more efficiently. I’ve had EasyFind for years, but it’s never fit the bill for this particular use case. Path Finder is my goto for this, but TotalFinder definitely needs this functionality to be competitive in this area.


#8

@Recuerom if this feature request goes south, you might want to put your paid support towards Path Finder as this already works super well in it. As I noted in the other post, I am worried about the future of Path Finder and so I’m hoping to see TotalFinder pick up the critical areas such as this minimally viable functionality for a file manager in today’s environment. I own both products and like to keep my options open!


#9

@your_average_daemon: Is it really necessary to use vulgar language and resort to personal attacks in response to a simple post about software function? Seriously? (Perhaps using ‘wtf’ in your opinion is not vulgar but every day language for you, but in my book, directing that a stranger IS vulgar, and at a minimum certainly rude and uncalled for). You could have just said ‘I beg to differ, here’ why’. In any case, I will respond to some of your points objectively without personal attacks.

It is important to see the forest through the trees. Whether the actual amount of code or effort to implement said filter feature is great or small was not my focus, the ‘bloat’ I’m referring too is one of philosophy and user perception. Philosophy: what does the dev envision as the path the software should take. User perception: how does the way that users use and perceive the app effect the way they use it or choose not to use it. If you focus on just the immediate technical aspect of feature enhancement, which typically developers do (what’s the effort, how much code does this add) then its very easy to overlook these EQUALLY important questions. That is how ‘feature creep’ starts. That is why in most successful software companies, especially INCs, Marketing dept drives product development, not Development.

In my 40 plus years working in the Si Valley, from a grunt at a startup to C-level of Fortune 50 (that’s fifty, not five hundred), I’ve seen more ideas and fledgling apps fall by the way side and DIE due to over emphasis on the technical (How to do something), and lack of consideration on ‘what are we doing here? what is our plan?’ (WHY are we doing what we are doing, or not doing). You state: “Isn’t it [TF] already aspiring to become like PathFinder, etc.?” Do we know that? HIstorically, it would seem the answer is no. TF has been around years now, and has remained essentially very close to original conception. If you read these forum posts going back many years, Darwin has been asked MANY times to add this or that feature. All of these suggestions taken as a whole, if implemented, would have made TF by now an app approaching Pathfinder or Forklift territory, not equal, but certainly closer that direction than what it is now and remained.

In general, TF has stayed close to its initial mission, as an enhancement to Finder (not a replacement) with the main selling point being dual pane function and being responsive and able to get out of your way (think VISOR mode). This is reflected in the design architecture Darwin has stayed with, using code injection, versus creating a stand alone app like PF or Forklift.

The ‘bloat’ I refer to is one of philosophy and user perception and expectation, as I said, not necessarily if it is ‘a few subroutines or a library dependency’. Again it’s the WHY you must answer first, not the HOW. A feature might require 10 lines of code to implement, does that mean every feature that only requires 10 lines of code should be implemented? I presume even you would say, ‘duh’ of course not, it DEPENDS. Does the feature fit the philosophy or purpose of what the app is intended for, OR PLANS TO BE IN THE FUTURE? Instead of search filter, what if someone said “Hey, I know what would be cool, I really want TF to be able to sync folders, since ‘obviously’ if i have two folders side by side, who wouldn’t want to compare them, and if I’m going to compare them, then the next ‘logical’ step is to be able to sync them.” But why (or can you) stop there? Then the next user comes along and says, “Well, TF can sync local drives, why can’t TF auto connect to my cloud repositories and sync across the cloud? And not just 1 to 1, but 1 to many?” And then the next user says “But I need to be able to define rules, like Chronosync, to manage the syncing…and not just just mirror synching, but differential synching, and bi-directional, with roll back and archiving in case I make a mistake, and … and…”. That’s how the spiral starts for so many apps and companies. THAT is how Pathfinder 1.0 ends up being today what we see in Pathfinder 7.0

Let’s set aside for a moment what is required technically to implement a feature (10 or 10,000 lines of code, whatever). First, you should consider, what does this mean for the future, does it fit the philosophy of what the app is, was meant to fit, what I want it to be? What user EXPECTATION does this meet or not meet AND what does it set up for the future expectations of users if I start adding features without a plan? If I open ‘the door’ I can’t close it, will users expect more and more because I chose to add a few features that at the time seemed easy to do and reasonable, but in hindsight, has now created an expectation that TF is looking to become more than just a dual pane enhancement to Finder (e.g. PathFinder or Forklift.) Only after Devs answer that first, then you look at the technical. “CAn I do that just with code injection?”. Am I headed down a road by taking this seemingly simple ONE step to where I have to reimplement the app as a stand alone app? (Probably, there is limit to what you can do with code injection, and good chance Apple will eventually find a way to kill that back door too for various security reasons.) What is the effort, not just programmatically, but personally to me in time, commitment, SUPPORT, bug fixing, cost, THE PRICE I HAVE TO CHARGE TO MAKE IT ECONOMICALLY MAKE SENSE. There is a reason TF as it is now is $12 and PathFinder is $40. I may GAIN some users, but I may also lose some users. As a dev, those are the questions you need to consider, not just “oh, that’s easy, it just a subroutine, and ‘that would be cool’”

So, I never said there was problem with users requesting features, no problem, I simply said my PERSONAL preference is that TF stay light and focus on its strength. You and others are only looking at it from a technical aspect and that it is just ‘one feature’. After 40+ years, I can tell you, it is NEVER about just ‘one feature’. Everything you do or don’t do impacts and sets up what you do in the future. As i said before, 'Where do you draw the line?" Users are extremely fickle and most have no sense of loyalty, (nor should they, use what fits YOUR workflow, vote with your wallet). If Darwin wants one day that TF should have more PF like features, increases the price to $20- $40 to cover his time and effort, complicate his life 10x over by the need to support all those features, (which no amount of money can compensate for) that’s fine his choice. My choice as a user I would probably stop using it, but that’s me. If the users he gains offsets the users he looses, that’s fine, good for him. Even if it offsets on a monetary basis, I can tell it will not, as an independent dev, offset the increased complexity in Darwin’s personal life.

Look at the Macupdate forum, look how many users TURN on an app and the developer because of perceived ‘slight’ because the developer was ‘stupid’ to not adopt their ‘great’ idea that feature A should be added, or the reverse, feature A is added, but because the developer did not have a clear idea about implementation or usability and where the app was headed, and just reacted to user demands, it is implemented so poorly, they get slammed for making a mess of it. You will never please every user, so consider carefully what you do. In this day of social media and online software reviews, it doesn’t take much for a disgruntled user to bring down an app, even a company. Social media has made it so easy for a user with an axe to grind to bring a small, indie developer to his knees.

Suppose a user posted an opinion that TF sucked because it paled in comparison to PF? Your reaction might be that the user is misguided because TF isn’t supposed to be a PF competitor. But that users opinion and your reaction to it are both determined by your personal bias and perception each of you thinks TF is and supposed to be. Right or wrong is secondary; as developer, Darwin ultimately decides, what user group am I targeting to satisfy. When he decides that or sticks with it, that guides how he markets the app to promote the ‘perception’ he desires, and ‘demote’ the perception he doesn’t desire. It guides his development road map, the price structure. If he decides TF IS meant to grow more complex, then he has to consider the long term business (can he do it alone? will he have to sell the app to a bigger company that has the resources? hire help? What is the impact to his personal life, in time and impact to wife, kids?)

I suspect what you are thinking right now, is that I’m over reacting, adding one little feature doesn’t mean TF is heading down the road of ruin, doesn’t mean it is becoming Pathfinder. That’s not what I’m saying. I’m simply saying, I"ve seen SO MANY ideas and apps that started down the road of “Let’s just add this.” and lost all sense of direction, and ultimate lost users, the market, and their opportunity. Look, I have no problem with Pathfinder or Forklift, I’m a registered user of both. Used Forklift since version 1. At one point when it looked like Darwin was abandoning TF due to problems with SIP, I switched to PF as my daily tool.

I have nothing against adding features to any app, contrary to what you and ylluminate think, but can’t be done in a vacuum just because it’s easy or simple to do or because some users ‘really want it’. For 90% of MY workflow, I use TF because it is seamless and the ‘perception’ of being light, I’m ‘in and out’ it doesn’t get in my way. Any user would be hard pressed to say that PF or Forklift feels ‘light’. If I want WebDav, Amazon S3, folder compare, etc, I’ll fire up PF now and then, but I like falling back to TF for the 90% of what I need. TF fills a niche, PF and Forklift fill a different niche, not better or worse, just different, the price and the level of support reflects that for each. I tried to switch my wife from TF to PF when I thought TF was end of life. She did not like PF because she didn’t need 80% of what it does, too many menu items, too ‘busy’, and preferred TF so much so she’d rather stay on Yosemite or run El Cap with SIP off (in this day and age, security and all, running with SIP off is not what I think average NON-technical users should do. Okay for me, not my wife, can’t look over her shoulder every second or tell her what she apps are safe or not)

So, see the forest through the trees, don’t make this about what it would take programmatically to implement filter or any said feature. You’ve heard the saying, you don’t buy a sports car to drive to the corner grocery store. And you don’t criticize a Toyota Tercel because it doesn’t drive like an Audi sedan, because that isn’t what a Tercel was meant to be. And you don’t criticize the Audi because it costs 10x more than the Tercel, because that isn’t what it meant to be.

Darwin might implement this filter or any xyz feature and it might end there and be okay, OR it might open the barn doors from which there is no going back and start the ‘feature creep’ that has KILLED so many apps and companies. End of the day, his call, I simply expressed an opinion, you expressed yours, (although felt the need to use vulgarisms).

Peace be with you.


#10

@Michael1 First of all, where I come from, terms like “crap” and “wtf” are rather mild phrases to use (“f” doesn’t necessarily stand for f*ck in my book) so I apologize that you took it so offensively. Since your above posting is so long, I’ll only reply to it in general since I don’t have time to respond to each point there. I understand that you’re just expressing your opinion and trying to get the point across that feature creep is an easy thing to fall prey to. I actually think that feature creep is not really a bad thing if done right so that things are efficient and well-organized (disclaimer: I’m an Emacs user so take that with a grain of salt :wink: ).

As you say, I do think that you’re overreacting here. Although TF, PF, etc. fulfill their own niches that doesn’t mean that there’s anything wrong with just expanding that niche a little bit. Not to mention, PF hasn’t gotten a stable release since 2014 and no one is suggesting the kinds of features in Forklift such as remote connections, syncing, etc. So just keep in mind the context here and don’t talk about these sorts of principles in a vacuum. Just because one feature request gets through doesn’t mean that the flood gates are open and we all need to board the ark for safety.

You’re right in that there may come a point where you want to draw the line if you feel that other apps already do want you’re planning on doing and they do it better. But there is such a thing as drawing the line too early. You make it sound like each decision for a new feature must become a matter of principle so that one avoids feature creep. However, if you apply that mindset to minuscule features like this, your software will ultimately stagnate and users will likely become dissatisfied.

I appreciate that many apps die because they take on too many feature requests and design it poorly or implement it poorly, etc. However that needn’t be the case and it likely will not ever happen for small features like this which are frankly hard to screw up. It’s not like TF is going to lose its “lightweight-ness” even by adding dozens of little features like this, as long as they’re implemented efficiently and tucked away from users that don’t want to see them.

One more point here: folks should keep in mind that the Unix philosophy (do one thing and do it well) was designed with operating system architecture in mind. It made sense to implement things as independent little chunks that would then be glued together. This was good for system design as it emphasizes simplicity above all else in each program. But this approach makes sense at a more foundational level than at a user-interface level. Some reading on this topic as it pertains to Unix:

I realize that you have not mentioned the Unix philosophy explicitly, but your ideology here has probably been influenced directly or indirectly by the Unix philosophy so I think it’s important to note these points.

Anyway, what I’m really trying to say here is that this kind of principled design thinking that you’re talking about is something that should not be applied indiscriminately. Otherwise, you end up asking yourself these kinds of big questions when it really might not matter. It seems to be a problem with many people nowadays(?) that they get too caught up in applying principles all across the board even for little things that just don’t matter.


#11

Thanks for the apology, we’re cool :wink: I grew up in a generation where we still addressed people of seniority as ‘Sir’, not in a militant way, but as a sign of respect. The market is big enough to support many options, and price points. I trust Darwin and Co. to steer the product successfully.

If you want, take a look at an app called Commander One if you want an example of a train wreck that can happen when there is no plan or vetting process in place.


Started out as a dual pane file manager ‘want a be’, showed promise early on, started adding features left and right with no clear view of design or structure, has come off the rails while trying to figure out what it wants to be when it grows up. Example of how NOT to do a dual pane file manager.
Peace


#12

If you are looking for an easy way to find things, EasyFind is great. You can customize the type of search to do and the starting point as well. It is not crippled, unlike Spotlight. It is even free.


#13

So just to let you know how critical this feature is to me, I have had to stop using TotalFinder and moved back to Path Finder. It’s just impossible to use Finder / TotalFinder without being able to filter large folders. I work with a lot of documents and files for various and many projects and the inability to filter (NOT FIND) is extremely critical to my / our ability to find things.


#14

I need to tell you developer: the fella who says filtering is not needed is full of shit. I have been looking for an option in 10.13 since Path Finder has been ignored by its developers and TotalFinder would be totally viable if it had filtering to quickly filter through large file sets. It’s sad idiots like that get involved in these conversations because it adds NO value at all to this product. The bottom line is that TotalFinder NEEDS filtering and it needs it NOW.