To answer your last question first, do not lock the other UI elements if you can avoid it. Even if your options have clear labels, nothing beats seeing the effect for users to decide if that’s the option setting they want. You want to allow users to test out each option easily. That means giving them full access to the other windows (e.g., so they can scroll down to see a change in visual style, or open a Save dialog to see the changed file format setting). Along the same lines, your Options window should have an Apply button, or (better) instant apply so users can see changes as they go without closing the Options window. You don’t want users being in a situation where they change 13 options, submit them all at once, then find their apps hopelessly hosed and the users don’t know which option did it.
As for the other choices:
Choice 4 means users have to cross-reference documentation in order to use it (e.g., to know what setting values are available or to know what each means), and it makes it too easy for users to enter untrapped invalid input. Pretty user-hostile. Your other three choices can have dropdown menus, radio buttons, in-line validation, and help links to make a self-documenting UI. The main advantage to a text setting file is the user can copy and paste blocks of options –handy for copying the same options to other parts of the file, or saving them to a separate file so the user can reset the option file later. Assuming your Options UI is well-designed with good Undo support, the costs of this choice far out-weighs the benefits for most users. If you need to support copy-and-pasting of multiple attributes, find a different way than using a text file.
Choice 3 means occluding the current window content with the options so now users can’t see the effect the options have and confirm they’re getting what they want. Like I said, nothing beats seeing the effect. I don’t see an upside to this choice.
Choice 2 is okay if you have an MDI-type app anyway, and want to be consistent with it. I don’t know what other advantages it would have from the user’s perspective.
Choice 1 is thus probably the best way to go, especially if you have a large number of options, or if the options affect more than one kind of window in your app (that is, if you app has multiple primary windows).
Here’re some other options:
Dialog Box
If your options only affect one window (or one kind of window), you might want to use a dialog box (JDialog) to avoid cluttering the task bar and to make the hierarchical relation between the windows clear. This also might be suitable if your app has only one primary window.
Pulldown Menu Items
If you have a small number of simple options (e.g., six Boolean attributes), consider an Options pulldown menu, with the options being check-box or radio-button menu items. These can be set faster and easier than going through a separate window. An options pulldown menu also solves the problem of where to put the options command. Standards and conventions would have it under application, File, Edit, or Tools, none of which are particularly good choices.
Multi-window
Consider dividing you options up into multiple small windows. This may be desirable if you have a vast number of options but need to keep the Options window small so users with small screens can see the effects. Multiple windows is an alternative to having a tabbed Options window or useful when you’re out of room for tabs. Put your Options windows under an Options pulldown menu and once again you’ve solved the problem of where to put your options.
Feature-located Options
I think the whole idea of options being centralized in one window is mostly an artifact of the implementation: the app needs to read a bunch of options at start-up, so we store them in a single location (e.g., settings file). Because we store them in a single location, we show them to the user in a single location (e.g., an options window). Users don’t necessarily think that way. They don’t think “I need to go set my Options.” They think, “I should make this the default Save format.” They very often decide to change the options of a feature while using the feature. So instead of forcing the user to an entirely different UI to search for and set the option for the feature, let the user set the option in the UI for the feature. For example, put a Make This Default button beside the format dropdown in the Save dialog box.
