Thursday, May 10, 2012

Full of CRUD

Joel Kallman has an interesting and amusing reaction to a recent Gartner paper authored by Mark Driver posted here.  After reading Joel's reply and Mark's paper, it got me thinking a bit about what was both in and not in the Gartner review and conclusions regarding Oracle Forms migration paths.

But before that, let's consider the longevity of Oracle Forms.  Oracle has pledged support for Forms time and time again, and despite the negative stigma that Forms usually drags along with it about being an older technology, it's a perfectly good place to leave any existing applications and perhaps even build a few new ones.  Thus, if you have no immediate need to urge to migrate, then simply don't do it.  In fact, a new version of Oracle Forms - 12c - is already in development and will integrate with Fusion Middleware 12c.

If you're a Forms customer and for whatever reason want out, there's a number of different options that you can take, all of which are highlighted in the paper:

  1. Migrate to Oracle ADF
  2. Migrate to Oracle APEX
  3. Migrate to a non-Oracle platform

I'm going to ignore the third option - not because it's not a viable one, but my point lies elsewhere.

Given that exclusion, which works best as a Forms migration platform - ADF or APEX?  

In the paper, Driver makes a very clear case for ADF over APEX.  He considers APEX a tool targeted at "citizen developers" and considers it "less suited for elements of Oracle Forms applications with more complex business logic requirements".  He also states that APEX has "very limited support for advanced software development life cycle (SDLC) and application life cycle management (ALM) feature and best practices (e.g., no team support and no direct source code versioning).".

Five years ago, I may be tempted to agree with some or part of that.  But clearly not today.  APEX 4.1 is a major upgrade from what was available in versions 3.2 and prior.  While it definitely excels at building small, "quick hit" type applications, all - not some - but each and every one of our clients are also using APEX for mission critical and essential systems on a daily basis; Applications that drive their primary business operations, whether those are academic, commercial or governmental in nature.  

Since 4.0, APEX has incorporated a "Team Development" module, aimed at facilitating the development, bug tracking and release process of APEX applications.  The APEX team at Oracle actually uses this tool to track the development of APEX itself.  APEX can also work quite well with any source code control system, although not directly.  But since most developers put their business rules in PL/SQL, that tends not to be an issue, as all popular PL/SQL IDEs have direct integration with source code control.

While those misstated facts are bothersome, I don't believe they are intentional.  I can easily get past them, as we all make mistakes from time to time.  What I have a harder time accepting are the misleading statements in the following excerpt:

Select a migration target platform carefully. We believe the least risky (and often the least costly) migration path forward from Oracle Forms is Oracle's JDeveloper IDE and ADF — especially for application leaders who plan to retain their existing programming staff.

Now I have taught countless APEX training classes and have talked to many, many Oracle customers over my 15+ years of working with Oracle products.  Never have I ever heard a single person highlight how much easier Java is than APEX.  Some put APEX on par with ADF, and others think that ADF as a whole is better suited for enterprise development, and I can't say that I disagree with those assessments.  Clearly there is some bias in my sample, but the most vocal of the group were those who were professional developers, not "citizen developers".

As for costs, I'd like to see some figures or numbers behind that argument.  Not only is there the possibility of saving some license costs by moving to APEX, but many of our customers actually save on consulting costs by being able to take full ownership of the applications once we deliver them.  They don't need to hire consultants to continue to maintain their applications, as they almost always learn how to do that themselves, either from training or their own experience with APEX.

Unless Driver advocates firing your existing staff and starting anew with fresh college graduates for about half the salary, I don't see what basis he is using for his point about retaining programming staff.  Allow me to be blunt for a moment: most Oracle Forms developers know PL/SQL and the Oracle Database very well.  Given the age of Oracle Forms, most Forms developers are closer to retirement than they are their first day on the job.  What type of developer is willing to forego 20+ years of experience in any technology and start fresh learning another technology 3/4 of the way through their career?

The key factor that was largely ignored in this and so many other migration papers is simple: people.

APEX gives developers a new lease on life, so to speak.  It gives the PL/SQL developer a chance to once again shine by building web-based applications that their customers will not only love, but want to use.  It keeps resources in place with minimal training, and also preserves the years and countless dollars invested in the PL/SQL packages that have been finely tuned over the years.

Java - much like any other programming language - takes years to master.  I have tremendous respect for those who have done so. Experts are not made overnight, they are crafted over many, many years of experience.  No book or class can substitute for that.  Driver's advice assumes that a PL/SQL programmer is the same as a Java programmer, or at least a PL/SQL programmer can easily be made into a Java programmer with a couple weeks of training and a good book.  This assumption is just plain wrong, and almost fatally damages his justifications against APEX as a viable Oracle Forms alternative.

My advice when choosing a platform to migrate Oracle Forms to: take a long, hard look at your developers, and note where their talents are.  Ask them if they think that given some time and training if they would be able to continue to maintain applications in another technology at the same level they do today.  If they believe that this is possible, then consider that alternative technology - be it Java, .NET or something else entirely.  But if they believe that their talents are in PL/SQL and the Oracle Database - and you'll likely have the investment by way of PL/SQL-based business logic to prove it - then you owe it to yourself to take an equally long, hard look as APEX as a viable platform to replace Oracle Forms.

APEX UI Lessons - Part II

As soon as I posted this entry yesterday, I thought of a few additional "rules" that probably should have been included.  Pitor's comment also spurred on an additional rule.  So without further adieu, here they are:


Learn 'em and stick to 'em.  Period!  Most modern browsers do pretty well with them, so the closer you are to them, the better off your site will be in the long run.  

Ignore Old Browsers When Possible

Take a page from the Apple playbook here, and simply stop supporting browsers that are too old, despite the fact that they may still be in use.  (I'm looking at you IE 6 & 7…)  Be careful with this one, as you may have no choice but to support some of the older browsers, based on your customers or potential customers.  We wanted to be sure to provide support for at least IE 7 and above, and that decision did add some time and effort to our design process.  We did this because some of our existing and potential customers - at least for the short term - are running IE 7.  Not having support meant not having customers, so the decision was quite simple.

On the other hand, not for a single second did we consider supporting IE 6.  At the beginning of the development cycle, we did have a couple of prospects on IE 6, but we took a gamble that by the time we were production, they would be on at least IE 7.  That gamble paid off, and we saved countless hours by avoiding IE 6.

Identical Look & Feel Across Browsers in Unachievable

This is another rule to address up front to save a lot of time later. Your application will look a little different on IE than it will on Firefox or Chrome or Opera.  And that's OK.  In fact, it's unavoidable.  Throw in the way that the Mac renders and smooths fonts vs. how Windows or Linux does it, and you'll have even more differences.

Thus, making the site look similar across browsers is a more achievable goal than striving for perfection.  Unlike most developers, most users are are "single-browser" users, so they will never know the difference at all.

When in Doubt, Hire Someone

Either you're a graphic designer, or you're not.  If you're somewhere in between the two, then it will take your users about 2 seconds to realize that.  Thus, know your limitations.  There's plenty of free or low cost templates that you can use, and a decent graphic designer also won't set you back too much.  At the end of the day, the way your application looks and feels is critical, and will make a lasting impression on your users and potential customers.  Don't cut corners here and don't be afraid to seek assistance from a professional.

Wednesday, May 09, 2012

APEX UI Lessons

There's something to be said for corporate standards for browsers. Sure, it's almost always some flavor of IE, but at least you're only charged with making sure that your application runs and looks good on one browser on a single OS.

 However, when designing a product, you simply don't have that luxury anymore. Your application must now not only run but look good on all popular versions of popular browsers: MSIE, Chrome, Firefox and maybe even Safari. And if you think that these browsers behave exactly the same on different operating systems, you're completely wrong.

As we put the final touches on sumnevaSERT v2.0, I wanted to share some of the experiences that I went through over the past few months with regards to user interface - mostly so that you can learn from my mistakes and plan accordingly.

Design and stick with a Design Pattern

This is the most important step. If you skip it, or do it poorly, it will flow throughout your entire project and come back to haunt you on a daily basis.

Simply put, a design pattern is how different components will be laid out on the page. It's OK and quite often that you have two or three variations of this (one-level tab vs. two-level tab, sidebar vs. no sidebar, etc.).

Once a design pattern is defined, do all that you can to not stray from it. If you designed the HTML & CSS to work with 2 columns of reports, then stick to that. APEX templates are flexible to a point. Once you cross that point, not only do your applications start to look "busted", but issues with usability will start to arise on at least one of the browsers.

It helps tremendously to use a tool such as Balsamic Mockups to come up with a design pattern for your site.

Design and test the Templates first

Once you have a design pattern, it's time to convert that to APEX templates. While this is also one of the most important pieces of advice, it's also the one that you will undoubtedly fail on. It's 100% impossible to get this all done up front, so set your expectations accordingly. However, if you can get some portions of the templates done before you start adding content, that will go a long way later on. 

While designing your templates, keep the HTML as clean as possible - do not use any inline styles or other tags that could be interpreted differently by different browsers.

Also, I usually start with a clean Theme, and only use the APEX provided templates as a guide. There is no application out there that needs all 75+ templates that the APEX themes provide. Thus, I typically start with a brand new theme and build that up as needed.

Another trick that I have used forever is how I name my templates. APEX template names are too specific - "Form" region, "Report" region, and "Chart" region all look the same to me - and they should! Thus, I create a single region called "Content Region", and use that for all content - Forms, reports, charts, trees, etc. If I need a second region, it's likely going to be called something like "Content Region - Narrow" - and as the name implies, will be narrow. This small change will go a long way in keeping the templates as usable and compact as possible.

Start your cross-browser testing NOW

Don't wait until you more than a few days into development to start testing on different browsers. In fact, delegate a different browser for each day of the week for both development and testing to ensure that your application works well in all of them.

My advice: make Friday "IE day", as happy hour will never be happier.

Two (or more) CSS files

Critical when supporting most browsers and IE, you'll need to have at least two CSS files. I can't imagine putting all CSS classes into a single one and having all browsers play nice with it. You can start out with a single one, and when you hit a point where you'll have to clone it, at least you'll have a good solid base.

If you use a STYLE tag, you will pay

Don't use a STYLE tag. Can't emphasize this enough. It will come back to haunt you, as one browser will be OK with it, and others (i.e. IE) won't. At that point, you'll have to retro-fit your HTML to use classes, add them to both files, and re-test.

You'll be most likely tempted to do this when rendering HTML from PL/SQL, as if you use a STYLE tag, you don't have to open up another application to add the class, etc. Don't be lazy.

Images and CSS Files

We chose to store all images in the database, as it makes for a much easier installation. Unfortunately, even if you store the CSS file in the database as well, you can't reference the location of the images in the file, as APEX has to include some internal IDs in the link. Thus, we had to create a region on page 0 that augments the class definitions that have images. If you use a simple HTML region for this, you can include the tag #APP_IMAGES# or #WORKSPACE_IMAGES#, and they will resolve correctly.

Conclusion: Keep It Simple and Consistent

Never stray from this. EVER. The more complex you make your UI, the less your users will like it and the harder it will be to maintain. Sacrifice complexity for simplicity and consistency. Think of the web sites that you use on a daily basis and then look at their design and how simple and easy to use it is, and try to imitate that.