Recommendation(s): none needed.
 

Recommendation(s): See below.
 

Recommendation(s): Issue 20133 proposes a solution for the context sensitivity problem. It involves making File|New context-insensitive, so that the user could always find the new projects templates. In addition, we should consider having a New Projects menu item, possibly under the Projects menu. Although, this solution may violate the Java Look and Feel Design Guidelines, and therefore should be explored as a last resort.
 

Recommendation(s): This just seems like a bug, and will be filed as such. Whenever the user creates a new file, it should always be within the context of an existing project. Although, we might let the user open an existing file for browsing purposes, without having to attach it to an existing project. The user would not be able to do anything significant with that file, however.
 

Recommendation(s): This is a known problem, and is being worked on.
 

Recommendation(s): none needed.
 

Proposed Resolution: This is an interesting idea, but one that might have to wait for a post-4.0 release.
 

Recommendation(s): This problem will probably be resolved when we have multiple project types, as each type will have its own folder; the folder's name (e.g., "Java Projects", "Web Projects") should tell users that these are projects. In addition, Docs may want to change the name of the project templates to more clearly indicate that they are projects, e.g., "Java Application" --> "Simple Java Project".
 

Recommendation(s): The desired project group should be included as an option in the New Project wizard. If a project group is selected, then that value should be filled in on the wizard.
 

Recommendation(s): See below.
 

Recommendation(s): Have an "Open..." menu that shows a JFileChooser, and an "Open Project..." menu that shows a dialog for opening (closed) projects. (Note that this dialog has already been designed; a version is in the current Projects Infrastructure UI Spec but needs to be revised.) Consider putting the "Open Project" menu item under the Project menu. Although, this solution may violate the Java Look and Feel Design Guidelines, and therefore should be explored as a last resort.
 

Recommendation(s): None needed.
 

Recommendation(s): This applies to the use of the MRU list to reopen a project. A project should be re-opened in the last place where it was closed. Therefore, if project P1 is open in group G1 and G2, and then the user closes it in G1 and then G2, then reopening P1 from the MRU should reopen it in G2.
 

Recommendation(s): The user should not have to search for project or group files in order to reopen a project; rather, they should be able to use the dialog discussed in the Projects Infrastructure UI Spec.
 

Recommendation(s): If the File menu isn't too long, a Close menu item would be a sensible addition.
 

Recommendation(s): This dialog needs to be replaced with a JFileChooser; this is a known issue which is being worked.
 

Recommendation(s): Currently, the IDE has two mechanisms for getting source directories: the concept of adding an existing directory and the concept of creating a new directory under the project's home directory. We should consider unifying these two mechanisms. One way to do this is to have a single "Add Source Directory" function, which shows a JFileChooser dialog. The default location for the JFileChooser would be the project's home directory; the user would have the choice of adding/creating any arbitrary directory. If we do this, we need to make sure that users know they can create directories with the JFileChooser, and that the directory creation process is easy. 
 

Recommendation(s): Most projects should come with a pre-created source directory under the project's home directory. In addition, the process of creating a new file should automatically add the file's directory to the sources node. As mentioned elsewhere, the orphaned file problem is a bug.
 

Recommendation(s): Presumably this is a bug, since it probably wasn't intentional to expose NetBeans' guts like this.
 

Recommendation(s): First, the Filesystems tab, as we have discussed, needs to be substantially reduced in functionality so that users can't get themselves into trouble. For example, users probably shouldn't be able to mount subdirectories of a currently mounted filesystem. Second, we need to consider names for the Filesystems tab that communicate what it does without making legacy users think that this is their "escape hatch". Perhaps, "Filesystems Browser"?
 

Recommendation(s): Opening an arbitrary file should add its source directory to the Java Sources node.
 

Recommendation(s): This dialog needs to be replaced with a JFileChooser; this is a known issue which is being worked.
 

Recommendation(s): The easy way to resolve this is to provide a look for the Java Sources node that simply hides the individual source directories. The harder way to resolve this is to allow the user to add both individual files and directories. The latter will require resolving some UI and development issues.
 

Recommendation(s): A bug will be filed.
 

Recommendation(s): File|New and the pop-up menus on the sources node are probably enough. But, if it doesn't cause too much clutter, it might be reasonable to let the user create new source files and add directories from the project node's pop-up menu. Also, as discussed, the Filesystems Browser should let users easily add a source directory/file to a project.
 

Recommendation(s): When one user did this, the IDE got confused, threw exceptions, etc. We need to gracefully handle whatever types of source directories the user might try to add (regardless of whether or not we let them do that).
 

Recommendation(s): This requires some careful thought before we create an artificial split between "real" source files (Java files, Xml files) and "other" source files (bitmaps, sounds, text files). A better strategy might be to rethink the name, "Resources", and replace it with something more accurate. This is probably an issue for docs.
 

Recommendation(s): These are more ideas than anything else. They should be added to the effort to make the IDE more flexible in working with Java packages.
 

Recommendation(s): Move the Java Packages menu item up in the template list, so that it is one of the first things that the user sees. Also, consider adding some explanatory text to the dialog(s) that create new folders. The text should say that a folder that has a legal Java package name will be treated as a package.
 

Recommendation(s): Either constrain package creation to be in the existing source directories, or automatically add the package's parent directory when the user creates it.
 

Recommendation(s): Will be filed as a bug.
 

Recommendation(s): Only one participant had difficulty with this, but it is something to consider. One idea, besides beefing up the help materials, is to always show the <default package> under the Java Sources node.
 

Recommendation(s): A known problem that is being worked on.
 

Recommendation(s): Being unable to drag and drop, a majority of the users tried other ways to move the files between packages. Some of these should be investigated, particularly adding a "Move" pop-up menu to files.

Recommendation(s): By default open the code, but have an "Edit GUI" menu item for objects that have GUIs.
 

Recommendation(s): As discussed elsewhere, orphaned files should not be permitted.
 

Recommendation(s): The warning dialog that tells the user to set the project's main class was a stopgap that was put in place for the prototype. A better approach would be to display a dialog that lets the user select the main class. Possibly even better would be to detect when a) the project has no main class, and b) the user has just created a class with a main method. Then, the user could be asked if the newly created class should be the project's main class.
 

Recommendation(s): None. This is just the observation that the startup materials like the Welcome screen, the tips of the day and the sample project were used.
 

Recommendation(s): Only one user had problems with this. It will probably suffice to provide the Execute Project menu item with an icon.
 

Recommendation(s): We should probably permit the class file to be executed, or at least a good explanation why we won't let the users do it.
 

Recommendation(s): None needed.
 

Recommendation(s): We could let the user rely on the physical view. A better solution would be to use tooltips, or to let the user see the full directory path for the output directories upon request.
 

Recommendation(s): Consider adding more paths to add a resource. So, for example, the user should be able to add a resource through the project node's pop-up menu.
 

Recommendation(s): Provide an easy way for the user to view the entire classpath. This might be done in the project's customizer, or perhaps on the Resource node's customizer. An alternative would be to have a special "Current Classpath" menu item on the Resource node's pop-up menu. It would give a read-only presentation of the current classpath. 
 

Recommendation(s): Consider choosing a different default name (e.g., the name of the Jar file or directory), or saving the rename function for later (i.e., after the wizard has been dismissed).
 

Recommendation(s): This requires some careful thought before we create an artificial split between "real" source files (.java files, .xml files) and "other" source files (bitmaps, sounds, text files). A better strategy might be to rethink the name, "Resources", and replace it with something more accurate. This is probably an issue for docs.
 

Recommendation(s): Exactly what to show when another project's target is used under the Resources node is the focus of ongoing design work.
 

Recommendation(s): Presumably the work on the Looks UI will solve this. 
 

Recommendation(s): None needed.
 

Recommendation(s): None needed. 
 

Recommendation(s): None needed.
 

Recommendation(s): None needed. This should be doable with the IDE's fileset ability. 
 

Recommendation(s): The Projects menu still needs a final round of design work.
 

Recommendation(s): The participant suggested collapsing the package view, so that subpackages are presented more like subfolders. If package clutter turns out to be a problem, this solution should be considered as an alternative view.
 

Recommendation(s): One solution is to just replace the output node if it's deleted. However, this seems a bit odd, as the user might have really meant to delete the node. A better solution would be to detect that the deletion is being done, and to display a dialog asking the user to select a new output node.