NetBeans Project Manager

A Usability Study of the First Prototype

Detailed Results

Dirk Ruiz, Jennifer Gove
June 4, 2002
This report lists all the main issues encountered during the usability test in tabular form.  The data supporting each issue is listed below the issues.

Please see the usability report for more information.


Participants
Key: Blue = Non NetBeans / FFJ user Orange = NetBeans / FFJ User
0
1
2
3
4
5
Grey = Not applicable / Participant didn't attempt this task            
Orienting Self to IDE
Issue: Startup materials are helpful, particularly the Welcome screen. (1, 5, 6, 7)

Recommendation(s): none needed.

           
1. Reads welcome screen
X
X
     
X
2. Says that they use tips if they're not familiar with the sort of software  
X
       
3. Says that there may need to be more blurb about customizing NetBeans using modules  
X
       
4. P. looks through the menu and says "oh, we don't have Open Projects yet"        
X
 
5. Says that they'd typically look through an example          
X
6. Says that they'd typically look for getting started Help          
X
7. Notes that Creating a Project section is useful on the welcome screen          
X
Creating/Opening/Closing Projects
Creating a New Project (Under Projects Node)            
Issue: NetBeans' extreme context sensitivity can complicate project creation: unless the user has selected exactly the right node, she gets the wrong set of templates. (2, 4, 5, 6, 7)
 
Issue: People expect a New in the Project menu. (1, also p4 commented on this)
 
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.
Issue: It is possible to create an "orphaned" file that doesn't seem to belong to a project. (3)
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.
           
1. Looks (for New) in Project Menu / (and / or may also make comment about wanting 'New' in Project menu...) (p3: first choice, p4 comments on not having new project in Project menu when orienting to IDE)
X
   
X
   
2. Tries to create from File > New; but (at least initially) doesn't do so because can't see projects listed in things that can be created once dialog is open.  (However, this approach this approach taken by the participants is described on welcome window: To create a Project, just do one of the following: - Select the File menu and choose the New... item). (P4 P5: first choice)
X
     
X
X
3. Creates a class or main (for instance) from File > New, ( because the wrong set of templates is available (context problem) and there isn't the option of creating a project listed there). (P0: first choice, and (p3) realizes that is not making project; but is following the instructions on the welcome screen)
X
   
X
   
4. Facilitator points out context problem, and then File > New activates the correct set of templates, as context has been changed to Projects node in the explorer
X
         
5. Uses the New Project button on the welcome screen (this approach is described on the welcome window: To create a Project, just do one of the following: - Click the New Project... button on the panel to the right).  (P1, P2: first choice)  
X
X
     
6. When P5's first choice didn't produce a useful set of templates, they read from the welcome screen "click the New Project button" and then clicked the New File button in the toolbar, though they said, "I presume that this will do the same thing" (i.e. Mistook New File Button on task bar, for New Project button on Welcome Screen. Didn't read to the end of the sentence about where the New Project button was).           
X
7. Facilitator hints / participant is shown Project > (right click), New / New Project Button on Welcome Screen          
X
8. Participant chooses Project (right click) > New for themselves      
X
   
Creating a Project Group / Comments about Project Groupings            
Issue: Redesign New screen that still asks for package information when creating a group. (1)
 
Recommendation(s): This is a known problem, and is being worked on.
 
Issue: Most people felt it was a reasonable idea. (7, 8, 9, 10, 12)
Recommendation(s): none needed.
Issue: Consider augmenting project groups with more useful functionality. For example, the project group might contain resources that all projects need. (11)

Recommendation(s): This is an interesting idea, but one that might have to wait for a post-4.0 release.

           
1. Confused by the re-use of a legacy screen here (requesting package information)  
X
     
X
2. P. expected it to create a folder rather than a file (but then says that's fair)  
X
       
3. Went to File| New initially    
X
     
4. Found it pretty ease to create Project Groups
X
X
X
X
X
X
5. Looked first in Project menu      
X
   
6. When creating the second project grouping (C++) P. notes that the dialog to choose the location remembers the previous location (where Java group was created) but doesn't scroll to it.         
X
 
7. Comment: This is something new
X
         
8. Comment: It's a good idea
X
         
9. Comment: Could be useful, just as another layer of organization to organize your different projects by.     
X
     
10. Comment: Could organize your projects by, for example, servlets, beans, server API's not using http, jsp      
X
   
11. Comment: The use of it depends upon what functionality it provides besides just grouping them. If it makes classes created and marked as exportable in one project, to be available in other projects of the group - maybe it would be useful.         
X
 
12. I usually only use one project at a time and close everything else.         
X
X
Creating a New Project (Under a Project Group Node)            
Issue: Users right-click on a project group, select New, and get a simple list of available project types. Unfortunately, some users failed to understand that these were project templates. (1)
 
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".
 
Issue: If the project group isn't selected, then the new project gets created outside of that group and there is no way for the user to rectify this without exiting and restarting the wizard. (2, 3)
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.
           
1. Expected it to have an submenu that states Projects, rather than just straight to Java Application (P believes it won't create a project, since this is the same menu and File > New, i.e. Without Projects). P5: this same issue occurred when creating a new project for Hangman.
 
X
 
X
 
X
2. Participant chooses something besides project group before doing New action.
X
   
X
 
X
3. P. chooses their Java project group before doing New action as their first choice.  
X
X
 
X
 
Opening the Project into the IDE            
Issue: Opening projects from the File menu is expected, but we need to make sure that it's obvious that this is where you go to open a project. (1, 2)
Issue: People also expect Project Open to be under the Project menu. (1)
 
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.
           
1. Wants to open projects from Projects menu (First choice for P0, P3)
X
X
 
X
   
2. Wants to open projects from File menu (but currently causes a bug) (P1 P2 P4 P5: first choice) P5: notes that they want to open a Project, not a File, so why should they go to File|Open. Has always found this problem with IDE's: the distinction between a File and a Project is not made very clearly - the user needs to be clear about what they're opening from the outset. 
X
X
X
 
X
X
3. Attempts to open project from Projects node in explorer
X
 
X
 
X
X
4. Wants to open projects from Windows Explorer  
X
       
5. Explores icons and tooltips to try and find another way to open projects  
X
       
6. Facilitator hints / participant is shown Project > (right click), New  
X
       
7. P expresses that they'd like to have double clicked from the file to open it (note: didn't see them try this)  
X
       
8. Wants to open project from File toolbar button    
X
     
9. Looks in recent projects       
X
 
X
Reopening a Project Under a Project Group Node            
Issue: In general, people did OK on opening a project from within a group. (5)
 
Recommendation(s): None needed.
 
Issue: Need to decide whether a reopened project should appear under its old group or not. (2)
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.
Issue: Consider making it more convenient to reopen a project under a group, e.g., by NOT forcing users to search through the filesystem to reopen the project. (4)

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.

Bug: Recent projects isn't showing all recent projects.

Recommendation(s): This bug doesn't seem to happen in the current prototype.

           
1. Wants to use recent projects; but project isn't showing (Bug)  
X
     
X
2. After closing a project, and going to re-open a project again: Didn't re-open Hangman Project via Java Projects, just opened it from Projects, so it didn't appear in Java Projects as it had before. P. wanted it to automatically re-appear in Java Projects. (Note: If P. did this, could drag and drop back into project grouping, when project grouping is enabled).   
X
       
3. Wants to open a previously closed project by right-clicking on Java Projects grouping, but missed the menu item and had to be directed to it          
X
4. P notes that when they open a project through right-clicking on a project grouping node and saying open, they then have to navigate the file system again; however, it would be better if they didn't have to do this, and they shouldn't have to because they had previously associated projects under that projects grouping, so from Open, should just get a list of the projects associated with that grouping directly.           
X
5. P did it right the first time around.    
X
X
X
 
Closing Projects (in explicit task, plus in participant-initiated cases)            
Issue: Mostly this worked just fine, but should consider providing Close elsewhere, e.g., under File or Project since some users expect it there. (3, 4, 5)
Recommendation(s): If the File menu isn't too long, a Close menu item would be a sensible addition.
           
1. Requests 'Save' after project has disappeared from explorer is disorientating (since the 'Save' dialog is often then in front of some other source file left up, so user is confused as to which is being closed / saved)
 
X
       
2. Comments that presumes that closing project grouping also closes the project in there.
 
X
       
3. Is able to find the action (right click > close) easily
X
X
X
X
X
 
4. Wants to be able to close the project from the Project Menu (P1: expresses this, since they opened the project from the project menu, they went back there to close it; but if they hadn't had guidance on opening it, they probably would have wanted to do this from the project menu. The important point is if they'd been able to use File > Open, then they wouldn't have known how to close it. Open and close needs to be in the same location). 
X
X
       
5. Wants to close the project from File menu          
X
Creating/Adding Source Directories and Packages
Creating a New Source Directory            
Issue: The Add Source Directory dialog is confusing. (2)
 
Recommendation(s): This dialog needs to be replaced with a JFileChooser; this is a known issue which is being worked.
 
Issue: New Sources dialog in the New Project wizard is confusing. (3)
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. 
Issue: Not having a default source directory causes mischief, including orphaned files. (4, 5)

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.

Issue: If a project is selected and the user does a File|New, the default location presented to her in the second wizard page is the project's home directory, but it's under a node called, "Default System". (8)

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

Issue: The Filesystems tab is going to be a problem for legacy users. (12, 13)

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"?

           
1. Participant discovers that they need to add a source directory after creating project, and discovers how to do it (Java Sources, (right click) > Add Source Directory). 
X
         
2. Add Source Directory dialog is confusing (OK / create, and having no name in field)
X
X
X
     
3. Is confused by Add Sources dialog in Projects wizard (New Wizard - Java Application) (Caused P1 to go back in the wizard to see if they'd missed something previously in the wizard).
X
X
       
4. Does not add source directory while going through wizard, just clicks Next
X
 
X
 
X
X
5. After making Project, (in which P didn't add source directory) creates file (with main method) by clicking New File button on Welcome Screen (which, by design, doesn't end up in their Project) (P2: First choice)    
X
     
6. To create a file under the Project, user wants to right click the Project node itself    
X
     
7. P. creates an empty project (no sources directory) and says that although they realize they've done that (i.e. Create a project that is empty, when clicking on the project (or one of the nodes below) they'd expect to see something change on the right -  i.e. in the source editing area - they'd expect to have some sort of gui builder for example. Subsequently they try the GUI editing tab, but this doesn't help. P. says that they wouldn't expect to dive into source code yet.           
X
8. Tries to / wants to create a source file for existing Project that participant has created from File -> New (some note that the Project itself is highlighted); but it doesn't go in sources of project. File > New. P. expected it to because had taken care of context sensitivity by highlighting the project. 
X
 
X
 
X
 
9. Goes to command line or Windows explorer to locate files
X
         
10. Facilitator needs to be guided to add source directory (P2, P4 P5: both concept and location for functionality). P5. Suggestions that it should create a source directory by default, given that it's required. Presumed it was making one by default.    
X
 
X
X
11. P. adds a multilevel directory into Java Sources          
X
12. P. brings in the tab for the filesystems then brings up properties to locate which directory the project is located within. Mounts project directory in filesystem tab.        
X
 
13. Participant guided away from filesystem tab        
X
 
14. P. goes to windows explorer to find source file they created        
X
 
15. Initially my preference would be to use a GUI (rather than source code), especially in a new product (P. tries to create a GUI to go within Java Sources).           
X
16. Would expect that by creating a source directory, that the IDE would also create a default .java file for me.           
X
Adding an Existing Source Directory            
Issue: Some users have an expectation that sources can be added by using Open File. (1, 2)
 
Recommendation(s): Opening an arbitrary file should add its source directory to the Java Sources node.
 
Issue: The Add Source Directory dialog is confusing. (3)
Recommendation(s): This dialog needs to be replaced with a JFileChooser; this is a known issue which is being worked.
Issue: Some users expect to be able to add individual files under the Java Sources node, rather than adding a whole directory. (2, 4, 12)

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.

Bug: IDE doesn't detect the presence of new directories that have been externally placed into a project source directory; the IDE must be restarted for the change to be detected. (5)

Recommendation(s): A bug will be filed.

Issue: Consider giving users more paths to create or add source files. (6, 7, 8)

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.

Issue: Be able to handle the situation where the user tries to have source directory = project home directory. (10)

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).

Issue: Users expect Resources node to hold non-Java objects, e.g., images, locale data. Note that the evidence for this is in (11), and in the questions that follow after adding Dictionary.jar.

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.

           
1. Highlights Hangman Project and chooses File menu > Open File (P0, P2: first choice)
X
 
X
     
2. Right Clicks on Java Sources in Hangman, and Add(s) Source Directory (P2 is directed to do this; keeps wanting to add the source file directly to the source node, rather than adding the source directory, P3 is directed to do this: didn't want to use Add Source Directory because it looked like the project was pointing to some directory instead of importing files.)
X
X
X
X
X
 
3. Add Source Directory Dialog is confusing (OK / Create, & having no name in field)
X
X
 
X
 
X
4. Doesn't think they should add the whole directory, is just looking to add source files
X
       
X
5. P. creates a source directory through wizard, then attempts to move the Hangman sources into that Directory via the Windows Explorer. Doesn't show up in NB's Explorer. (Bug) (p1: First choice)  
X
       
6. Attempts to highlight Hangman Project and right-clicks to create a new source file for the project     
X
     
7. Tries using filesystem to copy sourcefiles across (is unable to paste into source node)      
X
   
8. Tries highlighting Java Sources in Explorer, and then using Project menu      
X
   
9. P. wants to use properties so that the source is not placed in a separate src directory of the project directory        
X
 
10. Wants to use the home directory as the same directory as c:/Hangman, and this gets the IDE snarled up        
X
 
11. Wanted the images to end up in the Resources node of the Project, and the .java files to end up under the Java Sources node (but since the whole directory is added to sources, it doesn't distribute the files this way). 
X
         
12. When adding Java Sources you have to add the whole directory (as in the Hangman Project). Participant asks, what if I want to add files from the root directory - I don't want to add the whole root directory - i.e. Whole hard disk into the IDE - just the specific files. I want to have control over the specific files that I add).       
X
   
Creating packages             
Issue: Consider some alternative ways to create new packages, e.g., by renaming the default package or by picking up the package from the package statement in the source file (as in Eclipse). (1,2)
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.
 
Issue: If someone creates a folder (that is a legitimate Java package) rather than a package, they may be confused about whether or not they really did create a package. (3,5)
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.
Issue: The user can click on the project node or the Java Sources node and then use File|New to create a new package. But if the package is created anywhere but under an existing source directory, it does not appear in the project. (6, 7)

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.

           
1. Types the package name into the Java source file - wanted it to build the package directory via doing this, and tries to rename the two files to their package names (P3: First Choice)
     
X
   
2. Wanted to rename the default package, through right click on menu item
X
         
3. Creates folders rather than packages (didn't see package as it was so low down in menu). P4: later comments that it's unusual that Java Packages should be the last in the menu, and that folders are created less frequently than packages and should be further down. P5: created packages; but also didn't see them for a long time in the menu because they were so low down.
       
X
X
4. Participant is told that they need to create a new packages (Note: may be a blip in the instructions, which just said, "them in package".)
X
   
X
 
X
5. Participant notices that new folder and new package give the same icon. Participant is unsure as to whether folder has the same, or a different functionality. 
X
         
6. In creating package, puts package into root of C, rather than in the project (but notes at the time that it's probably not a good idea). P. is told that they do actually need their package in the project, but then they put the package in Project home, not src.
         
X
7. P. comments that if they are associating a package with a project, then they should just be able to right-click on the project and do that; it should know by default where to put it (i.e. They shouldn't have to navigate specifically to src). 
         
X
Working With Source Files
New Class / Main Wizard            
Bug: package declaration in new class wizard is wrong. (3)
 
Recommendation(s): Will be filed as a bug.
 
Issue: It is sometimes not clear where package information is kept before the participant has seen the package node(s). (4)
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.
           
1. Second half of class wizard (creating methods, fields etc. is somewhat confusing)
X
X
     
X
2. Attempts to add main method in method window of new class wizard, (after having selected a regular class)
X
         
3. P. notices code (which is inaccurate) when creating .java file, on the new wizard notices that it says Projects.Hello.src, and was hoping that it would be in the default package. It actually is; but it's showing up incorrectly in the New Wizard (bug, which misleads ).   
X
       
4. P expects source code to have package declaration within it, and adds one
   
X
     
5. P. created a new > empty (rather than a class or main). Facilitator then advises to create another one, with the main template.           
X
6. P. always drilled down to the constructors in the Explorer prior to editing code          
X
Moving Files into Packages            
Issue: Need drag and drop for moving source files around. (1)
 
Recommendation(s): A known problem that is being worked on.
 
Issue: Consider other ways to move files into/out of packages, e.g., right-clicking on package or file or using properties. (4, 5, 6, 7, 8)
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.
           
1. Wants to drag and drop to put source files into packages (P0, P1, P3, P4 P5: first choice)
X
X
 
X
X
X
2. Cuts and pastes on own accord (p2, first choice)
 
X
X
 
X
 
3. Facilitator hints / instructs to cut & paste
X
   
X
 
X
4. Wants to see a right click menu option from package for add files
     
X
   
5. Wants to see a right click menu option from file to move it to a package 
X
   
X
   
6. Looks to see if can move class into package through using properties
X
   
X
   
7. Wants to see 'Add to Package' in the file menu (context sensitive - with the class file highlighted)
X
         
8. Looks through menu's to find if there is a refactoring to move the class        
X
 
Viewing Source            
Issue: When Form Editor pops up and obscures the code window, it can confuse users. (1)


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

           
1. Confused by seeing frame editor rather than source when class file highlighted, and is confused by how to get to source files; does so by experimenting (and some are quicker at finding a way than others) / or being told how to (e.g. Shutting the form editor, or using go to source). P5: not confused by GUI editor; but is guided how to shut it. 
X
X
X
 
X
X
2. Doesn't have difficulty in defining main method through properties
X
     
X
 
Building/Compiling/Executing
Building and Compiling            
Issue: Orphaned files don't get compiled. (1)
Recommendation(s): As discussed elsewhere, orphaned files should not be permitted.
 
Issue: Not all users could easily set the main class using the property sheet. (3, 4)
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.
Issue: Startup materials are important. (5)

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.

Issue: Execute project needs to be salient. (8)

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

Issue: Be able to handle the situation where the user clicks the class file and does an execute. (9)

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.

           
1. Attempts to build Hello World (through project menu, selecting specific project); but gets "Nothing was compiled, everything is up to date". (Probably due to a bug or to an orphaned file.)
X
     
X
 
2. Saves project first because can't yet compile (???)
X
         
3. Is able to easily set main class for the project in properties when prompted to
X
         
4. Is unable to easily set main class for the project in properties when prompted to / wanted to         
X
 
5. Uses sample project to compare own project to
X
       
X
6. Directly uses execute (Did not build or compile project, just executed directly)  
X
       
7. P. first looks on File menu, and then Project menu, before Build menu, to run the project. Decides to take action from Project menu > compile project.           
X
8. P. expected to see something on project menu that says: run, or some equivalent. Though find execute at the bottom of the Build menu after this.           
X
9. Participant wanted to right click from .java class (source) and have run / execute in the menu. (PO: This was when there were bugs with compiling and running the whole project that we were trying to get around. It was suggested to the participant that the class file be executed, rather than the whole project). P5: first choice
X
       
X
Finding the Compiled Class            
Issue: This worked out well. (1)

Recommendation(s): None needed.

Issue: Need to make the physical location of the compiled class files discoverable. (2, 3)

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.

           
1. Finds compiled class in Output node of Project straight away
X
X
X
X
X
X
2. If there was 'Save as' for a source file, then would be able to save it to an identifiable place. Participant can't locate source file they are using, and wants to use this as a way of doing so. 
X
         
3. P. wonders where (physically in the file system) it keeps the compiled classes. Note: Presently in this code you can't change that location. P. says that changing that location is something that they need to do occasionally, particularly if you want projects to share compiled classes.     
X
     
Resources
Using an External Library            
Issue: In general people had a bit of difficulty finding this functionality, but once they found it everything worked out fine. (1, 2, 3, 4, 5, 6, 7, 10, 14)
 
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.
 
Issue: Some users are unsure whether the Jar file is on the classpath, as there is no feedback indicating that it is, aside from the existence of the node under Resources. (11, 12, 15)
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.
Issue: At least one person was confused about whether a resource was being created or added. This might just have been because of the default name. (13)

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).

Issue: Users expect Resources node to hold non-Java objects, e.g., images, locale data. (16, 17)

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.

           
1. Participant works out to right-click on Resources to add resources with ease (P1, P2 first choice.)
 
X
X
 
X
X
2. Participant is unsure about how to get the Hangman Project to use the jar file
X
         
3. Participant right-clicks Hangman Project node to find menu item to add jar. (P3 first choice: wants to get to properties through here). (P4: first choice)
     
X
X
 
4. Participant looks to use Properties to get Hangman Project to use the jar file (P0: first choice)
X
   
X
   
5. Participant looks to Tools menu to get Hangman Project to use jar file
X
   
X
   
6. Participant looks to Options to get Hangman Project to use jar file (p0, P3: says they're looking for path, where you can have these jar files listed, which you can attach. Looking for jar files that are already mentioned). 
X
   
X
   
7. Facilitator gives hint: Where in your project would you refer to the jar file? 
X
   
X
   
8. Left Library1 as default name
       
X
 
9. Participant types own name in for Java Resources (in New Wizard - Java Resources, accessed from the Resources node). 
X
X
 
X
   
10. Once at the New Wizard - Java Resources, the participant completes the step of pointing to the .jar file with ease
X
X
       
11. Once completed (i.e. Once the dictionary.jar is under the Resources of the project) user is unsure as to whether the project will know about dictionary.jar (i.e. whether this method will work) P4: talks about wanting to have some feedback as to whether it's on the classpath, and tries to look in properties to find out. 
X
   
X
X
 
12. Requests dynamic code completion update (i.e. for code assist to be functional) in source editor for resources added to a project, i.e. If you add a jar file, and it's part of the resources, (or packages as part of Fancy List Box task) it should be added to the database for code completion. 
     
X
X
 
13. The Add Resource dialog is confusing because P felt is was only to create a resource, rather than add a resource at first. Because of the auto generated name Library1, lead them to believe it was trying to create a resource.  
X
       
14. To get to jar file, P. goes File|Open (P5: first choice)          
X
15. Once the jar is added to that the project, think that they need to refresh the project somehow so can ensure that the files from the jar get picked up. Looks for a refresh project in the right-click menu. Would like more feedback at this point, or would like to look at the content of the jar. The 'need' to do these things is brought on because code assist isn't dynamic or updating for newly added resources. Code assist would be the best option.         
X
 
16. Participants feel that resources should be: P3: locale data, parameter files, images. P4: images P5: images and any thing other than .java & .class. Note that this question was not asked for P0 - P2.      
X
X
X
17. P. says that they thought Resources referred to locale information, and all the text for labels etc. Now that they see it they agree, it should be there.      
X
   
Resource Dependencies (Discussion)            
Issue: Most people guessed that dependencies would be expressed under the Resources node, or under a similar, parallel node. However, there was some divergence about exactly how things would be arranged under Resources.

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

           
Guessed that the dependency would be expressed under the Resources node or parallel, similar node.  
X
X
X
 
X
P1: Would expect there to be a projects dependency entry under Hangman Project on the same level as Resources. It seems to be on the same level in terms of the aspects of the project. Within that Folder or tree or sub-tree I would add other projects. So, if these were Projects inside my own Projects explorer, then the projects would already be listed wherever they might be; but there would be some sort of icon that indicates some sort of link. And maybe if I right-clicked on the entry, then I could have an entry like: go back to the original, and then I would just highlight in the explorer, what the original project was, so that I could open that up. The link would point to the project, because the dependency is on the project, and I'd want the most direct link.             
P2: I'd imagine that you might have Build Properties, and you might even have another node that has Build and shows the dependencies. It would indicate that the dictionary file would be compiled before this project was built. It would point to the set of files that comprise the dictionary.jar (a set of files). I think it could even just point to the dictionary jar, and that would indicate that the files underneath it would be compiled. From my point of view I don't really need to know what files comprise the dictionary.jar. Expect that the pointer would be displayed under Output - I mean if you don't have like another Build node, maybe Output because Output deals with the compiled classes. You might even have another node under output called Build Dependencies, or something like that. P. agreed that it would also make sense to put it under Resources, when told.             
P3: I think one way to have it is linked as when you add the resources here is that your resource (dictionary) should have properties that you can access from the menu. Then in properties of that jar you can say that it's automatically generated by another project and then you can point to that project. So that they at least keep a reference to each other. That is assuming that we're pointing to a project that generates a jar file. For each jar file you should have properties that point to the project that creates that jar. If it's a class file, instead of a jar file, it should be pointing to a project that builds that class.             
P4: It may be an implicit dependency so that all the projects in the group have their stuff shared. That could be an option. The other option could be to have a project property that allows this project to export stuff and import stuff that has been exported by other projects. And maybe it shouldn't be even relevant to a group,  i.e., should be from within a project. Would like to see this dependency from somewhere within project properties, similarly to Eclipse, I'd have Java build path, or something like that, project property. Whether it points to a whole project or a file will depend upon what that other project declared as exportable. So it would point to the project and see whatever that project declared as exportable. 

P. then told that we're thinking of pointing to it under resources somewhere. P. says that would make sense; but it could be accessed both ways, through resources node, and through project properties.

P. then told that projects will be dynamic. P. says that for that other project, the jar should be a target of it because the jar file will not be created every time just because files have changed. 

P. notes that Eclipse has this concept. 

           
P5: The only way I can see that being done is if the dictionary is being managed within NB's. The bi-directional relationship would be useful. If you were updating the dictionary project it would be useful to know it was being used by the Hangman project. If it's going to be one of these three subgroupings (Resources, Output, Java Sources) it should certainly be Resources, if not a full node that says Dependencies, or something like that.

Facilitator explained that it would point to a whole Project because a project would be considered dynamic and a file would be considered static. P. says: I presume that will introduce some deployment issues. 

           
Logical and Physical Groupings
Issue: Users had some difficulty finding the switch for logical/physical view. Consider making this more salient. (1, 10)
Recommendation(s): Presumably the work on the Looks UI will solve this.
Issue: Users understand the difference between physical and logical views. (6, 7)
Recommendation(s): None needed.
Issue: Users favor the logical view for their work. (2, 3)

Recommendation(s): None needed.

Issue: Users expect the same functionality to be available in the two different views. (9)

Recommendation(s): None needed.

Issue: At least one user wants to filter the files displayed in the project. (11)

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

           
1. P. has to be told to open the project up to see the difference between physical and logical
X
X
X
   
X
2. Answers will use logical view most frequently
 
X
X
X
X
X
3. Has no comment at this point on the use of the physical view vs logical view
X
         
4. I can imagine a third view where you have a full inventory of every physical element a project requires (because in the physical view you don't see files and project that are pointed to). It would be nice to see the physical view; but also show the dependencies in a different sort of way
         
X
5. Answers that they often go to the operating system (e.g. Windows) filesystem to look a files, whilst using their regular IDE (p2: says that they sometimes use it to copy and paste files)
     
X
   
6. Answers that the physical view represents the physical location of files (or something equivalent) (P4: A replacement for the filesystems tab - P. notes that the jar file that they added is not present, and states that if the stuff is present in one view it should be present in the other. The trouble is that i don't know how to get it in the physical view if I want to see it. Would like some representation of all the objects that are used in the project)
X
X
X
X
X
X
7. Answers that the logical view represents a conceptual organization of the files (or something equivalent)
X
X
X
X
 
X
8. Participant notes that in Forte / NB, the filesystems tab is the physical view   
X
       
9. Functionality should be the same (e.g. P1: However, how you achieve the same results should be different, so, for example, to create a new package in the physical view you'd create a folder on the file system, etc. instead of going through the wizards and dialogs. So I'd have the same results, therefore same functionality; but different ways in which to achieve them)  
X
X
X
 
X
10. P. opens View menu from main toolbar (P3 P5: first choice)    
X
   
X
11. P. comments that it might be nice to filter out certain sorts of files, and just see those files in the physical view - to be able to narrow it down (e.g. Packages)    
X
     
12. P notes (at a different point in the tasks - during the FLB task), that they'd like to have some sort of visual cue, of what within the explorer represents physical directories and files versus conceptual stuff          
X
Miscellaneous Issues
Issue: At least two people expressed a wish for a beefier Projects menu with more functionality. (3)
 
Recommendation(s): The Projects menu still needs a final round of design work.
 
Issue: One participant commented that presenting packages individually might cause clutter, since each subpackage will create an entirely new node. (8)
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.
Issue: Be able to handle the situation where the user wants to delete the output folder from the Output node. (9)

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.

           
1. Participant wants to know if they delete the output folder and rebuild, whether it'll get recreated (p2)
   
X
     
2. Participant notes that the welcome screen instructions are confusing due to having the same instructions for Creating and Project and Creating Source File. They both say Select the File menu and choose the New... item 
X
       
3. Participant notes that what is enabled on right-clicking for the project nodes in the explorer should also be enabled through the projects menu, e.g. open, delete etc. 
X
   
X
   
4. Participant comments that projects should be able to share jar files, and that the way this may be represented is putting them on the projects node. 
X
         
5. Wants to be able to delete a project in the Explorer by right clicking on the project > delete
X
         
6. It's difficult to know when sources / resources are being pointed to, and when you're actually bringing them in. For example, Hangman source files, have they actually been brought in, or is it a pointer? I actually want to bring them into my Project. Similarly with resources, how do you know if you've brought them in, or pointed to them? Would like the option of choosing whether to import them in or point to them.       
X
   
7. In creating HelloWorld app. P4 has a lot of trouble and states " it was difficult to get acquainted with packaging sources and stuff"        
X
 
8. P2: notes a potential problem with the current package presentation is that you may have multiple different packages, all showing up on separate lines. With com.yodts.dialogs, and com.yodts.renderers, you could have them both be under com.yodts, i.e. collapse them and then have sub-packages underneath them. If you have say, 50 different packages, that's helpful.     
X
     
9. P2: asks, If I delete the output folder and rebuild, will it get recreated?    
X
     
COMPARISONS WITH OTHER DEVELOPMENT ENVIRONMENTS            
The path of the source file is shown at the top of the IDE, on the toolbar. Useful for knowing where the file is stored (P0: Visual Cafe). 
X
         
Would like to see a drop-down list that contains methods in the source file, located at the top of the source file window (as in Visual Cafe), that enables direct access to any particular Method
X
         
Having templates to code the java (e.g. Main etc.) is good in comparison to other IDEs used
X
         
Right clicking is also common in the other IDE's I use
X
         
The logical view is similar to the representation in other IDE's
X
         
Metrowerks: in the source tree you could see what the file sizes are for all the the compiled classes. This would be really useful, if in this (Forte / NB) you could see what the entire size is for the complete project, and for the individual files, and you could isolate the files with sizes too large. This would be displayed on the right side of each file in the tree.   
X
       
Metrowerks had a feature in which you could say which files belonged to a debug target, and which belonged to a main target. This could be useful.   
X
       
Within the study, participant tried to use the following JBuilder short-cuts: compile: ctrl-shift-F9 ctrl-alt-m: to hide the output window; P also discovered that ctl-4 for Output window works in NB.     
X
     
Within the study, for a considerable while P. didn't realize that they had to specify source directory. What they said that they were used to in JBuilder was when you set up your project, you specify within properties where your filesystem is. It's something you do upfront, whereas here you have to explicitly pick it.     
X
     
The layout of the files is nice, specifically, in JBuilder to see the added libraries you have to click on your project and go to a menu and get Project Properties to see the files. It's nice to see it visually on the left (i.e. in the NetBeans Explorer).     
X
     
Seeing visually your libraries (resources) and class files is good in this, compared with JBuilder. Seeing your class files in the same app is useful. A lot of time you want to clear out your class files so that when you build your project again, if you ever like delete files or do anything like that, you don't want your class files, because it could build improperly because there could be some old class files, or some old Java files that no longer exist. So, being able to delete your class files from here is useful. In Jbuilder you alt-tab over to you explorer, and then you know where your class files are i.e. not within the IDE - but that is something that I end up doing a lot - just because then you know you get a clean build. So here it's useful having the Output right here in the IDE.     
X
     
One thing I didn't like about Visual Age is that you had to import files into what they called a Repository. You had to physically import files into its own memory space. I like how this doesn't have that.     
X
     
Used to seeing the contents of a Project (e.g. The class specification and all the different method definitions) in a window below the explorer; but can see how this (NB's) layout could be useful if you want to see inside multiple ones at one time. So if you had two files of course you can see the class definition for each of those files, whereas in the IDE I used (JBuilder) you have to click on each of those files and it brings it up in the lower left, one file at a time).     
X
     
JDeveloper is incorporating UML into the IDE, I know that there are modules that you can do this with NetBeans; but it would be nice if you could incorporate this into the actual core.       
X
   
P believes that the major problems with many of the IDE's (including this one) is that users have to jump straight into source code. It would be better to provide GUI environments.          
X
It's similar to Visual Studio. I think that this (NB) has a better logical breakdown, because i think that Studio's view of the world is primarily physical files. But that's always an area that's been a bit confusing to me, knowing whether I'm really looking at a physical file, or someone's categorization of that file. The physical and logical view would be useful in this respect; but you'd have to be introduced to them initially, and then that would be useful. This could be highlighted to users, and maybe explain the rationale behind the breakdown. It's the last thing on the menu item - I don't think I'd have found it if we hadn't done it here.          
X
The main issues for me particularly with Java has been the deployment of it, so once you've created a project and have got dependencies on all these jar files and all of that, how do you package that up, so that someone can do anything useful with it. Because there's all these dependencies and that's always has been something that I've never quite got a good handle on myself - it seems that you always have to handle that externally, so it seems that any help that you can give in terms of ... like the way you're doing that in terms of the jar files, and also indirect references to another project, and those kind of things...          
X
Comparisons with Previous Versions of Forte/NetBeans
Do you currently use projects in Forte / NetBeans.   
X
       
Here all the projects are visible right from the top. I like having my projects available up top.   
X
       
This makes more sense than the former - with mounting that seems like an administration tasks      
X
   
There are too many nodes in the tree now. Two levels have been added. Previously to get to the sources I'd do two less clicks. If I can create shortcuts to whatever resources I want, then I could overcome it, I wouldn't have to go through opening all the tree structure up.         
X
 
The organization is good. Forces you to do things more cleanly.         
X
 
Other suggestions: when the project implementation gets towards a version control system like cvs, I was wondering how the links to various resources get stored: as an absolute path, or a relative path, because different developers may have different structures on their disk, so is it possible to share these projects with cvs for example.         
X
 

Project Features

About this Project

ui was started in November 2009, is owned by Jiří Kovalský, and has 44 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
 
 
Close
loading
Please Confirm
Close