The DDS Designer Showdown

For our EXTRA article this week, we wrote about the new DDS Designer--the one integrated with RSE in its latest incarnation as part of RDP or RD Power or ….  

In that piece, we couldn't help drawing parallels between the new DDS Designer and the CODE Designer. We're extending that discussion here and inviting your participation.

Neither of us are big fans of SDA and we pretty much considered RLU hopeless. CODE Designer, while far from perfect, has been our DDS designer of choice for many years. When the integrated Screen Designer came out as a Technology Preview, we spent some time with it. But since it wasn't recommended for production work, we didn't teach it in any detail in our private RSE classes 

Now that the new designer is officially supported, we're beginning to teach it, and in doing so, running into the inevitable comparisons with what came before--for us and for many of our students who are/were CODE Designer users as well. Which do we like better? That's not an easy answer. There are some really nice new features in the new one, but at the same time, we miss some of CODE's features.

First of all, the new designer is space hungry; it seems to work best with a large monitor. Since we spend so much time working on a laptop screen, this gets frustrating. The new designer makes extensive use of an expanded Properties view, much like the properties notebook we used in CODE. We could make the properties view a fast view or detach it, which would feel more like opening the CODE properties dialog. The difference is CODE had many of the most-used properties integrated at the top of the design screen (i.e., name, data type, length, row/column, color, display attributes, etc.) so we didn't need to use the properties dialog as often. With the new designer, the properties view is the most obvious place to change these things, so after dropping a named field onto the design screen, we want to use properties to change the field's name, data type, etc. and we need to use multiple tabs on the properties view to get to things like display attributes and color. This isn’t a big deal if you have a large monitor available, but it’s an irritant compared to the ease of adding new fields with CODE.

On the other hand, one option for changing those things that’s quite feasible with the new designer is to click on the source tab and directly edit the DDS source. The changes are immediately reflected on the properties view and the outline view and, best of all, you can quickly flip back over to the design view to do additional work. The ease and speed with which we can flip back and forth between graphical design mode and raw DDS-edit mode is miles ahead of CODE. Yes, you could do it in CODE, but it was slow and painful, so we rarely did it.

There are a few irritants in the new designer, such as the inability to key static text on the screen directly. You must first select an item from the palette and then change its contents. This isn't horrible, but seems unnecessarily cumbersome compared to what we did with CODE. Similarly, to lasso multiple items on the screen, you must first select the marquee tool from the palette. Why? This is particularly frustrating when you lassoed them to move them and you must manually switch back to the other tool from the palette to move the lassoed items. Not show-stoppers, by any means, but irritating to those of us who used CODE.

On the other hand (again), with the new designer (in its latest incarnation, not in some of the earlier technology preview versions) you may use the graphical designer to design a single record format. You’re not forced to put it into a group (CODE term) or a screen (new designer term). The concept of a group/screen is great for those occasions when you need it, but much of the time, working with record formats is all that’s necessary. You do seem to be required to create a screen if you want to use the preview faculty, for some reason, which is also where the indicator sets and sample values for screen and report fields can be used.

The use of the field table to drop database reference fields onto a screen is great. Yes, we could do a similar function in CODE, but this one seems a little simpler and makes good use of an existing RSE feature that shows off the integration of the tool set, as does the use of the outline view for navigation, which replaces the "DDS tree view" of the CODE designer.

Other niceties in the new designer include the sliders to adjust the screen-image size and the visibility of the grid lines on the design screen. One of our other favorite features we ran across by chance is the capability to peek at the source code for the selected item on a screen (including an entire record format) by hovering over the name of the item just above the design screen image. The source for the item pops up in a box over the design screen--a very cool feature.

Of course, "undo" is more useful than making and reverting to checkpoints in CODE.
But we find we do miss the capability to distribute a group of fields evenly across a screen.

We could go on with the comparisons, but perhaps we've said enough for one blog post. All in all, we like the new designer, even more than the CODE designer. The very notion that it’s truly integrated with RSE makes a difference and some of the new features are nice. We're hopeful the new one may, over time, re-learn a few of the tricks its ancestor had as time goes on.

We're anticipating comments along the lines of "why are we even devoting time and energy to a DDS screen designer when the world has moved on to browsers and other non-green-screen user interfaces?"  Our reaction to that is some have moved away from green screens at a slower pace than others and why shouldn't maintenance of those applications be as productive as it can be? Maybe they can use the time saved to work on modernization efforts!

If you’ve experienced both designers, help us continue the discussion via the comment section. If you haven't used the new designer yet, take a look at EXTRA when it comes out this week.