This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 211786 - UI review of the inspect members dialog
Summary: UI review of the inspect members dialog
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Navigation (show other bugs)
Version: 7.2
Hardware: All All
: P3 normal (vote)
Assignee: Tomas Zezula
URL: http://wiki.netbeans.org/UEXInspectMe...
Keywords: UI
Depends on:
Blocks:
 
Reported: 2012-04-26 13:18 UTC by David Strupl
Modified: 2012-12-11 09:56 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Strupl 2012-04-26 13:18:58 UTC
The Inspect members dialog has some flaws and functional overlap with the Navigator. Please review it current status and especially compare for each use case whether this dialog should be used or Navigator or some editor feature should be used instead.
Comment 1 Tomas Zezula 2012-08-27 11:12:02 UTC
Fixed jet-main fd38fa389764
Comment 2 NukemBy 2012-09-27 21:31:04 UTC
Hi, i've got this feature in one of the nighly buids and was very disappointed with degradation of the user experience in 'reviewed' UI. The problem is described here: http://forums.netbeans.org/viewtopic.php?p=136242.

Shortly:
- "Navigator" window lacks filtering, and when i try to quickly find methods ending with 'val' - i have to jump between 5 of such amoung 50 total methods in current file. I'd like to see on screen only 5 those filtered methods.

- Less annoying thing - former Members dialog had Javadoc side-by-side and it was rather convinient. Now it is rather hard to get to JavaDoc - it is available as 'tooltip' window which disappears when i try to move mouse onto it.

I think it would be better to keep both "File Members" and relevant navigation functionality as dialog and in Navigator pane, with the separate commands so that i can quickly get wanted behaviour via different keyboard shortcuts. For example:

- Ctrl+7 - already opens and focuses Navigator window, so for the most cases this former shortcut will work with new layout
- "new File Members" command - does the same, plus switches selector to "Members". In most cases i'd like to open this as dialog - so 2 commands would be nice to have for user's choice:
   Navigate -> Inspect -> Members
   Navigate -> Inspect -> Members Dialog
Comment 3 Petr Somol 2012-10-01 08:48:20 UTC
(In reply to comment #2)
> Hi, i've got this feature in one of the nighly buids and was very disappointed
> with degradation of the user experience in 'reviewed' UI. The problem is
> described here: http://forums.netbeans.org/viewtopic.php?p=136242.

Actually we've had good reasons to make Inspect Members and Hierarchy dockable. This has been a loudly proclaimed demand from a large group of users and their argument makes sense - modal dialog is inconvenient if one needs the contained information at hand, what is often the case.

However, I confirm that your points are valid. Comments below.

> - "Navigator" window lacks filtering, and when i try to quickly find methods
> ending with 'val' - i have to jump between 5 of such amoung 50 total methods in
> current file. I'd like to see on screen only 5 those filtered methods.
> 

I confirm this is a problem, which we intend to fix in future. This limitation has technical reasons - we had to attach new functionality to original Navigator code which does not support filtering yet. But from UEX point of view I confirm that filtering search results in both Navigator and Hierarchy panels is highly desirable.


> - Less annoying thing - former Members dialog had Javadoc side-by-side and it
> was rather convinient. Now it is rather hard to get to JavaDoc - it is
> available as 'tooltip' window which disappears when i try to move mouse onto
> it.

Note the little icon on the right of the Navigator panel toolbar. It opens the JavaDoc panel under the main editor pane. So the intended workflow is to have this JavaDoc pane open - then browsing through Navigator (or Hierarchy) keeps JavaDoc pane contents updated accordingly.
Comment 4 NukemBy 2012-10-01 10:23:23 UTC
Thanks for response, will wait for the filtering to appear in Navigator. Where can I track this? Will this issue be reopened or new one created?
Comment 5 Tomas Zezula 2012-10-01 11:58:21 UTC
>In most cases i'd like to open this as dialog - so 2 commands would be nice to have for user's choice:
The dialog is not a good solution from usability point of view. It makes the navigation features unusable as it hides the most important part of the IDE - the editor. There were in fact two reasons to redesign the Inspect features. The major was remove the dialog as it blocks users. The smaller one was bad performance of the previous implementation. Dialogs in navigation features make little sense.
Comment 6 NukemBy 2012-10-01 14:15:36 UTC
Tomas, I would say that Naviagtor page and Dialog both have good and bad points - but what is good for one in one scenario it is bad for another :)

For example - lets's try to evaluate the scenario I like the File Memers dialog for ...

The goal: I'm editing (actually updating huge class written by someone else) and want to invoke some method of this class, but can't remember it's name and exact list of arguments and which of them should be invoked in which case.

Process (in 7.2): I open file members dialog, type in few characters i remember from method name - voila, i've got 3 overloaded members and i just have to press UP/DOWN to switch between them to check their arguments and JavaDocs and JavaDoc is synchronized immeditelly with currently selected method. Now I'm done with it - i press ESC and i'm immediatelly back to what I was doing.

Process (in 7.3): I goto Navigation pane, (let's assume techical problem with filtering is resolved and filtering is already there) i've got same 3 overloaded members and i need to check their invokation conditions - i need to go through JavaDocs for each of them. I can press JavaDoc button (mentioned by psomol) - this will show up JavaDoc pane and will hide/overlap the navigator pane (because my nagivator pane is in the bottom-left corner in my workspace) - thus making navigator not useable until i close JavaDoc pane or make window Group with Javadoc pane "restored"/"pinned" - thus eating space from my editor. Ok - now i have Navigator and JavaDoc synchronized - but they are sycnhronized with some delay (about 0.5 sec vs. immediate in 'dialog' version) - so i have to wait each time i go from method to enother. Ok, finally i've found what i needed and need to get back to my editor, but now i have to close the pinned JavaDoc pane - i needed it only during browsing. Now i have to manually close the window group with java doc.

There are few usability flows (bugs?) in second scenario:
- JavaDoc pane does not show up on JavaDoc button if it belongs to minimized window group - so attepts to find it really take some time (the same from key board works always)
- If i keep mouse over the method name in Naviagtor - JavaDoc hint overlays the editor and does not hide if i forward focus to editor by either of ENTER/ESC keys. I have to move mouse to some other place to hide the Javadoc hint.

I guess it is obvious ( :) - just by size of paragraphs with discription of the process for different versions of UIX) that new implementation takes much more key-strokes/mouse moves/time to achieve that particular goal (and i, personally, use 'FileMembers' for that goal in 90% of cases).


However, i completely agree that dialog is not a good choice for some other workflows. That is why i think both versions would better leave side-by-side rather than one-or-another.
Comment 7 enebo 2012-12-10 22:03:45 UTC
I realize this is closed but I would like to also point out one thing I hate about the new implementation, which was not mentioned by the other person who aired his grievances (I also liked the old implementation more as well -- and I don't care whether it is modal or not).  I am only pointing this out in the hopes of this getting changed in a later version of nb.

When I would inspect members in the past I would type in the method I wanted to search for and all inherited classes would also show their members/methods.  Each inherited class would be indented after the current class.  The new dialog also allows for showing methods from inherited classes but it jumbles them all together into a single linear list instead of a nesting down.  

In the old mode the methods I would see in the list would be more specialized to least specialized methods which generally is exactly what is most relevant (for me usually).  In the new mode, I see literally hundreds on grey methods from base objects/interfaces which I would never ever look at.  On top of that I need to hover over them to see what class they belong too.   I think the new design really misses something substantial from a workflow perspective on how people used the old version of this.  The indentation display in the old file members I think much more closely presented what I was likely wanting to see.
Comment 8 enebo 2012-12-10 22:57:25 UTC
One other UI comment on this feature.  I never ever have anything on the left pane docked.  In fact, I might be in a strange set of company, but I know no-one who has these panels docked by default.  The result of navigator not being docked is it obscures the entire left side of the editor panel.  This also covers the bottom docks (like the new jdocs feature).  I know this is how it is supposed to work, but the old dialogue covered much less of the editor window that this new one.  The only way for this new design to work is if you have navigator docked by default.  I find this highly undesirable and it seems like dockless left (unobtrusive layout) was not considered in this new UI change.

I am not sure what can be done about this, but I thought it was worth mentioning.
Comment 9 Petr Somol 2012-12-11 09:56:06 UTC
Thanks everyone for the comments on usability of the redesigned inspect members feature. They will be considered; see http://wiki.netbeans.org/UIReviewsAreas.