WTP UX Whiteboard
The purpose of this wiki page is to collect and summarize all ideas for User Experience improvements in WTP.
There is no guarantee that any of the ideas listed here will be implemented in certain WTP release. This wiki page is rather a place for brainstorming and discussion. If during the evolution of an idea there is enough commitment from parties, then the idea could be put in the WTP Requirements Plan.
How to submit new idea
Each UX improvement idea should be described briefly on this wiki page with the following structure:
UX idea title Bugzilla: link to the Bugzilla enhancement for this idea Pain point Describe the usability problem from users perspective. Solution Give brief idea how to solve the problem.
For each UX improvement idea there should be a Bugzilla enhancement entry created. In Bugzilla should happen things like:
- detailed description: design documents, screenshots, etc.
- votes and decision whether to put the idea in the WTP Requirement Plan.
In case the idea evolves significantly in Bugzilla, this should be reflected in its brief description on this wiki page.
When submitting the enhancement in Bugzilla there are some special fields that need to be set in the bug:
- Severity must be set to enhancement.
- Target Milestone must be set to Future.
- URL must point to the corresponding section in this wiki page.
- Whiteboard must include the UX word.
- Keywords must include the usability word.
- Add email@example.com in the CC list.
There are already several ideas submitted in the UX ideas section that can be used as examples.
How to comment on existing idea
Java EE application scenarios
Java EE patterns
Tools for easy EJB testing
EJB developers would appreciate tools that enables them to easily test developed EJB artifacts. Such tools could be:
- a framework for generating JUnit test stubs out from EJB beans.
- a lightweight EJB container that runs locally and enables developers to test their EJB beans without a need of full-blown Java EE application server.
- an integration between the JUnit generation framework and the lightweight EJB container where the tests would be executed.
Index search for Java EE metadata
- Pain point
Working on huge projects is a common task for many Java EE developers. Sooner or later the developer would fall in a situation where he or she needs to find an exact Java EE artifact by just remembering a portion of the artifact's name or description, but not the its exact location. In such situation the developer should try different methods of searching, including file search, full-text search, etc. It would be much more convenient if the IDE provides a Java EE metadata search.
We are all familiar with the Open Type and Open Resource index searches in the workbench and how useful they are when we try to quickly locate our files and Java classes in the huge projects we are working with. The Java EE perspective should naturally evolve these features to Java EE metadata index search, where developers can search for certain metadata in their Java EE projects.
This new feature should introduce new dialog box that looks similar to the Open Type and Open Resource dialogs. There should be a hotkey combination available that enables users to quickly call the dialog. Typing a portion of the Java EE metadata name or description should filter the available Java EE artifacts and assist the user choice.
Examples for Java EE metadata are:
- EJB beans
- Web servlets
- EJB references
- Security roles
Context-sensitive view with possible high level actions
- Pain point
Developing an end-to-end Java EE scenario involves many steps. It is a common situation for non-experienced Java EE developers to ask themselves: "OK. I have generated the JPA entity for my DB table. Now, what's next?". It is true that the context menus of the editors and Project Navigator contain Java EE-specific actions, but they are somehow lost for the user in the whole bunch of context-menu actions.
The Java EE perspective should provide a special view that guides and hints developers with the possible Java EE-specific steps they could execute. For example: "Generate Session facade for JPA entity".
Here are some of the characteristics that should be required for the view:
- Context-sensitive. Only the actions relevant for the current (on focus) artifacts should be displayed in the view.
- Sections. Available actions should be grouped in sections by relevance criteria, e.g. JPA, JSF, EJB related actions.
- Extensibility. Adopters should be able to contribute their own specific actions and sections to the view.