Revision as of 13:42, 11 February 2008

DTP Connectivity Usability High Level Design Comments

<BrianF>Comments should go on this 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! </BrianF>

<LarryD>I think the new dialogs are a great improvement. However, I do think that usability could be dramatically improved by removing the concept of a driver instance so that the Driver Definitions Dialog and Preference Page could be removed altogether. Currently, the driver template acts as a template providing default values to the driver definitions dialog. The resulting driver instance created by the driver definitions dialog is then used as a template for setting the default values of a connection profile. It seems to me that the driver definition template could provide the default values directly to a connection profile eliminating the need for driver instances and the necessary dialogs and preference pages for managing them.

One of the functions provided by the driver instances is to give the user a way to simplify creating multiple connections with similar properties that may be different than those provided by the driver definition template. However, the user can accomplish the same task now by using the Duplicate menu item provided in the Data Source Explorer and editing the duplicated connection profile.

Another function provided by the driver instances is that they allow the user to edit the jar list for multiple connections in a single place. However, one way to address this is to provide a preference page for "Jarlist Aliases". The user could provide an alias name and the jar list in the preference page. Then when a new connection profile is created, the user could specify actual file paths or specify the alias. At connect time, the connectivity framework could convert the alias to the actual jar list specified in the preference page.

I do not believe the functionality provided by driver instances justifies the negative impact it makes on usability especially when the functionality can be provided in another more usable fashion. </LarryD>

<HuguesM> The new dialogs are a great improvement.

The request for improvement https://bugs.eclipse.org/bugs/show_bug.cgi?id=213584? is somewhat related to usability. It would let eclipse developers contribute connection profiles programmatically.

Supporting this scenario will make sure that users don't come up with unreasonable requirements for the UI of DTP that would only fit their own product.

For example, a set of plugins for a J2EE server might very well be aware of the definition of a JNDI datasource setup inside a J2EE server. It would know here is the driver and all parameters to connect to the database. This improvement would let those plugins add an appropriate connection profile. </HuguesM>

<DavidB> I agree with the reasoning behind the changes and a number of the suggested changes. I'll start with some constructive criticism and then move on to some other suggestions.

For the New Drop-down image, I'd be concerned about the usability. People are used to buttons next to drop-down comboboxes, but I'm not sure they'd understand, at least initially, what the purpose of those images are.

While I do like aspects of the New Driver Dialog, I'd be concerned that you've in essence replaced mouse clicks to expand the treeview for having to use the scrollbar. One alternative, which I can't claim is any better than either the old or the new approach, would be to have a Vendor filter combobox (which would include an All entry in addition to individual vendors) and filter the list of templates in that way. As a slight variation on that theme, you could have a filter textfield, similar to other New wizards.

Looking at the New Connection Profile wizard, from a personal perspective, I don't like the usability of tab controls on wizards. I understand the motivation, but I'd personally prefer a collapsible Optional section or a separate page.

As a general note, I think one of the ways of addressing the issue would be to precreate driver instances, even though the jar(s) that those instances point to don't exist. If the user chose a driver instance which wasn't properly configured, they should be told about it at that point, and given the ability to configure the instance at that time.

As another general note, I think there would be value in having a New Connection wizard (something you would implement a Connect menuitem with), in which the end goal wasn't a new connection profile, but rather just simply a connection to a database. You might have a checkbox option whereby the user could, as a side-effect, create a connection profile, but that would be up to them. An example usage would be in the SQL editor, the user might, in the process of writing a SQL statement, want to connect to a database, but might not necessarily care about remembering the connection to that database. </DavidB>

<RoyG> I thought about these three issues: • Auto Connect to the database upon pressing finish in the new connection wizard (today the required additional step is annoying). We can add a checkbox in the summary page that is checked if the connection should be enabled right after the wizard is finished, vendors will be able to change the default for this checkbox.

• Database List in the Connectivity Wizard - Have the list of all databases for a specific connection prior to the connection creation (for vendors that support it). Today users should know or ‘guess’ the database name.

• Driver Management- Lets provide a download option from within the driver page to ease the process of updating and receiving jars. We should provide an infrastructure for vendors to implement it, but a basic implementation can be getting the files from the net (with a given URL). Vendors will be able to add authentications / disclaimer screen / (long) agreements screens, etc.

</RoyG>