I hate the new inspection result look.


I guess some mice lovers will disagree, but I really hate the new look.
Why force us to click our way through a forest of words, unfolding 5
levels of branches with a machete, sorry, a mouse, to find the useful
info, and find out it's only a begnine javadoc error!! A pain in the wrist.

Previously, after running an inspection, I would see in a glimpse,
without having to grab the rodent, how many, and what kind of error had
been found.
Now, its the mouse hunt, each time; I hate it.


Alain


18 comments
Comment actions Permalink

I'm unsure what mouse is about here. AFAIK trees are easily can be expanded using keyboard, aren't they? Moreover everything under JavaDoc top level node will contain javadoc errors and you can skip expanding if you're not interested. And number of errors are still there grayed left to each node text.
Obviously there was a reason for changing inspection UI. Once you've installed Dave's InspectionGadgets plugin and accept more than a half of avaliable inspections you'll get half of the screen busy with tabs.
Old UI just wasn't scalable.

Luck!
Maxim Shafirov

0
Comment actions Permalink

Maxim Shafirov wrote:

>I'm unsure what mouse is about here.
>
As I said in the O.P., after running the inspections, the first bit of
useful info is buried 5 or 6 level deep in a tree.
You first have to deploy, and navigate, and read a LOT of text, to
decide if it's important or not.

In the old mode, after launching the inspections, this info would jump
in your face, before you even touched the keyboard.
It was much much more readable, and clear.

>Obviously there was a reason for changing inspection UI. Once you've installed Dave's InspectionGadgets plugin and accept more than a half of avaliable inspections you'll get half of the screen busy with tabs.

>
>Old UI just wasn't scalable.
>

In another message about the same subject, I suggested a table based
display mode, with filters, and sortable on any columns, like - the old
? - Together.
The basic table display can be improved, to offer all the advantages of
the tree, without all the inconvenients.
That solution is completely scalable, simpler, and richer in feature
(sorting and filtering).

Why did I complained so loudly?
-



I - used to - use the inspections in 2 ways:

way 1: a small set of inspections, very often (many times a day) on 1
class, or 1 package.
way 2: a more complete set of inspections, rarely (once a week?), on
most of the project.

In way 1,
-


I use the inspection to help me find smells, to iron out before adding a
new feature, a new test.
In a matter of seconds, I would launch the inspections, and see directly
(no action required), for example, that there was only a few "may be
final" and "javadoc" error spotted in the class.

Now, I need to deploy, and navigate, and deploy, and navigate, ... and
read a lot of blabla to get the same info.
A pain.



in way 2,
-


I would run dozens of inspections, on the whole/a big part of the
project, and the error categories would take 2 to 5 rows.
That's ok, because...
I would rapidly remove, by a simple on the tab, the
begnine/less important errors categories. This would take a few seconds.
I would then rapidly browse the remaining error categories, and decide
which one were the worse, and start working on them.
ex: variable unused,
When finished with one category, I would remove it from the display -
on the tab,
rinse, and repeat, till happy.


Alain

0
Comment actions Permalink

What if the inspection group headings in the tree were expanded by default?
So instead of seeing

+ MyProject.ipr
+ Declaration has javadoc problems (10 items)
+ Unused declaration (3 items)
+ Declaration redundancy (15 items)
+ Local code analysis (38 items)

you would be seeing

+ MyProject.ipr
+ Declaration has javadoc problems (10 items)
+ Unused declaration (3 items)
+ Declaration redundancy (15 items)
| + Declaration can have final modifier (5 items)
| + Declaration can have static modifier (2 items)
| + Redundant throws clause (5 items)
| + Unused method return value (3 items)
+ Local code analysis (38 items)
+ Local variable or parameter can be final (32 items)
+ Unused assignment (6 items)

Would that meet your needs better? If we had that as well as the option to
switch off the grouping by package, then all the information would be
approximately the same number of clicks away as with the old tabbed view
plus it remains in a more compact and readable format that scales as you add
more inspections.

You mentioned a table view in your post. What sort of information would be
in each column? I guess inspection type and package are natural candidates;
what else would go in there? Would it be a normal table, or a tree table?

Cheers,
Vil.


Alain Ravet wrote:

Maxim Shafirov wrote:

>> I'm unsure what mouse is about here.


As I said in the O.P., after running the inspections, the first bit of
useful info is buried 5 or 6 level deep in a tree.
You first have to deploy, and navigate, and read a LOT of text, to
decide if it's important or not.

In the old mode, after launching the inspections, this info would jump
in your face, before you even touched the keyboard.
It was much much more readable, and clear.

>> Obviously there was a reason for changing inspection UI. Once you've
>> installed Dave's InspectionGadgets plugin and accept more than a half
>> of avaliable inspections you'll get half of the screen busy with tabs.
>>
>>
>> Old UI just wasn't scalable.
>>


In another message about the same subject, I suggested a table based
display mode, with filters, and sortable on any columns, like - the old
? - Together.
The basic table display can be improved, to offer all the advantages of
the tree, without all the inconvenients.
That solution is completely scalable, simpler, and richer in feature
(sorting and filtering).

Why did I complained so loudly?
-----------

I - used to - use the inspections in 2 ways:

way 1: a small set of inspections, very often (many times a day) on 1
class, or 1 package.
way 2: a more complete set of inspections, rarely (once a week?), on
most of the project.

In way 1,
---------
I use the inspection to help me find smells, to iron out before adding a
new feature, a new test.
In a matter of seconds, I would launch the inspections, and see directly
(no action required), for example, that there was only a few "may be
final" and "javadoc" error spotted in the class.

Now, I need to deploy, and navigate, and deploy, and navigate, ... and
read a lot of blabla to get the same info.
A pain.



in way 2,
---------
I would run dozens of inspections, on the whole/a big part of the
project, and the error categories would take 2 to 5 rows.
That's ok, because...
I would rapidly remove, by a simple on the tab, the
begnine/less important errors categories. This would take a few seconds.
I would then rapidly browse the remaining error categories, and decide
which one were the worse, and start working on them.
ex: variable unused,
When finished with one category, I would remove it from the display -
on the tab,
rinse, and repeat, till happy.


Alain


--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

Disclaimer

This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.

0
Comment actions Permalink

What if the inspection group headings in the tree
were expanded by default?


Yes, that would be nice and actually that's the behaviuor I expected to see. I would also suggest to devise different icons for different inspections (groups of inspections), so that it is easier to spot them in the tree.

0
Comment actions Permalink

Maybe i'll get use to it, but I really liked the tabs better.

0
Comment actions Permalink

Vilya Harvey wrote:

What if the inspection group headings in the tree were expanded by
default? So instead of seeing ..

>

It still feels dead wrong, and doesn't solve the main problems (see below).
Let me explain. I'll try to be clear, and to the point.


In the old way, the info structure was bi-directional :
horizontal == categories
vertical == problem, per category.
The action is a 2-step one.
The visual result compact, simple and clear.

The new way is linear : all under 1 root.
The action (find what you need to see) is many scrolls and clicks (or
kbd equivalent) away, even for the simplest one.,


Menus/Menu entries vs Tree/Branches
-


Would you like to see IDEA's menus (horizontal) + menu entries
(vertical) flattened, and replaced by a tree structure, with the info
placed in branches?
Let me reply for you : NO, NEVER, DROP DEAD.

Why :
- it would me more compact!
- it could easily accommodate dozens of new first level
Menu/categories, while the menu bar is almost full!

Why would it suck for menus, and at the same time be a great idea for
inspection reports.


Use case : the old way
-



When I would run an extensive inspection (20 rules), and get error tabs
spanning 3 rows, I would
1/ quickly remove with a the begnine ones, that I wanted
to ignore.

2/ click on the worse category, and clean it/solve it.
3/ when finished, on the category tab => it disappears.

rinse and repeat step 2-3, till happy, or finished.
This was easy, and comfortable.
Now, even the simplest task is a pain. I sucks. We lost a lot in
convenience and usability. IMHO.


Summary :
-



We lost the quick one-look/no-action error summary, with 1 tab per found
error category.
We lost the direct access by clicking on a chosen error category tab.
We lost the compact display, in 2 clear and spaced panels, of all the
errors of 1 chosen category.
We lost the readability of the well formatted left and right result panels.

We lost a lot. For what purpose? Avoid the clutter caused when you would
have errors spanning more that 5-10 categories. I'm sure this could have
been improved in a satisfactory way. Of could, it wouldn't be as cool as
a nice tree display, would it? (: (:


Alain

0
Comment actions Permalink

charles decroes wrote:

>Maybe i'll get use to it, but I really liked the tabs better.

>

Gosh, I thought I was the only one on the planet.
Thanks for stepping forward, Charles.

Not only did I prefer the tabs, but they were a lot more efficient.

Alain

0
Comment actions Permalink

Hi Alain

I completely understand your concerns, although I think that the new UI has some advantages as well. As I see it, the problem is twofold and it's better to discuss the different aspects separately.

Problem #1. Inspection result treeview is too noisy.

This was also the case with the previous UI. For example, I always wanted grouping by class. The new treeview UI added a lot of redundant information - making it even harder to perceive. There could be done a lot to improve the situation here.

Problem #2. Too much information at once.

This is probably what makes you unhappy about the new UI. In the previous version inspection results were segregated into separate tabs. So you could browse inspections one-by-one and concentrate on the particular inspection without your attention being drawn away by the results of the other inspections. Now everything is placed in the single large tree, which makes it harder to concentrate.

The motivation behind aggregation in a single tree was to get rid of tabs, because with pluggable inspections number of tabs may grow beyond of control.

Let's see how could we improve it. I had some discussions with my colleagues and after some brainstorming we got an idea that I will explain below.

What if we put all inspections and inspection groups in a drop-down combobox, placed above the result treeview? So, the layout will be like this:

The combobox may be enhanced, so that items have icons and inspections in inspection groups are indented.

We revert back to "review single inspection result at once" behavoiur, but we gain an unlimited extensibility for inspection list. Adding a new pluggable inspection will add only a new item to a combobox.

I would also suggest adding two keyboard actions (+buttons on the left-side panel) to traverse combobox forward and backward without the need to open it and select a new item.

What do you think about that? What do JetBrains think about that?

0
Comment actions Permalink

Serguey,
Sergei S. Ivanov wrote:
]]>


For sure, your suggestions would improve - a little - the current
design, but I don't think you/we could do much better.

The tree is too poor in formating options too allow for a much better result
Look at the old design, and its usage of :
- line spacing, tabulating, bulleting
- text size, colour, style (underline)
It was clear, and clean. No noise. Just info.

All these features are completely out of reach for the tree design. A
tree is a tree. Period.
I think they should bite this bullet, revert to the previous design and
improve it.

Alain

0
Comment actions Permalink

Simply put, my suggestion to problem #2 above was to replace tabs with combobox. Except for this change, everything else would remain the same as before. What else does so annoy you? The treeview has always been there and noone complained about that...

0
Comment actions Permalink

As I said before I may get use to it. I'm willing to give it a little time and see. The tabs made if easy to see what kind of problems I had. It may have been because the tab text was bigger. Maybe if the categories were bold or larger it would make it easier.

0
Comment actions Permalink

Sergei,

>Simply put, my suggestion to problem #2 above was to replace tabs with combobox. Except for this change, everything else would remain the same as before. What else does so annoy you? The treeview has always been there and noone complained about that...

>

I've just reread your suggestion, and I'm not sure if you suggest to
a) in the old design, replace tabs by a combo
or
b) in the new design, replace the first level by a combo

If b),
then look at my remarks concerning the lack of formating possibilities
with trees.
Trees are just trees, even if you prune a few branches.

If a),
it would satisfy those who complain when the error tabs span on more
than 1 row, but I rarely find this a problem.
What I don't like in the combo approach, is that you lose the control
panel to the categories of errors.
I like(d) seeing the remaining categories of error to handle.

It's damn useful, after running the inspection on a package, to see that
you have found 2 or 20 categories of errors.
If you found 2, then you handle 1, and then 2.
If you found 20, then you start killing a few , leaving only
the 3-5 important ones, that you want to work on. Now, all the tabs fit
in one row.


They have just "fixed" !!! the table display of live templates, and
replaced it with a tree.
#16140- Live templates dialog: make a tree table instead of table
http://www.intellij.net/tracker/idea/viewSCR?publicId=16140

I offered the same opposition, for the same reasons. I feel it will be
the same : cooler, but less effective; All they had to do was to make
the table sortable by a click on the column header.
Wait and see.
And cry.

Alain

0
Comment actions Permalink

>Simply put, my suggestion to problem #2 above was to
replace tabs with combobox. Except for this change,
everything else would remain the same as before. What
else does so annoy you? The treeview has always been
there and noone complained about that...


I've just reread your suggestion, and I'm not sure if
you suggest to
a) in the old design, replace tabs by a combo
or
b) in the new design, replace the first level by a
a combo


You may think of it as a), but you may also think of it as an extended variant of b). People at JetBrains are extremely skilled in creating custom widgets. So, this could be a greatly enhanced combobox. I thought a little bit more and now I see it as a way to drill down to concrete inspections, leaving you also a chance to use the currently available "view all at once" mode.

I imagine it as follows (in the "dropped down" mode):
As you see, the top level of the tree is moved into combobox. If I select the topmost element, then the entire tree displayed (as it's done currently). If I select a category group (e.g. "Local code analysis"), its subcategories are displayed and expandable. If I select a category (e.g. "Redundant type cast"), only results in that category are shown.

If b),
then look at my remarks concerning the lack of
formating possibilities
with trees.
Trees are just trees, even if you prune a few
branches.


Treeviews allow for rich formatting. See find results or refactoring preview for example. That said, I think that the current treeview has a lot of capacity for visual enhancements.

If a),
it would satisfy those who complain when the error
tabs span on more
than 1 row, but I rarely find this a problem.
What I don't like in the combo approach, is that you
lose the control
panel to the categories of errors.
I like(d) seeing the remaining categories of error to
handle.

It's damn useful, after running the inspection on a
package, to see that
you have found 2 or 20 categories of errors.
If you found 2, then you handle 1, and then 2.
If you found 20, then you start killing a few
, leaving only
the 3-5 important ones, that you want to work on.
Now, all the tabs fit
in one row.


Thinking in this direction, it is just needed to make possible the removal of inspection categories/groups from the tree.

As for me, I usually create several inspection profiles - for example: small, medium and complete. Then I start inspecting from small profile in order to detect and fix the issues, which are the most important for me at the moment. After that I may think of launching a complete inspection to tackle minor issues as well.

0
Comment actions Permalink

The problem with a combobox is that you still don't get the overview that the tabs
gave. How about having two list boxes like the OS X finder. Like this:


This gives you quick one-look/no-action summary, and direct access to category.

The list on the left could also provide different ways to view the result set, e.g.
by category, by severity, by class, etc.

0
Comment actions Permalink

Yes, it is a simple and obvious solution, but it has a major drawback: three rather wide views occupy too much horizontal space. Tabs potentially occupied too much vertical space. Combobox is a trade-off solution, it shares horizontal space with inspection result tree and it has always the same little height. If someone can come up with more ideas on how to improve the current inspection result pane UI, would be really nice to hear.

0
Comment actions Permalink

Sergei S. Ivanov wrote:

>..Tabs potentially occupied too much vertical space. Combobox is a trade-off solution, it shares horizontal space with inspection result tree and it has always the same little height.
>

They could simply have put the old tabs panel in a scroll panel. Should
an inspection results have spanned 25 tabs, over 6 rows, you could
either show them all (the all 'control-panel' like solution, that I
liked), or limit their height to 1 row. But I guess it's too late now.
We'll have to live with this new 'improved' interface, that put 4 levels
down from the root, what use to be at 2 levels. Long live the forest.

Alain

0
Comment actions Permalink

Alain Ravet wrote:

They could simply have put the old tabs panel in a scroll panel.
Should an inspection results have spanned 25 tabs, over 6 rows, you
could either show them all (the all 'control-panel' like solution,
that I liked), or limit their height to 1 row.



see illustration attached :



Attachment(s):
inspectionId.png
0
Comment actions Permalink

That might look the same as "Editor tabs in single row". Yes, that could be a nice alternative.

0

Please sign in to leave a comment.