Should Spotlight overtake Finder?

[TrenttonY]

Is anyone sick of using Finder in its current form? I feel like I'm still in the 00's. Finders main purpose when it was created was to organize all of your junk in a UI; to be able to use folders, search, rearrange, etc. When iOS was created this was never needed, why? Because we used apps. You wanted to play music you opened the Music.app, you wanted to make a document you opened the Pages.app and thats how the data was organized, simple concept. Why can't this be taken to OS X? Lets get rid of Finder in its current form of being an app and just incorporate it into Spotlight. What if when you searched and clicked on something in Spotlight, it didn't just open a Finder window but the Spotlight UI itself just expanded to accommodate whatever your doing. It could support dragging and dropping inside the UI, etc.

Now I know some of you hardcore Finder users will not like this, but I don't think the majority of Mac users would mind, heck it may even be beneficial to these type of people because they want simple (thats why they buy Macs and Apple products in general). But they could always give us an option for either way.

And another subject as it is related to Finder:
Why is Launchpad called Launchpad with a rocket icon?
Why can't it just be called "Applications" with either an icon thats shows your app icons stacked on top of each other or a folder icon with the applications logo on it?
When opened it still uses the the same Launchpad UI, but only shows the applications that are not already on your dock. Isn't it so annoying how the apps you have on your dock are still in the Launchpad UI?

Like this:


OR:


And when you click on it it uses the same UI of Launchpad.

So many inconsistencies between OS X and iOS. I get you want some diversity between the two but I think most would agree some things need to be consistent.​

 

[F1Mac]

So many inconsistencies between OS X and iOS. I get you want some diversity between the two but I think most would agree some things need to be consistent.​

The thing is OS X is a desktop OS, while iOS is a mobile OS. That's 2 radically different concepts, despite the constant iOSification of OS X. You still have to be able to VISUALLY navigate your documents, folder hierarchy, etc. My computer is a little more than a big iPhone.
[doublepost=1462188167][/doublepost]

Now I know some of you hardcore Finder users will not like this, but I don't think the majority of Mac users would mind, heck it may even be beneficial to these type of people because they want simple (thats why they buy Macs and Apple products in general).

No it's not. I've been using Macs for 20 years and "simple" has never been the reason why I used them, and I don't think I'm an exception. You're just talking about one type of "users". What I think is that the "majority" (whatever that means) of Mac users don't mind the Finder. And those people who "want simple", they couldn't define the Finder's purpose even if you spelled it for them anyway. Some don't even know it's called "Finder" - and I'm not joking. That's the kind of users Apple is aiming at these days.

 

[maflynn]

Is anyone sick of using Finder in its current form?

No

When iOS was created this was never needed, why? Because we used apps.

Yes, and you can only use a single app for a given document type and you have little say in where its located, i.e., you cannot organize the data to suit your needs in iOS. Yes, there's work arounds, but overall iOS is very restrictive because you do not have access to the file system.

Look how hard is it to attach multiple files of varying types in an email in iOS.

I prefer the Finder because I can setup my files and data in a way that makes the most sense for me and my work flow.

 

[TrenttonY]

No


Yes, and you can only use a single app for a given document type and you have little say in where its located, i.e., you cannot organize the data to suit your needs in iOS. Yes, there's work arounds, but overall iOS is very restrictive because you do not have access to the file system.

Look how hard is it to attach multiple files of varying types in an email in iOS.

I prefer the Finder because I can setup my files and data in a way that makes the most sense for me and my work flow.

I understand your points, but I don't think you understand my idea fully. Basically put the whole finder in the Spotlight UI. All the features, etc, just in a better UI (which spotlight is).

 

[beebarb]

You'd really want to LIMIT how a desktop machine or laptop can be used, because you don't like the thing that is used to navigate the filesystem?

The only reason iOS devices DON'T have that, is because they're sandboxed, and every file is pretty much restricted to the application that created it.

What you are proposing would be crippling to productivity.
Even if by some chance it worked, it wouldn't be practical.

Spotlight's search indexes can be corrupted.
A corrupted index would end up with duplicate entries, or files not able to be found because the index thinks they don't exist, or files that no longer exist still being listed.

Desktops are primarily production machines, mobiles and tablets are primarily consumption devices.
What works on a mobile phone, does not always work on the desktop, and vice versa.

Android phones have file managers such as ES File Explorer, because unlike iOS they don't try to wall off applications, and pretend a filesystem doesn't exist.

 

[maflynn]

I understand your points, but I don't think you understand my idea fully. Basically put the whole finder in the Spotlight UI. All the features, etc, just in a better UI (which spotlight is).

I understood your point, but why use a search tool for all of your file management needs, when you can organize your files.

For instance, I'd rather not dump all of my pictures I take in a single folder, sure I can do that, and use spotlight to find them, or I can organize them by year and type to effeciently work on them.

Another example, I'm working on a given project, its better to have each document for the project be in its own folder. How do I do that, with Finder. Doesn't make sense to not organize it, especially if start using similar names.

 

[KALLT]

I do not use Spotlight like that. I have a mental model of where my files are located. I probably have thousands of files with similar names and Spotlight failes me every time when I need to find something specific that I know where to find. It just is no substitute. Spotlight is great for generic searches or for finding unique things, but Finder has a much more powerful interface with hundreds of search filters.

 

[T'hain Esh Kelch]

Do you honestly assume you know the names of all files you have on your drive?

Finder is BY FAR more powerfull than Spotlight. Spotlight doesn't even come close as a file manager. Even on iOS it is severely limiting.

 

[Partron22]

Spotlight is built to hide many files from the user.
If you want a filesystemless OS, use an iPhone.
Those of us who actually want a file system need Finder.
That said, Apple really should work on making Finder work better.
They've been slighting it for several years now, and it shows.

 

[redheeler]

And another subject as it is related to Finder:
Why is Launchpad called Launchpad with a rocket icon?
Why can't it just be called "Applications" with either an icon thats shows your app icons stacked on top of each other or a folder icon with the applications logo on it?
When opened it still uses the the same Launchpad UI, but only shows the applications that are not already on your dock. Isn't it so annoying how the apps you have on your dock are still in the Launchpad UI?
Like this:


OR:


And when you click on it it uses the same UI of Launchpad.

Because the Stacks feature is a different folder-based way of organization, and that's what the folder icons on the right side of the Dock have always meant. Launchpad is an app for launching apps which emulates the iOS home screen on a Mac, and it's just like Mission Control or Dashboard which act like standalone apps and can be placed in the Dock (even though the apps are only launchers for these OS features).

 

[Gochugogi]

I like the Finder basically as is. Well, OS 10.8.5 was perfection. I'd hate my Mac to turn into a huge iPhone...

 

[throAU]

No


If you want spotlight it's there already.

 

[leman]

In principle, I don't have anything agains reorganising how we work with data. One could have some sort of richly annotated interlinked data bundles that can be addressed and located flexibly. I agree that the current file/folder abstraction is old and fairly limiting.

However, a change like that would be a titanic undertaking and is far from being trivial. In particular, how does one do it without compromising the UNIX underpinnings of OS X?

 

[beebarb]

One could have some sort of richly annotated interlinked data bundles that can be addressed and located flexibly. I agree that the current file/folder abstraction is old and fairly limiting.

File folders are in no way limiting, they create a fixed location for the data.

What you are suggesting seems to be data that has no fixed location, but would be accessed dynamically.

But without any fixed point to isolate the data sets the data will be lost just as fast as it is written.
Computers are purely logic based in their function, and they always will be.

If 'data a' is in 'location a' the computer will always expect it to be in 'location a'.

Dynamic data addressing of the kind you're suggesting is insane.

 

[Shirasaki]

One could have some sort of richly annotated interlinked data bundles that can be addressed and located flexibly.

But without any fixed point to isolate the data sets the data will be lost just as fast as it is written.
If 'data a' is in 'location a' the computer will always expect it to be in 'location a'.

This is just like everyone reaching a point will need to buy a house, or at least, rent a house for 3 or 5 years. We all need a fixed location to live, even for short period.

So, I don't think "dynamic data structure" or alike would be a valid option in the foreseeable future.

 

[leman]

File folders are in no way limiting, they create a fixed location for the data.

Exactly, that is their limitation. Imagine you are using a set of reference images that you want to use with different projects/web documents etc. With the traditional file structure you either need to make a copy, reference the original path, or create a proxy file hierarchy entry (symbolic link).

But without any fixed point to isolate the data sets the data will be lost just as fast as it is written.
Computers are purely logic based in their function, and they always will be.

There is obviously a key that will anchor the data to a certain location. There is just no necessary reason why that key should be a hierarchical filesystem location.

If 'data a' is in 'location a' the computer will always expect it to be in 'location a'. Dynamic data addressing of the kind you're suggesting is insane.

Define 'location'. Elements of dynamic file addressing have been used in Apple OSes since at least System 7 (aliases).

This is just like everyone reaching a point will need to buy a house, or at least, rent a house for 3 or 5 years. We all need a fixed location to live, even for short period.

So, I don't think "dynamic data structure" or alike would be a valid option in the foreseeable future.

I don't think your comparison is very well fitting here. Its not about having fixed location, its about knowing where to find stuff. The 'fixed locations' on the filesystem is just an illusion anyway, the actual data might be moving constantly. What you just see is a consistent abstract interface for locating the data. There is no particular reason why this interface should be a tree — it could be a more general graph.

Anyway, more flexible filesystems (aka database file systems) are a well know topic and have existed in various forms since the eighties. In fact, OS X has borrowed a lot from DBFS (Spotlight is based around it and HFS2 has a number of related extensions). No idea whether we will ever see a real DBFS on a consumer OS, but personally, I do find the concept enticing.

 

[owbp]

OS X without File management app would be a death of desktop Macs.
Not a very smart thing IMO.

Contrary to popular belief, you cannot do everything on iOS.

 

[F1Mac]

Define 'location'. Elements of dynamic file addressing have been used in Apple OSes since at least System 7 (aliases).

But an alias always points to the same location, no? If you move the source from its original location, the alias is useless. Besides, I don't know if I'm imagining things, but to me this would make the Finder much slower. The Finder isn't supposed to search for stuff (spotlight) before finding it

 

[beebarb]

Exactly, that is their limitation. Imagine you are using a set of reference images that you want to use with different projects/web documents etc. With the traditional file structure you either need to make a copy, reference the original path, or create a proxy file hierarchy entry (symbolic link).

There is nothing limiting about having to do either of those things, you KNOW where the image exists, so you can point to it as needed.

There is obviously a key that will anchor the data to a certain location. There is just no necessary reason why that key should be a hierarchical filesystem location.

Sounds like nonsense.

Define 'location'. Elements of dynamic file addressing have been used in Apple OSes since at least System 7 (aliases).

Those aliases aren't dynamic addressing.
They are equivalent to shortcuts in Windows.
The earliest ones of those were pretty much encoded text.

The primary string was just the absolute path to the referenced file on the filesystem, and as I understand them aliases on OS X are functionally identical.

I don't think your comparison is very well fitting here. Its not about having fixed location, its about knowing where to find stuff. The 'fixed locations' on the filesystem is just an illusion anyway, the actual data might be moving constantly. What you just see is a consistent abstract interface for locating the data. There is no particular reason why this interface should be a tree — it could be a more general graph.

'Knowing where to find stuff'
As you say, that is the point.

For people like me, a more structured approach like a traditional system makes sense, and I can easily find things.
If a dynamic system like you suggest were to happen, I assure you I'd probably lose track of my files far too often.

 

[Partron22]

If a dynamic system like you suggest were to happen, I assure you I'd probably lose track of my files far too often.

I'm certain that if Apple implemented a dynamic file system that it would be perfectly capable of losing your files all by itself, without your help. Even the relatively simple Finder structure we have now has bugs. Automated bugs do not sound like a good thing to aim for.

 

[Shirasaki]

Exactly, that is their limitation. Imagine you are using a set of reference images that you want to use with different projects/web documents etc. With the traditional file structure you either need to make a copy, reference the original path, or create a proxy file hierarchy entry (symbolic link).

There is obviously a key that will anchor the data to a certain location. There is just no necessary reason why that key should be a hierarchical filesystem location.

Define 'location'. Elements of dynamic file addressing have been used in Apple OSes since at least System 7 (aliases).

I don't think your comparison is very well fitting here. Its not about having fixed location, its about knowing where to find stuff. The 'fixed locations' on the filesystem is just an illusion anyway, the actual data might be moving constantly. What you just see is a consistent abstract interface for locating the data. There is no particular reason why this interface should be a tree — it could be a more general graph.

Anyway, more flexible filesystems (aka database file systems) are a well know topic and have existed in various forms since the eighties. In fact, OS X has borrowed a lot from DBFS (Spotlight is based around it and HFS2 has a number of related extensions). No idea whether we will ever see a real DBFS on a consumer OS, but personally, I do find the concept enticing.

Well. OK. There would be other alternatives to store data. But another thing you need to consider is current computer. Storing data in a form human brain stores data (which is still a mystery for many of us) may not be the right approach. Tree diagram is also very natural for human to find a certain file/object in a system.

And about reference image stuff, yes, we create a link to that stuff. And everything related to that image will become a link to that image. Otherwise, what is the better option?

 

[Jessica Lares]

I just don't see how a person who's incapable of understanding the concept of a file system would be the same person working on web related projects, and other things that use the same concept to organize its data. How are backups supposed to work when you're referencing stuff within text files? What happens when you remove stuff months down the line when stuff is still being referenced?

OS X already makes it easy for someone to just connect their phone and have Photos pop up so they can dump their photos in there, and they built the system that lets you work with them in iMovie, iWork, and a lot of third-party software can pull up this menu too. Safari by default is setup to automatically open stuff, which if it's audio, automatically goes into iTunes, and if it's a PDF, automatically goes into Preview.

 

[leman]

But an alias always points to the same location, no? If you move the source from its original location, the alias is useless.

Those aliases aren't dynamic addressing.

OS X aliases continue working even if the file was moved. Try it out. Aliases bypass the hierarchical filesystem and reference the FS storage directly. I have no idea about the details though.

Besides, I don't know if I'm imagining things, but to me this would make the Finder much slower. The Finder isn't supposed to search for stuff (spotlight) before finding it

This is one of the reasons why this stuff has not found its way to the consumer OSes yet. It is possible to make it very fast (the principal problems are solved long ago in form of indexed databases), but the overall system becomes much more complex. The nice thing about hierarchical FS is that is it very powerful and yet conceptually quite simple.

There is nothing limiting about having to do either of those things, you KNOW where the image exists, so you can point to it as needed.

'Knowing where to find stuff'
As you say, that is the point.

To illustrate the difference: give me the green book about medieval history (you know that there is only one such book) vs. give me the 5th book on the 3rd bookshelf from top in the book cabinet left to the door. The drawback of absolute anchoring is, well, the fact that it is absolute. If you need to move something, a lot of things might come crashing down.

On a more serious note, there are a lot of problems with the hierarchical FS. It does not offer a (very useful) notion of history and it lacks the ability to enforce relationships and constraints between distinct entities. The only thing it knows are spacial trees. Example: we use quite complex data layouts to work with language data. There are often multiple files that conceptually represent the same data (video, audio, different kinds of annotations, metadata etc.). These files belong together, essentially they are one unit. However, there is no proper way to represent that relationship in a hierarchical FS. Yes, you can put them into the same folder (which has other, very substantial drawbacks). However, that does nothing to minimise the risk of human or programmer error, which can result in mismatched file versions. It would be nice if the system itself would offer some sort of additional security here, by enforcing certain constraints. E.g. one could mark files that belong together as a kind of bundle, which would prevent files from different bundles getting mixed.
What I envision is a system were data is linked in a graph rather then in a tree, and one can have multiple simultaneous mappings from that graph to trees, depending on what one needs to do.

 

[boast]

I can understand your position. It is already done for iPhoto/Photos. You don't get to manage any of the individual photos or the structure and everything is done through the app. And it is already done with Itunes as well- you import the music but don't get to manage its file structure.

You simply open Photos and all your photos are there, you open iTunes and all your media is there.

I think the only part that is missing from your request is for iWorks/Pages. Everything else I think is already in place.

 

[Shirasaki]

OS X aliases continue working even if the file was moved. Try it out. Aliases bypass the hierarchical filesystem and reference the FS storage directly. I have no idea about the details though.



This is one of the reasons why this stuff has not found its way to the consumer OSes yet. It is possible to make it very fast (the principal problems are solved long ago in form of indexed databases), but the overall system becomes much more complex. The nice thing about hierarchical FS is that is it very powerful and yet conceptually quite simple.




To illustrate the difference: give me the green book about medieval history (you know that there is only one such book) vs. give me the 5th book on the 3rd bookshelf from top in the book cabinet left to the door. The drawback of absolute anchoring is, well, the fact that it is absolute. If you need to move something, a lot of things might come crashing down.

On a more serious note, there are a lot of problems with the hierarchical FS. It does not offer a (very useful) notion of history and it lacks the ability to enforce relationships and constraints between distinct entities. The only thing it knows are spacial trees. Example: we use quite complex data layouts to work with language data. There are often multiple files that conceptually represent the same data (video, audio, different kinds of annotations, metadata etc.). These files belong together, essentially they are one unit. However, there is no proper way to represent that relationship in a hierarchical FS. Yes, you can put them into the same folder (which has other, very substantial drawbacks). However, that does nothing to minimise the risk of human or programmer error, which can result in mismatched file versions. It would be nice if the system itself would offer some sort of additional security here, by enforcing certain constraints. E.g. one could mark files that belong together as a kind of bundle, which would prevent files from different bundles getting mixed.
What I envision is a system were data is linked in a graph rather then in a tree, and one can have multiple simultaneous mappings from that graph to trees, depending on what one needs to do.

For bundle stuff, xxx.app in Mac OS X is what you want. Basically it is a folder. But Apple encapsulate it as a package, and open it in a way like opening a package. RW disk image is similar to your bundle concept too. We create an image, then put everything related to each other together.
About the inner constrains, or more generally, relationships, current filesystem may not be able to achieve this feature. But, current computer is optimised for such hierarchical way to organise files. Teaching computer to think and store info similar to human still has a long way to go.

And about your graph. We see this graph "as a graph", then you know the entire picture of that graph. But what if you see individual element? How would you find the exact location of that element? We need clues to find it. And most of the time, multiple clues may be able to pinpoint that element. We treat that element as the "root", then all clues lie in a certain hierarchy level, or a "tree".

I am neither professional computer scientist nor neuroscientist. But I believe current hierarchically designed filesystem is the best we can get. And the problem you mention is already solved.

My two cents.