OS X: App-specific documents in the Apps folder, or the Docs folder?

Discussion in 'Apple' started by AES/newspost, Jan 5, 2005.

  1. AES/newspost

    AES/newspost Guest

    If an application (MS Word, let's say, or Photoshop) generates and edits
    *many* documents for many projects, it seems reasonable to put the app
    and its associated package components in the Apps folder, and put the
    various documents in some hierarchical, perhaps project-oriented
    substructure in the user's Docs folder.

    But what about apps that (at least for many users) generate just *one or
    two* documents (a database, for example) that are tied more to the
    individual app than to individual projects? -- for example:

    * Now UTDC and its address book and calendar files

    * Quicken and its single master database of accounts (for me, anyway)

    * EndNote and its (in my case) single master reference library

    (Note that EndNote itself recommends keeping just one master
    library, not a bunch of separate project-oriented libraries)

    * Eudora, and the Eudora settings and mail folders

    In these cases (and assuming a single-user machine) is it better to keep
    the documents with the apps, in the individual apps folders in the Apps
    folder? (so that if you want to make some major changes in that
    application you can access the entire Eudora or Quicken or EndNote setup
    in a single folder)

    Or should you follow the generic Docs vs Apps division, as you do with
    Word or Photoshop?

    I realize one can probably do this either way. I just wonder what
    others think is the *preferable way*? (I lean very much toward the
    first approach myself -- and I *have* thought about the backup
    implications.)
     
    AES/newspost, Jan 5, 2005
    #1
    1. Advertisements

  2. Keeping the data with the application is a really bad idea. If the data
    goes in the application bundle, the user may well lose it the next time
    they upgrade to a new version. If it goes in the same folder as the
    application, you just clutter things up and cause confusion. Not to
    mention that the assumption of a single-user machine is one you're
    likely to regret at some point.
    Given the scenario you describe, this is also probably incorrect.
    Apple's already got a recommended way for this situation-- this is why
    all users have a Library/Application Support folder in their home
    folder. Put the data there, that's the whole point of this location.

    You might want to take this over to comp.sys.mac.programmer.* somewhere.
     
    Tom Harrington, Jan 5, 2005
    #2
    1. Advertisements

  3. AES/newspost

    AES/newspost Guest

    Thanks for responses from Calle Dybedahl <> saying:

    ~/Library/Application Support/


    OK, thanks, I'll take these as informed opinions -- but to each his own,
    and I'll probably still do it my own preferred way, for my own reasons.

    (Keep thinking of the situation in the large multi-resident house and
    lab complex for which I'm in effect "systems manager": The purchase
    records, instruction manuals, warranties, one-of-a-kind specialized
    tools, spare parts, filters, maintenance supplies, and *everything* else
    directly connected with each of the maybe 50 to 100-odd different
    "appliances" in this place -- vacuum cleaners, hot water heaters,
    microwaves, furnaces, disposals, microwaves, computers, power tools, you
    name it -- are each kept in a single "folder" (box, envelope, carry
    case) that's attached directly to the appliance or in the closet or
    installation where the appliance itself lives, and are scrupulously kept
    there.

    Need to service one of these appliances: *all* the specialized stuff
    you need is *right there* -- don't have to go down and dig through the
    cupboards and files in some cluttered "Library/Appliance Support" area
    down in the basement or out in the garage.

    Want to dump (or sell) one of these: the related stuff is *all* there to
    dump or pass along, rather than hanging on down in the "support library
    area" for decades after the primary item is gone. And so on.

    And also, after 21 years of intensive professional use of a succession
    of single-user Macs, I really doubt I'll regret the single-user
    assumption.)
     
    AES/newspost, Jan 5, 2005
    #3
  4. I think maybe you missed the point of the Application Support folder,
    describing it with that analogy. The whole idea behind using it is
    that, since the application you had described only has one central data
    store (as opposed to multiple independent data files), the user never
    ever needs to look for the file. When they run the application, the
    application just automatically finds the data in Application Support,
    and opens it up for the user. Saving the file likewise automatically
    goes to this folder, and (as in the case of something like Quicken)
    might just happen automatically. The user could locate the file
    directly if they wanted to, but it should never be necessary.
    If you're actually managing the data somehow, you would presumably have
    deleted record(s) of the item(s) at the time of sale.
     
    Tom Harrington, Jan 5, 2005
    #4
  5. AES/newspost

    Daniel Cohen Guest

    This sounds like the Mac concept of a "package". Essentially it's a
    folder that looks to the user like a file. If the user *needs* to look
    inside, a control-click brings up the contextual menu list which has an
    item "show package contents".
     
    Daniel Cohen, Jan 5, 2005
    #5
  6. AES/newspost

    AES/newspost Guest

    Yup, exactly. And my original question was, and is, for those apps that
    really only create or operate on one (or a very few) data files -- like
    certain database programs -- can (or should) the data file be included
    right in the package also?

    Several other posters say "no -- you're just not supposed to do it that
    way".
     
    AES/newspost, Jan 6, 2005
    #6
  7. When it comes down to it, it's you're machine. You can do whatever you
    like. The major thing to keep in mind is that /Applications - and the
    application folders within it are pretty much fair game for installers.
    Given anecdotal information about some of the vendors of products you've
    mentioned, storing data in what they'll think of as their domain _may_
    be perilous.
     
    Gregory Weston, Jan 6, 2005
    #7
  8. AES/newspost

    Van Bagnol Guest

    I keep, generally, three physical places for such an appliance/tool:
    where the appliance and its everyday accessories live, where the
    appliance's rarely-used things are stored, and where to keep the
    paperwork (receipts, manual, and warranty information). While not quite
    an "all-in-one-place" solution, it works reasonably well. Thus the power
    drill and soldering iron reside in the toolbox but the instructions are
    in the binder for instruction manuals; the cyclocomputer is on the
    bicycle, its extra attachments and original box in the bin for bicycle
    accessories, and the instructions for programming it in the instruction
    manual binder.
    Except that in everyday use, it may be difficult to keep everything for
    one appliance/tool in one place without getting in the way of the other
    appliances/tools and forcing you to dig through the appliance's stuff to
    get to the appliance itself. For example, I hate having to dig in the
    AppleWorks folder to launch the AppleWorks app, into the AppleScript
    folder to launch Script Editor, or the Microsoft Office folder to launch
    Word. So if an app is not in the dock, I keep a folder of aliases to
    apps that I want to launch but not necessarily dig around for.
    But your data is not the application. For example, your mail application
    tends to be your "viewer" for e-mail, which you never manipulate
    directly, but while you can dump (or sell) your e-mail program in
    exchange for another, but you don't want to toss your store of messages
    with it. That's why Apple guidelines call for files not directly
    manipulated by the user in document fashion to be stored in the user's
    ~/Library folder.
    I administered and managed multi-user systems 24 years ago and used both
    personal (single-user) computers and multi-user systems since then, but
    this was the year of _not_ assuming a single-user paradigm for the Macs.

    Why? My kids have crossed the computer literacy threshold.

    My ten-year-old maintains her own website and my 13-year-old has to
    submit assignments via e-mail. They log on to whatever machine is
    available and need access to files on whatever other machine has them.
    When I was the only "driver" (power user) in the family, I could get
    away with thinking everything as "my car" (my computers) but now that
    the "kids are driving the family cars" I plan accordingly, including
    keeping app-related files specific to a user in the user's folder space.

    Van
     
    Van Bagnol, Jan 6, 2005
    #8
  9. It depends on what package you're thinking of.

    Most Mac OS X applications are themselves packages. User data should
    _never_ go in the application package. The reason is very simple: Users
    upgrading to a new version of the application may reasonably expect that
    they can simply trash the old version. If any data's stored there, it's
    lost. Of course, if you're just building an app for your own private
    use, you can do whatever you like and presume that you'll know better.
    But if the app's ever likely to be distributed in some way, you'll be
    going rather strongly against user expectations of how things should
    work.

    Documents can also be packages. This is really a sort of fancy
    alternative to a single monolithic data file. As such its use should be
    the same as any other document type-- apps which deal with multiple
    independent documents should allow the user to save the doc where they
    like, and apps with a single central data store should keep their data
    in the Library folder.
     
    Tom Harrington, Jan 6, 2005
    #9
  10. AES/newspost

    Van Bagnol Guest

    Packages are analogous to a well-thought-out appliance that has storage
    compartments for all its accessories, e.g., a washing machine with a bin
    for the lingerie basket and measuring cup, and even a hidden pocket for
    the instructions and warranty card.

    Some applications that don't come in packages may have an enclosing
    folderare like those appliances that have no built-in compartments but
    come with a carrying case for their accessories and instructions. Yet
    others are like appliances that come in bubble packaging, and end up
    scattered around because you can't fit things back in the package it
    came in.

    Packages are basically an organizational convenience. You can think of
    it either as an extension of resource and data forks into multiple
    hierarchical forks, or as an encapsulation of a directory structure to
    'bundle' the directly more tightly.

    Yet no matter how an application stores _its_ auxiliary files, the data
    that belongs to the _user_ should be kept logically separate, even if
    it's only one file and even if the user accesses it only through the
    application. It's like an electric toothbrush: the motor and charger are
    the 'application', but the bristle head is for your own personal use. If
    you lend the toothbrush to someone, you _don't_ want your bristle head
    included, but other users are free to attach their own.

    Additionally, apps may reside on a CD or be otherwise write-protected,
    where the user is not able to make or store changes except in his own
    writable user space.
    In fact, an *.rtfd file created by TextEdit is a package directory that
    encapsulates a document's text and its accompanying images.

    Van
     
    Van Bagnol, Jan 8, 2005
    #10
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.