Because it's in the Designer IdeaSpace, I couldn't link this to this idea, but I DO want to give credit where it's due:
{ Link }

Since being a designer, I've never actually used this features. This is close to what I was looking for, all it needs is to allow for categorization in the sort selection and to show hidden columns.

If this was fixed and allowed the user to save across design updates it would fit my needs.

I am always a fan of UI consistency. Whatever you do or design, the end-user should have an expectation that it work. If a button is visible, it should do what it states (e.g. Edit/Print/New Form) or remain invisible for that user. The same applies here. If they go through the process of customizing a view, it should remain unless the process explicitly states for current session or gives the user the option to set duration.

Would this create problems with future releases of the mail template. The InBox is a vital component to the mail template. While a user may want to customize the ordering of columns etc. IBM are more than likely going to make code changes to the scripts that run on various events/actions. As we know we can only prohibit design changes at the design element level. The real problem is that IBM do not have a strategy that support organizations, let alone individuals customize mail database easily.

@4 I have no issue with them 'clearing' the settings during an upgrade (which should address your concern).

I have an issue with this feature being implemented half way here.

Sorry. Hit "submit" there too early.

I have an issue with this feature being implemented halfway and unpredictably here.

@ Bill: Hiding/showing actions based on context is a philosophical design issue. If an Action is there but throws an error or doesn't do anything, at lest I know the action exists, gives me insight into the way the form works. Then I can ask questions about why it's not available to me.

Take standard windows application menus, when a menu item is not relevant it is genrally not hidden, but greyed out.

@7 Windows is noted as a horrific GUI and held that title throughout releases. Thus, other operating systems strive to excel beyond that. The Mac OS X windowing environment does improve that in many areas.

Your final paragraph contradicts your premise...as when a button menu option is unavailable the color changes and it does nothing. In Notes, that is not an option (whether it should be is another discussion). As such, the only other option is to remove the button. Good design ensures that when a user sees something, it should work. That is good design. Generating an error sometimes, and functionality at other times creates confusion as the user does not know when in the application the functionality changes -- i.e. when they will not get an error. If one is debugging code, that is a different story, because the design and overall application is still in-progress.