Applications versus Documents (by alaric)

Applications suck.

Many individual applications suck, yeah, but the concept of applications as they're implemented these days inherently sucks.

I mean, as a programmer, it makes perfect sense that when somebody opens a document handled by your app, a window should open with the document in, and since that window is your app's window, then the File > Open... menu option should be present so that people can open other documents.

But as a user, why on Earth is opening a document considered a function of another unrelated document? Isn't it odd that they can go into a letter they wrote and, from there, then open a different letter?

Of course, we teach them that their letters are "in Word", so it makes sense that when Microsoft Word is providing the foremost window on the screen they can from there get to other things "in Word". They end up with a mental model that applications somehow 'contain' files, which is good for software companies, because it discourages the idea that documents exist in their own right and different competing applications might open the same document.

Pages: 1 2

5 Comments

• 

  By andyjpb, Tue 22nd Aug 2006 @ 9:04 am

  Yes: it's all true! Even the File Open/Save dialogs under MAC OS X are a bit of a pain. Navigating to anywhere that isn't the current directory or on of the quick link thingies involves a lot of effort... That's all after you've dicosvered the little drop down part of the dialog.

• 

  By Charlee, Tue 22nd Aug 2006 @ 9:21 am

  You make so much sense. Why are you not the official oracle on these things?

• 

  By alaric, Tue 22nd Aug 2006 @ 12:09 pm

  Yeah, that one had me for a while 😉

  I've found that you can drag the little icon from the title bar of a Finder window into a Save As browser to make it show that directory, but it's fiddly to get everything side by side to manage it.

  The OSX finder sucks, though - lots of people seem to be saying this. It's odd and inconsistent and they really need to rewrite it.

  I read an interesting review somewhere that said it appeared to be confused between two models:

  1. The spatial model, where double clicking a folder should open a new window showing the contents of that folder; a 1:1 correspondance between windows and folders, UI objects and domain-model objects.
  2. The browser model, where a window is heavyweight thing with all the links down the side, and double clicking should change what that window displays. The window is an interface to a world of files and folders.

  You can flip any one window between the two display modes in the Finder, but it's a bit arbitrary what new windows open like.

  Here's the full moan:

  Ars Technica article on the Finder

  I'm all for giving people choice between UI styles rather than enforcing a monoculture, but the finder just confuses the two...

  This is one potential approach.

• 

  By Alex B, Wed 23rd Aug 2006 @ 10:56 am

  Preface: I am trying hard not to be intellectually limited to app-centric computing as The Only Conceivable Way.

  However: I am not so sure that the filesystem is the place to have users navigating. They have to create folders before creating documents, can't remember which folder they saved a document to, can accidentally delete documents, have to manually version documents as they modify them/receive modified versions from others.

  These issues are largely navigational and could be solved by the OS vendors, but they can't be bothered. (A global file-search does not suffice!) And for collaborative situations, having an app like Groove or Sharepoint manage documents is essential; they provide project-oriented document browsing, versioning and security without the user needing to fiddle with folders and saved searches and permissions and the like.

  So until filesystem browsers get a LOT better, I'll stick with app-centric computing 🙂

• 

  By alaric, Wed 23rd Aug 2006 @ 2:19 pm

  Oh, I didn't say filesystem browsers didn't need improving as well... 🙂

  That includes the possibilities of ditching folder structures in exchange for dynamic searches, although I tend to find that both have their places - my work stuff is all neatly organised by project, while I'd like things like photos to be searchable.

  The possibility of decoupling file storage from the core of a UI, so that different people can use different file storage managers, is also interesting - and would be easier to do without app-based file open/save dialog boxes; a document found in a folder-filesystem viewer, or in a search window, or in a versioned project browser, is still a document that (using a common activation API) can be double-clicked or dragged into an application to open up; and all of those viewers and search windows could be places that documents could be dragged TO to save them.

Other Links to this Post

RSS feed for comments on this post.

Leave a comment