File-centric or stuff-centric? How do you get to things?

[Copper Bezel]

Hey all. I'm not a developer, so I apologize for my poor terminology and general lack of awareness of the underlying mechanics here, but I wanted to hear your thoughts on this. Further credits to my total lack of credentials to enter into this discussion include that I'm an Ubuntu Linux user with zero OSX and iOS experience, I have not tried Windows 8, and I've had only very little interaction with Windows 7 or Android.

I may be conflating some trends, but I think that recently, there's been a very visible split between "application-centric" and "file-centric" models of interacting with documents. Desktops and applications can either act as modular handlers for the files you pass to them, what I'm calling file-centric, or as managers for classes of files, what I'm calling application-centric or stuff-centric. I know these terms are poorly chosen, so I'll gladly accept the first alternatives you'd propose, but if you're organizing your vacation photos, you could use a file manager and an image viewer, or you could use something like Picasa or Windows 8's picture manager, and that's the distinction I'm interested in. The file-centric approach is built into a lot of conventions in software design, and it's stated outright in the Unix philosophy. At the same time, I've heard (Linux) users compare the file manager to a terminal window - something occasionally necessary but not a part of ordinary daily computer use. So there's a disconnect, and I'm curious.

The example for the file-centric case would be something like a text editor, where a user generally locates a file through a file manager and invokes the text editor as a command on that file. If the user wants to open another file, there's generally an "open" dialogue available, but this is only ever a less featureful file manager with, at best, easy access to a list of recent documents of the appropriate types. When a file is modified, the changes exist only in the copy of the file handled in the RAM and won't affect the original until the user writes out or "saves" it. A file isn't normally erased from the drive from within the application. Office suites, image editors, etc. usually fall into this category.

The example for the application-centric case would be an iTunes-like media player, where music is purchased, cataloged, sorted, searched, and erased from within the media player application. All the system's relevant files, as well as files available through web services, are cataloged and accessible in a non-hierarchic, search-centric way. Changes to files (say, adding tags to a music track) tend to be saved automatically, periodically, or on exit. The conceit is that the application contains the documents and that the document you're looking at is the thing itself, not a copy made for editing. Web applications, among others, seem to operate this way as a rule.

Desktops themselves can favor one model or the other. Desktop icons mean that the file manager is, in some sense, the first thing a user sees on logging in, but they're falling out of favor in Windows and Linux (literally replaced by applications.) OSX Lion of course uses automatic saving and versioning in many applications, Windows 7 has its libraries, and Windows 8 Metro seems to favor an entirely application-centric approach with file management handled through applications tailored to specific kinds of content, while the desktop app follows the file-centric model. Most Linux applications are file-centric, but the Gnome desktop is making efforts to use a library approach for office document files (that is, like Windows 8, creating a specialized file manager with web service connections for a content type) and the desktop itself prominently features recent document searching to circumvent the need for a file manager in some cases. Android and iOS are fully application-centric.

In general, the latter approach tends to cause problems for portability across applications, and sharing and collaboration features are limited to the ones intended by the developers. It can also lead to workarounds. But recently, I've really got to like it a bit. I noticed this first with Dropbox, when I realized that it was sometimes easier to get to a particular file through the web interface than through my own filesystem, and now I've taken to using Tomboy Notes, an application-centric personal wiki app, over using plain text files for things like, say, typing this post up. There are occasions where web apps seem to skip steps over native ones because of this philosophical difference. And I've wished for a decent library functionality in an office document editor for quite some time.

So, first, are there names for these things? And second, which makes more sense to you as a user? How do you feel about desktop icons, and how often do you actually launch a file manager? How often would you want to, ideally?

[Iranon]

I strongly prefer a file-centric approach. More direct, transparent, open-ended. Less likely to cause trouble down the road.
I'll happily use a layer of shortcuts and abstractions on top of that, but I wouldn't want to rely on it... even less on an app-centric approach with no fallback. This is mostly a personal preference in the free world, with commercial software I'd be concerned about losing control and facing heavy vendor lock-in.

I have no use for desktop icons because I rarely see much of my desktop thanks to extensive use of window resizing/positioning shortcuts and manual tiling.
There is little reason for me to load up a file manager for everyday tasks unless I need to do something kinky and unusual with a file: usually semantic launchers and custom/dynamic menus get the basics done.

If adding complexity to the standard tools, I'd like a file manager with much-expanded functionality... a standalone Konqueror on steroids would appeal to me.

[Copper Bezel]

Yeah, I have a lot of the same concerns - since I'm running mostly free software, I don't worry about intentional vendor lock-in, but weird little file formats not designed to be portable are effectively the same thing. (It doesn't much matter whether the format is proprietary, or even binary, if no one else bothers to write anything that can read it.) That's part of why I was using .txt files for note taking, and why switching to Tomboy felt like making some bizarre commitment. In-app libraries also don't generally interface well (or at all) with something like Zeitgeist, and like you, I really appreciate semantic launching. I can also imagine some hassles with the specific example I mentioned of an office document library, with weird import and export steps for, say, dealing with downloaded files or e-mailing - Gnome's own Documents app doesn't have those problems, but it has so many other problems that I don't think it's an effective PK just yet, and I don't think it would be useful without being integrated into the document editor itself. But that further reduces options, because more integration means more compromises - situations where you're using this office suite instead of that one because it's a better file manager, which sounds like nonsense.

I never use Open dialogues, though, and I'm more likely to duplicate a file through the file manager, then open it, than open the first file and Save As. If I'm working in a particular location, I'd rather just keep that window open, and then I can deal with files of whatever type happen to be there for whatever apps I need to use on them. I've never played with Konqueror, but maybe something to do with the file manager itself is the solution I really want - something like a tagged, selectively indexy, highly-content-sensitive file manager. An omnipresent search-as-you-type box like the ones in every library-style app ever, ludicrous preview powers with some editing capability, etc.

I do like autosaving and versioning, though. I felt like OSX Lion's implementation solved the most basic and perpetual annoyance in computing, and I wouldn't mind losing the Ctrl+S tic.

[Jplus]

"File-centric" and "application-centric" sound like good, descriptive names, and I think I might've heard those terms before.

Power users tend to prefer the file-centric approach, and being one myself I can see where they're coming from. Basically file-centric systems give you more freedom and allow you to make heterogenous folders in which files are used by several applications. Or so it seems.

I own an ipad, and when I just purchased the thing I was a bit nervous about the fact that I couldn't "directly" access the file system. However I got used to it very soon and now, 10 months later, there are many things about the ipad that I like better than about my mac, including the application-centric approach to the user interface. The application-centric UI still needs to mature a bit, but I'm sure that it's the future and that file-centric UIs belong to the past.

How come I changed my mind? First, it struck me that surprisingly many things are possible with the seemingly very limited application-centric UI. That's mostly thanks to the "share buttons" (I find that a stupid name) which let you send files from one application to another. Then I realised that at a conceptual level, an app-centric UI provides a simpler, more general and more consistent abstraction than a file-centric UI.

Simpler, because users need to think less (just go to the right application) and they aren't needlessly confronted with implementation details (like a system folder).

More general, because everything's handled by an application. In a file-centric UI you can't say the same of files; in fact there are many special cases such as the trash icon, the file manager (which is just another application but for some reason has to always run and always take the entire screen), permanent little icons with quick access menus that let you control settings/network services/hardware, system menus, configuration panels, etcetera.

More consistent, because it offers harder invariants with regard to files. If you used an application with some file yesterday and you didn't remove the file from that application in the meanwhile, then it'll still be in there today, regardless of what happened in any other applications. Also, if you send a file from one application to another, then the original file in the first application will never be affected by modification in the second application. In file-centric UIs these things vary a lot more, often leading to confusion*.

It's time to come back to my "or so it seems". The file manager in a file-centric system doesn't actually allow a normal user to do anything more access-wise than can be done in an application-centric system, except perhaps for meddling with their own configuration files which is against their interest most of the time anyway. In application-centric systems you can easily install a dedicated file manager (or multiple) that allows you to create heterogenous project folders and the like. The fact that each application keeps its own files is a feature, because it takes away the responsibility from users to do something they'd otherwise probably do manually in a global file manager (like making separate folder for unrelated groups of files, or renaming duplicates of files to reflect that they serve a different purpose).

Why manage your files if your computer can do it for you? The computer is supposed to assist you, right? Besides, most people are quite bad at managing files. Consider all those messy desktops and the millions of files that get lost every day...

Right now iOS doesn't allow nerds to peek in /etc or to compile programs and install libraries at will, but there's no principal reason why you couldn't do such things in an application-centric UI. In fact, at some point the folks at Apple will probably decide to make iOS self-hosting, since OS X and iOS are now already growing towards each other. Basically, all you need to add is multi-user support and a terminal application.

As for the open file formats problem, I think it's orthogonal to the file-centric/application-centric distinction.

------
*) You may like to think that such things happen only to the less computer-savvy, but I can give several examples of situations that are confusing regardless of your level of computer skill.

[scarecrovv]

I see no reason why file-centric and application-centric approaches can't coexist. In fact, I think I'd like that very much. If my image editor kept a searchable/browsable/magical database of symlinks to all the images on my computer, that would be quite handy. If I wanted to keep it away from certain images (such as a porn stash) I could keep those in an encrypted filesystem that spends most of its time unmounted. However, if an image editor tries to keep the files themselves in some hidden database, not subject to my own organization, I would flat out refuse to use it. I demand the ability to organize my filesystem the way I like, and heterogeneous project directories are only one reason.

[EvanED]

Here're my general feelings, in no particular order or presented necessarily coherently.

Special purpose apps for the "application-centric" perspective can be extremely nice. For instance, I use Lightroom for my photos, and it's pretty wonderful. [I have no meaningful connection to any companies who make any products I mention in this post.] It's an order of magnitude more efficient than something more file-centric, where I have to explicitly open up the next picture. Something like audio programs that give you an integrated library (I like the iTunes-style library the best, but I hate that particular program and haven't found one I really like using) lets you do more complicated searching than you could with almost any file managers, and it can also present files that are in different physical locations in a uniform way, which in some cases can be nice. In situations like this, the application view is an enormous win over the file view.

Interoperability is very important. You have to offer some extremely compelling features to win out over "I can't open your files in another program." There have been a couple cases where this occurs for me (e.g. OneNote), but it's infrequent. Consider the cases of Lightroom and, to pick the media player I'm using now, Clementine. Neither of these hide much information. You can write out all of Lightroom's metadata to XMP sidecar files, and there are lots of other programs which can open them. (I'm not 100% sure that they can read the XMP files that Lightroom outputs, but there's at least some support.) The library that Clementine uses is based off of the ID3 tags of the MP3s, or some similar, standard, in-file metadata. These, of course, are eminently portable even if the databases themselves are not at all.

The file/application-centric division is somewhat independent of interoperability, of course; though I do worry that "these documents are mine" would promote using a propitiatory format.

However, with the caveat that I haven't spent significant amounts of time with systems that take it to the extreme of iOS or Windows 8 metro, I'm skeptical of the application-centric perspective at that level. What happens if I have a file that I want to open with two different applications, e.g. an image viewer (probably nice and lightweight) and Photoshop (takes a while to start), or a source file with either Visual Studio or Emacs? For instance, I have a couple different PDF viewers installed on my home computer, and I use both with some regularity. If I want to open a document that's "housed" with application A with application B, do I need to start A just so I can then "share it with B" or whatever? (I don't really know how that works.)

And there are other problems. For instance, physical location matters. Maybe not so much with the locked down impoverished iPad, but is some file located on internal storage? On a USB stick? SD card? Network share? How much space is left on the device? And if I want to delete stuff to make space, do I need to go into 10 different applications to do it? Or if I want to share documents of 10 different types by copying them to a USB stick, do I need to go into 10 different applications to do it?

More consistent, because it offers harder invariants with regard to files. If you used an application with some file yesterday and you didn't remove the file from that application in the meanwhile, then it'll still be in there today, regardless of what happened in any other applications. Also, if you send a file from one application to another, then the original file in the first application will never be affected by modification in the second application. In file-centric UIs these things vary a lot more, often leading to confusion*.
*) You may like to think that such things happen only to the less computer-savvy, but I can give several examples of situations that are confusing regardless of your level of computer skill.

I'm curious what your examples are.

It's time to come back to my "or so it seems". The file manager in a file-centric system doesn't actually allow a normal user to do anything more access-wise than can be done in an application-centric system, except perhaps for meddling with their own configuration files which is against their interest most of the time anyway.

That last bit is why I don't own any Apple products.

[Shivahn]

I see no reason why file-centric and application-centric approaches can't coexist. In fact, I think I'd like that very much. If my image editor kept a searchable/browsable/magical database of symlinks to all the images on my computer, that would be quite handy.

That idea is pretty much exactly what I thought as I was reading this page. That's functionally similar to "open recent" and such, which I use all the time because I have obsessive-compulsive behaviors regarding my directories and don't want to have to go all the way through a super nested directory just to get to a pdf I want to read.

[EvanED]

And it doesn't have to be symlinks exactly, just some logical connection. For example, I don't care if Lightroom or Clementine keeps some proprietary, non-portable database of what files it's tracking. Unless you spend time selecting exactly what you want it to track (something I don't do; for me, it'd just be saying "all my photos are under this directory" or "all my audio files are in these couple places"), that's not something that's hard to recreate in a different program. What's important is stuff like develop settings in Lightroom (so if I moved to Digikam or something it would keep my white balance, exposure adjustments, etc.) and the contents of the ID3 tags for Clementine. And that's stored in or next to the files anyway.

[Jplus]

[...] What happens if I have a file that I want to open with two different applications, e.g. an image viewer (probably nice and lightweight) and Photoshop (takes a while to start), or a source file with either Visual Studio or Emacs? For instance, I have a couple different PDF viewers installed on my home computer, and I use both with some regularity. If I want to open a document that's "housed" with application A with application B, do I need to start A just so I can then "share it with B" or whatever? (I don't really know how that works.)

By default, yes you need to do that (the exact phrasing on iOS is "open in B"). The good news is that the delay of opening something in another application is usually negligible.
Applications can be as sophisticated as you want, of course. At least one of my file managers (I'm not sure which) lets me choose with which rendering engine I want to open my Word files (or maybe it was another file type).

And there are other problems. For instance, physical location matters. Maybe not so much with the locked down impoverished iPad,

Now now, no need to get flamy!

but is some file located on internal storage? On a USB stick? SD card? Network share?

There are applications that let you choose between options like local, iCloud, Dropbox, etcetera. They're always very clear about the location of your files. Of course, that's more a matter of application design than of application-/file-centricness.

How much space is left on the device?

The application with the global system settings has an info section that tells you how much space is left.

And if I want to delete stuff to make space, do I need to go into 10 different applications to do it?

It could happen, if you have that many applications that store large files and you suddenly discover that your disk is full while you immediately need the same amount of space that all those applications take up. Personally, I would just immediately erase a file that I don't need anymore whenever I discover by coincidence that it's still in the application that I'm currently using.

Or if I want to share documents of 10 different types by copying them to a USB stick, do I need to go into 10 different applications to do it?

Again it depends. As I said, there are dedicated file manager applications which can store files of any type. But if you were storing those files in 10 different applications in the first place then yes, you need to go collect them first.

I'm curious what your examples are.

Spoiler:

• Most popular document-y file formats (such as Word and SVG) can be opened with many different programs. Some of these programs read/write the format natively and edit a file in place. Others use import/export semantics and silently convert the file to their own native format, saving your changes in a new file. So when you go back to the global file manager to check your document, it may sometimes seem like your changes haven't been saved. Now this is normally only a problem for users who are new to the application, but it can get more complex when multiple users are involved.
  --> In application-centric environments, all app-internal edits use native semantics and all file transfers between apps use import/export semantics, exactly as you'd expect.
• I'm using Transmission (a bittorrent client). I configured it to throw away the torrent file as soon as it's added to my torrents list (it keeps the data somewhere else of course). When Transmission is running it also automatically opens torrent files from my downloads folder. Obviously I'm not confused by this myself, but for another power user who isn't used to such configuration it could be terribly confusing. (As an aside, I also configured my archive extractor to behave in this way.)
  --> In an iOS-like setting this problem wouldn't exist, because if for example I sent a torrent file that I found in Safari to "Transmission Mobile", Transmission would keep the torrent in its list and Safari wouldn't close the tab with the torrent file. Or if I got the torrent from an email attachment, it would still show up in my email application afterwards.
• I'm not sure about the current state of the art, but when you downloaded something with IE7 on Windows XP and chose "Open" instead of "Save", you wouldn't be able to find the file back after closing it. It's still on your disk, but if you don't realize that and you haven't searched the web, there's no way to figure out that you have to open your %TEMP% if you want to open it again or erase it. You can also periodically run the Windows disk cleanup, but most people don't know it exists and that's nothing to do with skill (it's got everything to do with bad design, however).
  --> This wouldn't happen in an application-centric UI, because either you send your download directly to another app without storing it in the browser or you download it in the browser and it will stay there after you've shared it. In either case, the file won't disappear from the receiving app either.
• Mail, the email client on Mac OS X, has two folders for attachments, both of which are strictly speaking implementation details. One is for the attachments as they arrived. If you double-click an attachment in Mail to open it with the standard application, it copies the file to the second folder just in case you're going to edit it. While this works in order to prevent the original file from getting overwritten, it usually leads users to either needlessly copy the file again (if they're careful) or to save the file in the second folder, then be unable to find it back (because they were not alert enough to check the location of the file they were editing). To make things worse, if a power user decides to bypass Mail and browse their home folder in search for the Mail attachments without knowing about this design, they might end up finding either of those directories first and editing the contents directly with whatever application they choose (or deleting them). Depending on the outcome, that might severely screw up the operation of Mail. (I've been confused by this myself, but fortunately I didn't screw up anything until I learnt how things actually work). Amusingly, the usual workaround (by people who've been confused before) is to drag the attachment icon to a folder of your choosing, which is very similar to an app-centric way of working.
  --> You could probably say that this part of Mail is poorly designed. However, in an application-centric situation the problem is simply impossible to create. The mail application would never edit incoming attachments, since that is not its job. If another application would be used to edit an attachment, then that application would always have its own variant of the file and the user would always know that.

It's time to come back to my "or so it seems". The file manager in a file-centric system doesn't actually allow a normal user to do anything more access-wise than can be done in an application-centric system, except perhaps for meddling with their own configuration files which is against their interest most of the time anyway.

That last bit is why I don't own any Apple products.

The fact that you say this proves that you're prejudiced. I can meddle with my configuration files on my mac, in fact Mac OS X doesn't really protect the user against such unwise undertakings. Note that my point is that most users would only get worse from it if they were ever to touch their configuration files directly. It's a good thing that an application-centric system (such as iOS) doesn't enable this by default. But nothing prevents an application-centric system from offering a terminal application that allows the user to walk the file system, and if iOS is going to be self-hosting, which I believe it is going to be, it will have such a thing.

[EvanED]

And there are other problems. For instance, physical location matters. Maybe not so much with the locked down impoverished iPad,

Now now, no need to get flamy!

I'll take back my statement as soon as the iPad/Phone has an SD card slot.

(Built in, not available as something you plug in. After buying for $30.)

There are applications that let you choose between options like local, iCloud, Dropbox, etcetera. They're always very clear about the location of your files. Of course, that's more a matter of application design than of application-/file-centricness.

The fact that you have to say "there are applications..." indicates to me a problem. Why isn't it true for all? With a file-centric view, everything is obviously aware of this.

How much space is left on the device?

The application with the global system settings has an info section that tells you how much space is left.

I wasn't saying you wouldn't be able to determine that; heck even my TI-85 has information about how much space is used and left. My point was just that space is a reason that "it's stored somewhere" is a leaky abstraction and you have to be concerned with physical location.

It could happen, if you have that many applications that store large files and you suddenly discover that your disk is full while you immediately need the same amount of space that all those applications take up. Personally, I would just immediately erase a file that I don't need anymore whenever I discover by coincidence that it's still in the application that I'm currently using.

My problem with your behavior is that if I need to free up space, it's not so much a question of "do I want this file" (the answer is "yes") as "do I want this file more than what I'm clearing out space for?"

Most popular document-y file formats (such as Word and SVG) can be opened with many different programs. Some of these programs read/write the format natively and edit a file in place. Others use import/export semantics and silently convert the file to their own native format, saving your changes in a new file.

To be honest, even though I use a few of these, I can't think of any that will silently save a new file. Warnings like "if you save this in the original format, stuff will be lost, what do you want to do: save in original format (lossy) or save in my format" are basically universal in my experience, as is asking for the new file name when saving in the native format.

I agree that this can potentially be a problem if you have multiple users (a forgetful you counts as another user), but I don't see how the application-view helps things. If you were working in app A then export to app B and the other person doesn't know you did that and keeps working in app A, they'll still have the old file. Same as in the file-centric world if they keep working with the old file they'll, uh, keep working with the old file.

I'm not sure about the current state of the art, but when you downloaded something with IE7 on Windows XP and chose "Open" instead of "Save", you wouldn't be able to find the file back after closing it. It's still on your disk, but if you don't realize that and you haven't searched the web, there's no way to figure out that you have to open your %TEMP% if you want to open it again or erase it. You can also periodically run the Windows disk cleanup, but most people don't know it exists and that's nothing to do with skill (it's got everything to do with bad design, however).
--> This wouldn't happen in an application-centric UI, because either you send your download directly to another app without storing it in the browser or you download it in the browser and it will stay there after you've shared it. In either case, the file won't disappear from the receiving app either.

To be fair, the HD space issue would be solved with automatic cleanups of %TEMP%, like Linux does with /tmp.

And again, the application-centric view sounds like it isn't a clear win. Does that mean I have to manually delete stuff that I download just to view? That's annoying.

However, I do see the advantage in the "temporary file I want to keep around" scenario, which applies to both this and your mail example.

That last bit is why I don't own any Apple products.

The fact that you say this proves that you're prejudiced. I can meddle with my configuration files on my mac, in fact Mac OS X doesn't really protect the user against such unwise undertakings.

OK, you're right; that was unfair. However, it's basically true if I amend my statement to refer to Apple's iOS products, and expand my objection about lack of configurability to control in general (application selection).

It's also true to the extent that OS X is perfectly technically capable of running on non-Apple hardware, but you have to hack it to get it to run. I actually kind of want to give Apple my money for that, but they don't want it.

(Apple desktops I don't own for other reasons -- in particular I don't feel they make anything remotely suited to what I want. Laptops are about the only place where I'd even consider an Apple product, and even there there are significant disadvantages. These are mostly unrelated to Apple's iOS control fetish though.)

[Jplus]

There are applications that let you choose between options like local, iCloud, Dropbox, etcetera. They're always very clear about the location of your files. [...]

The fact that you have to say "there are applications..." indicates to me a problem. Why isn't it true for all? With a file-centric view, everything is obviously aware of this.

Oh, it is true for all. It's just that not all applications let you choose; by default they only store files locally on your device. (In your home folder, to be exact, but for current iOS that's irrelevant because it's single-user).

Personally, I would just immediately erase a file that I don't need anymore whenever I discover by coincidence that it's still in the application that I'm currently using.

My problem with your behavior is that if I need to free up space, it's not so much a question of "do I want this file" (the answer is "yes") as "do I want this file more than what I'm clearing out space for?"

Point taken, but then still I think an application-centric approach is more helpful because the files that you stored in your "take funny photos" app are probably much less valuable to you than the ones you stored in your code editor. Heck, in my case I could just throw away that 400 MB motor racing game that I'm never playing and didn't pay for.

Most popular document-y file formats (such as Word and SVG) can be opened with many different programs. Some of these programs read/write the format natively and edit a file in place. Others use import/export semantics and silently convert the file to their own native format, saving your changes in a new file.

To be honest, even though I use a few of these, I can't think of any that will silently save a new file. Warnings like "if you save this in the original format, stuff will be lost, what do you want to do: save in original format (lossy) or save in my format" are basically universal in my experience, as is asking for the new file name when saving in the native format.

Yeah, to be honest they do always prompt you before saving the file. However I've never seen an explicit warning of that kind. If the user is a bit sleepy or distracted, they might not be aware that they're saving a new file of a different type.

I agree that this can potentially be a problem if you have multiple users (a forgetful you counts as another user), but I don't see how the application-view helps things. If you were working in app A then export to app B and the other person doesn't know you did that and keeps working in app A, they'll still have the old file. Same as in the file-centric world if they keep working with the old file they'll, uh, keep working with the old file.

You're right, but if the other person knows there are two version at least there can be no confusion over which is the original. In a file-centric situation, the two versions are likely to reside in the same directory and even to have the same name.

I'm not sure about the current state of the art, but when you downloaded something with IE7 on Windows XP and chose "Open" instead of "Save", you wouldn't be able to find the file back after closing it. [...] %TEMP% [...] Windows disk cleanup [...]

To be fair, the HD space issue would be solved with automatic cleanups of %TEMP%, like Linux does with /tmp.

And again, the application-centric view sounds like it isn't a clear win. Does that mean I have to manually delete stuff that I download just to view? That's annoying.

I don't have to do that with mobile Safari, but someone could design a browser otherwise. It's not an inherent issue with application-centric systems in any case.

That last bit is why I don't own any Apple products.

The fact that you say this proves that you're prejudiced. I can meddle with my configuration files on my mac, in fact Mac OS X doesn't really protect the user against such unwise undertakings.

OK, you're right; that was unfair. However, it's basically true if I amend my statement to refer to Apple's iOS products, and expand my objection about lack of configurability to control in general (application selection).

What's wrong with application selection on iOS?

It's also true to the extent that OS X is perfectly technically capable of running on non-Apple hardware, but you have to hack it to get it to run. I actually kind of want to give Apple my money for that, but they don't want it.

I can see where you're coming from. Apple chose this as their business model because they think they can make more money in this way, but of course people have different preferences.

[EvanED]

There are applications that let you choose between options like local, iCloud, Dropbox, etcetera. They're always very clear about the location of your files. [...]

The fact that you have to say "there are applications..." indicates to me a problem. Why isn't it true for all? With a file-centric view, everything is obviously aware of this.

Oh, it is true for all. It's just that not all applications let you choose; by default they only store files locally on your device.

That's sort of what I mean... if the app doesn't let you choose where to save something, that's broken. Am I misunderstanding something?

Point taken, but then still I think an application-centric approach is more helpful because the files that you stored in your "take funny photos" app are probably much less valuable to you than the ones you stored in your code editor.

Yeah, but isn't your "take funny photos" app the same as your "take serious photos" app? And isn't your "watch this dumb video I downloaded for some reason" app the same as your "wow this video is awesome I want to keep it forever and ever" app?

Heck, in my case I could just throw away that 400 MB motor racing game that I'm never playing and didn't pay for.

Yeah, but that's not specific to the app-based setup; Windows gives you it's uninstall dialog (with sizes for most programs, though not all for whatever reason) and other systems can do something similar. The one potential benefit I could see is it might give a cleaner delineation of "this data belongs to this app" so that when you remove an app, it could say "would you like to remove the associated data or not?" and if you said yes, could actually delete the documents that app manages. (Of course, if you don't give me the option and just go ahead and do it, then I stop using your system. )

Yeah, to be honest they do always prompt you before saving the file. However I've never seen an explicit warning of that kind. If the user is a bit sleepy or distracted, they might not be aware that they're saving a new file of a different type.

Really?

Here's a list of programs that do what I said, off the top of my head:

Spoiler:

The Gimp (open a JPG, add a layer, save):


OO calc and writer:


Excel (probably can just save an empty, default file):


Word:


And even sort of Inkscape, though that does something different, which is continues to save it in the format you chose, but then when you close the document warn you that you could face data loss:

You're right, but if the other person knows there are two version at least there can be no confusion over which is the original. In a file-centric situation, the two versions are likely to reside in the same directory and even to have the same name.

I think you're being unfair to the file-centric version here. Why would you assume that the person knows which application it was originally done in but not which format is original?

Besides, you could just look at the last modification time for a perhaps-decent idea. Something you might get (would get, from any application worth its salt) with the application-centric version but definitely would get with the file-centric version.

What's wrong with application selection on iOS?

Do I really have to go and quote any of the dozens of stupid-ass rejections Apple has made? (E.g. these) Like the couple apps mentioned at that link that could access obscene material among oodles of non-obscene material. You know, like Safari.

Or the fact that you can't run interpreters. Hell, my phone has Python installed... and I use it!

Even if many of the most egregious problems have been fixed, they've only been fixed after a public thrashing of Apple. An Apple-sanction app store would be fine... the fact that it's the only source of applications is most definitely not OK by my book.

(And before you say "jailbreak it", go back and read what I said about if Apple doesn't want my money then I won't give it to them. There are plenty of reasonable alternatives to the iOS products, and I'll pick one from a less arrogant company.)

[Jplus]

There are applications that let you choose between options like local, iCloud, Dropbox, etcetera. They're always very clear about the location of your files. [...]

The fact that you have to say "there are applications..." indicates to me a problem. Why isn't it true for all? With a file-centric view, everything is obviously aware of this.

Oh, it is true for all. It's just that not all applications let you choose; by default they only store files locally on your device.

That's sort of what I mean... if the app doesn't let you choose where to save something, that's broken. Am I misunderstanding something?

No, I think we understand each other. It's not an inherent problem with app-centric systems, though.

Point taken, but then still I think an application-centric approach is more helpful because the files that you stored in your "take funny photos" app are probably much less valuable to you than the ones you stored in your code editor.

Yeah, but isn't your "take funny photos" app the same as your "take serious photos" app? And isn't your "watch this dumb video I downloaded for some reason" app the same as your "wow this video is awesome I want to keep it forever and ever" app?

Yes, the funny/dumb apps could coincide with the serious/awesome apps. You still know about an app that it stores things that are less valuable to you. But I concede that's not a real difference between app-centric and file-centric.

Heck, in my case I could just throw away that 400 MB motor racing game that I'm never playing and didn't pay for.

Yeah, but that's not specific to the app-based setup; Windows gives you it's uninstall dialog (with sizes for most programs, though not all for whatever reason) and other systems can do something similar. The one potential benefit I could see is it might give a cleaner delineation of "this data belongs to this app" so that when you remove an app, it could say "would you like to remove the associated data or not?" and if you said yes, could actually delete the documents that app manages.

Yes, file-centric systems let you uninstall applications too, but in an app-centric system (or at least in iOS) you can uninstall them directly from the same location that you launch them.

(Of course, if you don't give me the option and just go ahead and do it, then I stop using your system. )

Just give this a thought: if you remove an app, does it make sense to keep a dangling folder with that app's files?
(Perhaps you could have the app's files automatically moved to another app of your choice. iOS doesn't offer such a feature but it could be done.)

Yeah, to be honest they do always prompt you before saving the file. However I've never seen an explicit warning of that kind. If the user is a bit sleepy or distracted, they might not be aware that they're saving a new file of a different type.

Really?

Here's a list of programs that do what I said, off the top of my head:

All your examples are of programs that, in the act of converting your file, loose some of its contents. I happen to not do such things often, but you do have a point.

You're right, but if the other person knows there are two version at least there can be no confusion over which is the original. In a file-centric situation, the two versions are likely to reside in the same directory and even to have the same name.

I think you're being unfair to the file-centric version here. Why would you assume that the person knows which application it was originally done in but not which format is original?

True. Not a real advantage of app-centric, then.

What's wrong with application selection on iOS?

Do I really have to go and quote any of the dozens of stupid-ass rejections Apple has made? (E.g. these) Like the couple apps mentioned at that link that could access obscene material among oodles of non-obscene material. You know, like Safari.

Or the fact that you can't run interpreters. Hell, my phone has Python installed... and I use it!

Even if many of the most egregious problems have been fixed, they've only been fixed after a public thrashing of Apple. An Apple-sanction app store would be fine... the fact that it's the only source of applications is most definitely not OK by my book.

There are at least two Lua interpreters for iOS, one of which I'm using. I think the Python thing is more of a lack of effort problem. If it isn't available anyway. But sure, Apple is doing things you can disagree with. I disagree with some of their choices too, for example the choice to not allow web rendering engines other than WebKit in browsers.

All Apple criticism aside, none of what you say in this last quote is a problem with app-centric systems in general.

[EvanED]

It's not an inherent problem with app-centric systems, though.

No, but it's inherently not a problem with file-centric systems.

Just give this a thought: if you remove an app, does it make sense to keep a dangling folder with that app's files?

Absolutely.

For instance, I shuffle around what games I have installed from time to time since they tend to be enormous. I'm in the mood for game B, but game A is installed now so I'll delete A and install B. A couple months later, when I want to play A again, I'd be pissed if it removed my saved games.

Fortunately I don't have to do that much any more, but it was more common when I had even less disposable income than I do as a grad student and was more limited in my hard drive space.

Even for less drastic examples, there's nothing to say I won't re-install the same program later, and keeping around my old settings and documents can be nice.

(Speaking of saved games, here's another problem with the app-centric setup: what happens if I want to edit another program's file "against its will" in the sense that the other program isn't set up to allow me to do it? E.g. using a saved game editor. What would happen then? Can I do it with something like iOS? Have the saved game editor "steal" a file from another program, edit it, then put it back?)

(Perhaps you could have the app's files automatically moved to another app of your choice. iOS doesn't offer such a feature but it could be done.)

But such a thing doesn't even necessarily take sense. Take my saved games example. What app are you going to transfer ownership to? Nothing else can do anything with them, except for just "keep these around in case you need them later." (Sounds like a file system to me... )

All your examples are of programs that, in the act of converting your file, loose some of its contents. I happen to not do such things often, but you do have a point.

True. OTOH, I can't think of any programs which will "save" your file as a different format for some other reason... I can imagine that you could have a reader for format X but no writer, but I can't think of any programs that do that.

There are at least two Lua interpreters for iOS, one of which I'm using.

Unless those interpreters are basically uselessly limited in scope, they're in violation of the app store policies. (And these polices are enforced at least some of the time -- if Apple got wind of that capability, the apps would be in dire danger of being removed from the app store.)

Interpreters are allowed, but only if they can only run code that (1) came with the interpreter itself (e.g. you can write a program in an interpreted language, but you can't provide any hooks into the interpreter) or (2) that the user types in, and even (2) is questionable in my mind based on the iOS Developer Program License Agreement. In particular, the interpreter can't be able to run code you download.

3.3.2 Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework.

3.3.3 Without Apple’s prior written approval or as permitted under Section 3.3.23 (In App Purchase API), an Application may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the App Store.

By my reading, either of these would serve to exclude a general-purpose interpreter, and Apple has certainly banned such programs in the past for contravening them.

All Apple criticism aside, none of what you say in this last quote is a problem with app-centric systems in general.

True.

[Copper Bezel]

(Speaking of saved games, here's another problem with the app-centric setup: what happens if I want to edit another program's file "against its will" in the sense that the other program isn't set up to allow me to do it? E.g. using a saved game editor. What would happen then? Can I do it with something like iOS? Have the saved game editor "steal" a file from another program, edit it, then put it back?)

Well, the assumption is that even with a fully app-centric approach, there's still an archive associated that you could modify from outside. Presumably, you'd be editing the application's data, digging through weirdly named folders to find a file named in hex code and swapping it out. That's certainly not user friendly, but the process you're describing won't be, anyway.

I'm not convinced that the iOS way of doing things makes sense. I know the argument that if I'd used it for a while I'd grow accustomed to it, but it sounds like a step backward. I mean, I appreciate services like Dropbox because I know I'm always looking at the current version of a file, whether it's been edited by a friend, whether I'm accessing it on my desktop or via web, etc. I wouldn't want transferring files between applications to start to feel like e-mailing things to myself. You know, it's possible for something to be consistent in behavior without demonstrating design consistency. I'd much rather the system that scarecrovv is describing - applications keep tabs on associated files and associate a bunch of private metadata about those files in their own config data, but when a file is edited, it's edited for everyone. If I alter an image in the image editor, it's edited in the slideshow app, too. But that image editor might contain versioning data to step the image back to a prior version.

Take that approach, and you still never need to open a file manager or think about directory structure. All the user data could still be a set of assets on the system offered up through the application's abstraction. They'd just be shared assets (with the option of blocking them from view here or there, the convenience of organizing them differently between apps, etc.) And if they're simply organized into asset types - documents, videos, images, audio, etc. - it would still be possible to have a global file manager, with its own (presumably tag-based) abstracted organization, that could be used to browse, erase, and transfer data. I'll disagree with scarecrovv, though, in that I wouldn't really mind not having the ability to sort the files manually on the disk, either. I think that could easily stop being relevant with the right kind of library management approach. (I mean, it's trivially true that you can organize the files in your music folder however you like. It has no impact on how they're presented in your music player, and most people never navigate the music folder directly. I think that could be the case for everything, given the right approach.)

I really do think it's possible to have the benefits of both models, and I'd like to see the app-centric one to be the one the user sees on the surface in daily interaction. But I see that more in OSX than in iOS, particularly with the changes in Lion. There's a stronger sense that the file on the screen "is" the file on the disk, applications don't exit simply because you've closed the last document, and so on - all of which removes levels of abstraction for the user by making the workings a bit more abstracted in technical terms. All that's missing is the "library" sensibility in the applications themselves.

The alternative seems simple for simple tasks and a nightmare for complex ones. Life sometimes requires workarounds. If I have a batch of dozens of document files in heterogeneous formats I need to download and convert into yet another format, edit in another program, and package for use elsewhere - well, no model is going to make that straightforward, but a "simple" one is going to make it more complex than it needs to be.

Simpler, because users need to think less (just go to the right application) and they aren't needlessly confronted with implementation details (like a system folder).

I know this has already been addressed to some extent, but I just don't understand complaints of this nature. You're on OSX. You have almost exactly the same Unix filesystem hierarchy that I have on Ubuntu. When is it that you're seeing system files when you're not looking for them? In Ubuntu (and Gnome Linuxes in general,) the default location is always the user's home folder, with user config data hidden. I don't see system files unless I actively seek them out.

And things like this:

More general, because everything's handled by an application. In a file-centric UI you can't say the same of files; in fact there are many special cases such as the trash icon, the file manager (which is just another application but for some reason has to always run and always take the entire screen), permanent little icons with quick access menus that let you control settings/network services/hardware, system menus, configuration panels, etcetera.

Really do seem to be implementation details to me, because an app-centric system could still be just as inconsistent, and while I agree that desktop icons and faux-locations are nonsense, they're also going away. It seems like we're talking about failures of implementation of one philosophy while talking about strengths in the philosophy itself of the other. That desktop icons once existed seem like the same kind of hiccup as the occasional iOS app that doesn't include all of the right sharing options. At least the desktop icons can be turned off.

And by permanent little icons, are you referring to the system tray? iOS has indicators, too. So I'm very confused there. Not following the connection.

Right now iOS doesn't allow nerds to peek in /etc or to compile programs and install libraries at will, but there's no principal reason why you couldn't do such things in an application-centric UI. In fact, at some point the folks at Apple will probably decide to make iOS self-hosting, since OS X and iOS are now already growing towards each other. Basically, all you need to add is multi-user support and a terminal application.

This one is going a bit off the topic, but I just don't see that happening. It's not consistent with what iOS is. It's a philosophical difference even with Android, which has the terminal emulator and the desktoppy file manager already. But again, I'm not really concerned with the specific implementation, and iOS has a very specific and unusual set of goals it's designed around. I'd agree that this doesn't have anything to do with app-centric vs. file-centric.

[Derek]

Really do seem to be implementation details to me, because an app-centric system could still be just as inconsistent, and while I agree that desktop icons and faux-locations are nonsense, they're also going away. It seems like we're talking about failures of implementation of one philosophy while talking about strengths in the philosophy itself of the other. That desktop icons once existed seem like the same kind of hiccup as the occasional iOS app that doesn't include all of the right sharing options. At least the desktop icons can be turned off.

Whats wrong with desktop icons?

[Copper Bezel]

They're really tangential to the question I'd asked in the first place, so I regret bringing them up, and I didn't mean to rant after asking about them specifically in the first place. I just share Jplus's feeling that having an ever-present, special, full-screen file manager window that points to exactly one location and doesn't behave like any other window in switching makes no sense, so I've welcomed the transition to "home screens" instead.

[Jplus]

I've given some more thought to saved games and stuff like that, and I agree with EvanED that the OS should just offer the option to save the app's state (i.e. settings and files) in case you're going to reinstall it later. In fact, that would be a very nice and natural way to behave for an app-centric system.

As for "sharing" files, I agree with Copper Bezel that it could be nice in some cases if changes in one app would show automatically in another. Perhaps there should be two alternative modes for the share button, one that says "send to" in which case the file is duplicated and one that says "share with" in which case the receiving app gets a hard link.

As an aside, iOS currently offers no way to send multiple files at once. That definitely needs to be implemented.

(Speaking of saved games, here's another problem with the app-centric setup: what happens if I want to edit another program's file "against its will" in the sense that the other program isn't set up to allow me to do it? E.g. using a saved game editor. What would happen then? Can I do it with something like iOS? Have the saved game editor "steal" a file from another program, edit it, then put it back?)

Friendly game makers would offer the possibility to export saved games to another app. It's a free market, just boycot the unfriendly game makers and after a while all game makers will switch to friendly behaviour.

All your examples are of programs that, in the act of converting your file, loose some of its contents. I happen to not do such things often, but you do have a point.

True. OTOH, I can't think of any programs which will "save" your file as a different format for some other reason... I can imagine that you could have a reader for format X but no writer, but I can't think of any programs that do that.

Pages (Apple's proprietary word processor) and the other iWork apps behave as I described. It may occasionally warn you about missing fonts or something like that, but certainly not always. Since I'm on a mac and I'm not willing to pay a large sum for mediocre software like MS Office while the rest of the world seems to think of MS Office as some kind of standard (which it really isn't since even consecutive versions of MS Office itself often don't interoperate well), this is what I have most experience with.
(Open-/LibreOffice treats MS Office files in the native way, but I only resort to that unfriendly software in emergency cases.)

There are at least two Lua interpreters for iOS, one of which I'm using.

Unless those interpreters are basically uselessly limited in scope, they're in violation of the app store policies. (And these polices are enforced at least some of the time -- if Apple got wind of that capability, the apps would be in dire danger of being removed from the app store.)

iLuaBox
Codea
Cargo-Bot

[EvanED]

They're really tangential to the question I'd asked in the first place, so I regret bringing them up, and I didn't mean to rant after asking about them specifically in the first place. I just share Jplus's feeling that having an ever-present, special, full-screen file manager window that points to exactly one location and doesn't behave like any other window in switching makes no sense, so I've welcomed the transition to "home screens" instead.

You mean an ever-present, special, full-screen manager of links to a bunch of programs that only shows one set of items and doesn't behave like other windows in switching?

Friendly game makers would offer the possibility to export saved games to another app. It's a free market, just boycot the unfriendly game makers and after a while all game makers will switch to friendly behaviour.

IMO that's not a good enough answer.

I mean, it would be if I were everyone, but I'm not. Which is why EA and Ubisoft are still publishing the games that they are, despite me personally boycotting a few that I'd otherwise have bought.

Pages (Apple's proprietary word processor) and the other iWork apps behave as I described

Ah, I don't have much experience with that not having a Mac. (I would really like to be able to use Keynote, but I rarely use any word processor or spreadsheet.)

Still, I would chalk that up as "badly behaved file-centric application" like you've chalked up many of my objections to "badly behaved app-centric application".

[Iranon]

I really think we should abandon analysis of desktop icons. Most people like some unique elements for basic stuff, with either paradigm: desktop icons, home screen, dock, panel. I don't, but I do use a main menu that's quite different from application menus and that's incongruous too.

Back to real topic:
An App-centric approach may be slightly more convenient when things are done responsibly and with the users' best interest in mind, for simple use cases when everything goes well.
It's much more annoying to deal with when problems arise and when software providers are careless or dicks. As soon as users want to do something the makers didn't think of or didn't found desirable, they're fighting the paradigm. I only find the approach appropriate if you actively want to keep the platform locked down (sometimes appropriate, but I normally consider that a very bad thing).

[Copper Bezel]

As for "sharing" files, I agree with Copper Bezel that it could be nice in some cases if changes in one app would show automatically in another. Perhaps there should be two alternative modes for the share button, one that says "send to" in which case the file is duplicated and one that says "share with" in which case the receiving app gets a hard link.

Not a symlink? I just think this leads to a lot of needless duplication and extra steps. If all libraries are shared, then every app has access to all associated files as soon as you launch it. There's no extra step of exporting from the other application. And the individual app can still have whatever metadata it needs associated with that file. You might have an image editor that's "really" storing an image in an internal format as soon as you edit it, but saving back out to the original when it's changed, so that within the app you have, say, layer data and an undo history, but the application still keeps all of that invisible to all of the other applications.

Constantly updating the library takes processor cycles, but we're probably not really concerned with that. And a reasonably navigable library interface within the app shouldn't be too overtaxed by having access to all of those files. Instead of a short list of documents that you've imported into the specific app, you have a short list of recent or favorite documents, plus the long list of "everything."

The one hangup I can see is the "database integrity" problem, the situation where a document is visible in two applications at once and could accidentally be overwritten by a previous version. That would apply to the "linked" situation you're describing, too. But the apps could consistently check to see if their own last edits are less recent than the file on disk. Would that solve the problem?

I also think that in the same way that you could "opt in" to having a file linked across applications, you could just as easily have an option to "opt out" in a library model, which would then store the file internally. (A "protect from changes" option or something.) Inevitably, not every app will comply and provide this feature, but that's true of anything we talk about being internal to the application.

(I'm really talking myself into wanting this third model that the OP doesn't even discuss, because it doesn't exist. Oy.)

An App-centric approach may be slightly more convenient when things are done responsibly and with the users' best interest in mind, for simple use cases when everything goes well.
It's much more annoying to deal with when problems arise and when software providers are careless or dicks. As soon as users want to do something the makers didn't think of or didn't found desirable, they're fighting the paradigm. I only find the approach appropriate if you actively want to keep the platform locked down (sometimes appropriate, but I normally consider that a very bad thing).

Agreed, but I think some of those problems really could be ameliorated. Particularly when, as you say, the user's best interests are actually in mind. And, again, I think convenience for simple tasks can turn into inconvenience for complex ones if it's not handled well - Jplus's example of the lack of batch export in iOS would be utterly unbearable on the desktop.

I've given some more thought to saved games and stuff like that, and I agree with EvanED that the OS should just offer the option to save the app's state (i.e. settings and files) in case you're going to reinstall it later. In fact, that would be a very nice and natural way to behave for an app-centric system.

Good for any system, really. I appreciate the abstraction of being able to move config data around, reinstall the OS and have my apps still configured once I reinstall them, etc.

You mean an ever-present, special, full-screen manager of links to a bunch of programs that only shows one set of items and doesn't behave like other windows in switching?

Well, yes, but there has to be a top level somewhere, and at least they're not sitting half-visible underneath all of the other applications. I was thinking more of Mission Control, the Win 8 Start screen, and the Gnome Activities Overview than iOS's application icon grid and Android's icon-and-widget grids. The desktop home screens justify themselves a little more with one form or another of interaction with the applications, instead of just being a way of launching them. But iOS and Android, of course, don't have traditional window management and running apps to contend with. I do hate that Android's home screens, application grid, and application search tool are all in different places, when they all seem to be closely related parts of the same thing.

[EvanED]

Not a symlink?

I'm not the originator of the hard link idea, but I'd say it depends on your model. Having the physical file belong to one program and a symlink to it from the other sounds like a recipe for disaster to me when you go and delete it from the original program. (Now you have to keep track of what documents are links or not. Maybe "keep track of" is the wrong word, but your programs need to display that information and you need to pay attention to it.) A shared file abstraction to me sounds way more likely to fit with hard link semantics.

However, you could also imagine that the physical store is separate from both programs, and then both programs have a symlink. I'm not quite sure how deletion looks in this scenario though.

The one hangup I can see is the "database integrity" problem, the situation where a document is visible in two applications at once and could accidentally be overwritten by a previous version. That would apply to the "linked" situation you're describing, too. But the apps could consistently check to see if their own last edits are less recent than the file on disk. Would that solve the problem?

Actually here, depending on the environment, it might actually make sense to move to a "lock the file by default" behavior. That can get obnoxious on a system like Windows, but for something like an iOS device, I think it'd probably make sense.

Agreed, but I think some of those problems really could be ameliorated. Particularly when, as you say, the user's best interests are actually in mind.

What's in mind, IMO, is mostly irrelevant, and it can even backfire. "It's for your own good" can lessen the annoyance of something behaving annoyingly (e.g. when security is involved -- passwords are obnoxious but for our own good), but there's a thin line between that and "fuck you, I know what I want."

A model where each app has control of its documents and there's no "escape hatch" to go and muck about with an app's files without it's consent... that's in the second category. At least for me. And your system will need something pretty damn compelling (or no real competition, which isn't going to be the case any time in the foreseeable future) to get me to use it.

[Derek]

Well, yes, but there has to be a top level somewhere, and at least they're not sitting half-visible underneath all of the other applications. I was thinking more of Mission Control, the Win 8 Start screen, and the Gnome Activities Overview than iOS's application icon grid and Android's icon-and-widget grids. The desktop home screens justify themselves a little more with one form or another of interaction with the applications, instead of just being a way of launching them. But iOS and Android, of course, don't have traditional window management and running apps to contend with. I do hate that Android's home screens, application grid, and application search tool are all in different places, when they all seem to be closely related parts of the same thing.

I have to launch my applications some how. How are desktop icons worse than anything else?

[Copper Bezel]

I have to launch my applications some how. How are desktop icons worse than anything else?

I had a reasons, I gave you them? = /

But seriously, if it's just a way of launching apps, then I personally feel that an overlay icon grid makes more sense. It's less clutter on the screen except when you need it, and it doesn't interact at all with other windows, where a desktop icon grid seems to me to interact very strangely with other application windows. And personally, I'm more a fan of search-based launching and doing something else interesting with the "home screen," as Win 8 and Gnome do.

I'm sorry I hate the things you like. = ( Do you like cake or ice cream? We could probably agree about cake or ice cream.

What's in mind, IMO, is mostly irrelevant, and it can even backfire. "It's for your own good" can lessen the annoyance of something behaving annoyingly (e.g. when security is involved -- passwords are obnoxious but for our own good), but there's a thin line between that and "fuck you, I know what I want."

Oh, agreed - which is what I was on about with "simple" solutions to complex problems. I guess I was thinking that the definition of "best interests" has a lot of bearing on the decisions made. When it's a matter of hiding or omitting complex features because the user won't understand them, sheer obfuscation, I'm not supporting that. I meant to emphasize that it's the user's "best interests" as opposed to the vendor's interests and so on.

I'm not the originator of the hard link idea, but I'd say it depends on your model. Having the physical file belong to one program and a symlink to it from the other sounds like a recipe for disaster to me when you go and delete it from the original program. (Now you have to keep track of what documents are links or not. Maybe "keep track of" is the wrong word, but your programs need to display that information and you need to pay attention to it.) A shared file abstraction to me sounds way more likely to fit with hard link semantics.

Yes, you're right, and I wasn't thinking. (Although it's another strike against the fully app-centric model if we imagine a large number of files actually being in this state. But of course, Jplus's argument is based on the idea that there wouldn't be, because most work with any file is contained within its app, and I'm disagreeing because I don't think that that is, itself, a good assumption.)

Actually here, depending on the environment, it might actually make sense to move to a "lock the file by default" behavior. That can get obnoxious on a system like Windows, but for something like an iOS device, I think it'd probably make sense.

Yeah, you're right, that's simpler. Really, I think that could work on the desktop, too. Particularly with these iOS-style universal send-to sharing buttons, repurposed as simply a way to close the file in this app and open it in another.

[Derek]

I had a reasons, I gave you them? = /

But seriously, if it's just a way of launching apps, then I personally feel that an overlay icon grid makes more sense. It's less clutter on the screen except when you need it, and it doesn't interact at all with other windows, where a desktop icon grid seems to me to interact very strangely with other application windows. And personally, I'm more a fan of search-based launching and doing something else interesting with the "home screen," as Win 8 and Gnome do.

Your reason mainly seemed to be that it's a special case, and you don't seem to like special cases. But as Evan pointed out, home screen are also special cases. I'm just really not seeing a significant difference between a desktop and what you call a home screen, so I'm trying to understand what you really mean. I can organize my desktop icons however I like and it's only visible when I don't have a maximized window, which is pretty much only when I want to use it, so I don't understand the "less cluttered and only on the screen when you need it" argument either.

I'm sorry I hate the things you like. = ( Do you like cake or ice cream? We could probably agree about cake or ice cream.

I like cake and ice cream

[Iranon]

For something as basic as launching our staples, all options suck - being either too limited or overly complicated:

*

Some environments just have a hierarchical main menu. Sparse and not user friendly.

Let's enable us to keep often-used favourites on the top level instead of buried in some vendor/application group hierarchy.

Hmm, that clutters up our menu, and we don't need a menu if we know what we want. Let's put the favourites on the desktop.

Annoyingly, desktop icons are often covered by application windows. Let's put them somewhere out of the way but easily accessible. Depending on one's preferences, this could be a dock or home screen.

Drat, those get cluttered too quickly. Let's group things that belong together.

Oops, we're back at a hierarchical menu, only a weird, awkwardly sized and limited one.

*

We wouldn't need to break consistency if we kept a general purpose tool like a terminal or file manager open from which we can do whatever we want. Finder deliberately blurs the differences between files, libraries and applications. Some others (e.g. PCManFM) incorporate what's essentially a home screen...

Still, being expected to keep a command line or file/app manager open wouldn't appeal to most.

[woddfellow2]

I am not entirely sure... I use mainly text-mode/command-line applications (Firefox, from which I am posting this, is the main exception), and with the main exceptions of feh, MPlayer, and less (I may be forgetting at least one other), I normally open files from within the applications themselves (e.g. :e in Vim, C-x C-f in Emacs, g<type URI here> in ELinks), and my main file manager is bash/coreutils.

[Copper Bezel]

Yeah, and that's the thing that I'm trying to avoid. If you're hardcore enough to type URIs, it's no problem, but most of us us GUIs. Ostensibly, GUIs are meant to simplify common tasks, and yet the ubiquitous Open dialogue isn't fundamentally any less awkward than typing URIs is.

Your reason mainly seemed to be that it's a special case, and you don't seem to like special cases. But as Evan pointed out, home screen are also special cases. I'm just really not seeing a significant difference between a desktop and what you call a home screen, so I'm trying to understand what you really mean. I can organize my desktop icons however I like and it's only visible when I don't have a maximized window, which is pretty much only when I want to use it, so I don't understand the "less cluttered and only on the screen when you need it" argument either.

I don't run everything maximized.

The only difference between the best arrangement for desktop icons (something like Win 7) and the most feature-poor arrangement for a home screen (something like iOS) is an aesthetic one, yes. They're both icon grids, where one is "on top" and menu-like and the other is "underneath" and window-like. In Windows 7, you click a weird little unmarked button to show the desktop and your windows collapse, presenting you with an icon grid. In iOS, you push the home button and your current app hides, presenting you with an icon grid.

What Win 7 has in that arrangement and iOS doesn't is the option of putting files directly in the same space, which is where it intersects with the main topic here.

For something as basic as launching our staples, all options suck - being either too limited or overly complicated:

I guess I just don't have as many apps to run as a lot of folks. Here's how this comes back to the topic, though, at least for me. I currently have seven pinned apps, and that's sufficient. The first three are my file browser, desktop search tool (for when Zeitgeist's recent log isn't enough,) and my web browser. Conspicuously absent are the apps I use to actually generate content - office apps, GIMP, even gedit, etc. - because I tend to launch them through the file browser on particular files instead. If LibreOffice had a library feature, it would make sense to launch it directly and open my files from the library instead.

But at the same time, I don't know if that would make more sense. I have three different applications I use to handle PDFs, for instance - Chrome for reading, PDF-X for markup, PDF Mod for little collating tasks. Most of the PDFs I work with were .odt files or other document files at some point in their histories, which means LibreOffice or Softmaker's Textmaker are in on the fun. That means that I have one location (or a collection of related locations) and between three and five apps for a given group of documents. So if I'm working, I do have a file manager open to do all of my launching, and that actually seems to make the most sense. (PDF-X can't be invoked directly on files, but it opens them by drag-and-drop.)

It's really just the current project I'm working on (that is, grading this semester) and I'm pushing most of this off to a web-based solution, but I really don't know whether in a scenario like this, driving everything from the file manager really does make the most sense. I know it's better than Open dialogues, but I'm really not certain whether or not a theoretical library-driven, app-focused model would actually be more efficient.

With that said, a universal "open in" button like Jplus described would certainly make up a lot of the difference, and easily save time over what I'm doing now; the open document then represents the file on disk and can do anything with it the file manager can. I'm really convinced now that the iOS model given shared libraries is the best compromise.

Edit: And I've also been using the search feature quite a bit for those same files, and using names like [student's name] [project] [draft stage] to make them easy to find and group in searches, so I'm really starting to hear the argument for tags instead of locations as the primary way of organizing files. That's separate from the in-app library vs. file manager question, because it could be implemented either way, but it's already standard in a typical application library model and still unheard of in file managers that aren't Windows Explorer, which still doesn't do it as smoothly as the in-app libraries do.

I like cake and ice cream

Cool, me too! = D