Latest revision as of 17:12, 12 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>

<Chenhong Xia 02/11/2008>

The following comments are from IBM UCD, and include both high-level design thoughts and detailed UI remarks. The GUI changes mentioned in the HL Design doc mostly make sense to us. Since we are new comers, please allow us to think from different perspectives.

1. Task Flow: The current design is a top-down task flow, where user has to first define a driver definition, then a conn profile, then connect. This is computer-oriented, similar to the way programmers have to first define a class before creating an object from it. A human-oriented way could be more bottom-up. I.e., let me use the shortest path, or minimal steps, to first create a connection, and see whether it works. If it did, then give me the option to make it a template for future reuse. I’d rather not having to go thru all that heavy-headed process to define this and that, then later found out that it doesn’t connect at all.

2. Driver Definition Necessary? Based on the reasoning above, it may not be necessary to have the concept Driver Definition. Unlike computers, humans in general don’t like extra layers of abstraction. Tools could fill in driver defaults for users and give them the option to tweak them and later make reusable templates from their work.

3. Tool Should Manage Reusability Implicitly. E.g., tool provides default assumptions of driver definitions to users, so that users don’t have to explicitly create them to start with. If users tweak the parameters, tool should remember the session state for the future, so that users don’t have to type again. If users want to create a different instance of the driver definition, but also want to keep the current one for future reuse, then give them the option to “Save This as A Template”.

4. Terminology: Based on existing design/implementation,

a. “Connection Profile” easier to be just “Connection”. A Connection can be active/inactive, or connected/disconnected. The “Databases” tree node in DS Explorer view should be “Data Sources” or “Data Source Connections”

b. “Connection profile repository”, not sure what is a “Connection profile repository”

c. “Duplicate” vs. “Copy”. In DS Explorer view, it is “Duplicate”. On Driver Definition dialog, it is “Copy”. They behave about the same. May want to keep consistent terminology.

d. “Ping” vs. “Connect”. Since Ping is in fact “Test Connection”, should name it so. “Ping succeeded” is actually “Connection succeeded”. Ping is too much a network concept, and you are actually connecting to the DB using the ID/PW provided.

5. New Connection Profile Wizard:

a. Should have 2 checkboxes on the last page

  i.	Auto connect at eclipse start
  ii.	Connect after wizard finishes

b. Give the user the option to enter ID/PW separately at connect time instead of inside of the wizard. Think about the scenario where a large dev team needs many connections. A team lead creates those conns then export to share with team members. Different members connect with different IDs/PWs.

6. Preferences Dialog: I typed “data” in the filter box, but didn’t see Driver Def. Need to rename tree node to be “Data” or “Data Source” and have sub nodes “Data Connectivity” and “SQL Development”, etc.

7. GUI Consistency: The content of the Conn Wizard and that of the Conn Properties view don’t match. Another inconsistency is the coexistence of Properties Dialog and Properties View, each with different contents. Got user complaints about such inconsistencies.

</Chenhong Xia>

<brianf>Thanks to everyone who contributed comments! I'm going to start work tomorrow (2/13/08) on trying to integrate as many comments as possible into the design and writing some example code for a demo at EclipseCon. As I work through the comments, I may ask for clarification or feedback as the design is updated, so keep an eye out for possible requests. But I'm very encouraged by the community support for this effort! Thanks again!

Please keep in mind that we will be continuing to solicit comments and feedback even past the Ganymede release, as usability can ALWAYS be improved and new requirements are always popping up. So don't let the fact that I'm getting started on some code keep you from putting in your opinions, suggestions, and comments!</brianf>