Connectivity:Usability:High Level Design

Status

Work in progress -- DRAFT - started 1/22/08

DTP Usability: High Level Design

This document will serve as the starting point for the conversation going forward about DTP Connectivity UI usability concerns and design choices/decisions. The goal is to open the conversation to the community to gain feedback and input all the way along the process, from now to EclipseCon 2008 where we will be able to demonstrate a prototype of many of the concepts and decisions documented and discussed here.

The general plan is to open the discussion up for the next two weeks (through February 6) and then take a cut of the decisions at that point to start coding a prototype. That doesn't mean that feedback should stop, but that if we don't stop soon enough we won't have enough time to code some of these concepts for EclipseCon. After EclipseCon, we'll make decisions regarding distribution (for example whether these changes should be made to the main codeline or provided as an alternative path in a separate feature) and fine tuning for the Ganymede release.

Keep in mind that this process will continue long after Ganymede also, but we wanted to get started down the usability path as soon as we had the resources to do so. We'll see what we can get into Ganymede and then determine what we would like to see in future releases. So please continue to provide feedback even after the Ganymede process is done, as we will continue to work on usability for the forseeable future.

Also note that all of these are PROPOSED/SUGGESTED changes based on feedback from the community and are merely early screen shots at this point. Nothing is set in stone. We merely wanted to provide a starting point for the conversation. If you have other ideas to put forward, we'd be happy to hear them. Screen shots and patches are welcome!

Driver UI

A number of suggestions have come in from folks regarding the "clickyness" of the process of creating a driver and a connection profile. Some folks have mentioned that there are a great many steps required to go from a new workspace to having a connection profile you can connect to, and a good chunk of those steps appear in the Driver UI portions of the process.

That said, I'm proposing a few minor changes to existing framework objects to simplify some of the more common steps.

Driver Drop-down List

The existing Driver Drop-down list provides a simple combo box with a sorted list of all available drivers or a filtered list, and a "..." button that opens the Driver Definitions dialog (basically the Driver Definitions preference page hosted on a dialog), where users can create their own drivers, manipulate existing drivers, and so on.

The proposed changes to the drop-down list makes the buttons to the right of the combo box a toolbar, which provides some nice functionality for free and easier addition of buttons in the future should we need them. The image shows the buttons as flat, but we could easily make them raised also. There are three buttons:

• New Driver Definition (opens the new New/Edit Driver Definition dialog discussed later)
• Fast Driver (opens the new New/Edit Driver Definition dialog with the Generic JDBC template pre-selected)
• Drop-down menu (provides a menu for each toolbar action)

Combined New/Edit Driver Dialog

Currently the user goes through three dialogs from the old drop-down to create a driver on the fly. From the preference page, it's only two dialogs. But this should be simplified to provide a more concise, shared UI that can be used to create new driver definitions or edit existing driver definitions.

This new dialog has three tabs to help break the info into more easily-digested pieces -- Name/Type, Jar List, and Properties. The old dialog had everything top to bottom in a single area.

Also notice that instead of a Tree, there is a Tree-Table displaying the list of available driver templates. This table can be sorted by any column (name, vendor, or version) in either ascending or descending order to help quickly find the template you're looking for.

The Jar List tab is the same as the Jar List section on the old dialog.

The Properties tab is the same as the Properties section on the old dialog.

A couple of things to note:

• Though JDBC drivers do require Jars, not every potential driver definition type will have drivers (at Sybase, we're using driver definitions to indicate a compression type for some security functionality). Having the Jar list functionality on a tab will make it easier to hide it if it is unnecessary.
• And not all driver definitions will have editable properties. Some may have many hidden properties that are used by a customized connection profile, but provide no editable properties to the user. Again, we can hide this tab now if there are no editable properties for the driver definition in question.
• We may also be able to add icons to the tabs to more specifically indicate where problems lie. For instance, if there is an issue with the jar list, the user might see a warning or error icon in the Jar List tab to more easily identify where the issue is and where it can be resolved.

Variant: Combined Edit Driver Dialog

Instead of having two separate dialogs for selecting the name and type of your new driver definition and then going to another dialog to edit it, we can reuse the same dialog and just hide the section allowing the user to change the type of driver template.

All of the other tabs are the same and have the same capabilities. But once a driver is created for a particular template, we don't allow changing the template at this point.

Driver Definitions Dialog/Preference Page

Another change would be on the Driver Definitions Dialog and Drivers Preference page to shift from displaying the tree of all available categories/vendors/versions/etc. which can take a lot of clicking to navigate and switching that to another table. Each column would be sortable to allow users to see which drivers they have and which vendor/version (if applicable) each is using.

New Profile Wizard

A minor change has already gone into the New Connection Profile wizard to allow each driver to have a custom UI. This simplifies the process for adopters greatly, as they can customize a driver UI and provide it via an extension point rather than totally revamping and extending existing new profile wizards to get it to look/work the way they want. Nothing prevents them from extending the wizards, but this is a mid-way point for a lower bar of access.

I envision using the updated driver drop-down list at the top of this wizard page, which would allow a user to quickly create a new driver definition of any existing driver template type or a Generic JDBC driver definition to get them started even more quickly.

API Changes

Lastly, I'm in the process of working on an API to handle a new optional property for driver templates which will instantiate a class that gets queried for customized driver defaults (such as platform-specific jar paths, pre-discovered jars, and so on). This should address many of the concerns folks have had with creating default drivers with preset jar lists and so on.

Conclusion

These are all very high level designs and screen shots at this point. We hope to get feedback of the general variety (yes we like it, no we don't like it) but would be pleased to get much more detailed input (we like it, but would like to propose these changes; or we don't like it, but here's something else we've thought of that might work). This is very much a community effort and we hope the ever-growing DTP community will help us get this effort off the ground!

If you have feedback, please either add it to the "Comments" section at the end of this page, or send it to the DTP newsgroup or mailing lists to keep the conversation going in full view of the community!

Comments

High Level Design for DTP Usability - Comments

Comments should go on the above page link and we will integrate them in with the design document. Please remember to note your comments in brackets, such as <BrianF>My comments...</BrianF> so we can keep track of different threads. Any comments that are sent in to the newsgroup or mailing lists may be paraphrased and reposted on the Comments page and be integrated into the document also.

We look forward to your feedback and suggestions!