Connectivity:Usability:High Level Design
DTP Usability: High Level Design
(Work in progress -- DRAFT - started 1/22/08)
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!
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.
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.