ERD UIsepcsReview

ERD Module UI Specifications, Review


Posted By : Wessam Abdrabo


This page is used to manage the review of the ERD Module UI Specifications.

The value of this approach is that it allows us to track each issue separately and drive them to resolution. The document can be considered approved when all comments are marked as Approved.

The review process works like this:

  • Add a comment header of the format
    "<initials>-<number> - <description> (<status>)"
    (see below for examples)
  • A discussion then can take place under that comment header
  • Each comment will have a status at the top, with the status set to Approved, Accepted PDU (pending doc update) or Unresolved. If a comment has no status, it is assumed to be unresolved.
  • If necessary, we do more rounds of discussion until the item is marked as Approved
  • There may be some items which can not be resolved through this means. If that happens, we may arrange a meeting (perhaps on an IRC channel) to try and work through the remaining open issues.

Commenter Initials Key

  • DVC - David Van Couvering

[[{TableOfContentsTitle=TableOfContents} | {TableOfContents title='Table of Contents'}]]

DVC-00 - General - Approved

Really, really, really good work! It is simple, to the point, and readable. Congratulations to your team on this spec!

Thanks! -Wessam

DVC-01 - General - Approved

As I mentioned in my email, I highly suggest implementing the ability to view an E/R diagram first, and then we can add editing and generating capabilities. I have limited time right now, so I am only going to review those aspects of the design that have to do with the ability to view an E/R diagram.

We're giving the functionality of viewing an ER diagram a higher priority, but we're also working on the design work in parallel -Wessam

DVC-02 - Generating ER Diagram - Approved

The research I have done shows this is a key use case, and we should make it easy. More people will want this than any other aspect of the E/R diagram functionality.

I would like to see this be as easy as possible. Here is how I envision it:

  • User opens a database connection
  • They right-click on the connection and choose "Generate E/R Diagram"
  • You can select which tables you want to use for the diagram
  • Zip, you have a view

You may not even want to save this - a quick view. Once you press 'Save' then it asks you what project and a file name.

To me this is preferable to the steps of having to open a project, create a new file, navigate down to Other->ER Diagram, set a name, choose "Reverse Engineer" and then choose a connection and tables. I'm exhausted by the time I get to the results.

The time you want to visualize a database schema is when you are looking at the connection already, IMHO.

Perhaps both mechanisms could be available, but I would choose the one I suggested as the first one to do.

I agree that this scenario is much easier for a user. We're going to implement it. However, i don't see how we can add an action to the connection node in db explorer for generating E/R diagram. If this is what you meant, how can we do this? I also see the idea of having a quick view without saving a nice one. But what about if the user clicks save? So now we start a wizard to ask the user for a project name and location (new or existing?) and a name for the file? In a later comment, you say that there's no need to include a .erd file extension for the user. How can he save the generated diagram then for editing later? -Wessam

I ran into the same question about how to add an action to the connection. I think it's going to require some plumbing in the DB explorer. But let me talk to folks here and get back to you. But let's make it work this way - I know there are ways to do it so from the perspective of UI design, let's just do it this way.

I think asking for a project when they want to save makes sense. I would love to get our usability folks involved in this review, I'm going to see if they're available now, these are great questions.

I'm not sure about the .erd file extension, let me think about that. - David

We've got no problem with implementing this scenario. the only problem is with adding the action to db explorer connection. If this can be done, then there's no problem. We'll wait for your feedback on that -Wessam

Hi, Wessam. If necessary I can add plumbing to the DB Explorer. We'll work that out during design discussions. I'm checking with Andrei to see the best way to do this.

Hi David. OK. Please let us know of the updates of this step ASAP. I updated the scenario to be the suggested one. -Wessam

Regarding .erd file extensions - see below, I think my concern was invalid, and I would go with your original plan. Marking this accepted, pending doc update.

DVC-03 - Organization of the spec - Approved

It was difficult to switch up and down between use case description and visual layouts. Perhaps you could show the layouts in the same section as the use case description? Not essential, not worth spending a lot of time on.

I'm sorry for that. I just followed the template you gave me for UI Specs. I couldn't create links for the pictures in the sepcifications. -Wessam

DVC-04 - New Connection Wizard - Approved

I was confused when you showed the UI for New Connection Wizard, Driver Name Combo, and New Driver. Aren't those existing dialogs? I hope they're not new ones, because we already have them. In particular, the New Connection dialog we have today does not have a progress bar. Are you suggesting we add this?

If you are referring to existing dialogs, please don't provide the UI specs for them here, just indicate you'll be using them.

Ok, that was a misconception. I thought that any wizard we use should be specified. I removed it - Wessam

DVC-05 - E/R Diagram File name - Approved

I don't know why you should let the user specify or even have to know about the E/R diagram file. This should be an internally managed file. If the user wants to export to a file in some standard format, then that's another thing.

Have you looked to see how the internal storage is managed for other visual components, such as the Page Flow Editor in web projects? We should probably follow the same model.

This is so confusing for me. How can the user not have any knowledge of the erd file? what about when he saves the model for editing later?or what if he's on the desing view and want to save whatever he designed and add it to a project? shouldn't we provide a file type for that to allow saving and opening? For clarification, erd file is just the design and not any underlying file like the XML generated or SQL or anything. Could you please elaborate on this -Wessam

I think you're right on this one Wessam, sorry for causing confusion. I'll try to get the UI folks to review too, they have much more background in these sorts of things than I do. - David

DVC-06 - Moving entities - Approved

"If the user drops the entity/relation on top of another component, it will be place on another layer on top of it." -- I don't understand this.

I removed this line. It doesn't mean anything -Wessam

DVC-07 - Creating New Database - Approved

This use case already exists and is out of the scope of this document. It should be removed, as well as the UI screens for it.

removed - Wessam

DVC-08 - Showing key attributes/all attributes/only entitys on the diagram - Approved

This use case is useful but not necessary. I wouldn't implement it in the first revision.

Ok - Wessam

DVC-09 - Switch to conceptual view - Approved

This differentiation between "physcial view" and "conceptual view" is interesting, but I'm not sure I'm clear I understand exactly what these two views are about and what they look like. The only thing I have to go on is the one set of diagrams showing the two views, which raises more questions than they answer:

  • What are the "S" prefixes before ID and Name?
  • What does "DNO" mean before "NUMERIC"?

These were just examples for naming the attributes (SID-student id) and (DNO- Department Number). It was meant to be illustrative but ended up being confusing -Wessam

I am concerned that this is more complex than it needs to be.

It seems to me that the main goal for many users is to quickly understand the schema, and in that case the conceptual view works.

Then they could potentially double-click on an entity, and it would show the "details" for the entity, which includes the physical information such as type, constraints, etc.

What do you think?

Sounds good to me. We'll just provide a conceptual view for the entities and attributes (which will include only names and primary key icon if the attribute is key). We can then provide a properties sheet for the enitiy, attribute and indexes which will include all the detailed physical information. what do you say? -Wessam

This sounds good - David

DVC-10 - Hiding/showing Indexes - Approved

This use case is useful but not necessary.

Ok. all "useful but not necessary" features are going to be delayed -Wessam

DVC-11 - Resizing entity - Approved

Isn't this covered by the graph library? Maybe not worth mentioning it...

Yes it is covered by visual library. I'll remove anything i mentioned that is already provided by visual library -Wessam

DVC-12 - Zoom in/out and "satellite view" - Approved

Useful, but not necessary

i see, but they're just too easy to implement. They're also provided by Visual Library so we thought there's no harm in adding them -Wessam

OK, great, let's add them then. - David

DVC-13 - Setting layout - Approved

Useful, but not necessary. This one in particular sounds like a lot of work and can be skipped for now. I would pick one layout, the most common one (I actually don't even know what these layouts even mean), and implement that. You could have a menu choice to "arrange layout" and it will use that default layout.

Later on we can add other layouts.

we thought it will be useful, on the design side, to provide a way for auto arrangement of the diagram's entities. But you're right. For time sake, we'll pick only one layout and work on implementing it -Wessam

DVC-14 - Export - Accepted Pending Doc Update

Interiews have shown me there is a need to communicate a database design. People have requested the ability to print and display in HTML. Probably the easiest way to do this initially is to support exporting the diagram as an image file (JPG or GIF). Perhaps the Visual Library already supports this? But we should discuss this use case.

Ultimately what I would love is that we generate "live" HTML that lets someone navigate the design from a browser: zoom in, zoom out, view details, hide details, get satellite view, etc. But that's a longer-term vision. First things first.

i don't get the live HTML part? you mean export the diagram as HTML? We'll see about the JPG export thing, if it's already provided by visual library then we'll add it -Wessam

Further research has shown me that the HTML stuff is "nice", but what they really want is the ability to export to PDF. I would make that the highest priority - people really want this so they can send the diagram in email or print it out - David

I think exporting to JPG or PNG is easy. I looked it up in Visual Library and it can be done. However, it is said that it can't be done for relatively large diagrams. PDF could need more work. Is there anything significant about PDF in sepcific? -Wessam

It's quite possible that print to PDF is already available. The Visual Library page says printing support was planned for NB 6. Let me check with on that.

If push comes to shove, this can be delayed; I would not deliver this in the first checkin, for example. But here are my preferences, in order of priority:

  • Print to PDF
  • Export to JPG
  • Export to PNG
  • Nothing

I think we agree there is a need for a use case to export/print, so I'll close this as accepted pending a doc update.

After checking, i think all (PDF, JPG, PNG) is doable. I added them to the list of main functionalities. Export to PDF, Export to PNG/JPG, buttons will be added to the diagram's toolbar. What do you think? -Wessam

DVC-15 - Main Window - Approved

I'm having trouble picturing this. It looks like you're showing it as a "floating" window? Wouldn't it fit into the NetBeans "frame" like other document windows, such as the SQL editor, source files, and so on? Or is that what you're showing?

No, it is part of the Netbeans frame like other windows or editors. Perhaps the drawing is not clear -Wessam

DVC-16 - Relationships Property Window - Approved

I don't understand the "On Update", "On Delete" and "On Insert" drop downs. What are the possible values? What do they mean? How do you derive them from the database definition? Are these triggers? If so, how do you do this in a database-independent way?

Cascade, defualt value, and delete are the values. These are just to indicated what to do to a column that is related to another column that is updated or deleted. I think it can cause problems and needs more thinking so we might postpone that. -Wessam

Postponing sounds good, especially because what people really want is ERD for visualization, not database design. - David

DVC-17 - Attribute Property Window - Unresolved

Rather than "Key Attribute" I would just say "Key"

Changed -Wessam

I just checked, it still says "Key Attribute", under Section 3.5 - David

DVC-18 - Constraints - Approved

Isn't it possible for an attribute to have multiple constraints? How do you rationalize a foreign-key constraint and an identifying relationship?

Yes it is possible. But what i meant a check contraint to check on the value added to a column. It is meant for validation. I was thinking of postponing the On update, delete, insert part and constraint part, if people can live without them for now. -Wessam

Yes, let's postpone - David

DVC-19 - Non-identifying relationships - Approved

Are you intending to support deriving non-identifying relationships from a database when reverse engineering? A number of interviewees complained that tools that tried to do this generally did a bad job. We should probably not try to do this initially.

Do you mean identifying realtion? the non-identifying relation is just the normal realtion. if you mean this , then fine, we can drop that -Wessam

We should drop anything that requires us to "guess" what the relations are, only model that which we can derive from real metadata in the database. Identifying/non-identifying, whatever :) - David

DVC-20 - Weak entities - Approved

You don't describe what these are or how they are related to a physical database schema. Is this something you feel we need to support? I have never seen this in other systems, and seems like a non-essential feature. How would you even derive a weak entity from an existing database schema?

if it's non-essential, then no problem to drop it -Wessam

Yes, let's drop it - David

DVC-21 - Relationship icon - Unresolved

Nitpick, but the diamond seems awfully large, especially in the recursive relationship

We'll just use the connection shape provided by Visual Library, which is an arrow from the foreign attribute to the primary attribute. I'm going to update the icons for those -Wessam

Doesn't look any different - not a big issue though - David

DVC-22 - Relationship UI - Approved

One very useful thing from Access was that the relationship line would actually connect the two attributes that are related, in a strong relationship, so you could very quickly see what attributes are participating in the relationship

This is excalty how we're planning to implement the relation. Wait for the updated icons to see them -Wessam

DVC-23 - Adding attributes to entities - Unresolved

It would be very nice if you could just click in the section of the entity reserved for attributes and just start typing attribute names using a useful shorthand like "id integer primary key" and "lastname varchar 255". Usability is significantly improved with keyboard-based data entry that does not require mouse clicks.

Ditto for indexes.

DVC-24 - Keyboard shortcuts - Unresolved

All of the operations that require mouse clicks - please specify the default keyboard shortcuts for these operations. This is about both usability and accessibility (not everybody can use a mouse).

DVC-25 - General

Can you provide a table somewhere describing milestones/releases and what use cases will be implemented in which milestone? If you want to do that in a separate document that's fine, but you should refer to it here.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo