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