Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Connectivity:Usability:HighLevelPlan"
(→High Level Plan for Usability Improvements in DTP Ganymede) |
(→Overview) |
||
| Line 1: | Line 1: | ||
| − | == | + | ==High Level Plan for Usability Improvements in DTP Ganymede== |
Though the current Connectivity user interface framework has sufficed for the first couple of releases of DTP, some issues have been raised by adopters that can't be dealt with continuing down the same path that we have been pursuing. The "user experience" is lacking in a few key areas determined by the community: | Though the current Connectivity user interface framework has sufficed for the first couple of releases of DTP, some issues have been raised by adopters that can't be dealt with continuing down the same path that we have been pursuing. The "user experience" is lacking in a few key areas determined by the community: | ||
| Line 14: | Line 14: | ||
As you can see, this covers a variety of areas and concerns from the community. Our goal is to provide enough options that adopters and therefore users gain the productivity benefits when such options are used by adopters. | As you can see, this covers a variety of areas and concerns from the community. Our goal is to provide enough options that adopters and therefore users gain the productivity benefits when such options are used by adopters. | ||
| + | |||
| + | ==Focus== | ||
At a high level for Ganymede, we're going to try and focus on two main areas: | At a high level for Ganymede, we're going to try and focus on two main areas: | ||
| Line 36: | Line 38: | ||
We will be creating additional BZ entries for issues to be addressed so they are not lost if not dealt with in the Ganymede release. This may become a phased approach, with some changes starting in Ganymede and others being pushed further out, due to time and resource constraints. | We will be creating additional BZ entries for issues to be addressed so they are not lost if not dealt with in the Ganymede release. This may become a phased approach, with some changes starting in Ganymede and others being pushed further out, due to time and resource constraints. | ||
| − | |||
==UI Framework Changes== | ==UI Framework Changes== | ||
Latest revision as of 17:20, 15 January 2008
Contents
High Level Plan for Usability Improvements in DTP Ganymede
Though the current Connectivity user interface framework has sufficed for the first couple of releases of DTP, some issues have been raised by adopters that can't be dealt with continuing down the same path that we have been pursuing. The "user experience" is lacking in a few key areas determined by the community:
- Driver management is less than ideal, requiring a great deal of knowledge for first time users and a number of steps that should be collapsed into a much smaller process
- Also in the drivers area, default drivers should be created behind the scenes where possible to eliminate this step entirely for most users
- Connection profile creation is also less than ideal, requiring that drivers be defined before beginning the process or they are forced into the driver management steps before defining their connection properties
- Also in the connection profile creation area, wherever possible we should customize the UI gathering connection info (especially for the JDBC URL) to allow users to input more easily recognized data (host, port, database name, and so on) and create the URL automatically (if desired by the user) and then allow the user to modify it further if necessary
- Dialog layout does not work well on platforms other than Windows (i.e. linux or Macintosh)
As you can see, this covers a variety of areas and concerns from the community. Our goal is to provide enough options that adopters and therefore users gain the productivity benefits when such options are used by adopters.
Focus
At a high level for Ganymede, we're going to try and focus on two main areas:
- Changes to the framework directly to improve the existing user and adopter experiences (covered in the "UI Framework Changes" section)
- Additional paths that can be used by adopters to streamline these processes further to help their users (covered in the "Additional Paths" section)
There are already a number of BZ entries dealing with usability, including, but not limited to:
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=163624 (Too Many Steps - Compile down to 1 page wizard)
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=164534 (Driver usability - hide jar section for drivers without jars, hide properties section if no editable properties, possibly give driver defn developers the option to make a particular driver defn read only, possibly add additional base property descriptors to help prevent duplication of effort for common property types like boolean or string list box)
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=208203 (another BZ like 163624 to compile down the new profile wizard into a more manageable piece, provide default profile name, provide a mechanism for populating the jar list at runtime, create default driver definitions -- split into 213146)
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=211428 (reduce number of clicks to a manageable amount)
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=213146 (create default driver definitions, request vendors provide such default drivers (with appropriate jars) from their own sites for easy downloading by adopters/packagers/users)
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=201682 (provide an optional property in the driver template extension for populating default driver properties - this would allow for checking for the platform and providing a platform-specific path separator, as well as a way during the default driver creation process to see if a particular driver jar is in the OS somewhere and use the path (i.e. check the Windows Registry for a particular key, check the Java installation to see if the drivers were registered and in the classpath, or some other OS-specific registration method)
We will be creating additional BZ entries for issues to be addressed so they are not lost if not dealt with in the Ganymede release. This may become a phased approach, with some changes starting in Ganymede and others being pushed further out, due to time and resource constraints.
UI Framework Changes
A number of minor changes can be made to the UI framework itself to simplify the experience. Some of these ideas include:
- Adding a new action (either via a button or menu) to provide easier access to creating a new generic driver definition. This would shift the user from having to filter through the myriad driver type/vendor/version combinations in the tree to using the generic driver template by default, and if they want to be more specific, we can provide drop-downs for selecting the vendor/version they're looking for. This would reduce the clutter of the tree-based approach to a more effective, simpler UI for adding and editing driver definitions (down from the clunky series of dialogs we have currently).
- Change the driver list from a tree to a simple alpha-sorted list of available (i.e. set up) driver definitions. Then, if a user wanted to add a new driver, they would go to the first bullet item in this list for the simplified new driver process. We could offer a switch to allow the user to see the view in the traditional tree also.
- Provide a default connection profile name in the current New Connection Profile wizard.
- Provide a platform-aware mechanism for populating the jar list at runtime (perhaps the suggestion made in BZ 201682)
- Provide examples of how to add databaseRecognizers to minimize the number of vendor/version combinations and have the class do the work setting those properties
- Improve dialog layout across the Connectivity UI to help with issues on non-Windows (mac, linux) platforms (need to research best-practices for cross-platform layout)
Additional Paths
Beyond the framework changes, we will also being introducing an alternate path for adopters to use instead of the core wizards in their tooling. These alternate UI pieces will reside in a separate plug-in from the org.eclipse.datatools.connectivity.ui plug-in and a separate feature so adopters can choose to include it or not. These changes may also require us to spin off certain classes out of the o.e.d.connectivity.ui plug-in into a separate class to simplify use of one path or the other in an adopter's application.
Create a new "New Connection Profile" wizard that simplifies the process greatly, perhaps down to one wizard page with multiple tabs, or a minimal set of pages.
Or perhaps create a couple of variations of the wizard -- one with a single page, one with a minimal set of pages
Conclusion
Over the next month or so, I hope to collect input from all interested parties and start formulating a design and prototype from those comments. We would also like to ask for help with the process, either by providing patches or helping to test at various stages in the development.
We hope to have a first cut of this new functionality available in the M5 timeframe to help drive the discussion further, having a more complete sample in the EclipseCon timeframe.
In addition, we welcome feedback at all points in the process, so feel free to chime in with your suggestions and problems. Keep in mind that your comments will help us prioritize features so we get as many key requirements addressed for Ganymede as possible.
The goal is to make DTP better for users and adopters alike and that can only be done with your (the DTP and Eclipse community) involvement. Thanks!