> Stop it Apple! Every minute we spend dealing with this nonsense is a minute of lost productivity and a minute of aggravation. Collectively we've clocked up billions of these minutes and we hate it! You understand, Apple? We HATE it!
Do you remember that Leave Britney Alone kid?
Speaking as a developer, the ability to do interesting things with files has improved dramatically over the years. You can do the email attachment thing, iTunes sync, clipboard, Dropbox... In my day, we put things on S3 and passed custom links around. And we liked it! (Not really; it was terrible.)
As a user, now, I call bullshit. It's occasionally weird but it's definitely not a rage-inducing condition. Besides that, Apple has found an easy-to-communicate means of enabling their users manage the limitations of their storage:
Every app has its own weight. Need room? Dump an app. Don't worry – nothing you do in any other app will be affected.
Does it make for some duped data? Probably. Maybe tons for certain workflows. Doesn't matter.
The hermitcally sealed environments of each app let a larger swath of their userbase manage things without outside help. Limited complexity makes it easy to understand the scope of possible problems and solutions.
> Every app has its own weight. Need room? Dump an app. Don't worry – nothing you do in any other app will be affected.
To put it another way: apps need to communicate large blobs of information (i.e., documents). You'd say, from first principles, that they need a nonvolatile Inter-Process Communication mechanism.
In most OSes, apps pass documents between them with the moral equivalent of "shared memory" IPC: files that both apps have read/write access to.
In iOS, on the other hand, apps use the moral equivalent of message-passing-with-copy.
Thus, apps get all the same benefits from this that, say, Erlang processes get from in-memory message-passing-with-copy IPC. The primary one being that when the process/app is removed from the system, all its resources can be released, without having to disentangle them from any other process/app that might be depending on them. This gives you the dual philosophies of "let it crash" and "just delete it", respectively.
Android has direct filesystem access, but I can't think of the last time I ever used it. The "sharing" mechanism provides a much nicer experience than forcing the user to fumble around in a tree abstraction that hasn't changed in ~40 years. I eagerly await the day when filenames become completely opaque identifiers, never exposed in the UI.
iOS's problem is that there is no standardized way for third-party apps to allow other apps access to a particular document. That's what the OP is actually asking for. Just because desktops have historically implemented this feature as an N-ary tree of (string, blob) pairs doesn't matter.
There seems to be a prevailing attitude among some that the "users" don't like trees of files and we should all move to something more advanced. It has always seemed weird to me.
Is something being 40 years old make it bad? Humans naturally like to put things in hierarchies. It is a very well understood concept by everyone.
I'm a user. I hate file hierarchies. IMO, the ideal interface to a computer's data storage system would have two ways to find a document:
1) A list of most-recently-seen documents. Each application would have its own list of documents it had seen, and there would be a per-user list for documents from all apps. Documents are added to the lists when they're created, opened, downloaded, etc. There is no limit on number of documents in the list, and the list is searchable. Some modern applications have primitive equivalents, but not as the primary document-opening interface.
2) Give each list a search box, with results as a flat list of extracted metadata. Honestly, just clone the current standard web search engine UI and use that. A search box is the closest computers have come to being user-friendly, and is certainly nicer than dropping the user into a file manager.
---
Example: Firefox's "recent documents" list would be a combination of browser history and downloads panel. To open a file you just downloaded, find it in either Firefox's list, or the global list, and click/tap it. To open a web page you just created in a text editor, you would click/tap it in the global documents list and indicate that Firefox should handle it (e.g. with an Android-style app selector).
Keep existing file-management API calls as they are, and don't tie them into the document system. I don't want a game to add a new document entry for every .so or .png it loads. Application developers can decide how best to represent their document in terms of low-level filesystem objects (a directory, a flat text file, a binary blob, whatever fits the document best).
People can cope fine with hierarchies when different things go at different levels of the hierarchy. Recursive hierarchies? A bit harder.
So: God at the top, then the king, then the barons/lords/etc until you get to the peasants at the bottom. Easy to understand.
Or: shopping centre at the top, then different floors in the shopping centre, then various shops, then aisles in the shop, then vaguely demarcated lengths of aisle, then shelves, then individual items on shelves. Fine.
But: a folder at the top, then more folders in that folder, and further folders in those folders? And all those folders look the same (only the names are different. Actually, sometimes the names are the same as well). That is a bit confusing for most people.
Also consider menus. A menu bar across the top, with a single level of drop down menus underneath? Easy peasy. A start button with a pop up menu, that contains more pop up menus, that contain still more pop up menus? Disorienting. Microsoft thought the only thing holding back deep hierarchical menus was mouse control, so when they refined that for Windows 95 they went crazy with menus inside menus inside menus. Mistake. They've been trying to flatten and differentiate different levels of the start menu ever since.
Meanwhile, programmers need to be good at abstraction, so have no problem with undifferentiated folders within folders within folders.
Yet the first thing anyone does when they're looking for something is to Google it, not go to Yahoo's front page, look for the relevant category, find a suitable sub-category, ad nauseam. There's a reason search won that battle.
People can navigate a web page. They can find a food item in a menu or in the supermarket. There are a million examples. Hierarchical navigation is central to living in society.
Not very well, which is why so much time is spent trying to avoid increasing navigation depth and reducing the amount of views to minimum.
> They can find a food item in a menu or in the supermarket.
First time I see a menu that's comparable to a filesystem tree I'm going to burst out in laughter and think it's a gimmick. A supermarket is closer to an art statement about inherent chaos of modern lives than to anything hierarchical.
Yes, there are hierarchical systems, the big one being a common management structure (which works eh), and administrative subdivision of countries (hint: people almost never actually traverse that tree, they always go directly for a specific entity in it. Also, they routinely get lost in it). They're a bother and used when they can't be avoided, or when nobody bothered to work on something better. Or when you need to sort a bunch of numbers or something. The reason for avoidance being, besides the low transparency, complex data maps into trees really poorly.
The quibble isn't with the hierarchies. It's with the navigation. The point is that some do not enjoy navigating anything, hierarchical or not. That's why librarians' assistants have jobs.
So if you have a magical medium where information can be abstracted behind any means of retrieval, you give the apes what they want: their bananas in a pile, instead of in tiny, head-scratch-inducing drawers.
The vast majority of computer users (outside of knowledge workers, and techies) are completely befuddled by hierarchial navigation. Eliminating it was one of the great steps forward on the iPhone.
you can tell someone's orientation towards hierachical file systems by how they normally put their files right now.
I observed two different distinct species - one will just dump everything into the desktop (or the My Documents) folder. The other will place all of their files in subdirectories, or sub-sub directories, in a very organized manner. If you look at their real life organization techniques, it would very likely be the same.
Barely. Perhaps you never read the complaints people have about webpage navigation, or noticed that almost no user understands hierarchical URLs.
You know what the top Google searches are? Stuff like "fb", "facebook", "twitter" etc. Because people cannot even understand they can write the URL on the address bar or remember it.
>They can find a food item in a menu or in the supermarket.
You kidding me? People can barely find stuff in the supermarket, and only after searching and scanning with their eyes the shelves. For items they haven't bought in a while, they have to check the sings over every isle, or ask a supermarket employee.
If someone is able to purchase food at a supermarket does it follow that this same individual cannot also have difficulty understanding a hierarchical filesystem?
Who actually puts things in hierarchies, besides technical people? That always struck me as the most ridiculous thing about the "folder" metaphor--when have you ever seen people put folders inside folders?!
Every designer I've known falls into one of two camps: they either have an incredibly detailed folder hierarchy or else they store every file they've ever created or downloaded on the desktop.
They way I view is similar to de-normalization/"pre-materializing" in a database: the real solution is for a file to be tagged with pieces of metadata, maintain a real-time index, and then to be able to perform exact queries instantly (something like LinkedIn's faceted search) against this metadata.
E.g., first I want to find all files tagged with "code", then I want to find all files tagged with "current project". Then I get a list of all files in a current project and possible tags I could look for (e.g., it will show many are also tagged with "java" or with "C++" so I can add those tags to my search).
The problem is historically (that is, until recently) these kind of queries have been prohibitively expensive in both space and time: there's time complexity of doing a boolean query on the index, there's the space complexity of storing the index amenable to those queries both on memory and in-disk. This is difficult to in the context of legacy desktop machines (think minimal requirements to run Windows XP: 256mb of RAM, 5400 rpm disk, pentium III cpu) that were prevalent until just a few years ago.
Instead, the solution chosen is the same solution that folks building distributed "NoSQL" databases or sharded SQL database setup go for: group all related data into a few rows (in this case directories) and treat the data as hierarchical (a return to pre-RDBMS era).
Today if your working set fits in main memory (which is most probably the case for even the biggest data collections on most people's personal desktops), there's no longer a performance related reason to use a single-node (non-partitioned) "NoSQL"-style setup (there may be other reasons to, e.g., wanting to have a more flexible schema, saving time, wanting to scale out later, etc...)
I suspect the real reason we haven't done this with file systems is due to legacy: I have data organized into files and folders going back to ~1998 that I do not want to lose and can't afford to tag manually.
The support from my theory comes from the fact that the first systems to embrace non-hierarchical file system have been legacy-free devices where important storage (for 99% of the people out there...) is either on the SIM card (addresses), in the cloud (mail) or is de-facto tagged and has to be copied over in any case (photos which have EXIF tags and are stored in photo album apps or cloud services).
The same has also been happening on the other end of the spectrum: e.g., large scale distributed storage system for much similar reasons (i.e., they are the first of their kind, so there was a "license" to build these systems in a legacy-free fashion).
tl;dr Hierarchical storage is a non-functional requirement. Functional requirement is being able to do complex exact queries.
>There seems to be a prevailing attitude among some that the "users" don't like trees of files and we should all move to something more advanced.It has always seemed weird to me.
The opposite should feel weird to you. The notion that files belong in some kind of tree structure. It's just an artificial implementation we came up with, more Platonic than realistic.
A file doesn't belong in some "node" in a "tree". It belongs to multiple nodes all around the tree, including "nodes" that only make sense for that one only.
A tree hierarchy FS doesn't reflect that (except if you go crazy with symbolic links). And then it doesn't scale with lots of tags, or tens of thousands of files.
A tagging/metadata system is a far better way to manage those files, and closer to they way we think (associating attributes with objects, remembering based on keywords, etc).
Filesystem is mostly useful for a number of cases (though perhaps not the average person), but I am glad it's there and one can access external storage or /system (read only) without root.
It's pretty useful for the following conditions:
1) root users that want move around and change config files (boot animations, system wide theming, etc). Also for flashing stuff in recovery where you need to point to the file you want.
2) ROM modders/developers - looking at various files live on the device and also for low level things such as filesystem access in recovery to get yourself out of a jam.
3) app developers - I like to use sftp on my device and sshfs on my pc to directly access sqlite dbs for apps I am working on and play with the db directly without having to reinstall the app to update it.
4) Those that want apps that obey filesystem rules versus global (like for a music player, I use one that reads by directory instead of just dumping everything in by tags).
Isn't this exactly what UIDocumentInteractionController, etc accomplishes? [0] Each application registers the data types for which it is a "viewer". Application with the content provides a way to open the document interaction controller with reference to the document, iOS supplies icons of apps that can open it, user selects app and it opens with a different launch options so it opens the content directly.
There is nothing more fine-grained than file-type but mime-types, win32 registry keys, etc have always just been conventions really outside of a few well-known types. BFS (beos) tried to add in metadata attributes to the filesystem and it was pretty slick, admittedly.
I guess I can kind of see the complaint about wasting space on duplicates but if one app is a viewer, and the other is an editor... well I think the OP comment is kind or obtuse. Sandboxing files is a much better approach for lots of reasons.
Apple made the right decision, let each application organize access to its information in the way it best sees fit. If it's a tree view, ok if it is some skeumorphic bookshelf, ok.
I use Android's filesystem to move files from SD to internal or reverse, from the downloads folder to more appropriate categorized folders, and to find files to delete for more room. I appreciate having this ability a lot. Things like this should just be standard for any OS. I also open some local html files with file:// on firefox mobile sometimes.
If you mean ContentProvider [0] that is really only useful for highly structured data. Falls apart pretty quickly for non-relational data files and documents as well as media, or do you have some counter examples I could consider?
It's a tradeoff. Not sharing files means that rogue/buggy apps can't mess up data from other apps, app developers can change file formats without worrying about other apps reading their files, you don't need to worry about files left over after you delete an app, etc.
On the flip side, nobody except Apple can implement utilities that work with "data regardless of what kind of data it is" - things like synchronization, compression, encryption.
Personally, I agree with the OP in a sense that I don't like the choice that Apple made, but I can see their logic... And given that choice, what I would really like to see is more apps using UIFileSharingEnabled key, which allows me to copy files between app sandbox and my computer via iTunes - you hear me, Dropbox?
Yes, users. Presumably, in Apple's view, the filesystem is a poor metaphor for users. Users think of their files as "in iTunes" or the like. Removing the filesystem separates concerns by requiring more strict ways of passing files around.
>> "each app must copy every file it needs access to"
>> "Each and every developer must reinvent the file system"
These points are fair criticisms, but to claim blankly, "Apple needs to make a full U-turn on this" seems a bit much. I think there are a lot of potential fixes for this issue, and even though the author dismisses Dropbox, it seems like an obvious potential solution. There are other OS-level potentials though, like web intents, etc.
The claims, however, seem like a one-sided argument which fails to understand Apple's line of reasoning whatsoever.
It became such a pain in the ass for audio users that a new inter-app standard, AudioBus, was given the greenlight by Apple after accumulating signups from thousands of musicians who wanted to push audio & MIDI data between apps.
>It became such a pain in the ass for audio users that a new inter-app standard, AudioBus, was given the greenlight by Apple after accumulating signups from thousands of musicians who wanted to push audio & MIDI data between apps.
AudioBus doesn't have anything to do with sharing files on some folder. It's about passing audio and midi information around, which is different. You can do that, and still have every application perfectly isolated and deletable at will.
No, it arose because "saving audio in one and opening in another" is not how you work with sequences, plugins and effects in real time. You have to stream music and control data from one to another. It doesn't solve the "copy/paste audio from app to app" problem, it solves something totally different.
Obviously this is a problem that doesn't exist for most file types that don't have to be passed in real time between many apps to be manipulated at once (i.e almost all of them).
I guess this guy does not understand what sandboxing is and the benefit it brings in terms of security. Android today has 79% of malware issues and IOS is at 0.7% — thanks to policies like sandboxing.
Developers are generally intelligent people but unfortunately many users are not. Sandboxing is for those people and it does its job well.
I do think however that there is a case for allowing a vendor-level sandbox so that apps made by the same vendor could share data amongst themselves.
This would facilitate free-trial to paid app upgrades.
In any case, give it time. Apple tends to start off with a solid base and build from there (rather than throwing everything onto the wall to see what sticks).
I'm sure there is a use case for sharing files between applications beyond what we currently have (Photos, Contacts), but, in the 5+ years I've been using my iPhone (and it's 200+ current apps installed currently on my phone) - I've never run into it. I (personally) love the fact that everything is reasonably sealed off. In fact, the major problem I had with the iPhone was that it allowed applications to access my address book without my explicit permission (since resolved) - it wasn't sealed off enough.
I'll be the first person to sign a petition requesting that Apple continue to enforce their absolute separation without really explicit guidance from me. The tradeoff (lack of flexibility versus increased security) is one that I'm very happy to make.
I ran into that on my first day, and a bunch of times since. I guess you've never been in an airport, and realized you left that audio book at home, and though to yourself "Oh, right, I'll just copy it over."
Surprise, unless your scp application has a built in audio player, tough nuggets.
It's infuriating when you're dealing with ebooks in other languages (particularly Japanese) as iBooks and a bunch of other apps are not very good at supporting these. With no way of sharing books between apps, you wind up needing to find a new way to smuggle your book app to app in order to find out that this one doesn't work, either.
I'm sick of all the apple apologists acting like this isn't a pain point or that inability to do these things is somehow good. It's bad, it's a major pain point, and it's not about malware. It's about limiting your choices.
I'm also willing to attribute the lack of app-app sharing of data to intellectual cowardice.
I'm not an Apple apologist. They make some miserable choices, and a some of their apps are complete crap (Their podcast app should have never, ever been released.) I've never been happy with any of their cloud applications, mobile me was crud, their web photo sharing system is still next to useless, and photostream is barely useable - you'd think after a couple years they would have been able to figure out how DropBox syncs so reliably. Battery Management is horrible - I can't tell what's heating up my iPhone and sucking down my battery. Background applications STILL can't download files, even when you have 100% battery, are plugged in, and are on WiFi (Seriously - when is Apple ever going to figure that one out - When will my NYT app be able to download a newspaper, OmniFocus Sync my Tasks, Downcast download my Podcasts, etc..).
I could go on and on about the things I don't like about Apple, and Apple products - but, the one thing they nailed is 100% App Separation on the iPhone. Malware is already starting to make it's way onto the iPhone, and the more they can do to lock down that platform, the happier I'll be.
Does this mean that I don't have the flexibility with my Phone that I have with my Laptop? Yes. But does it mean my phone is about 10x more consistently reliable than my Laptop - Also yes.
But, with all that said - could Apple come up with a mechanism to allow some kind of Inter-App sharing, wherein you could explicitly (I.E. User Initiated, not App Initiated) send data from one application to another - Almost certainly. John Siracusa has been on them to do this for at least a couple years now - and if they'd simply use one of his (very well informed) rants as their PRD, the IOS platform would certainly evolve. But I'm hoping they do it in a way (Copy / Paste?, Sharing Icon?) that guarantees the same level of separation, reliability, and simplicity that we currently enjoy.
Until then - Media viewing/consumption apps like GoodReader usually offer a pretty broad variety of input options, including just reading from your Dropbox folder (among many, many choices)
Ummm.. they did. [0] Let me know if you have any questions, happy to answer them but I really get the feeling you're not an actual mobile app developer?
Definitely not a mobile app developer, actual or otherwise. But, as a user, I look forward to the day when I can, say, take a newspaper article, and send them to GoodReader, or grab my boarding pass on singapore air, and put it into Omnifocus.
It is a little frustrating when I see the Doc/Object right in front of me - and I can't send it anywhere.
My current model of sharing files/docs between Apps is usually to Take a screen shot with the Home/Power button, which gets it into my camera roll, from there I can copy/paste the image into various apps that take paste.. Screen Shot + Camera Roll + Copy/Paste is my current iPhone Inter-App sharing process. I have to believe there is something more efficient in the future.
Not having a mess of folders I need to deal with is mostly a welcome change in the new devices. On iOS I never have to think about the files, but if I do uninstall an app (say if I get a better drawing app or something), all my work done in app 1 is lost. On Android thats not always the case though I do find folders of data written by apps that I have uninstalled and had no idea was still around.
I think having a file system is a good thing, but it doesnt need to be very much in a user's face. A middle ground may be where a user doesn't see a file system but can get a prompt like "Get data from app..." that then negotiates with the other app to actually find the relevant directories.
As I replied to this developer, I think a device-level file management store and UX is very 80s.
The solution to the current trade off IMO is to maintain the sandboxes, but to fix pervasive search across apps and devices - expose more data facets, make the UX ubiquitous, ensure strong default privacy controls, and oh yes, ensure the FAST=TRUE setting is enabled. That's how you outflank DropBox.
I'm not sure if many here use iCloud search today (for mail), but it is abysmally slow and unreliable. This isn't just my personal pipe dream - apple really needs to fix search... but they could do it in a way that is consistent with their long term goal of eliminating the hierarchical file system for regular users, and really revolutionizing data access/sharing UX.
The lack of file organization is fine for what iOS is right now. But if Apple is pushing this platform as a place to do real work, there ought to be a way to group assets by project, save/restore them as a group, etc. Maybe this could be done as tags, but I don't know if users actually prefer that to folders.
For instance, on the Mac you have the "Web Receipts" folder for all your saved purchase receipts. On iOS, where would those go? The Apple solution would be a dedicated "Receipts" app, where otherwise a generic PDF viewer would do the same job.
iOS is kind of the opposite of the Unix philosophy - every app has to do everything.
This isn't a very well informed rant. Sandboxing exists so that malware doesn't get access to all of your files. The address book used to not be protected and look at the crapstorm that caused when Path accessed the address book without informing users.
And a file tree is a poor abstraction for "mere mortals". John Siracusa has a much better discussion of why an exposed file system is a bad idea in the last episode of the Accidental Tech podcast.
http://atp.fm/episodes/6-live-like-other-people
I disagree. The post ends with "We HATE it!", with "HATE" bolded. The title (rage included) is a pretty accurate summary of what you're going to read.
Now if you're asking if this is a useful way of starting an HN discussion about whether or not iOS should change its file managment... I'd say probably not, but that's a different question from whether or not the title accurately captures what the link points to.
Someone with access to edit headlines on HN fixed it. When I first saw it, it said "hate apple for" while the actual post said "hate it". That changes the meaning of it.
Do you remember that Leave Britney Alone kid?
Speaking as a developer, the ability to do interesting things with files has improved dramatically over the years. You can do the email attachment thing, iTunes sync, clipboard, Dropbox... In my day, we put things on S3 and passed custom links around. And we liked it! (Not really; it was terrible.)
As a user, now, I call bullshit. It's occasionally weird but it's definitely not a rage-inducing condition. Besides that, Apple has found an easy-to-communicate means of enabling their users manage the limitations of their storage:
Every app has its own weight. Need room? Dump an app. Don't worry – nothing you do in any other app will be affected.
Does it make for some duped data? Probably. Maybe tons for certain workflows. Doesn't matter.
The hermitcally sealed environments of each app let a larger swath of their userbase manage things without outside help. Limited complexity makes it easy to understand the scope of possible problems and solutions.
tl;dr: Ain't no Santa Claus and keep on crying.