Leap 2.0 - Why Didn't Apple Do This For 10.4?
Leap 2.0
I've been asking Apple to create such a browser for a long time and it seems to be falling onto deaf ears.
I'm sure a quick search of AI forums for words like "hierarchical filesystems are so 1984" and "why can't Apple leverage Spotlight to its fullest" and "Dominic Giampaolo must be rolling in his grave - oh wait, he's not dead yet and still working for Apple, wtf does the Finder still suck?" and "they rewrote the Finder for 10.6 and they haven't bothered to change how it's used?" you'd find threads in which I discuss:
1. How to make the Finder better by making it, by default, use Spotlight to browse files
2. Still offer a hierarchical file browser for old timers that can't adapt and for backwards compatibility
3. Open/Save dialogs that allow users to search using metadata tags and tag documents with metadata that makes sense
The guys behind Leap are geniuses. The guys behind Finder are morons.
Apple, seriously, fire your team of 1000 monkeys typing on 1000 Apple Keyboards and hire Ted and Tom. It'll cost you a bit more but you'll feel better knowing the Finder is now ready for the 21st century.
I've been asking Apple to create such a browser for a long time and it seems to be falling onto deaf ears.
I'm sure a quick search of AI forums for words like "hierarchical filesystems are so 1984" and "why can't Apple leverage Spotlight to its fullest" and "Dominic Giampaolo must be rolling in his grave - oh wait, he's not dead yet and still working for Apple, wtf does the Finder still suck?" and "they rewrote the Finder for 10.6 and they haven't bothered to change how it's used?" you'd find threads in which I discuss:
1. How to make the Finder better by making it, by default, use Spotlight to browse files
2. Still offer a hierarchical file browser for old timers that can't adapt and for backwards compatibility
3. Open/Save dialogs that allow users to search using metadata tags and tag documents with metadata that makes sense
The guys behind Leap are geniuses. The guys behind Finder are morons.
Apple, seriously, fire your team of 1000 monkeys typing on 1000 Apple Keyboards and hire Ted and Tom. It'll cost you a bit more but you'll feel better knowing the Finder is now ready for the 21st century.
Comments
There's also a huge amount of stuff that relies on path references for file locations - again mostly the unix core when it looks for startup locations. Every single path reference has to know that it's looking for certain meta-tag information.
I'm sure it will come eventually but I don't think it's something they can trivially drop in without some sort of progression towards it. You also have to consider performance because one reason that I personally barely use Spotlight at all these days is that typing one character tries to search for everything straight away - I don't know why they can't just wait until I've typed maybe 3 characters or until I've not typed anything more for 3 seconds, whichever comes first.
Pulling up a list of thousands of items I don't have any need for makes the search harder to use and it's worse when it searches inside documents.
My biggest problem with abstracting the filesystem to tags and I guess pushing people to use search is that it can make things slower. I know that statements like:
"Still offer a hierarchical file browser for old timers that can't adapt"
are intended to make this look like a cool idea but if I'm about to start work on a project and I know that my files are in ~/Documents/projects/project_name/ then I'm not going to need to search for the files and in fact typing the names is slower than descending the hierarchy with between 1 and 3 clicks of the mouse. If you use hierarchical tags then where is the advantage of using tags over what is used now?
The main advantage to tags is finding stuff that you don't know where it is and spotlight generally manages this already. It also has advantages for categorizing files - mainly media - as you can use multiple grouping but unless people are having a problem with the current system, which I don't think is the case, it's not an urgent change to make.
Apple may have popularized the Graphica User Interface but they have another
battle looming and that is ridding people of the self imposed limitations of folder
hierarchy. Folders are a metaphor carried over from the physical world that have done
nothing but create the same problems in computerdom that they created in the physical world. A rigid structure that does not do a good job of showing content from a variety of different angles.
Now we've seen crazy things like 3D interfaces and other "demoware" dreams but the reality is that people need to effectively manage their data and the next step in this evolution is moving to a flatter folder structure and leveraging metadata more efficiently IMO.
The computer has many uses but I think should be evident to all that a computer should be a tool that automates your life in many areas. The metadata that Spotlight tracks currently is based on established parameters and for many people they may be enough but for many others they need the extra extensibility that only custom metadata can provide. It's a way to make your computer search for terms that you feel comfortable using.
I have to echo KKS' praise of the Ironic team. They are passionate about what metadata tagging can do for document management and without this passion we would not have seen OpenMeta (their framework for systemwide tagging and management) and we wouldn't have developers like
- St Clair using OpenMeta for Default Folder X
- DEVONthink using OpenMeta for their tagging (forthcoming)
- Punakea looking at OpenMeta for their tagging
- Hazel from Noodlesoft looking at OpenMeta
- Tag Folders leveraging Applescript and OpenMeta
- MailtTags from Indev Software beta testing OpenMeta
My hope is that Apple sees the work of these developers and greenlights an Apple solution by 10.7. There is a need for system-wide tags and management. There is a need for tag preservation across various filesystems. There is a need to integrate tags into the OS at a peer level with other attributes like labels, creator code etc....are intended to make this look like a cool idea but if I'm about to start work on a project and I know that my files are in ~/Documents/projects/project_name/ then I'm not going to need to search for the files and in fact typing the names is slower than descending the hierarchy with between 1 and 3 clicks of the mouse. If you use hierarchical tags then where is the advantage of using tags over what is used now?
You make it sound like finding your project files is fast and easy. The reality though is that it's more than just a few clicks - it involves finding the Documents folder, then the Projects folder and then the folder of the project you're looking for. Finding these folders take time as the number of files in the enclosing folder grows.
The advantage to hierarchical tags comes from the fact that you don't need to drill down to your project like you would on a hierarchical file browser. Your documents that would otherwise be in ~/Documents/projects/project_name would already have these tags. You could browser your "projects" and get a list of all your projects...but you could also instantly display a specific project you're looking for without having to drill down to the specific project.
The other advantage is that you can dynamically change how the information is presented. If you set up your projects in ~/Documents/projects/project_name, you've essentially created a rigid structure that can't easily be changed. If, for example, you have a similar project every year and want to display all the 2009 project files and the 2007 project files but this recurring project within a single folder called project_name, it won't be easy to find all your 2009 and 2007 files. To slightly remedy this, you could create folders named '2006', '2007', '2008, '2009' within your project_name folder but this is an inelegant solution if, for example, one file in your recurring project is used and unchanged every year or, for example, if you have to maintain two different versions of a single file within a project (for example, one file is presented a certain way and is intended to be sent to Joe, the other file has a slightly different presentation and is intended to be sent to Bob.) With tags, you'd simply tag the file that always remains unchanged with 2006, 2007, 2008, 2009 and it would always show up within your project files if you decided to display project_name for the year 2009, or if you're looking to display the files from project_name for the year 2008 that are intended to be sent to Bob.
Really the possibilities with tagging become endless because the structure is loose and can be changed on-the-fly.
You don't really need to type names (although the possibility exists). The Spotlight menu and the Finder's Spotlight interface leads people to believe that using Spotlight is an exercise of remembering file names or project names and typing it in a search box. This *is* the problem with the current interface and why I think Apple should be focussing on creating something more like Leap which has a much more visual browsing experience.
Leap 2.0 is not perfect but it's a heck of a lot more useful than the Spotlight menu's Googlesque "I'm only looking for a single file and I feel lucky" interface (I'm not saying the Spotlight menu is bad, just saying that its purpose is restricted to finding stuff things that are hidden away as you explain in the next quote.
The main advantage to tags is finding stuff that you don't know where it is and spotlight generally manages this already. It also has advantages for categorizing files - mainly media - as you can use multiple grouping but unless people are having a problem with the current system, which I don't think is the case, it's not an urgent change to make.
That's one advantage...and like you said, the Spotlight menu is perfect for this.
However there is room to replace the current system for something less rigid. The beauty of tags is that virtual file hierarchies can be maintained but would not enforced like they are now.
I fully understand that both can coexist in the transition period...and that they must coexist because legacy systems wouldn't know what to do with the extra metadata or what to do with files that aren't in a specific place in a fs hierarchy. However, the first step must be taken soon, there's no reason to delay it.
The current Finder is hierarchy-friendly and Spotlight-tag-unfriendly. Apple should at least offer both in the Finder at this point in time. Apple should feel embarrassed that Ironic has developed an app that uses Spotlight visually while the Finder's Spotlight interface is still stuck in user-unfriendly text mode.
Command- Spacebar
"tag:Redmatica"
voila nothing but the 6 video files I tagged appeared in the results.
Tagging is the feature that everyone who manages even a modest amount of documents
need. Most people don't know the benefits and why something like OpenMeta is different from Spotlight.
If I'm able to get my mother to switch her sole practice over to a Mac with Fusion running for the few windows apps she needs I will certainly attempt to show her how to coalesce all the files she needs for a particular case together underneath tags so that she can have multiple, and relevant, views of the information for her case.
The power for attorney and anyone who needs to track disparate documents for case work is that a Smart Folder truly becomes smart when it's only looking for the metadata unique to your casework.
I'm hoping Apple does go here because the chants of
"fix the fxxxx finder" strike me as quite odd that computing power users are still stuck managing their files with a method that has been around over 30 years. There is a new way ..there is a modern way and folders expanding like Tribbles ain't it.
You make it sound like finding your project files is fast and easy. The reality though is that it's more than just a few clicks
At most, click Finder, then home shortcut, then projects, then project name = 4 clicks.
You could browser your "projects" and get a list of all your projects.
But surely you either have to type out the word projects in which case you may get results from other 'projects' matches or you have loads of single word tags everywhere, like shortcuts, which would need to be managed.
..but you could also instantly display a specific project you're looking for without having to drill down to the specific project.
You still have to find a way to tell the browser to find the file you want by either typing the file name or choosing/typing the tags. You may not have to click as many tags to get to what you want but it's really the difference between:
the file I want is in ~/Pictures/events/holiday-spain-2009/tree.jpg
meta: click images tag, start typing image name, tree.jpg (filter out results)
hierarchical: 4 clicks direct to where you want
meta is great for when you don't know where something is, otherwise is about the same or slower. I find typing to be far slower than mousing.
The other advantage is that you can dynamically change how the information is presented. If you set up your projects in ~/Documents/projects/project_name, you've essentially created a rigid structure that can't easily be changed.
I agree entirely that this is a huge advantage but it also sort of forces people to maintain a tag system and not necessarily being able to visualize it. When you start creating non-linear relationships between leaf nodes and identifying information, the user has to do the tagging meaningfully otherwise the grouping system fails and it becomes like a typical computer-illiterate user's machine with everything on the desktop.
The beauty of tags is that virtual file hierarchies can be maintained but would not enforced like they are now.
I doubt they will ever throw out rigid hierarchies until everyone agrees to transition too. They had this sort of thing in OS 9 with the file types and creators to prevent the need to have extensions but the problem was making changes accessible to the user and cross-platform. Sending a file without the extension to a Windows user wouldn't work and the same sort of thing would happen zipping a meta file-system folder - it would uncompress on the other end as flat files. If Windows never adopts the convention, it's just too much work to stay compatible and it may simply go the way that the OS 9 types/creator meta-data. They are pretty much unused and we now do what Windows users did, which is change the extensions.
Meta-data tags mean extensions are unneeded but it won't happen for years if ever because tags are just too much part of the normal working day that changing it means re-training people who 'need' training to use a computer. For most people here, adapting would be no problem but everyone needs to adapt for it to work.
At most, click Finder, then home shortcut, then projects, then project name = 4 clicks.
But surely you either have to type out the word projects in which case you may get results from other 'projects' matches or you have loads of single word tags everywhere, like shortcuts, which would need to be managed.
You still have to find a way to tell the browser to find the file you want by either typing the file name or choosing/typing the tags. You may not have to click as many tags to get to what you want but it's really the difference between:
the file I want is in ~/Pictures/events/holiday-spain-2009/tree.jpg
meta: click images tag, start typing image name, tree.jpg (filter out results)
hierarchical: 4 clicks direct to where you want
meta is great for when you don't know where something is, otherwise is about the same or slower. I find typing to be far slower than mousing.
I agree entirely that this is a huge advantage but it also sort of forces people to maintain a tag system and not necessarily being able to visualize it. When you start creating non-linear relationships between leaf nodes and identifying information, the user has to do the tagging meaningfully otherwise the grouping system fails and it becomes like a typical computer-illiterate user's machine with everything on the desktop.
I doubt they will ever throw out rigid hierarchies until everyone agrees to transition too. They had this sort of thing in OS 9 with the file types and creators to prevent the need to have extensions but the problem was making changes accessible to the user and cross-platform. Sending a file without the extension to a Windows user wouldn't work and the same sort of thing would happen zipping a meta file-system folder - it would uncompress on the other end as flat files. If Windows never adopts the convention, it's just too much work to stay compatible and it may simply go the way that the OS 9 types/creator meta-data. They are pretty much unused and we now do what Windows users did, which is change the extensions.
Meta-data tags mean extensions are unneeded but it won't happen for years if ever because tags are just too much part of the normal working day that changing it means re-training people who 'need' training to use a computer. For most people here, adapting would be no problem but everyone needs to adapt for it to work.
You still have that false presumption that you'd have to type anything. This is totally false. This may be the way the Finder's Spotlight or the way the Spotlight menu operates today but that's why they fail to be an interesting and efficient metadata browsing solution.
If you take a look at Leap 2.0, you don't need to type anything. Although Leap's interface allows for a Spotlight experience close to what we have today in Mac OS X, you can also opt to not touch the keyboard.
You also still have the false presumption that it's impossible to visualize something as unstructured as tags. This is not true. A sufficiently thought out interface could present the information in a familiar manner to a user. If it were true that humans could only visualize linear or hierarchical organization systems, then perhaps the current file browsers/managers would be the ultimate method to organize files. But this is patently false.
Maintaining a tag system is no different than maintaining a hierarchical system if it's maintained manually. Except that it's not in the former case. Much is automated.
And you're also saying the human race is doomed to stick it out with hierachical file systems because no one is ready to cast away their old habits or because different platforms evolve at different rates. This is also untrue and impossible. People can evolve and can adapt...even if the process is slow for certain groups of people.
The only thing I'm saying is that the current hiearchical system is unsustainable. At the rate people gather files, a new system will have to take its place.
The example I always like giving is the world wide web. Nobody would ever want to navigate it hierarchically. And while home computers don't store quantities of information remotely near the quantities found on the web, they do store vast amounts.
I believe I started realizing this 8 years ago when I saw how easy it was to find the music you want to listen to using iTunes. Some people would find it a daunting task to navigate and maintain a hierarchical system for a library of music. But iTunes with it's autotagging and elegant browsing interface makes it easy to find something you want to listen to.
I believe I started realizing this 8 years ago when I saw how easy it was to find the music you want to listen to using iTunes. Some people would find it a daunting task to navigate and maintain a hierarchical system for a library of music. But iTunes with it's autotagging and elegant browsing interface makes it easy to find something you want to listen to.
iTunes and the tagging benefit it offers is probably the most coherent and easy to use comparison for how tagging can improve file access.
You also still have the false presumption that it's impossible to visualize something as unstructured as tags. This is not true. A sufficiently thought out interface could present the information in a familiar manner to a user.
It adds situations that make things more difficult though. For example, you may try to clean up your filesystem by removing duplicate files. The browser presents a method of navigating to images/holidays/2009/tree.jpg and also to images/published-online/tree.jpg. You decide you don't want 2 copies and delete the published copy not realizing these are one and the same file with non-linear tags that identify it in two different ways.
In that case, you may recognize the mistake if you had two filebrowser panes open but I even do this sort of thing with a hierarchical filesystem by accident. It may just mean listing all tag paths for a file when it's selected but presenting it is troublesome. The typical window title bar isn't big enough.
The only thing I'm saying is that the current hiearchical system is unsustainable. At the rate people gather files, a new system will have to take its place.
I don't think people will reach a stage where they keep collecting files more and more. Most computers I come across use under 100GB of space. Anything that goes above this is with music, photos and movies, which can be sorted, tagged and searched with specialty apps like itunes etc. There is a limit to the amount of data individuals need, can cope with and can collect.
If a single user places 100 pictures, 100 songs and 5 movies every day for their entire life and they live to be 100, this only amounts to about 7.5 million files and it's a pretty unlikely occurrence that they would do this and keep those files all that time.
The example I always like giving is the world wide web. Nobody would ever want to navigate it hierarchically.
Rigid hierarchies force people to categorize data appropriately because they have to in order that a filesystem is tidy - this means that navigating to any given level does not return an unmanageable amount of data. The internet is a great example of not being able to find what you need quickly and the reason that people almost always start an internet session by googling something and only get what google thinks is close to what you want. The whole idea of a search is that you don't know where something is, which is always going to be slower than knowing where something is.
Try for example using the internet for information on a very esoteric subject matter vs simply navigating your own structured filesystem in the field of expertise you are familiar with and dig up the reference you want. The reason it's difficult to use google for these sorts of things is that people don't tag things with enough detail. A linear structure forces you to in the interests of tidiness.
Also note that most of the time, the data you use on the internet is not merged between sites but on a single site that google finds for you and the files on the individual server use a hierarchical filesystem.
I'm not saying rigid hierarchies are better as they are a subset of meta-tags but there are reasons why some people choose to use linear techniques. Non-linear isn't always the better option for all structuring.
Some people would say AJAX is much better than normal page loading as it's quicker to load stuff in. But, it has issues like if you asynchronously load data that another function depends on and it hasn't finished, when you try to use that function, it fails and you have to take account of it. Normally you'd have forced it to wait until you could use it. Both systems work, one is faster for the user but more work for a developer.
Maybe the development work for tags won't be so hard if it's done sufficiently low-level. Apple could perhaps even do it transparently, which I think it has to be. If this is the case and they can find workarounds for any issues it may cause then I see no reason why they can't implement it. Perhaps it would be best to implement it with the new ZFS filesystem though so that people adapt to both at once.
I believe tags will visually/UI-wise remain very files/folder like, because thats just how people are wired to go about gathering possesions, whether they are physical or digital. It is a metaphore that works. Think about it, you don't pile all your possesions randomly in one box and tag them: "t-shirt", "frying pan", "shampoo"! You spatially organize them by separating them in visually/spatially distinct places: "wardrobe", "kitchen", "shower".
What I see working, is a system in which folders equal tags: save/move/drag a file to a certain folder/visually distinct area and it will be tagged according to the folder hierarchy. This will be the only way to get mainstream computer users use tags: hide it from them! Let them continue their years-old usage patterns and leverage that to generate tags (without them even noticing the change!).
Then show them the power of tagging to go beyond the possibilities of a strict hierarchical file/folder paradigm: built-in search and smart folders in finder, itunes, iphoto, smarter auto-tagging functionality. Which happens to be exactly the direction apple is headed in! Should/could apple be more aggressive implementing the tagged future of computer-usage? Yes, they could, but apparently they took a middle-of-the-road approach of slowly implementing a tag-based future without (for now) depreciating the 30+ years old file/folder paradigm.
While I do understand the yearning for a quicker path to tomorrows great possibilities, I actually applaud apple for their well thought-out strategy of gradually familiarizing the mainstream computer-user with all the possibilities of a tag-and-search based computer future without alienating their user-base by going too fast or immersing people in too much new functionality.
It adds situations that make things more difficult though. For example, you may try to clean up your filesystem by removing duplicate files. The browser presents a method of navigating to images/holidays/2009/tree.jpg and also to images/published-online/tree.jpg. You decide you don't want 2 copies and delete the published copy not realizing these are one and the same file with non-linear tags that identify it in two different ways.
This would only happen on a badly designed browser and is not in any way related to a tagging system. This type of situation could very well happen in a badly designed hierarchical browser.
You make the assumption that the browser would make it difficult to know that you're not looking at the exact same file.
In that case, you may recognize the mistake if you had two filebrowser panes open but I even do this sort of thing with a hierarchical filesystem by accident. It may just mean listing all tag paths for a file when it's selected but presenting it is troublesome. The typical window title bar isn't big enough.
I don't understand this myopia about tag paths. Is this really how you imagine a tag browser would work? Perhaps this mistake would happen if we used today's hierarchical file browsing concept and applied it to tags but why impose this limitation? It's of course entirely possible to mimic this behavior for people that want to continue navigating to their files hiearchically but should not be the sole method to navigate.
I don't think people will reach a stage where they keep collecting files more and more. Most computers I come across use under 100GB of space. Anything that goes above this is with music, photos and movies, which can be sorted, tagged and searched with specialty apps like itunes etc. There is a limit to the amount of data individuals need, can cope with and can collect.
I'm sure many people said the same thing when they bought a 40 meg hard drive back in 1985. Nobody's will ever store anything but a a few dozen text documents, MacPaint bitmap files, and HyperCard stacks.
I'm sure there's a limit...I'm also sure we haven't reached it.
As for the speciality app idea...sure, the speciality apps take care of managing and browsing specific files. Why can't that idea be applied more globally?
If a single user places 100 pictures, 100 songs and 5 movies every day for their entire life and they live to be 100, this only amounts to about 7.5 million files and it's a pretty unlikely occurrence that they would do this and keep those files all that time.
That's a shit load of files to manage hierarchically. Are you sure you want to use that example?
Rigid hierarchies force people to categorize data appropriately because they have to in order that a filesystem is tidy - this means that navigating to any given level does not return an unmanageable amount of data.
Right, but not everyone has the patience to organize and tidy things up manually. If they did, they wouldn't be using a computer.
The internet is a great example of not being able to find what you need quickly and the reason that people almost always start an internet session by googling something and only get what google thinks is close to what you want.
Pretty damn close too. I think you're wrong about not being able to find what you need quickly. I'm sure many would disagree. I find pretty much everything that I want to find rather quickly.
The whole idea of a search is that you don't know where something is, which is always going to be slower than knowing where something is.
Not quite. I've explained in my post above but you disagreed with it. That's fine but I still maintain the idea that as the number of files grow and as the hierarchical system becomes more complex, the user spends more time than clicking a few times. The user must spend time remebering the exact file path and then find the folders to navigate to said file. Finding the folders is a non-negligeable wasted time chunk.
So if the user actually knows where to find the file knows its content, why should he be forced to navigate a hierarchy when clicking on 2 tags or typing a few words in a search box might suffice?
I know you're trying to convince yourself, myself and others that navigating to the file hierarchically would be faster but I'm convinced that this can't be...especially not on a computer with thousands of files with a few nested folders to organize them all.
Try for example using the internet for information on a very esoteric subject matter vs simply navigating your own structured filesystem in the field of expertise you are familiar with and dig up the reference you want. The reason it's difficult to use google for these sorts of things is that people don't tag things with enough detail. A linear structure forces you to in the interests of tidiness.
You'll have to give me an example of an esoteric subject matter that is difficult to find on the internet. I'm still not sure that it would be difficult to find what you're looking for unless it's not on the internet or hasn't been indexed by Google.
Also note that most of the time, the data you use on the internet is not merged between sites but on a single site that google finds for you and the files on the individual server use a hierarchical filesystem.
Okay, but I never said that internet search engines or the structure of the internet was perfect. It could use some work. Search engines could use some work also. Like I said, internet search engines are like the Spotlight menu - a crude "I feel lucky" type of search for users that know what they're looking for. And for the most part, you will definitely find what you're looking for.
I'm not saying rigid hierarchies are better as they are a subset of meta-tags but there are reasons why some people choose to use linear techniques. Non-linear isn't always the better option for all structuring.
You're right...a linear structuring is fine for a small number of files. That's why the linear structure can be preserved virtually through metadata tagging. There could be multiple virtual paths pointing to the file, as you stated earlier, but the perceived linearity is there. If the browser is well designed, there should not be any ambiguity that it's pointing on the same file.
Maybe the development work for tags won't be so hard if it's done sufficiently low-level. Apple could perhaps even do it transparently, which I think it has to be. If this is the case and they can find workarounds for any issues it may cause then I see no reason why they can't implement it. Perhaps it would be best to implement it with the new ZFS filesystem though so that people adapt to both at once.
Well, for now, you're right that it would be impossible to do anything to the current hiearchical system. Mac OS X's unixy underpinnings, the need for legacy support, etc. would make it hard to do anything but a slow transition. But that's why the Finder should at least allow both ways of browsing.
I just want to see Apple try to do something like the Ironic dev team did because I usually now just dump my text documents into the Documents folder without any folder structure. If I'm looking for a specific file, I usually find it instantly with a Spotlight menu search. But when I'm not too sure what file I'm searching for, the Finder's Spotlight can be a pain to use. With Leap, however, I can browse them rapidly because I can easily filter the results by clicking on a couple tags. Compared to the Finder's way of filtering results, Leap is a godsend.
You make the assumption that the browser would make it difficult to know that you're not looking at the exact same file.
True but I can't think of how it couldn't without presenting all relevant tags simultaneously and there just isn't room to convey that at once. Perhaps displaying all tags connected to the file in alphabetical order would be enough for people to know which file is which but numbering and dates are used to separate files too. How do you relate the difference between two files with the same tags but different modification dates? You have to fit this info in somewhere.
I'm sure many people said the same thing when they bought a 40 meg hard drive back in 1985. Nobody's will ever store anything but a a few dozen text documents, MacPaint bitmap files, and HyperCard stacks.
I'm sure there's a limit...I'm also sure we haven't reached it.
Images and movies were round about the same size they are now so they would have been wrong to make that assumption whereas we aren't. Time constraints are the limiting factor and taking the 100 year old person example again, if that person watches a 90 minute film back to back for 100 years during all waking and non-working hours (say 6 hours per day), they can only ever watch 146000 movies.
That's about all the movies available on Amazon. Realistically, people only store about 1% of that.
This is also the kind of things that limit personal storage capacity needs, which I would put at around 6TB absolute maximum. For the likes of a digital HD VOD service with that selection, 1PB should suffice = approx 150 servers with 6TB personal storage. The technology is available for this right now.
As for the speciality app idea...sure, the speciality apps take care of managing and browsing specific files. Why can't that idea be applied more globally?
I would agree with this in that the Finder should eventually make itunes, iphoto but perhaps not imovie irrelevant. There's no reason why you can't have playlists in the Finder sidebar (and have the visualizer on your desktop) given that they are just listing selected files or be able to do image editing and cropping in quicklook after using Finder search to get images.
That's a shit load of files to manage hierarchically. Are you sure you want to use that example?
We already manage around 1 million just fine - after removing language translations, my machine has about half a million files on it. That 7.5 million number was basically what I would say is an upper limit on what people will be able to cope with and the realistic limit will lie fairly safely below that. That range I don't believe requires moving beyond hierarchical filing e.g. 7 categories of images > 1000 folders per category > 1000 images per folder. That is easily manageable.
Not quite. I've explained in my post above but you disagreed with it. That's fine but I still maintain the idea that as the number of files grow and as the hierarchical system becomes more complex, the user spends more time than clicking a few times. The user must spend time remebering the exact file path and then find the folders to navigate to said file. Finding the folders is a non-negligeable wasted time chunk.
But you have to remember the file tags and file name which is the same or worse. As mentioned above, when you look for things in real life, everything isn't piled up with labels on them, they are separated spatially in a rigid manner as this helps the human mind to narrow down a search.
Say you are looking for an image but you can't remember the name of the file, you just have a picture in your head. With a hierarchy, you would generally have an idea of where you last saw it and where you keep the image you want. With tags, you basically know that it's an image. What other information would you be able to remember so you could find it?
So if the user actually knows where to find the file knows its content, why should he be forced to navigate a hierarchy when clicking on 2 tags or typing a few words in a search box might suffice?
Time typing a few words vs navigating to a file with clicking. I doubt you'll find a significant difference between them but making typos adds slowdown.
I know you're trying to convince yourself, myself and others that navigating to the file hierarchically would be faster but I'm convinced that this can't be...especially not on a computer with thousands of files with a few nested folders to organize them all.
I find it to be faster because I can't remember the names of all those files but I am able to easily remember the hierarchies. That's part of the advantage of hierarchical structures - information compression - which is why they use them for file compression. I can't always remember lower level folder names but the higher up ones point me in the right direction. Meta-tags can be structured this way too but you end up back with a hierarchy anyway.
The way a meta-tag system should be is that no tag has a higher up generalization than any other tag - all tags have an equal weighting so you can jump directly to any grouping. This system makes things messier. It's great when you need to pull things together that aren't normally together but I personally rarely feel the need to do this as I use logical groupings in my hierarchies already.
You'll have to give me an example of an esoteric subject matter that is difficult to find on the internet. I'm still not sure that it would be difficult to find what you're looking for unless it's not on the internet or hasn't been indexed by Google.
I was trying to think one up but I can't recall exactly what I was looking for when Google failed to help. Mainly it's very specific stuff that you find in a reference manual. I will often search for terms that I think Google needs and it returns links to forums with related discussions that have a high page rank but don't answer the question.
Most of the time spent with Google is trying to construct search terms that will be effective. In many ways it's like being in a foreign country and asking for directions. If I knew where I was going, I could just go right there without asking.
I usually now just dump my text documents into the Documents folder without any folder structure. If I'm looking for a specific file, I usually find it instantly with a Spotlight menu search. But when I'm not too sure what file I'm searching for, the Finder's Spotlight can be a pain to use. With Leap, however, I can browse them rapidly because I can easily filter the results by clicking on a couple tags. Compared to the Finder's way of filtering results, Leap is a godsend.
That's exactly the type of scenario I don't like - having everything in one folder. The Finder clogs up badly when you go above 10,000 files. Plus you always have to give every file a unique name.
instead of:
series1 > episode1 > 1.jpg, 2.jpg
series1 > episode2 > 1.jpg, 2.jpg
you have to do:
series1-episode1-1.jpg
And you get ordering issues because some browsers list files with _ ahead of numbers. In the above system, if you used a tag series1, you'd end up with:
1.jpg, 1.jpg, 2.jpg, 2.jpg
which means the images aren't even in the right order and you'd have to be able to sort by the episode tag - you may actually have to use multiple sorting options.
Different kinds of files require different approach to locate them.
If you import photos from a digital camera without bothering to rename the folder, (it contains the date in it's name on many cameras), it is really hard to find an image using hierarchy. Organizing songs could be a pain too.
For the business document you produce hierarchical structure is the best, no matter whether these are office documents, dtp, video projects or code.
As it stands now, the problem of browsing is partially solved by Apple. We have the Media tab in the Open panel. By using it when opening/importing files we could locate the respective resource using a more intuitive navigation method. There is also some sort of versioning implemented by the OS - the Time machine. It is not the best for many purposes, but there are other specific versioning options, like Aperture versions for image editing and software configuration management and Xcode snapshots for code. There is an option for searching by name or content - the Spotlight. An improvement to the advanced search interface is all that is needed here. There is QuickLook for a visual search.
The missing parts are:
- Locate a resource without launching the respective apps directly. This seems an easy part - just add the media and possibly other tabs to the Finder.
- Provide a way to 'save' a resource by directly exporting it to the respective application, e.g. copy the image from the flash memory card to the iPhoto/Aperture library without launching the respective apps explicitly. This one is tricky, but doable.
Note that this kind of change depends not only on Apple but on third party developer adoption as well. Every third party software may write a plugin to Spotlight to make it's proprietary format searchable and a QuickLook plugin, to make it viewable with QuickLook and cover-flow.
Also, for the vast majority of the people using typing for file navigation is dead two decades ago. There are some UNIX geeks here and there who may prefer terminal, the normal people will navigate through the Finder tree. Some people use Spotlight for navigation-related activities, e.g. to launch an application without browsing, but most will prefer double-click and use spotlight as a fallback, when other methods to locate the file failed.
The bottom line:
If Apple abruptly changes the way we are used to access the files for the last 2 decades or more, 99.99 of the users and the developers will be pissed off. Apple is improving file navigation incrementally, keeping the backwards compatibility. The fact that most of the users failed to even notice that highlights the complexity of the problem. It is not like 1984, when you get new users to use a new paradigm.
That's exactly the type of scenario I don't like - having everything in one folder. The Finder clogs up badly when you go above 10,000 files. Plus you always have to give every file a unique name.
instead of:
series1 > episode1 > 1.jpg, 2.jpg
series1 > episode2 > 1.jpg, 2.jpg
you have to do:
series1-episode1-1.jpg
And you get ordering issues because some browsers list files with _ ahead of numbers. In the above system, if you used a tag series1, you'd end up with:
1.jpg, 1.jpg, 2.jpg, 2.jpg
which means the images aren't even in the right order and you'd have to be able to sort by the episode tag - you may actually have to use multiple sorting options.
While all of this is true, they are flaws of the Finder. The Finder shouldn't choke on 10,000 files. File names shouldn't have to be unique. This idea of unique file names is part of this whole problem with hierarchical file systems and putting too much importance on rigid structures with unique folder and file names. A file is a file. People shouldn't be limited to giving it a unique name. It should be possible for two files of the same type to have the same name.
Of course, I'm sure some people are thinking "well people will think they have duplicate files and delete one". But again, this is just part of people's conditioning...people that have used computers long enough have the idea that files should have unique names engrained in their heads and that it's impossible to have two files with the same name. This is totally wrong and just a flaw in the way old filesystems work. If we take a real life example, nobody would throw away two books with the same name thinking they are duplicates. They could have the same name but have different contents from different authors.
Unfortunately, current filesystems give *waaaay* too much importance on the filename + extension as the sole method to identify a file.
Leopard is somewhat changing this by showing file previews using Coverflow or icons that reflect the first page of a document or picture file. This remedies part of the problem considering people could theoretically have two files with the same name and not mistake one for a duplicate of the other by having other metadata confirm this.
This also brings me to a final point: people often use the file name as a way to put as much metadata on a file as possible. So instead of just giving it a simple title, they insist on putting a date in the file name, or the name of the author, or tacking on a version number. This, imo, should be totally unnecessary.
Unfortunately, this is how the Finder works. It retains legacy flaws from filesystems of the early 70s.
While all of this is true, they are flaws of the Finder. The Finder shouldn't choke on 10,000 files. File names shouldn't have to be unique. This idea of unique file names is part of this whole problem with hierarchical file systems and putting too much importance on rigid structures with unique folder and file names. A file is a file. People shouldn't be limited to giving it a unique name. It should be possible for two files of the same type to have the same name.
Of course, I'm sure some people are thinking "well people will think they have duplicate files and delete one". But again, this is just part of people's conditioning...people that have used computers long enough have the idea that files should have unique names engrained in their heads and that it's impossible to have two files with the same name. This is totally wrong and just a flaw in the way old filesystems work. If we take a real life example, nobody would throw away two books with the same name thinking they are duplicates. They could have the same name but have different contents from different authors.
And by what actually reliable method could you possibly implement this? Tags? Well if the filename and type is the same there is a high probability of a tag collision too.
Oh, so now we move on to contextual differences in the file itself. But will this mean when I update a file, the newly updated version becomes a new and unique file in the eyes of the filesystem? But, but I only wanted to fix a typo!
The problem with this whole line of radically more intelligent filesystem behavior reasoning is that there is no user-input independent semantically derivable guarantee-of-uniqueness possible which can be programmed ahead of time by a bunch of OS programmers in their lab. That's important enough to the thread to repeat:
There is no user-input independent semantically derivable guarantee-of-uniqueness possible which can be programmed ahead of time by a bunch of OS programmers in their lab. So the burden of uniqueness identification has been left in the hands of the user, who IS in possession of the knowledge, at the time of creation or modification, of whether a file should be unique or not. Because the user is the one with access to the user's intention when the file is created or modified.
See, that bolded & italicized phrase is the whole sticking point in coming up with new filesystem identification/storage/presentation methods. Until we can guarantee that we can 99.999%+ accurately derive the user's intention from a user's actions we cannot make the appropriate semantic judgements about how to correctly identify/store/present a file.
Talk about changing paradigms is cheap, coming up with solutions to the above problems is the price of admission to do what you appear to be asking for. Getting there will be very expensive. I see AI assistants doing these type of things, running on some of the vast number of processing cores which will come available eventually. But we are still a very long way away in the AI arena from being able to do this with any generality or reliability.
The Finder shouldn't choke on 10,000 files.
It's a hardware limit though. The read speed for lots of small files is pretty slow. SSD improves on mechanical drives by a huge amount, which is why they boot faster but they can't make the assumption that people have a fast enough drive.
In real-time, drives aren't fast enough to analyze the information of so much at once. So for example, calculating the number of files that match a given search as with Spotlight takes a few seconds when you don't narrow it down enough. If you had to deal with that all day long for everything you did, it would be pretty frustrating.
They would need to ensure their index was reliable enough and up to date enough. Spotlight indexes fail more than filesystem maps so reliability is absolutely key. This is why I think they need to start doing this on a filesystem level rather than apps like the Finder or Spotlight so implementing it with a new one like ZFS:
"Ditto blocks: Metadata is replicated inside the pool, two or three times (according to metadata importance).[15] If the pool has several devices, ZFS tries to replicate over different devices. So a pool without redundancy can lose data if you find bad sectors, but metadata should be fairly safe even in this scenario."
http://www.sun.com/bigadmin/features...e.jsp#metadata
"Dynamic Metadata
In addition to being 128-bit, ZFS metadata is 100 percent dynamic. Because of this, creation of new storage pools and file systems is extremely fast. Only 1 to 2 percent of writes to disk are metadata, which results in a big initial overhead savings. There are, for example, no static inodes, so the only restriction is the number of inodes that will fit on the the disks in the storage pool.
2^48 attributes for a file"
Filesystem inodes typically have static metadata as listed here:
http://www.onlamp.com/pub/a/bsd/2001...SD_Basics.html
"the permissions of the file
the file link count
old user and group ids
the inode number
the size of the file in bytes
the last time the file was accessed (atime)
the last time the file was modified (mtime)
the last inode change time for the file (ctime)
direct disk blocks
indirect disk blocks
status flags (chflags)
blocks actually held
file generation number
the owner of the file
the primary group of the owner of the file
Notice that the name of the file is not part of the inode's metadata. The filesystem doesn't care what the name of the file is; it only needs to know what inode number is associated with that file."
I think arbitrary and practically unlimited filesystem-level metadata is a necessity for the system you want and for this we will need ZFS or something like it first. Otherwise, it will simply be solutions like Spotlight bolted on top of a more limited management routine.
One day, I hope we all use the same filesystem and it's important this happens in order to achieve more advanced data management. Otherwise, other filesystems can strip off important metadata.
File names shouldn't have to be unique. It should be possible for two files of the same type to have the same name.
They don't need to be unique with a hierarchy because files have a well-defined path which acts as part of their unique definition. With a non-linear description, this isn't enough. A meta browser could prevent you naming files with the same name if they have the same text tags but then it doesn't allow you to keep versions of one file based on date alone.
On the other hand, if it allows you to have the same tags and the same name, when you need to find a file, it's going to be far more difficult as the results will simply return all files with that name and you will get the scenario above with e.g 1.jpg, 1.jpg, 1.jpg, 1.jpg and not knowing which you want without having an image preview. But note, image previews don't work on files like exr files or unsupported formats.
Unfortunately, current filesystems give *waaaay* too much importance on the filename + extension as the sole method to identify a file.
The reason is that it conveys all the information you need quickly. If you have to look at a different panel to find what you need, it kills your workflow. The information you get in the current finder window lets you see the following:
1. the hierarchy level
2. the position within that hierarchy level via filename
3. the file type via the extension
4. the date on the file
Leopard is somewhat changing this by showing file previews using Coverflow or icons that reflect the first page of a document or picture file. This remedies part of the problem considering people could theoretically have two files with the same name and not mistake one for a duplicate of the other by having other metadata confirm this.
Trouble is coverflow is a pretty bad way to navigate through files. I only ever used coverflow to see what it was like and I haven't used it once since. I also had to turn off column view icon previews because they were bogging down the Finder (it has to be this way because it dynamically generates previews unlike Windows, which leaves invisible icon files that use a lot of drive space). The fixed navigation and filename use alone is the most efficient way to browse in terms of computer resources.
And by what actually reliable method could you possibly implement this? Tags? Well if the filename and type is the same there is a high probability of a tag collision too.
Oh, so now we move on to contextual differences in the file itself. But will this mean when I update a file, the newly updated version becomes a new and unique file in the eyes of the filesystem? But, but I only wanted to fix a typo!
The problem with this whole line of radically more intelligent filesystem behavior reasoning is that there is no user-input independent semantically derivable guarantee-of-uniqueness possible which can be programmed ahead of time by a bunch of OS programmers in their lab. That's important enough to the thread to repeat:
There is no user-input independent semantically derivable guarantee-of-uniqueness possible which can be programmed ahead of time by a bunch of OS programmers in their lab. So the burden of uniqueness identification has been left in the hands of the user, who IS in possession of the knowledge, at the time of creation or modification, of whether a file should be unique or not. Because the user is the one with access to the user's intention when the file is created or modified.
See, that bolded & italicized phrase is the whole sticking point in coming up with new filesystem identification/storage/presentation methods. Until we can guarantee that we can 99.999%+ accurately derive the user's intention from a user's actions we cannot make the appropriate semantic judgements about how to correctly identify/store/present a file.
Talk about changing paradigms is cheap, coming up with solutions to the above problems is the price of admission to do what you appear to be asking for. Getting there will be very expensive. I see AI assistants doing these type of things, running on some of the vast number of processing cores which will come available eventually. But we are still a very long way away in the AI arena from being able to do this with any generality or reliability.
Well, talk about changing paradigms is the *first* step. Coming up with solutions is the second. I don't think very many people would be convinced to find solutions to this problem if it wasn't first acknowledged.
But I suppose very little people want solutions because very little people find current filesystems to be problematic. Fine. If that's the case then let's keep our old, cruddy 70s filesystems.
I think you've waaaay over-analyzed this whole thing by saying filesystems would be too dumb to recognize how to handle files that have seen content changes or tag changes and that some kind of AI would be needed to somehow guess with high accuracy what the user's intention was.
You'll have to explain how a filesystem suddenly stops recognizing a file's uniqueness if it stops relying on the file name and extension.
If you truly think that it would be impossible for a filesystem to identify the uniqueness of two files with the same name, then consider this: A unique signature based on its content metadata would be created to stamp files as being unique. Files that see content or metadata changes would see its signature change but the OS knows what the old signature was and the user could then decide to create a new file or overwrite the old file.
Simple and elegant. No two files would ever have the same signature unless they were truly identical...in such a case they would not be unique.
Do I win a prize? I don't know why you have to drag any AI in this at all.
I also like how you try to put words in my post making it seem as though I say a file's uniqueness cannot be ascertained. I explicitly told you that can be done, but that the vast majority of the time you don't want that behavior!
I told you what the solution will take, a recognition of intent. If you don't like that it's your problem, but that won't remove the necessity of being able to quantify intent to get the behavior you want.
Nice job of trying to move the goalposts. What you want is not technically feasible today. Period.
I also like how you try to put words in my post making it seem as though I say a file's uniqueness cannot be ascertained. I explicitly told you that can be done, but that the vast majority of the time you don't want that behavior!
I told you what the solution will take, a recognition of intent. If you don't like that it's your problem, but that won't remove the necessity of being able to quantify intent to get the behavior you want.
What the heck are you babbling about...there's no more recognition of intent than there ever was before via "Save" and "Save As" options. You're the one that's trying to make everyone believe that the problem is bigger than it is and requires a complex solution.
What I want is technically feasible today. It just hasn't been done because nobody's ready to create a filesystem that will be incompatible with current filesystems.
Listen, I don't really care if someone implements a solution or not for file uniqueness. There are tons of different ways to handle it on an OS that doesn't particularly care about the underlying structure of a file system.
All I said is that I dump all my files in the Documents folder and let Spotlight find them for me. I don't give a shit if the OS or the filesystem decides to put different files with the same name in different directories so that there are no collision. I'm just saying that it needs to happen. It needs to be transparent to the user. And the OS and filesystem don't need to be so dumb that they get mixed up between files with the same name.
It's utterly ridiculous that filesystems trip on files with the same name unless they're not in the same directory.
Like I said...I don't care what the solution is. My first solution was elegant and simple but this second solution would work also even if it was a hack to make this stuff work on current filesystems.
Leap 2.0
I've been asking Apple to create such a browser for a long time and it seems to be falling onto deaf ears.
I'm sure a quick search of AI forums for words like "hierarchical filesystems are so 1984" and "why can't Apple leverage Spotlight to its fullest" and "Dominic Giampaolo must be rolling in his grave - oh wait, he's not dead yet and still working for Apple, wtf does the Finder still suck?" and "they rewrote the Finder for 10.6 and they haven't bothered to change how it's used?" you'd find threads in which I discuss:
1. How to make the Finder better by making it, by default, use Spotlight to browse files
2. Still offer a hierarchical file browser for old timers that can't adapt and for backwards compatibility
3. Open/Save dialogs that allow users to search using metadata tags and tag documents with metadata that makes sense
The guys behind Leap are geniuses. The guys behind Finder are morons.
Apple, seriously, fire your team of 1000 monkeys typing on 1000 Apple Keyboards and hire Ted and Tom. It'll cost you a bit more but you'll feel better knowing the Finder is now ready for the 21st century.
So let me get this straight. Apple gets panned for "adding" functionality in other apps and thus "killing" 3rd party players and now you want Apple to "kill" a 3rd party player because you don't want to pay beyond the $129 and get that add-on functionality?
What the heck are you babbling about...there's no more recognition of intent than there ever was before via "Save" and "Save As" options. You're the one that's trying to make everyone believe that the problem is bigger than it is and requires a complex solution.
What I want is technically feasible today. It just hasn't been done because nobody's ready to create a filesystem that will be incompatible with current filesystems.
Listen, I don't really care if someone implements a solution or not for file uniqueness. There are tons of different ways to handle it on an OS that doesn't particularly care about the underlying structure of a file system.
All I said is that I dump all my files in the Documents folder and let Spotlight find them for me. I don't give a shit if the OS or the filesystem decides to put different files with the same name in different directories so that there are no collision. I'm just saying that it needs to happen. It needs to be transparent to the user. And the OS and filesystem don't need to be so dumb that they get mixed up between files with the same name.
It's utterly ridiculous that filesystems trip on files with the same name unless they're not in the same directory.
Like I said...I don't care what the solution is. My first solution was elegant and simple but this second solution would work also even if it was a hack to make this stuff work on current filesystems.
This display of ignorance is illuminating. You want it all, want it right, want changed things to seem the same and have some things that are the same seem different. You want stuff to only show up once even though it may appear on the disk many times in identical formats because the filesystem should know they are the same. You want things that are different because we only changed little things to seem the same because semantically they are. You need this whole new paradigm but are restricting us to using Save and Save As.
What you want is not a bad thing, I want that too. But you absolutely refuse to believe the level of difficulty of the task when it has been laid out repeatedly. Get this through your thick skull, the more obvious subtle things are for people, the exponentially harder they are to program in a way that is executable on a reasonable time-scale. It is not frakking simple even though the idea is simple, because the idea is infused with intent and common sense, the hardest frakking nut there is to crack in computing.