Me: I live in Silicon Valley with my wife, child and cat. I have worked at Microsoft since I graduated from College, mostly in the Macintosh Business Unit on products such as Outlook Express, Entourage, IE, and Virtual PC. I am currently a Senior Lead Program Manager on the Windows Live Hotmail Frontdoor team. I basically manage a team of Program Managers responsible for the User Interface of Hotmail as well as some of the Infrastructure and Architecture. I've been blogging since 2001 and like to play around with .NET in my spare time working on projects such as dasBlog (the blog that powers this site) and Send to SmugMug (an application for uploading photos to SmugMug). I blog about a number of technology and productivity related topics.
Powered by: newtelligence dasBlog 2.1.7238.742
Disclaimer The posts on this weblog are provided "AS IS" with no warranties, and confer no rights. The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.
© Copyright 2008, Omar Shahine
E-mail
That folder in Windows is called “My Documents” not your documents. Over the years a bunch of applications have decided to set up shop there. I don’t understand this.
On Mac OS X, in addition to My Documents, there is “Application Support” or something of that sort. If your Application needs to store stuff, put it there. Applications should not be allowed to rent space in My documents folder without my permission.
Here are the current offenders:
At the very least, programs that create this folders on install/first boot should change their behavior to create them on first use of the functionality.
Actually, I just found this guideline from Apple. I wish Windows had something like this. Back in MacBU the Testers were rabid about filing bugs whenever we violated any of the Apple Human Interface Guidelines. I learned and memorized almost all of them real fast… I wish we provided, enforced, and even followed something similar.
Support Files A support file is any type of file that supports the application but is not required for the application to run. Document templates and sample files are simple examples of support files. However, you might store more application-bound information, such as custom configurations or preset data files for your application’s workspace. In these instances, the information is intrinsically tied to a specific application (as opposed to the user’s data) but is not essential for the application to run. The preferred location for nearly all support files is in the Application Support directory of the appropriate domain. Which domain you choose to store your support files depends on the intended use of those resources. If the resources apply to all users on the system, such as document templates, place them in /Library/Application Support. If the resources are user-specific, such as workspace configuration files, place them in the current user’s ~/Library/Application Support directory. Within the Application Support directory, you should always place support files in a custom subdirectory named for your application or company. Normally, you should use the application name, but you might want to use your company name if you have multiple products that share many of the same resources. How you organize the resources in this custom subdirectory is entirely up to you. Even if a support file is user-specific, your application should not have any trouble accessing it from multiple user sessions. Because of fast user switching and remote logins, it’s possible that the same user could be logged into the computer more than once. Support files should not contain any data that would adversely affect the behavior of multiple user sessions. All sessions should see the exact same behavior.
A support file is any type of file that supports the application but is not required for the application to run. Document templates and sample files are simple examples of support files. However, you might store more application-bound information, such as custom configurations or preset data files for your application’s workspace. In these instances, the information is intrinsically tied to a specific application (as opposed to the user’s data) but is not essential for the application to run.
The preferred location for nearly all support files is in the Application Support directory of the appropriate domain. Which domain you choose to store your support files depends on the intended use of those resources. If the resources apply to all users on the system, such as document templates, place them in /Library/Application Support. If the resources are user-specific, such as workspace configuration files, place them in the current user’s ~/Library/Application Support directory.
Application Support
/Library/Application Support
~/Library/Application Support
Within the Application Support directory, you should always place support files in a custom subdirectory named for your application or company. Normally, you should use the application name, but you might want to use your company name if you have multiple products that share many of the same resources. How you organize the resources in this custom subdirectory is entirely up to you.
Even if a support file is user-specific, your application should not have any trouble accessing it from multiple user sessions. Because of fast user switching and remote logins, it’s possible that the same user could be logged into the computer more than once. Support files should not contain any data that would adversely affect the behavior of multiple user sessions. All sessions should see the exact same behavior.
And of course there is this gem:
Don’t Pollute User Space It is important to remember that the user domain (/Users) is intended for files created by the user. With the exception of the ~/Library directory, your application should never install files into the user’s home directory. In particular, you should never install files into a user’s Documents directory or into the /Users/Shared directory. These directories should only be modified by the user. Even if your application provides clip art or sample files that the user would normally manipulate, you should place those files in either the local or user’s Library/Application Support directory by default. The user can move or copy files from this directory as desired. If you are concerned about the user finding these files, you should include a way for the user to browse or access them directly from your application’s user interface.
It is important to remember that the user domain (/Users) is intended for files created by the user. With the exception of the ~/Library directory, your application should never install files into the user’s home directory. In particular, you should never install files into a user’s Documents directory or into the /Users/Shared directory. These directories should only be modified by the user.
/Users
~/Library
Documents
/Users/Shared
Even if your application provides clip art or sample files that the user would normally manipulate, you should place those files in either the local or user’s Library/Application Support directory by default. The user can move or copy files from this directory as desired. If you are concerned about the user finding these files, you should include a way for the user to browse or access them directly from your application’s user interface.
Library/Application Support
Remember Me
a@href@title, b, blockquote@cite, em, i, strike, strong, sub, super, u