| |
| Description and Recommendations |
Participants |
Resolution |
| No issues. |
|
|
CREATING
AND OPENING PROJECTS |
| Creating
a New Project |
| Description and Recommendations |
Participants |
Resolution |
| No issues. All of the participants go
smoothly through a new project creation. They use either Basic Java App
template, or Empty Java App. In case of Empty Java App none of the participants
modifies the source directory. Some invoke the new project wizard from
main menu, some from the popup menu and one from the welcome screen.
| -- |
-- |
| Creating
a New Project From Existing Sources |
| Description and Recommendations |
Participants |
Resolution |
| Issue: A participant opens the
NFT wizard, reads template descriptions and cancels the wizard. Invokes
the open project dialog, navigates to the source directory and cancels
the dialog. Then again invokes the wizard and chooses a correct template.
Analysis: This is a communication problem. The text in the wizard
does not make it obvious enough that it is the right place to be.
Recommendation(s): Go over wizard text and action names. This
problem could also be attributed to user haste. See bug 33596. |
5 |
|
| Issue: A Participant assumes the
home directory text field is a place where he should specify the location
of existing sources. Probably means he equals the project home with sources
home.
Analysis: Communication problem
Recommendation(s): Change text label to more accurately describe
what the 'Home Directory' is for. See bug 33596. |
1, 2 |
|
| Issue: The Project tree contains
classes twice after finishing the wizard, once in the packages hierarchy,
once in the source hierarchy.
Analysis: When sources are added via the Sources node and then
also marked as Java Roots this duplication appears. This problem is
a symptom of the ambiguously communicated relationship of Java and Source
roots in the project.
Recommendation(s): Java and Source roots as user concepts do
not work well. The duplication of files in two places is only one symptom
connected with confusion about what a Java root is and what a Source
root is when adding files to a project.
Removing the user concept may help this problem though more thought
needs to go into how to mark sources for inclusion on the classpath
(which is really what the Java root represents). See bug 33597 |
1, 2, 4, 5 |
|
| Issue: Participant tried to add
a classes directly in the source root selector. A classes were shown,
but OK button was disabled when he selected the classes.
Analysis: UI Bug.
Recommendation(s): The selector should always show only objects
which could be selected. This is not saying whether the sources panel
is appropriate in the wizard or not. See bug 33598 |
2 |
|
| Issue: A participant use Empty
Java App template to create a project from existing sources. Adds additional
java roots in the java roots panel. But the roots are not correct, they
are "../src/org" and "../src/test".
Analysis: UI Bug
Recommendation(s): Wizards should correct such errors when adding
Java roots. See bug 33598 |
3 |
|
| Issue: A participant set the sources
root in the source roots panel to a incorrect directory ".../src/org".
For some participant it is hard to tell what is the source root, whether
".../src" dir or ".../src/org".
Analysis: UI Bug
Recommendation(s): See above. See bug 33599 |
5 |
|
| Opening
an Existing Project |
| Description and Recommendations |
Participants |
Resolution |
| No issues. Participants have no problems
with opening an existing project. Some users open the wizard from main
menu, some from the popup menu.
| 1, 2, 3, 4, 5 |
|
CREATING
AND MODIFYING SOURCE FILES/DIRECTORIES/PACKAGES |
| Creating
a Java Package |
| Description and Recommendations |
Participants |
Resolution |
| No issues. All of the participants created
a new package without problems.
| 1, 2, 3, 4, 5 |
|
| Creating
a Java Class |
| Description and Recommendations |
Participants |
Resolution |
| Issue: A participant can't find
how to create a new file. He is looking into main menus, completely ignoring
the project structure and contextual menus. Moderator is pointing him
to use the contextual menus.
Analysis: Context sensitivity of New action overdone.
Recommendation(s): Make sure common actions like New are accessible
in non-context sensitive form from the main menu. See bug 33600 |
5 |
|
| Creating
a Text File |
| Description and Recommendations |
Participants |
Resolution |
| Issue: Participant supplies extension
in the name text field in the second NFT wizard panel, but then the third
panel asks for the extension. So, he goes back one step and deletes the
extension from the text field.
Analysis: Old nb problem.
Recommendation(s): IDE should resolve this automatically. See
bug 33601 |
1, 5 |
|
| Issue: A participant creates "worldlibrary.txt.txt"
text file. He doesn't realize that the extension in the third panel is
added to the name supplied in previous panel.
Analysis: See above.
Recommendation(s): See above. See bug 33601 |
4 |
|
| Issue: Participant creates the
text file outside of the IDE and can't find a way how to add it to the
project.
Analysis: Refresh problem with the current build. For performance
reasons automatic refresh has been disabled. In order to update the
filesystem the user must manually refresh in the filesystems tab which
is not shown be default explorer.
Recommendation(s): The refresh issue should be re-examined.
Performance implications aside, we cannot guarantee that all our users
work will be created from within the IDE. See bug 33602 |
2 |
|
| Issue: A participant tries to create
a text file as a new resource through "New Resource..." popup menu item
of the resources node. Then tries to add it as the source under the sources
node. Participant #5 invokes also the new project wizard from the contextual
menu.
Analysis: Wizard wording issues. This is connected to other
problems participants had in trying to add resources to a project (see
below) the connection of resource to the classpath is ambiguous as it
is to other things that may not be strictly considered source.
Recommendation(s): Clarify relationship between logical parts
of the project and Java specific concepts (sources = class and cohabitating
files, resources = classpath and external libs). See bug 33603 |
3, 4, 5 |
|
BUILDING
AND RUNNING PROJECTS |
| Building
a Project |
| Description and Recommendations |
Participants |
Resolution |
| Issue: A participant uses "Build
Active Project" toolbar button or main menu item to build a non-active
project.
Analysis: Active project is not understood. Partly because the
active project is not highlighted well enough -the little noticed '[active]'
text next to the project name is lost in the jumble of text and nodes
in the project explorer.
This problem is exacerbated because the IDE starts up with an example
project that is set active (and new projects do not automatically get
the active setting).
Recommendation(s): Make the active project title bold and re-order
the project nodes to improve discoverability of both Resources and Output
node as well as create some visual space between the bolded title and
the content of the Sources node.
Do not start the IDE with an example Project open. Have a link in the
welcome page that will automatically open an example project instead.
See bug 33604
|
2, 4, 5 |
|
| Issue: A participant doesn't notice
that the build output results belong to a different project than he wants
to build.
Analysis: Symptom of the Active Project issue.
Recommendation(s): See above + do a better job of making the
compiled project title noticeable in the output window. See bug 33604
|
2, 4 |
|
| Issue: A participant doesn't compile
a project, only a class using a shortcut, main menu, or contextual menu
of the class.
Analysis: Work around for Active project issue.
Recommendation(s): See above. See bug 33604
|
2, 3 |
|
| Issue: A build output says it compiled
a method. Also a menu item says it compiles a method.
Analysis: UI Bug.
Recommendation(s): Fix the language. See bug 33596 |
3 |
|
| Issue: A build output scrolls to
the last error, instead of the first error. Participant immediately scrolled
to beginning to see first error.
Analysis: UI Bug
Recommendation(s): This seems to be an ongoing tug of war -should
the output scroll or stay fixed at the top. The results here indicate
that for compiler errors the first error is more important than the
last (especially since one syntax error can create a string of error
following it). See bug 33605 |
2, 3, 4 |
|
| Issue: User builds a project with
a project dependency on another project, but is not sure that both projects
are built, when reading the build output.
Analysis: Communication issue.
Recommendation(s): Clarify output -if the dependency does not
need to be built then the output window should indicate that it is up
to date. See bug 33596 |
3 |
|
| Running
a Project |
| Description and Recommendations |
Participants |
Resolution |
| Issue: A participant executes a
class using its contextual menu, after closing the profiles dialog open
by the run action. He doesn't set up the profile, just closes the dialog.
Analysis: The barrier to running a project is too high. The
concept of profiles is not helpful or necessary at the point and should
only be introduced when there is need.
Recommendation(s): See below. See bug 33606 |
1, 2, 4, 5 |
|
| Issue: A participant tries to execute
a non-active project using "Run Active Project" menu item or shortcut.
Analysis: Active project issue.
Recommendation(s): See above. See bug 33604
|
1, 2, 3, 4, 5 |
|
| Issue: A participant executed the
active project using main menu, but it runs the old profile pointing to
incorrect main class, which has been deleted. The participant doesn't
know where is the problem. The output just says "No class def found error."
Analysis: UI Bug
Recommendation(s): When the class an execution profile depends
on is deleted the the profile should be deactivated as well. See bug
33606 |
3 |
|
| Issue: No feedback is printed into
the output window about started or finished execution. Especially if user
code doesn't prints anything into the output window.
Analysis: UI Bug
Recommendation(s): Improve output window feedback. See bug 33596 |
1, 5 |
|
| Issue: A participant executes main
class from its contextual menu. The class is executed even if there are
a build errors.
Analysis: n/a
Recommendation(s): A class with build errors shouldn't be run.
See bug 33607 |
2, 4 |
|
| Setting
up a Profile |
| Description and Recommendations |
Participants |
Resolution |
| Issue: A participant closes the
profiles dialog because he thinks he doesn't need it for execution.
Analysis: Profiles problem - the concept does not have an obvious
connection with running the project.
Recommendation(s): The profile may not be necessary for many
cases where the user wants to run a project -removing it from the direct
path would reduce the number of steps to running a project.
In simple cases with only one runnable class the IDE should run the
class without extra input from the user. When creating a new class that
is runnable the IDE should keep track and perhaps offer the a choice
when Run project is later selected. More work needs to go into the profile
issue. See bug 33606 |
2, 5 |
|
| Issue: A participant invokes the
run action from project's popup menu, but it displays the profiles dialog
even if a profile exists. It is because non of the profiles is active(default).
Analysis: UI Bug
Recommendation(s): When only one profile exists it should be
the default. See bug 33606 |
4 |
|
| Issue: User doesn't find where
to set the arguments by looking into menus, so reads the welcome screen.
Analysis: n/a
Recommendation(s): None. |
2 |
|
| Issue: The main class selector
doesn't display which class is runnable, so a participant has to open
files in the editor to figure out which class is the main class.
Analysis: Show information specifically relevant to the functionality.
Recommendation(s): Class selector should display runnable classes
in the project. Navigating through the entire source tree does not help
the user. See bug 33598 |
4 |
|
SETTING
UP BUILD DEPENDENCIES |
| Add a
Project as a Resource to Another Project |
| Description and Recommendations |
Participants |
Resolution |
| Issue: A participant can't find
how to set a build dependencies between projects. Most of the participants
look into: Project customizer, Project properties, Configuration editor.
Few of participants are looking for "something named classpath".
Analysis: Two-fold problem: the logical structure of a project
gets lost when the sources node is expanded -participants did not notice
the Output or Resources node easily; the connection of Java concepts
to Project concepts is not obvious (stated above).
The problem is not specifically connecting up two projects but understanding
what the different parts of a project provide -that Output is the built
bits of the code and Resources are the libraries one uses when building
a project. Once those concepts were understood or explained by the moderator
the rest of the task (opening the wizard and choosing the right template)
was trivial.
Recommendation(s): Wording needs to be improved and the logical
layout to keep things from getting lost when viewed with the expanse
of nodes that appear under the Sources node. See bug 33603 |
1, 2, 3, 4, 5 |
|
| Issue: A participant invokes help
to read about the project dependencies, but doesn't understand it.
Analysis: n/a
Recommendation(s): None. Help was clarified after the first
test run. |
1 |
|
| Issue: A participant selected a
wrong template in the new resource wizard.
Analysis: Communication issue -the names of things, especially
concepts particular to the NetBeans need to be very clear and obvious
at a glance.
Recommendation(s): Go over naming and other visual cues. See
bug 33596 |
2, 3 |
|
| Issue: A participant adds a resource
in the runtime classpath panel of profile customizer. But it is not working
for building the project.
Analysis: Bug.
Recommendation(s): None. |
4 |
|
| Issue: A participant adds a resource
in the runtime classpath panel of profile customizer. Selects "use everywhere"
in the last panel, but after finishing the wizard the resource is not
shown in the list. He does this four times with the same result.
Analysis: Bug. Adding a Resource and specifying that it should
be used everywhere should work.
Recommendation(s): None. |
4 |
|
| Issue: A participant adds the java
class library as a resource to runtime class path of run profile. He points
to ".../anagram-lib/src" directory.
Analysis: The participant may not have completely understood
the task and drawn the connection between adding the Output of a different
project as the best way to proceed. Instead the participant tried to
add the sources which is reasonable given that the class files are currently
left in place with the sources.
Recommendation(s): Go over wording. See bug 33596 |
5 |
|
| Issue: A participant added ".../anagram-lib/src"
directory as a resource. But it added also the "src" dir under the resources
node. This is different from adding packages roots under the sources node.
Analysis: The level at which resources are added is not the
same as the level at which sources are added.
Recommendation(s): The two need to be the same. See bug 33608 |
5 |
|
