Some observations on my first use of Data Modeler Beta

Question

First of all, I can see this tool has a lot of promise.
I hope Oracle keeps at it, it could turn into a real winner if all the features I see being worked on mature.
Thanks!
Here are a few observations on things that I found non-obvious or tedious to do.
1. When designing an entity, I want to give it a name, a definition, attributes and keys. I want that process to be quick and require the minimum amount of mouse-clicking/navigation fiddling as possible. The current way of defining the attribute's datatype and size is painfully slow. I have to click to get a pop-up. Then I have to click to choose from a set of categories. Then I have to click on a dropdown list. If I try to use the down-arrow on the dropdown list, it works, but not if I go past the one I want. The up-arrow won't take me backwards in the list, so more clicking. It's just a nasty, slow interface to do a simple task that I have to do a thousand times in a data model. If I need to change the size of something, back I go thru the entire process all over again.
That makes it doubly slow to work in the most natural way, which is to list the attributes and the datatypes, then come back and refine the sizes once the model is maturing and relatively stable.
2. Adding an additional attribute requires a mouse click instead of a down-arrow. That means I have to take my hands off the keyboard to add a new attribute. Maybe there is some short-cut key that does that, but I have better things to do than memorize non-standard keyboard mappings. Make the down/up arrows works as they should.
3. Adding the comment that describes the attributes is not quite as slow, but still requires more keystrokes/mouse movements than it should. It's hard enough to get developers to document their attributes, don't discourage them.
4. I can't see the list of attributes, data types, sizes, key/mandatory settings, and the comment at one time while editing the entity. Makes it harder to grasp what all the attributes mean at a glance, which slows down the modeling and the comprehension of an existing model.
5. All the entities I created had primary keys with columns in them. But when I tried to have it build a physical model, it complained that some relationships had no columns in them. For the life of me, I couldn't figure out how to fix that. Never had that problem in any other case tool.
6. Getting it to generate DDL was awkward to find. Make it something obvious, like a button on the toolbar that says "Generate DDL".
7. Apostrophes in the Comments in RDBMS are not escaped, so the generated DDL won't run.
8. For the ease of use/speed of use testing on high-volume key tasks, make the developers do the task 1000 times in a row. Make them use long names that require typing, not table A with columns c1, c2 and c3. Long before they get to iteration 1000 they will have many ideas on how to make that task easier and faster to do.
9. Make developers use names of things that are the maximum length allowed. For example, for a table name in oracle, the max length of the name is 30 characters. The name of one testing table should be AMMMMMMMMMMMMMMMMMMMMMMMMMMMMZ. That's a capital A followed by 28 capital M's and a capital Z. For numbers, use the pattern 1555559. If the developers can't see the A and Z or 1 and 9 in the display area for the name in the default layout for the window, they did the display layout wrong. For places where the text can be really long, choose a "supported visible length" for that field and enter data in the pattern AMMMMMMMMMMMMMMMQMMMMMMMMZ, where Q is placed at the supported visible length. if the A and Q don't show, the layout is wrong.
10. SQL Developer has quite a few truly gooberish UI interaction designs and I can see some of that carrying over to the Data Modeler tool. I really recommend getting a windows UI expert to design the ui interface, not a java expert. I've seen a lot of very productive windows user interfaces and extremely few java interfaces suitable for high-speed data entry. Give the UI expert the authority to tell the java programmers "I don't want to hear about java coding internals - make the user interface perform this way." I think the technical limitations in java UIs are much less than the mindset limitations I've seen in all to many programmers. That, and making the developers use their code 1000 times in a row to perform key tasks will cause the UI to get streamlined considerably.
Thanks, and keep up the good work!

Answer 1

Dear David,
Again thank you for your valuable and highly appreciated feedback. Find included a more elaborated answer to your observations:
*1. When designing an entity, I want to give it a name, a definition, attributes and keys.*
In the new Early Adopter Release, a "SQL developer like" property window has been added for Entities and Tables. For each attribute/column you will have the ability to add name, datatype, Primary Key, Mandatory and comment from one and the same screen
*2. Adding an additional attribute requires a mouse click instead of a down-arrow.*
An enhancement request has been created
*3. Adding the comment that describes the attributes is not quite as slow, but still requires more keystrokes/mouse movements than it should.*
In the new Early Adopter Release, a "SQL developer like" property window has been added for Entities and Tables. For each attribute/column you will have the ability to add name, datatype, PK, M and comment from one and the same screen
*4. I can't see the list of attributes, data types, sizes, key/mandatory settings, and the comment at one time while editing the entity. Makes it harder to grasp what all the attributes mean at a glance, which slows down the modeling and the comprehension of an existing model.*
See former answers. For meaning of attributes you can also use the Glossary and Naming Standardization facilities: see Tools Option menu, Glossary and General Options for naming standards
*5. All the entities I created had primary keys with columns in them. But when I tried to have it build a physical model, it complained that some relationships had no columns in them. For the life of me, I couldn't figure out how to fix that. Never had that problem in any other case tool.*
A Bug report has been created. Issue will most probably be solved in the nexr Early Adopter release
*6. Getting it to generate DDL was awkward to find. Make it something obvious, like a button on the toolbar that says "Generate DDL".*
An enhancement request has been created.
*7. Apostrophes in the Comments in RDBMS are not escaped, so the generated DDL won't run.*
A bug report has been created
*8. For the ease of use/speed of use testing on high-volume key tasks, make the developers do the task 1000 times in a row. Make them use long names that require typing, not table A with columns c1, c2 and c3. Long before they get to iteration 1000 they will have many ideas on how to make that task easier and faster to do.*
I aplogize, but I don't understand clearly what you want to say with the use/speed of use here.
*9. Make developers use names of things that are the maximum length allowed.*
Our relational model is for use for not just Oracle, but also DB2, SQL Server and in the future maybe other database systems. Whicjh means that we can't taylor it to just one of these database systems. However you can set maxinum name lenghts by clicking right on the diagram and select Model Properties and here you can set naming Options. Here you can also use the Glossary and Naming Standardization facilities: see Tools Option menu, Glossary and General Options for naming standards
*10. SQL Developer has quite a few truly gooberish UI interaction designs and I can see some of that carrying over to the Data Modeler tool.*
Fully agree. As you will see in our next Early Adopter release we have started to use SQL Developer like UI objects.
Edited by: René De Vleeschauwer on 17-nov-2008 1:58