Date: 24 JAN 2013. Authors: Petr Somol, Standa Aubrecht, Petr Jiricka...
Work in progress, subject to change.
UI and UEX Areas of Interest
NetBeans IDE keeps evolving. Although it's UI has been stable for a long time, adjustments and improvements are of course possible and in many respects desirable. Also, UI flaws get recognized that need correction.
To keep the IDE in good shape we introduced an updated UI Review process (NetBeans 7.3+). See UIReviews for details.
Here we summarize some of the wider areas of concern. If adding/modifying, please keep descriptions short (details to be filed as Bugzilla issues), state what is the current state, and briefly what is the intention of the UI change to be considered. Include links to relevant Bugzilla issues if such exist (file them if needed).
Splash Screen To Inform on What's New
Current state: Currently the IDE start time is roughly 10 to 12s. For this time a splash screen is displayed, informing briefly about the loading progress. It is however customary in many software applications to take use of this time and display tips and to inform on what is new in the current version.
Intention: Take use of the starting time to inform users briefly about what's new in current NB version. The brief info can refer to more details to be found at Start page. Provided info should change on each IDE launch to cover more topics than can fit into 10s. A "what's new" info can be considered also for installer.
Current state: Works, but for a long time remains undeveloped.
Intention: Consider update of both content and look.
New Project and New File Dialogs
Current state: New Project and New File dialogs suffer by project/file type ordering and categorization flaws. Frequency of use is not respected. Many types end up in Others category, generally in many cases it is not clear quickly enough where to search for a particular type. Project type categorizing is partly but not completely mixed up with technical details (we have Maven category but no Ant category). No filtering is possible.
Intention: Provide more flexibility and streamline project/file type selection procedure.
See: Issue 224999
Current state: Menu structure has been quite stable, yet it gets disrupted from time to time by modules that do not respect conventions. Apart from that, some contextual flaws can be found, like partial logical duplicities (Source->Inspect and Refactor->Inspect and Transform can arguably be unified ?), displaying project specific items at times when they logically should not be available (Tools->Ant Variables is available at all times, even for Maven projects), etc. Parts of the structure could certainly be improved by reorganization (see the contents of Window->Output, Navigating, Debugging, Profiling, Versioning, Other, etc. Note misplacements and omissions, like the missing Hierarchy item in Window->Navigating etc.) There is also problem with startup - when the menu is clicked too soon in the startup sequence its dropdown does show but it is unusable until the menu initialization is finished (that could take a few seconds). Perhaps we should introduce some better menu initialization process.
Intention: overall check of all menus and possibly improvements in all respects mentioned above.
Keyboard Shortcuts and Mnemonics
Current state: duplicities and other keyboard shortcut assignment flaws can be seen in current IDE. Non-default shortcut configurations are outdated/nonfunctional.
Intention: overall clean-up and update should be made.
Lengthy Operations Notification / Notification Center
Current state: Lengthy operations are currently tracked using a progressbar in bottom right of the IDE. Multiple progressbars can get stacked for multiple running operations. What is missing according to some users is extended ways of notifying that something has finished etc. Using sounds, or pop-ups, or bubbles, or other ways of notification have been demanded.
Intention: consider creating a 'Notification Center' as a unified and powerful tool for managing IDE messages of any kind, including notifications related to lengthy operations.
Dockable Window Lifecycle, Sub-Tab Lifecycle
Current state: Various dockable windows get opened under the main editor window as result of user action (Find in Project, Find Usages, Variables when debugging, etc.). In some cases repeated action invocation reuses the already opened window, in others it opens a new sub-tab. In some cases this can be affected (at places that may not be easily discoverable, see the Open in New Tab checkbox in the bottom of Find Usages dialog). There is no way to 'pin' a tab, i.e., to make its contents read-only on demand.
Intention: A generally applicable UI should be found to enable more intuitive and powerful management of dockable windows and re-use of their contents.
Dockable Windows UI
Current state: Various dockable windows get opened under the main editor window as result of user action (Find in Project, Find Usages, Variables when debugging, etc.). Many of them display similar type of output or at least the actions provided in their UI are equivalent. Yet their UI is often quite different. Compare especially the vertical toolbars in them. One example of this discrepancy is the handling of Refresh. In some cases there is one Refresh button in the top and a disabled Cancel underneath, which gets enables when refresh is going on. Elsewhere the button Cancel replaces Refresh. Etc.
Intention: Unify UI wherever unification makes sense (where the same or equivalent actions are to be presented in the UI).
Code Analysis and Transformation Tools
Current state: Currently we have Source->Inspect..., Refactoring->Inspect & Transform... and Tools->JavaDoc Analyzer. All of these provide functionality that is closely related and that would probably benefit from a more unified UI.
Intention: Improve the UI and reconsider whether and how to collect the aforementioned functionality in one configurable dialog with its output targeted to one? unified dockable output window.
Versioning Systems Support
Current state: NetBeans provides thorough support of various versioning systems, but a recent short survey suggests that a significant proportion of users prefer to call VCS command from an external command line. Generally those commands that just collect information (getting diffs, annotations etc.) are frequently used inside IDE by most users but commands that manipulate repositories (push, branching etc.) are quite often invoked from the external commandline. This causes performance problems (IDE can not react as effectively to external changes as it would to internal command invocations), and in isolated cases even repository consistency problems.
Intention: Ways of improving the UI and UEX of VCS support inside NB should be investigated with the aim to attract more users to use the IDE internal VCS support.
See: Issue 194147
Inspect Members and Hierarchy
Current state: Inspecting Members and Hierarchies of class inheritance, but also call hierarchies etc. have been improved in 7.3 but still provide lots of space for improvement. UI is different in Java and C++, etc. Users point out several usability concerns, see .
Intention: Improve UI of hierarchy views that come from various implementation sources (hierarchies). Find ways to improve user experience with respect to the aforementioned user comments.
Diff and History in Editor Windows
Current state: History view in editor window is in many ways counter-intuitive. Request to retrieve next "page" of older version is done by clicking on what looks like an "unfold" icon (little plus sign).
Intention: Preferably the whole History/Diff UI should be reviewed for possibilities of usability improvements.
Current state: NetBeans IDE provides many ways of maximizing vertical space, that is becoming more and more precious due to the current trend of wide-screen LCDs. Yet more can be done.
Intention: Consider optimizations, both static (current LaF) and functional (actions) that would help either temporarily or permanently increase the amount of vertical space available to editor.
See: Issue 209259
Current state: the latest style of NB imagery as seen, e.g., in main toolbar and in the most common windows, can be considered successful. There is nevertheless the problem of lacking unity. Not always the latest icons are used to good effect, older versions are often mixed up to depict the same or equivalent actions.
Intention: unify the icon style across the IDE and ensure the correct icon is always used for each action.
Alternative Look & Feels - Dark/Inverted Background
Current state: NB allows adjustments of color in editor but not for the whole IDE. A color profile called City Lights currently provides dark background for the editor window but not for the rest of the ide. There is a certain percentage of users that prefer dark LaFs over bright ones; I do not know exact numbers but the number certainly is not negligible. (With NB I know several users who use City Lights despite the fact that the combination of dark editor and bright navigation/projects/output etc windows is highly unpleasant for viewing due to the stark contrast - eyes need to adjust extensively when focusing between dark and bright areas. The need for dark LaF is supported also by the fact that it has been made available in Idea12, and it has become more common in more editing applications of various types (Adobe Creative Suite etc.)
Technical note: We tried the ability of operating systems to switch their LaF to a dark/inverted scheme. On Win7 there is no low-contrast dark/inverted profile available, users would need to tweak manually each windowing element's color. The only profiles available (right-click the workspace and choose Personalize) are high contrast; choosing such profile and switching NB to City Lights profile leads to this result:
The problem with the above is the too hard contrast. Dark/inverted LaFs that are becoming more popular are more like those used in Adobe software - background dark gray but distinctly non-black, fonts, icons and other elements bright but not too bright - generally too much of contrast is considered tiring for the eyes. Compare the screenshot above with the one below, which (in the editor window) shows a significantly easier to read color scheme. On Mac there seems to be no system-wide dark/inverted color profile available. On Gnome a profile does exist. KDE uses Metal LaF which would have to be manually redefined. Please correct if this is not true.
Intention: Provide better customizability of the LaF (at least of coloring) of the whole IDE. In particular provide a complete Dark/Inverted LaF. As a good basis for full such profile can serve the current Norway Today color profile:
Mouse Wheel Utilization
Current state: Mouse wheel seems to be used for two purposes only: simple scrolling in editor and Alt-MouseWheel to change editor font size.
Intention: It appears that mouse wheel can be used for more useful purposes, as suggested by the issue referenced below.
See: Issue 214770
Global vs. Project-specific Options' Management
Current state: Various settings now can be specified either globally (Tools->Options dialog) or specifically for a project (Project Properties dialog), or both, in which case the project specific setting has precedence. Check, e.g., the Formatting settings. Currently it is possible in Project Properties to choose whether to use global options, or to define project-specific ones, in which case they are recorded typically in project.properties file. It is also possible to import at one moment the settings from another project, what rewrites the previous ones. It is however not possible to define common settings for groups of projects, and once manually changed/imported, it is not easy to switch to another set of settings, with the exception of switching back to the global ones - but that leads to loss of the local ones. Moreover, currently there is mixup of various settings that might have different inherent scope; e.g., certain Java hint settings are more related to user's coding style than to particular project (and thus would make better sense to remain managed globally or in some kind of user profile), others relate to a software project coding style that might be relevant for a group of NB projects only. These situations are not too well supported by now.
Intention: Review the handling of global vs. local setting, their prioritizing and management. Consider defining a finer-grained and more powerful, but in effect also less confusing settings management.