OpenEdge Architect adoption "challenges"?

I might note that you have stated this poll entirely in the negative, i.e., "are there problems with OEA which are preventing you from adopting it?" What this misses is the other side of the coin, i.e., "Do you have a tool which you like better than OEA such that your barrier to moving to OEA is the superiority of this other tool?" There are a number of ways in which ED4W with appropriate extensions is a better editor than OEA. Other than the fact that my current direction gives me an incentive to specifically use OEA, I would be strongly inclined to stick with ED4W, not because of the problems with OEA, but simply because it is a better editor in many ways.

Hi Thomas,

I believe we had quite a bit of discussion of that kind in the "favorite missing editor feature" thread in this forum.

Mike

Indeed, and given that the two threads are right next to each other at the moment, it makes for an interesting juxtaposition.

Suffice it to say that, if one wants to increase the adoption of OEA, then one has to:

1) remove obstacles;

2) improve to create parity with other options; and

3) create compelling advantages.

All are needed to induce people to switch.

Thanks for your feedback on this issue. The results posted here are consistent with other feedback we have recieved from users, and we'll incorporate this into our OpenEdge plans.

Jim

Poll Results: OE Architect adoption "challenges"? (see description in the thread)

Have not seen these issues - full speed ahead: 3 (60.0%)

Little experience with these issues - minor impact: 0 (0.0%)

Some experience with these issues - will slow Architect adoption: 2 (40.0%)

Often experience these issues - Architect adoption is not possible: 0 (0.0%)

Total: 5

Of course, 5 responses doesn't make for much of a survey...

One might suggest that there are at least four levels of reason for such a low response.

The first level, of course, is simply that people are often not very good at responding to surveys, especially if they are a bit fuzzy about the issues. I would suspect that there was a pretty large percentage of the people who read this particular forum who are a bit fuzzy on the issues you have raised.

The second level is that a poll on a forum about OEA is likely only to be read by people using OEA, so someone who has decided not to use OEA isn't even seeing the poll.

The third level is that a lot of people reading PSDN aren't yet on 10.1, so it is a non-question. They are only reading this forum if they are curious and hoping to get there, but the ones locked into 8.3 or whatever are probably unaware and uninterested in the question.

The fourth level is that the traffic on PSDN is such a small percentage of the overall OpenEdge community.

The second level is that a poll on a forum about OEA

is likely only to be read by people using OEA, so

someone who has decided not to use OEA isn't even

seeing the poll.

I absolutely agree to this statement!

But since there are a few more people active in this forum (just have a quick look on the names that opened a thread) I would have expected some additional responses.

Not sure if we should take the low participation as a "yes I'm satisfied with OEA" or a "I don't understand the question" or "I'm not interested in sharing my opinion to make things a little better".

It is notoriously hard to get people to respond to surveys of any kind and, unless one is quite rigorous, it is very easy to end up with a biased sample because those who do respond do so for some reason that makes them less than typical of the population that one is trying to survey. When one only gets five responses, the results are statistically meaningless, regardless of how the survey was designed and with all the biases and exclusions which occur in a setup like this it is really meaningless.

But, what to do?

My guess in this case is that a lot of the people who even saw the poll didn't have well defined opinions and/or weren't entirely clear on the question. That translates into an automatic non-response. Add in a bit of can't be bothered and one doesn't get much.

I've posted this under an OEA "first impressions" - the issue I'm having right now is simply configuring colors. A bunch of the characters are defined as being black, but since I want a black background, they can't be seen.

and I can't find any color configuration which corresponds to these chars in order to fix the problem and make them visible again.

My first impression, obtained several times now is:

OMG! What is all this crap churning up my CPU and taking over my screen?

Why can't I just open an existing .p and do something useful right away? Why do I have to even think about "projects" blah, blah, blah...

What was i thinking? This was obviously a mistake -- I'll just uninstall this and go back to good old (micro)Emacs. Call me when it is usable.

I like the idea of OEA. It looks great in demos. It is truly tempting. But I've had the reaction above every time I've tried to use it... all that I want to do is to edit some code and tip-toe into using the neat tools that I keep seeing. But the mountain that I have to climb to do even the simplest things is just ridiculous. No thanks, I don't need it that badly.

You're just sore because there isn't a ChUI version!

I think your expectation is unreasonable. What you want is to be able to start with just another editor and somehow grow from there. But, I don't think you get an integrated tool set that way. Frankly, setup is not that difficult ... it just needs some better documentation and perhaps a setup wizard to prime the pump.

Hey Tom! How long did it take you to get used to emacs? It's always hard to compare the (CHUI) tool you fly blind with a new toolset on a new platform.

Give it a chance!

I'm just reporting my experiences regarding adoption challenges... I've tried it. At least 3 times and found it to be a waste of energy, disk space and computing capacity all three times.

Maybe there needs to be an adoption kit for dinosaurs or some such but what is there now has not, so far, convinced me that this is a useful tool.

Emacs took me about 10 milliseconds to get used to and to use effectively. It took a couple of days to figure out how to migrate all of my EDT macros (the old VAX/VMS editor) but I could use it to do useful stuff right away. I started life with "sos"

When I'm stuck on Windows I prefer Wordpad to the Progress editor or OEA. It doesn't screw up my code and try to "help" me with stuff that I don't want it doing.

Vi is somewhere in the middle between emacs & OEA. It has taken years to get beyond "hunt & peck" with that piece of crap excuse for an editor ("ed" is better). But it is often the only choice (until I can get emacs ported) so I've reluctantly learned to deal with it.

Anyhow... the thread is about 'adoption "challenges"' and these are mine

I was impressed at Exchange this year by all that Architect could do, so we committed to make the switch by year's end. We're on 10.1C and have gotten past some major issues with CPU usage and the editing of large programs.

The only major hurdle at this point is that I can't configure my environment to automatically open the appBuilder for .w code. My co-worker has apparently the same settings (we spent about an hour comparing them one by one) and has no problem, but I can't do it. I've also followed the instructions in the Knowledge Base, etc. So I have to keep switching back and forth, and once I go to appBuilder I tend to stay in it for the rest of the day because I'm more comfortable with it ...

We do miss the outline view (is that the term?) in appBuilder which eliminated the need to see a bunch of pre-processor code and made it easy to tell when you had reached the end of an internal procedure.

Anne Disney

Great Valley Technologies

There is a new view in 10.2A (not available in 10.1C) that allows you to see the code with the pre-processors resolved. When in the OpenEdge Editor the Preprocessor view can be opened from Windows > Show View > Preprocessor, or from the context menu by selecting Show In > Preprocessor. The view is read only. However, if you wanted to have full editor capabilities, using a new file, you can select all of the code, Ctrl-A, and then copy it into a new program file.

If the functionality is not working as you expect to open AppBuilder then I recommend that you report the issue to PSC Technical Support.

FWIW...

With Mike's help I have overcome my initial issues with OEA and I am now productive, if not exactly comfortable, using it. I haven't used WordPad on a Progress program for almost 2 weeks now

Thanks Mike!

No WordPad, but what about vi?

I only use vi when emacs isn't handy... Frankly I think WordPad is a better coding editor than vi

Anyhow, once you shut off as many of the distracting and supposedly "helpful" features of OEA as you can find like syntax completion, code coloring, capitalization and so forth it isn't so bad. Eventually I hope to dig into the templates that it uses to populate new modules and fix those too. For now I just erase the cursed things when they get inserted.

It would be nice if it had reasonable printing support though. The huge headers, footers and margins are definitely not what I want on a code printout.

I guess this proves that even dinosaurs are trainable, if one takes enough effort!

didn't dinosaurs evolve into birds ? Fast, agile, like the sparrow and the , erm ... albatross ... dammit

He He! It hasn't been that hard.

In fact it was a lot of fun!

Care to elaborate on the OEA usability mods?

I am still in the wordpad/vi phase I'm afraid...

Edit: @JLS L L!

Well, some of them evolved ...

So, Mike, perhaps you should do an "OEA for Dinosaurs" book?

If you give me the time to do it...

Take all the time you want ...

Actually, I expect there might be some demand for a comprehensive OEA book, i.e., a combination of how to turn things off for people who liked things simple and how to turn things on for those who wanted fancier stuff. There are a few whitepapers on the later part that would be a good starting point. Could be more than one author, of course.

Since this thread is still active, I thought I'd post a few thoughts.

We decided to make the switch to Architect. The primary driver was that we want to begin using the new .net UI. We have upgraded our dev environment to 10.2a and are now about 2 weeks into the use of Architect.

As a little background, we've been using the AppBuilder for many years now. Much of our code is appbuilder .Ws and structured procedures. We also use RoundTable.

As a shared development environment, RoundTable was extremely effective in creating our initial working environment. It took care of deciding where to store files etc. so this was not a challenge. I suspect that for many, deciding how to implement a shared dev environment could be daunting.

Now to some challenges.

Editing .Ws in the Architect AppBuilder is doable but has certain problems, most of which we've been able to work around.

The first, and most challenging, was working with freeform browses. Without the section editor, these was no obvious way to change code that we previously would have edited using the pseudo open-query trigger in the AppBuilder. Our first attempts were met with extreme frustration as the AppBuilder basically trashed any changes we made, generated faulty code when adding widgets and other, seemingly intractable problems. We found a kbase (P114930) discussing this that basically said "you can't do this, go back to using the old appbuilder". Fortunately the kbase is wrong. The trick is to edit the comments between the STARTFREEFORM and ENDFREEFORM lines. This does the exact same thing as editing the open-query trigger in the AppBuilder.

Function definitions are easily edited but unlike the section editor, the generated forward declarations need to be edited independently. Not a big problem and one that can be easily dealt with.

I'm not sure if this is a RoundTable or Architect problem but opening a .w read-only (not checked out) will not open it in the AppBuilder. Very annoying when you just want to look at an existing window.

Other annoyances

The procedure editor buttons opens with the current procedure code. It should open up blank. If I already have the code open in the Eclipse Editor, why would I want to open it in another editor? At the very least there should be an option for a blank procedure window. The opposite is true for the AppBuilder button, this always opens an empty AppBuilder.

The help system, especially for ABL Reference, is extremely slow to open. The CHM help was so much faster and easier to use.

The editor is kind of dumb in a few places. The auto parentheses should be smart enough to go around what I'm doing. IOW, when I type "string(", I'd like the close to be after the next expression if there is one.

When I type "if do:" I don't want auto-complete yet when I type "buffer-field:" I do. I had to turn it off as I got tired of having to erase something every time I started a block.

Bugs

I had hoped that having waited through a couple of years worth of upgrades, that Architect would be pretty reliable. Unfortunately that doesn't seem to be the case. The "Restart Architect" button has become my friend. The problems are not repeatable but, when in doubt, restart. Usually the problem goes away. Of course, the AppBuilder wasn't any better in this regard.

Among the problems that won't go away with a restart are that certain programs will not display an outline. The first two found were new bugs, there were work-arounds that required minor modifications to the code but not in pre-processor or other previously known manners. The last two were reported yesterday and I don't yet know the outcome. This is very disconcerting as without an outline view, the use of this tool is severely limited. What's worse is that this appears to be never ending. Whenever I open a program never before edited in Architect I don't know if I'll actually be able to continue editing or if it'll be time to contact TS again.

So overall, we're surviving. It's been a bit difficult but while there was certainly a productivity loss during the transition, we're now doing pretty well. Only one developer threw up their hands and went back to AppBuilder for a while. This was primarily over the freeform issue above.

There are certainly many good things about Archtect/Eclipse so don't take the above as an indictment. I'm glad we've made the shift.

Tom

Other annoyances

The procedure editor buttons opens with the current

procedure code. It should open up blank. If I already

have the code open in the Eclipse Editor, why would I

want to open it in another editor? At the very least

there should be an option for a blank procedure

window. The opposite is true for the AppBuilder

button, this always opens an empty AppBuilder.

This is one of the things that I really like! From time to time, I use this when I prefer the old way of "Check syntax". Also this is a very effective way of jumping into the old CHM help file. A choice may be a wise option. I kind of got used to Shift-F3 to clear the editor contents...

The help system, especially for ABL Reference, is

extremely slow to open. The CHM help was so much

faster and easier to use.

See above.

Care to elaborate on the OEA usability mods?

I am still in the wordpad/vi phase I'm afraid...

I think that this is most of what I did to make it usable:

1) Turn off color syntax highlighting -- I've since turned it back on but, initially, it was a huge distraction to have the screen constantly flickering and flashing for no good reason. To turn it off:

Window -> Preferences -> OpenEdge Architect -> Editor -> Colors

And then just make them all black. Turn it back on by using the "restore defaults" button.

2) While you're in the neighborhood go into "Assistance" and shut off all that crap too.

3) On the "Editor" preferences set the # of spaces to something reasonable like "2", change the casing to "lower" (or "none") and uncheck everything from "as you type" down.

Additionally I would love to have the time to fix all of the templates. The code that this thing automatically generates is hideous. Although I must admit it is quite a lot better than the app builder and it takes much less time to remove all the ridiculous comments so, so far, I haven't gone down that path.

It also helps, a lot, to be using a dual monitor desktop setup. I've got 2 24" monitors on my desk rotated to be 1200x1920. This is much better than tryiong to use OEA on my laptop OEA fills the screen on right and the left hand screen is for running the application, popping open the Progress help, running a browser etc. Having OEA in a "portrait" window like that this gives me a full page of 85 lines by 132 columns of program code just like I would see on a printout (OEA printing is a weak point -- it insists on wasting half the page with ridiculous margins, headers and footers; so I select all, copy, paste into a putty window and then print from a linux session... which is a completely awful way to do things.) Anyhow, you get a full page of code plus a reasonable amount left over on the bottom for the "problems" or "class browser" windows and so forth.

While I'm on the topic... The class browser would be more useful if it tracked the history of your browsing -- I often start with a class, click on a property, click on that class and so forth 3 or 4 deep and then wish that I could just cut & paste that chain back into my code. It can be confusing to remember all the intermediate steps along the way to the property that I need. Some sort of "breadcrumb" thing would be helpful. The Ultra controls have gazillions of options and it's a real pain making sense of them. The documentation is pretty "sparse" too. Very few of them have anything beyond a basic name.