Plea for feedback:project roots configuration dialog

Starting with the most confusing and heading to the least confusing...


0) RENAME IT. The panel configures much more than project roots. Maybe "Project Structure". I've had two new 6.0 users ask me about that in the last two days.

1) Make the setting of project properties MUCH easier to find. Right now, it's an easter egg. Give it it's own node in the tree, rather than hiding it in the module root node.

2) Project Libraries needs to be at the same level of the tree as Global Libraries and Application Libraries. Nesting it under Modules makes no damn sense.

3)JDKs don't belong in the tree at all. The tree should show the project, not every JDK I've got configured.

4)You'll hate this, but JDK configuration really does need a completely separate settings panel, like it used to have. It's simply got nothing to do with configuring project roots. If that settings panel also let you configure global and app-server libraries, I wouldn't complain (although that should be settable from the project roots configuration dialog.

5)Rename the "Classpath" tab to "Dependencies". If I'm a naive user and need to add a module dependency, why would I ever look in a place called "Classpath". It's also not clear just what the "Add" and "Remove" buttons should do under a "Classpath" tab (since 'classpath' is singular), but it is clear under a "Dependencies" tab.

6)The module JDK drop-down is somewhat confusing, in as much as it will usually have entries that look like duplicates at a quick glance. Instead of having an entry like

1.5 (Use Project JDK)

the entry should be

Project JDK (1.5)

with the 1.5 grayed.

7) Language level belongs on the "Dependencies" tab, not the "Sources" tab.

(On a meta level, it needs to become much easier to maintain project structure without using the Project Roots panel. If I move a class from one module to another, I should be offered the option of creating any necessary module dependencies. If I use a class from a library in a module without having first added the dependency, there should be an intention that offers to fix it for me. The New Module wizard needs to do more, offering to create a test root and offering to add dependencies on existing libraries. It should be possible to add a content root or test root from the Project toolwindow. I could keep going, but I think you get the idea.)


One further note, it is arguable that the entire panel doesn't belong under Settings at all, as all of the other settings are more or less optional and ignorable, while the project structure very decidedly isn't. Configuring your project structure is simply a lot different from configuring compiler flags.

--Dave Griffith

My biggest complaints about it are

- The configuration of (global) libraries has become more inconvenient and
non-obvious than it has to be. There was IMO nothing wrong wrong with the way to
simply check/uncheck a checkbox to include a library, as opposed to having to
open an extra dialog with a lot more clicks.

- The same basically applies to configuring module dependencies.

While the changes make the the configuration UI appear more slick at first
glance, it in fact hurts a) the usability when you're changing the configuration
often (especially after starting new projects) and b) hurts the concept of a
self-explaining UI. Honestly, would anyone really expect a module dependency to
be configured via "Classpath -> Add ..."?

- Configuring source code/Javadoc for a module library is really inconvenient.
You have to add the jar file first, then search for the jar in the tree on the
left and switch to another view to add the sources.

- JDKs, Global Libraries and AppServer libs don't make much sense under
/Project/ Roots. It's a global setting. And please don't tell me that e.g. "JDK
1.5" is unused - I may be tempted to delete it even though it's used by other
projects of course!

Sascha

Hello Dave,

Starting with the most confusing and heading to thel least
confusing...

0) RENAME IT. The panel configures much more than project roots.
Maybe "Project Structure". I've had two new 6.0 users ask me about
that in the last two days.

Agree ...

1) Make the setting of project properties MUCH easier to find. Right
now, it's an easter egg. Give it it's own node in the tree, rather
than hiding it in the module root node.

Already done.

2) Project Libraries needs to be at the same level of the tree as
Global Libraries and Application Libraries. Nesting it under Modules
makes no damn sense.

Why? You contradict yourself they are not the same ;)

3)JDKs don't belong in the tree at all. The tree should show the
project, not every JDK I've got configured.

Is it inconvenient to configure everything for a project in one place?

4)You'll hate this, but JDK configuration really does need a
completely separate settings panel, like it used to have. It's simply
got nothing to do with configuring project roots. If that settings
panel also let you configure global and app-server libraries, I
wouldn't complain (although that should be settable from the project
roots configuration dialog.

Why? Why do they come together?

5)Rename the "Classpath" tab to "Dependencies". If I'm a naive user
and need to add a module dependency, why would I ever look in a place
called "Classpath". It's also not clear just what the "Add" and
"Remove" buttons should do under a "Classpath" tab (since 'classpath'
is singular), but it is clear under a "Dependencies" tab.

I am not sure ...

6)The module JDK drop-down is somewhat confusing, in as much as it
will usually have entries that look like duplicates at a quick glance.
Instead of having an entry like

1.5 (Use Project JDK)

the entry should be

Project Entry (1.5)

with the 1.5 grayed.

Agree.

7) Language level belongs on the "Dependencies" tab, not the "Sources"
tab.

Why? Really do not understand :(

(On a meta level, it needs to become much easier to maintain project
structure <i>without<i> using the Project Roots panel. If I move a
class from one module to another, I should be offered the option of
creating any necessary module dependencies. If I use a class from a
library in a module without having first added the dependency, there
should be an intention that offers to fix it for me. The New Module
wizard needs to do more, offering to create a test root and offering
to add dependencies on existing libraries. It should be possible to
add a content root or test root from the Project toolwindow. I could
keep going, but I think you get the idea.)

Defenitely it's true.

One further note, it is arguable that the entire panel doesn't belong
under Settings at all, as all of the other settings are more or less
optional and ignorable, while the project structure very decidedly
isn't. Configuring your project structure is simply a lot different
from configuring compiler flags.

It's a good idea but how about discovering this setting? In Main Menu|File?
:)

--Dave Griffith

Hello Sascha,

My biggest complaints about it are

- The configuration of (global) libraries has become more inconvenient
and non-obvious than it has to be. There was IMO nothing wrong wrong
with the way to simply check/uncheck a checkbox to include a library,
as opposed to having to open an extra dialog with a lot more clicks.

Currently we have about 30 project libraries. I am not sure that checkboxes
are good here. ?

- The same basically applies to configuring module dependencies.

While the changes make the the configuration UI appear more slick at
first glance, it in fact hurts a) the usability when you're changing
the configuration often (especially after starting new projects) and
b) hurts the concept of a self-explaining UI. Honestly, would anyone
really expect a module dependency to be configured via "Classpath ->
Add ..."?

May be wording can help?

- Configuring source code/Javadoc for a module library is really
inconvenient. You have to add the jar file first, then search for the
jar in the tree on the left and switch to another view to add the
sources.

Agree.

- JDKs, Global Libraries and AppServer libs don't make much sense
under /Project/ Roots. It's a global setting. And please don't tell me
that e.g. "JDK 1.5" is unused - I may be tempted to delete it even
though it's used by other projects of course!

Do they confuse you here? Why not all for project in the same settings?

Thank you.

I agree with everything that Dave says, with one exception:

7) I don't believe Language Level belongs on the Dependencies tab. It is a source setting. But it's also a JDK setting. I'd say it's more strongly related to the JDK setting so it should be grouped with that.

Ciao,
Gordon

Dave Griffith wrote:

2) Project Libraries needs to be at the same level of the tree as Global Libraries and Application Libraries. Nesting it under Modules makes no damn sense.

It does make sense if you were to rename 'Modules' to 'Project
Contents'... then it's in the right place.

N.

True. That would be vastly better. In that case, I would also suggest grouping JDKs, Global Libraries, and App Server libraries under their own parallel node, named something like "Global Contents" or "Global Resources". This would have the advantage of making clear to new users just what the difference is between project and global libraries (something that has historically been very confusing).

--Dave Griffith

Hello Anna,

>> - The configuration of (global) libraries has become more inconvenient
>> and non-obvious than it has to be. There was IMO nothing wrong wrong
>> with the way to simply check/uncheck a checkbox to include a library,
>> as opposed to having to open an extra dialog with a lot more clicks.

Currently we have about 30 project libraries. I am not sure that
checkboxes are good here. ?

Well, I never had a problem with this in the old UI. Though I never used project
libraries, I didn't feel that the long list of global libraries was a problem.
Even the long list was much more easier accessible than the global library
configuration is right now.

>> - The same basically applies to configuring module dependencies.
>>
>> While the changes make the the configuration UI appear more slick at
>> first glance, it in fact hurts a) the usability when you're changing
>> the configuration often (especially after starting new projects) and
>> b) hurts the concept of a self-explaining UI. Honestly, would anyone
>> really expect a module dependency to be configured via "Classpath ->
>> Add ..."?

May be wording can help?

I'm not sure. Basically I think that you optimized too much into the Classpath
tab; the "Dependencies" tab in 5.x did a pretty good job I think.

>> - JDKs, Global Libraries and AppServer libs don't make much sense
>> under /Project/ Roots. It's a global setting. And please don't tell me
>> that e.g. "JDK 1.5" is unused - I may be tempted to delete it even
>> though it's used by other projects of course!

Do they confuse you here? Why not all for project in the same settings?

Because they appear to be a part of the Project configuration, but actually
they're an IDE-setting. Currently, the UI implies that a project consists of
Modules, JDKs, Global Libraries and AppServer libs because they're all top-level
nodes of the Project Roots dialog. The "xxx is unused" even more stresses this
misconception.

This becomes really obvious when looking at the Project Roots in the Classic
Settings View: Now there's Project Settings and JDKs side by side.

A possible fix might be to give the Project its own node as Dave already said.
Then the distinction between project content and global stuff might become more
apparent. Maybe you should even give those "global" settings a dedicated parent
node as well.

Sascha

In the tree, right now if you right-click and select "add", you have to go through two levels of cascading menus to tell it what you want to add. Two levels of menu cascade is cruel and unusual, particularly if just what you want to add can be instead inferred from context. If I'm on or under the Project Library node and select "Add", then I'm totally okay with IDEA figuring that I really wanted to add a new Project Library, and not offering me the choice to add a new module or app-server library.

--Dave Griffith

>Is it inconvenient to configure everything for a project in one place?

You're configuring way more than just the project here, after users have been put in the mindset that this is the place to configure a project. It shouldn't be too surprising if people are confused by that. I don't think this is usability killer, more a matter of getting correct naming and layout so that people know what to expect. Some other suggestions in this thread would probably also be satisfactory for distinguishing global and project configuration if you don't want two panels, but whatever you do that distinction must be crystal clear.

>> 7) Language level belongs on the "Dependencies" tab, not the "Sources" tab.
>Why? Really do not understand.

Because it is tightly coupled to the JDK setting, which is (and should be) on the Dependencies tab (now Classpath).

--Dave Griffith

The Sources tree shows the full path for each folder, rather than just the name of the folder. That's a lot of unnecessary text, since the full path of the content root is right above it.

Somewhat off topic, but it would be nice if source and test directories/packages were visually distinguishable in the Project toolwindow.

--Dave Griffith

True, but notice that inferred item gets preselected. We think that this is a good enough balance between most frequent use case and orthogonality.

You only get preselection from the + action in the toolbar above the tree. You don't get it if you right-click in the tree (where filtering or preselection would be more expected). The preselection in the toolbar is cool, if perhaps not dreadfully standard.

From the looks of things, you're reusing the same ActionGroup for the toolbar and the right-click menu. Good for code reuse, not so good for usability.

--Dave Griffith

Hello Dave,

On right click you have only context-right actions now. Already done I mean
;)

-

Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

In the tree, right now if you right-click and select "add", you have
to go through two levels of cascading menus to tell it what you want
to add. Two levels of menu cascade is cruel and unusual, particularly
if just what you want to add can be instead inferred from context. If
I'm on or under the Project Library node and select "Add", then I'm
totally okay with IDEA figuring that I really wanted to add a new
Project Library, and not offering me the choice to add a new module or
app-server library.

--Dave Griffith

>Somewhat off topic, but it would be nice if source and test directories/packages were visually distinguishable in the Project toolwindow.

Good point, and seems easy to implement;)

Very cool. I figured most of this should be pretty quick to implement. What you had wasn't too far from being very usable, it just needs some clarification.

And speaking of UI rejiggerings, I just noticed that the Version Control menu has finally gotten rationalized, so that it now contains all of the version control functionality in the app in one obvious place and no sub-menus. Nice.

--Dave Griffith

Mostly fine, but we use a lot of named Module libraries and it seems
that the UI no longer supports creating a named group of jars at a
module level (although if I manually edit the .iml file it is
understood). You could bring this back quite easily by adding an "Add
classes ..." button above the "Add Sources ..." and "Add Javadoc ...",
and having some way to specify/change the name of the Module Library.

Thanks,
R

The windows with no usable information. For example, then you click on Module Group or Libraries root. It must have something usaful buttons :)

Hello Robert,

Why not project library? For me module library is the quick substitutor for
project library. But if it contains javadocs it isn't quick at all.

Could you please share your ideas?

Thank you.


-

Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

Mostly fine, but we use a lot of named Module libraries and it seems
that the UI no longer supports creating a named group of jars at a
module level (although if I manually edit the .iml file it is
understood). You could bring this back quite easily by adding an "Add
classes ..." button above the "Add Sources ..." and "Add Javadoc ...",
and having some way to specify/change the name of the Module Library.

Thanks,
R

Hi Anna,

Thanks for your interest. We share our module definitions between
developers, but not (yet) our project files. So our filesystem looks like
- svn
- core
- Core.iml
- lib
- log4j.jar
- doc
- log4jdoc.jar
- src
- com
- blah
- business
- Business.iml
- lib
- somelib.jar
- someotherlib.jar
- doc
- blah.jar
- src
- com
- blah

We currently have about 10 modules. When our filesystem looks like this,
it seems strange to define the libraries as project-level. (Speed of
definition has nothing to do with it for me.)

R

Hello All,

Do you notice navigate and find usages actions?
Do you need unused and misconfigured marks in tree?

Thank you.

-

Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

Hello, All,

We know that not all of you like the new UI for project roots
configuration. It would be very helpful to us if you could formulate
what you don't like, and/or suggestions for its improvement.

Thank you in advance,
Eugene.

Fixed.

--
regards,
--
Alexey Kudravtsev
Software Developer
JetBrains, Inc, http://www.jetbrains.com
"Develop with pleasure!"

"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:4898719.1155663142395.JavaMail.itn@is.intellij.net...

The Sources tree shows the full path for each folder, rather than just the
name of the folder. That's a lot of unnecessary text, since the full path
of the content root is right above it.

>

Somewhat off topic, but it would be nice if source and test
directories/packages were visually distinguishable in the Project
toolwindow.

>

--Dave Griffith

I agree with most of the suggestions made in this topic, but one very basic issue that I have is that the whole dialog seems to be too complex and user-unfriendly.

In the Project ToolWindow (not the Settings dialog) using view as "Project", you have a tree representation of the contents of your project, modules, and libraries. Why can't you simply configure the contents of your projects, modules, libraries, etc. using context menus for add/remove/new, etc? Also support for drag and drop between modules/projects or from a file explorer would be extremely useful.

Why hide it under "Settings"?

If it must be under "Settings" at least add a context menu item for "Project Settings" to the Project ToolWindow tree, and implement drag and drop functionality in the tree on the left hand side of the project roots configuration dialog. Also the Sources, Output, Classpath, Javadoc, and Web Module Settings tabs should have a representation in the tree similar to the library configuration trees.

I found that in build 5622 if I add a new global library, IDEA will ask me to add it to the current opening project. It's nice but you should change from OK + Cancel to Yes + No, it will look more naturally.

I copy a project to another PC which is not already set up for global libraries. If I add a new global library which has same name as the old one in my project, IDEA should fix it for me or confirm me to override.

At this time, if I accept to add new global library to my project, it will contain 2 libraries which have same name.