Difference between revisions of "WTP UX Whiteboard"

From Eclipsepedia

Jump to: navigation, search
(Index search for Java EE metadata)
 
(25 intermediate revisions by one user not shown)
Line 1: Line 1:
The goal of this wiki page is to collect and summarize all ideas for User Experience improvements in WTP.
+
== Introduction ==
  
== Procedure ==
+
The purpose of this wiki page is to collect and summarize all ideas for User Experience (UX) improvements in WTP.
  
== UX ideas ==
+
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 Main|WTP Requirements Plan]].
  
=== Java EE scenarios ===
+
== How to ==
 +
 
 +
=== submit new idea ===
 +
 
 +
First of all, you should decide if your ideas qualifies as an UX idea. UX ideas should be more large-scale, introducing new feature to the user, rather than just a small usability bug or enhancement. There is no dividing line that could be drawn between small usability bugs and UX ideas, therefore this qualification is quite subjective.
 +
 
 +
If you think that you have an UX idea then follow the next instructions. Otherwise, just file a normal bug in Bugzilla and mark it with the '''usability''' keyword.
 +
 
 +
Each UX improvement idea should be described briefly in the [[WTP UX Whiteboard#UX ideas|UX ideas]] section 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 [https://bugs.eclipse.org/bugs/enter_feature.cgi Bugzilla enhancement] entry created. In Bugzilla should happen things like:
 +
* detailed description: design documents, screenshots, etc.
 +
* discussions
 +
* 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'''. Once an UX idea becomes a feature in the requirements plan for a certain release, the ''Target Milestone'' should be changed to point to that release.
 +
* ''URL'' must point to the corresponding section in this wiki page.
 +
* ''Whiteboard'' must include the '''UX''' word. This is needed to have this Bugzilla entry indexed in the [[WTP UX Whiteboard#Bugzilla queries|Bugzilla queries]].
 +
* ''Keywords'' must include the '''usability''' word. There is a general recommendation to mark all usability related bugs with this keyword.
 +
* Add '''kaloyan.raev@sap.com''' in the ''CC'' list.
 +
 
 +
There are already several ideas submitted in the [[WTP UX Whiteboard#UX ideas|UX ideas]] section that can be used as examples.
 +
 
 +
=== watch for new ideas ===
 +
 
 +
If you are interested to know about new UX ideas that people come and describe on the UX Whiteboard, then it is highly recommend to [http://wiki.eclipse.org/index.php?title=WTP_UX_Whiteboard&action=watch watch] this wiki page. You have to just click on the '''Watch''' link in the left menu. You will then receive a mail notification for each new revision of this wiki page.
 +
 
 +
Another way to watch for new UX ideas is to regularly check some of the provided [[WTP UX Whiteboard#Bugzilla queries|Bugzilla queries]].
 +
 
 +
=== comment on existing ideas ===
 +
 
 +
If you want to comment, discuss or take part in the development of an idea, then you should post a comment with your thoughts in the corresponding Bugzilla entry. Bugzilla is the place where all discussions and decisions about UX ideas happens. Here, on this wiki page, is just the summary and overview of all UX ideas.
 +
 
 +
If you want to receive future comments on an idea, then make sure you add your e-mail address in the '''CC''' fields of the bug.
 +
 
 +
== Bugzilla queries ==
 +
 
 +
Here is a collection of some useful Bugzilla queries:
 +
* [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=UX&keywords_type=allwords&keywords=&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= All UX bugs]
 +
 
 +
== UX ideas ==
  
 
=== Java EE patterns ===
 
=== Java EE patterns ===
 +
 +
Bugzilla: [https://bugs.eclipse.org/235595 235595]
 +
 +
;Pain point
 +
 +
J2EE/Java EE programming has already been among us for several years. There are some famous techniques established in this programming domain during this time - the J2EE/Java EE patterns. These patterns are especially useful for inexperienced developers and are guidelines for them to follow. The problem is that WTP has still no wizard and actions to provide for helping and hinting users to take benefit of using patterns.
 +
 +
;Solution
 +
 +
Provide WTP with wizards and actions for using Java EE patterns like Java EE applications scenarios, EJB patterns, etc.
 +
 +
It would be nice if all patterns are build on top of common framework. Here are some recommended characteristics for such a solution:
 +
* Reusing of existing operations and actions for creating Java EE projects and artifacts.
 +
* Easy composition of atomic Java EE operations and actions.
 +
* Extensibility. Adopters should be able to contribute their own patterns to the framework.
 +
 +
Useful links
 +
* [http://java.sun.com/blueprints/patterns/index.html J2EE Patterns]
 +
* [http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/introduction/application_scenarios/index.html J2EE BluePrints]
 +
* [http://java.sun.com/blueprints/code/namingconventions.html Guidelines, Patterns, and code for end-to-end Java applications]
  
 
=== Tools for easy EJB testing ===
 
=== Tools for easy EJB testing ===
 +
 +
Bugzilla: [https://bugs.eclipse.org/234138 234138]
 +
 +
;Pain point
 +
 +
EJB developers have no easy way to test their EJB artifacts. They need to install an EJB-enabled appication server that typically consumes significant resources on their developer's machines. JUnit tests have to be written manually from scratch.
 +
 +
;Solution
 +
 
EJB developers would appreciate tools that enables them to easily test developed EJB artifacts. Such tools could be:
 
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 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.
 
* 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.
 
* an integration between the JUnit generation framework and the lightweight EJB container where the tests would be executed.
Line 17: Line 96:
 
=== Index search for Java EE metadata ===
 
=== Index search for Java EE metadata ===
  
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 project 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.  
+
Bugzilla: [https://bugs.eclipse.org/233505 233505]
  
These 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.  
+
;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.
 +
 
 +
;Solution
 +
 
 +
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:
 
Examples for Java EE metadata are:
Line 26: Line 113:
 
* EJB references
 
* EJB references
 
* Security roles
 
* Security roles
 +
 +
There is a new Eclipse project proposed - EMF Index - that could help with the realization of this idea.
 +
 +
Useful links:
 +
* [http://www.eclipse.org/proposals/emf-index/ EMF Index proposal]
  
 
=== Context-sensitive view with possible high level actions ===
 
=== Context-sensitive view with possible high level actions ===
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 from JPA entity"''.
 
  
Here are some of the characteristics that should for required for the view:
+
Bugzilla: [https://bugs.eclipse.org/233498 233498]
 +
 
 +
;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.
 +
 
 +
;Solution
 +
 
 +
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.  
 
* 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.  
 
* 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.  
+
* Extensibility. Adopters should be able to contribute their own specific actions and sections to the view.
 +
 
 +
== Related links ==
 +
* [[WTP User Experience Lead]]
  
 
[[Category:Eclipse Web Tools Platform Project| ]]
 
[[Category:Eclipse Web Tools Platform Project| ]]

Latest revision as of 11:32, 13 January 2009

Contents

[edit] Introduction

The purpose of this wiki page is to collect and summarize all ideas for User Experience (UX) 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.

[edit] How to

[edit] submit new idea

First of all, you should decide if your ideas qualifies as an UX idea. UX ideas should be more large-scale, introducing new feature to the user, rather than just a small usability bug or enhancement. There is no dividing line that could be drawn between small usability bugs and UX ideas, therefore this qualification is quite subjective.

If you think that you have an UX idea then follow the next instructions. Otherwise, just file a normal bug in Bugzilla and mark it with the usability keyword.

Each UX improvement idea should be described briefly in the UX ideas section 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.
  • discussions
  • 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. Once an UX idea becomes a feature in the requirements plan for a certain release, the Target Milestone should be changed to point to that release.
  • URL must point to the corresponding section in this wiki page.
  • Whiteboard must include the UX word. This is needed to have this Bugzilla entry indexed in the Bugzilla queries.
  • Keywords must include the usability word. There is a general recommendation to mark all usability related bugs with this keyword.
  • Add kaloyan.raev@sap.com in the CC list.

There are already several ideas submitted in the UX ideas section that can be used as examples.

[edit] watch for new ideas

If you are interested to know about new UX ideas that people come and describe on the UX Whiteboard, then it is highly recommend to watch this wiki page. You have to just click on the Watch link in the left menu. You will then receive a mail notification for each new revision of this wiki page.

Another way to watch for new UX ideas is to regularly check some of the provided Bugzilla queries.

[edit] comment on existing ideas

If you want to comment, discuss or take part in the development of an idea, then you should post a comment with your thoughts in the corresponding Bugzilla entry. Bugzilla is the place where all discussions and decisions about UX ideas happens. Here, on this wiki page, is just the summary and overview of all UX ideas.

If you want to receive future comments on an idea, then make sure you add your e-mail address in the CC fields of the bug.

[edit] Bugzilla queries

Here is a collection of some useful Bugzilla queries:

[edit] UX ideas

[edit] Java EE patterns

Bugzilla: 235595

Pain point

J2EE/Java EE programming has already been among us for several years. There are some famous techniques established in this programming domain during this time - the J2EE/Java EE patterns. These patterns are especially useful for inexperienced developers and are guidelines for them to follow. The problem is that WTP has still no wizard and actions to provide for helping and hinting users to take benefit of using patterns.

Solution

Provide WTP with wizards and actions for using Java EE patterns like Java EE applications scenarios, EJB patterns, etc.

It would be nice if all patterns are build on top of common framework. Here are some recommended characteristics for such a solution:

  • Reusing of existing operations and actions for creating Java EE projects and artifacts.
  • Easy composition of atomic Java EE operations and actions.
  • Extensibility. Adopters should be able to contribute their own patterns to the framework.

Useful links

[edit] Tools for easy EJB testing

Bugzilla: 234138

Pain point

EJB developers have no easy way to test their EJB artifacts. They need to install an EJB-enabled appication server that typically consumes significant resources on their developer's machines. JUnit tests have to be written manually from scratch.

Solution

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.

[edit] Index search for Java EE metadata

Bugzilla: 233505

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.

Solution

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

There is a new Eclipse project proposed - EMF Index - that could help with the realization of this idea.

Useful links:

[edit] Context-sensitive view with possible high level actions

Bugzilla: 233498

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.

Solution

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.

[edit] Related links