Feature On Demand UI Specification
Author: Ondrej Langr, User Experience Design Team
Table of Contents
- Problem Description
- Open Issues & Notes
The Feature On Demand functionality is motivated by the need to eliminate peformance overhead caused by the "big IDE" having too many modules running despite that many of them are not used by majority of users.
Given the way NetBeans IDE is distributed now (users can either choose smaller bundles with mininamalistic UI tailored to their needs or the big IDE including all offered functionality, but with cluttered UI), performance is mainly a problem with the big IDE. With Feature On Demand, the unused functionality/modules could be disabled, thus not consuming computational and/or memory resources, and enabled whenever the user requests to use it, absolutely transparently from his/her point of view.
Feature on Demand can also be used to distribute the big IDE in a physically small package, yet, with UI containing all functionality, which would be downloaded and installed when used for the first time. However, this would mean that every user, no matter how much functionality they use, would have the cluttered UI of the "big" IDE. Which is often not what they want. Also, our experience from usability studies (specifically the NetBeans download and install usability study in 2007) shows that users do not care that much about the download size. The ones who have chosen to download one of smaller distributions of NetBeans often reported that they only want what they will need, to keep the product reasonably simple.
Potential impact of this feature on NetBeans UI is:
- when a module is disabled, all UI elements added by this module (as of now) disappear. This results in inconsistency of the UI in time. However, this problem should be solved by adding entry-points, UI elements enabling needed functionality.
- worse responsiveness in (hopefully) rare situations when the IDE would be loading the functionality
- the modules disabled without users' awareness will be for no obvious reason disabled in Module Manager. This means there would be three module states:
- disabled with UI trigger
Use Cases for Feature on Demand correspond to situations when a new functionality is to be enabled. These points will be reffered to as entry-points and their up-to-date list can be found at the wiki.
The goal from users' standpoint is to achieve the absolute transparency of the disable/enable process.
All flash prototypes below show the behavior of the full IDE where some modules have been disabled to enhance ide's performance. Note that the purpose of this UI specification is not to define a behavior in all possible situations, but rather to demonstrate basic principles on which disabling/enabling of modules should work.
note: the "image"below is an interactive prototype, use buttons next/previous to move back/forward
There are two variations on this use case. In the first, the module/functionality needed for opening the project has been installed with the IDE, but disabled. In this case, the behavior should be very transparent (see prototype below):
note: the "image"below is an interactive prototype, not a static image
In the second variation, dynamic module loading and downloading "on demand" can be used to open a project type by an IDE distribution which does not support this particular project type. For example, a user of Base Java IDE can attempt to open a C/C++ project and succeed, because the IDE would automatically download and load the C/C++ module. The effect of this action is the same as if the user installed C/C++ module from plugin manager, only it is more straighforward in given context and does not break users' flow.
Note: Error state when there is no internet connection will need to be treated differently.
note: the "image"below is an interactive prototype, start with the Versioning menu
This entry point applies to two use-cases:
- Creating a new project - 3rd step of the wizard where the user is asked to choose frameworks for their web project (static image):
Because the Configuration pane below the list of frameworks is provided by the framework itself, the framework needs to be enabled in order to be configured. Enabling the framework upon selection is not tollerable as it would take too much time and would not provide snappy experience. Solving this problem would require redesigning the wizard to add frameworks in one step and configuring them in the other, obvious drawback of this solution is that it would make the wizard longer.
We dont' have the solution to this problem as of now, however, the easy solution is not to disable the frameworks.
- Adding a framework via Frameworks node of project properties dialog. The problem described above is not applicable here, because adding and configuring the framework already are two separate steps.
In option panel, the inactivity of modules should be as transparent as in the rest of the IDE. This means ideally the user should not be able to learn that some modules are diabled. However, since most of Option UI is provided by modules, this will be extremely difficult. The interactive animation below shows the UI whenever we will not be able to provide seemless interaction. Nevertheless, the ideal solution is absolutely transparent, with no UI changes.
- What to do if the download fails or does not even start (no internet connection) ?
- Option to "show" triggers in the small IDE and thus turn the small IDE into the big IDE (from the point of available IDE's functionality, but not responsiveness, as the modules would only be downloaded when first used)
- During the initial walkthrough, user may activate various modules just out of curiosity (especially when browsing options). If these modules stay enabled, user may get close to the performance of the big IDE very soon.