More than 10 years ago in early 1999, I built a web-based e-learning system known as a Learning Management System. The program, entitled Educator, enables academic institutions to put their courses and degree programs online.

By today's standards, the program is very antiquated both from a front-end and back-end perspective.

Therefore, over the last few years, I have been planning the follow-up to Educator which I am calling, simply enough, Educator 2.

A Learning Management System is a pretty diverse piece of software. There are myriad features such a system must support that span from content delivery and publishing to assessment and evaluation to communication and collaboration. And today's users of such systems are sophisticated and experienced Internet users. Functionality needs to be as elegant as it is simple and effective. Further, the functionality offered by such systems is, necessarily, becoming increasingly ambitious and moving into the realm of social networking, distributed content aggregation and management, as well as Digital Rights Management, and even further, capabilities well entrenched in the "Web 2.0" and "Web 3.0" realms.

Consequently, it is important to me that Educator 2 emerge as a system that is strong enough such that it won't have to be rebuilt again for at least another 10 (or even 15 years).

One of my own key metrics for success for the program will be the quality of the user experience offered by the application.

The quality of the user experience is somewhat of a subjective discussion, however, there are some very strong and inflexible requirements I have as far as what I want the user experience of Educator 2 to entail as well as its technical implementation details and I'll summarize these general key constraints below:

• The overall application should be comprised of numerous modular applications that can work independently or in conjunction with other applications within a portal-like implementation
• The application must provide the user an easy means of accessing their desktop content and functionality
• The application should be web-based to leverage the convenience, practicality, and ubiquity of a solution delivered via the web browser
• The user interface of the application should be intuitive by extending desktop-like usage paradigms of drag and drop and asynchronous updates of portions of the screen landscape without an entire page refreshing
• There should be as few constraints as possible on the specific technology (AJAX, Flex, Flash, etc.) used to develop the application's individual components (modules/sub-applications)

The selection of the individual technologies to accomplish the above challenges was relatively straightforward and easy for me. I've been programming with Flash since 1998 and Flex since 2005 (each of which can promote rich and interactive interfaces), AIR since 2006 (which can facilitate desktop interactivity), and I have a good deal of AJAX programming experience (which can sometimes promote rich and interactive interfaces without as much overhead or time investment as a Flash or Flex application).

But how I would bring all these technologies together to create the specific implementation I had in mind was not immediately clear. I set out to review many of the major frameworks that were in existence in the middle of 2008. There are some excellent frameworks out there and I spent the better part of 6 months learning the ins and outs of as many of them as possible.

While I found that many of them spoke to many of my core user experience objectives, none of them spoke to all of them.

When I stopped and looked at the design specifications of Educator 2 from a 30,000-foot level, I realized there were a lot of parallels between it and an Operating System paradigm.

My design specifications called for an MDI implementation (Multiple Document Interface), Menu Bar, Application Dock, and a model that would support the implementation of "widgets".

A plethora of out-of-the-box frameworks support all of these attributes but the one glaring exception was a very easy integration point to the desktop (I stress the "very easy" term).

Also, a lot of the frameworks are somewhat tightly coupled to a particular technology as far as building components to run in the individual framework implementation - either AJAX, Flash, Flex, etc. - typically one core technology is involved but rarely the flexibility to use them interchangeably very easily.

This point is a big deal to me. In the design specifications of Educator 2's individual components/sub-applications, there are some cases where HTML/AJAX will clearly be a much better option, whereas in some cases, an ActionScript 3 solution is compulsory. And in these situations, sometimes Flash will be a much better option, and in other cases Flex will be required. Still in other cases, I have legacy code built in ActionScript 2 that I'd rather not have to rewrite yet I'd still like to use. And further, there are some specifications that require access to desktop resources and functionality nested in a sub-application that is delivered in the browser - so in my case, some sort of AIR integration point was obviously crucial.

I took the fact that such a framework didn't exist out of the box as both a challenge and an opportunity and earlier this year, I set out to build the entire framework from bottom to top.

My rationale was that I'd spend 2009 building the framework and 2010 building the Educator 2 application on top of the framework.

I am somewhat ahead of schedule and am already well underway with building the individual Educator 2 applications and sub-applications on top of the framework.

On December 15, 2009, I released the Public Alpha of the Framework I've named the UcompOS Rich Experience Framework (RXF). The project web site is http://blog.ucompass.com and at that site there are a host of resources including AS3 and JavaScript SDK documentation, downloads to the Developers Package (which contains the UcompOS Portal and the SDK), over 90 minutes of video tutorials and numerous other materials to help you learn about the framework and get started exploring it.

I call the applications you create with the UcompOS RXF Rich Portal Applications (RPAs) because I don't think RIA describes what they are completely enough. I do believe, technically, a Rich Portal Application is a portal-like implementation for the management and co-habitation of numerous related or unrelated Rich Internet Applications working discretely or in conjunction with one another to create an overall Rich Experience.

At this juncture, I do not have immediate intentions to monetize the framework itself (Educator 2 however is to indeed be a commercial, for-profit application). My goals for releasing it to the public are to find at least a respectable amount of developers who see value in the framework who would be interested in building their own Rich Portal Applications on top of it while in the process providing me valuable feedback, bug eradication, and suggestions for improvement.

The main player in the implementation of a UcompOS Rich Portal Application is the UcompOS Portal.

The UcompOS Portal is a Flex 4 application that is sometimes referred to as the "Main Container".

The UcompOS Portal provides a number of core attributes including an Application Dock (similar in behavior and presentation to the Mac OS X Application Dock), a Menu Bar, a Multiple Document Interface (a customized implementation of the FlexMDI package in the FlexLib project), and an application run-time.

Applications that run in the UcompOS Portal's run-time are of a type of application called UcompOS Applications.

UcompOS Applications can be based in HTML/JavaScript/CSS, Flash or Flex (ActionScript 3), or AIR 2.0.

In order to make content created with one of these technologies into a UcompOS Application, you simply insert the UcompOS SDK into it.

The SDK for HTML is a JavaScript file that gets implemented in a SCRIPT element in the HTML source code, and, a SWF file that gets placed on the webserver that is serving the HTML source of the application. The SDK for Flash/Flex is a single SWC that can be used interchangeably between Flash and Flex applications as it has no Flex dependencies. The SDK for AIR 2.0 applications is also a single SWC file.

I have chosen to make AIR 2.0 (itself still in Beta at the time of writing) the minimum requirement for the UcompOS AIR SDK to take advantage of AIR 2.0's new ServerSocket class which is used for communication between UcompOS Applications running in the browser and those on the desktop.

User authentication to the UcompOS Portal is extremely flexible and simple to configure. The UcompOS Portal simply relies on the existence of a single encrypted cookie and the authentication can easily be built into the UcompOS Portal interface, or, the user can be authenticated on another page and then refreshed to the UcompOS Portal page.

Once authenticated into the UcompOS Portal, the UcompOS Portal retrieves a Dock Manifest (your authentication process provides the network address of this Dock Manifest resource) which is a simple XML list of the UcompOS Applications available to the authenticated user and these applications can be presented on the application dock or hidden, and the applications can run as background processes that are automatically loaded into the UcompOS run-time upon login.

Each application is associated with an individual UcompOS Application Manifest - which is a simple XML document. The Dock Manifest articulates the network addresses (URLs) of the Application Manifests of the individual UcompOS Applications.

The Application Manifest articulates things such as the application icon that the UcompOS Portal should use to represent the application on the application dock as well as on application windows, and the title of the application, as well as the location of the application's core source code. The titles, tooltips, and icons can be localized such that you can easily configure a language chooser which will dispatch an event to the UcompOS Portal instructing it to display a particular localized title or icon.

You can further customize other things in the manifest such as the Menu Bar options to show when the application is in focus as well as the context menus to present on the application dock for the application in scope.

UcompOS Applications have the UcompOS SDK implemented and the SDK has a number of classes in it called Proxy Components that let you exert activities on the UcompOS Portal.

For instance, as a simple example, if in your application you wanted to create an MDI window with the Google Website loaded into it, you could so something similar to this:

var w:UcompOSWindowProxy = new UcompOSWindowProxy();
w.add("http://www.google.com","Google Website",800,600,100,100);

Which would create an MDI window with the Google Website loaded into it of dimensions 800 x 600 positioned at 100,100 relative to the upper left origin point of the UcompOS Portal.

Applications can also create UcompOS Artifacts on the UcompOS Portal which can be thought of as analogous to desktop widgets.

Further, the UcompOS Portal can launch satellite browser windows as well.

All the content launched by the UcompOS Portal - UcompOS (MDI) Windows, UcompOS Artifacts, and UcompOS Browser Windows can be content that itself has the UcompOS SDK installed into it which means it can communicate with any other entity in the UcompOS Continuum (the UcompOS Continuum is the term used to collectively refer to the UcompOS Portal, and all applications and sub-applications it has launched or that have been loaded into its run-time).

Each entity that has the UcompOS SDK installed can expose functionality to other entities by describing the functionality as Public API Methods in a Services Dictionary.

Then other entities can target the Public API Methods in other entities by implementing a Proxy Component, which is a sort of client interface to an API method housed in another entity.

If all this sounds complex, it is at your first introduction to it, but with experience the alpha testers I have been working with have taken to it very quickly and comfortably. The UcompOS RXF enables a true Rich Portal experience that bridges the desktop and the browser and allows a variety of technologies to be used simultaneously to foster a single, seamless rich experience between multiple applications. If you don't have a need for the sorts of challenges the UcompOS RXF exists, it is likely to be of little or no use to you though you may still find it interesting to explore and analyze.

I am committed to providing leadership and assistance to those interested in building great Rich Portal Application experiences with the UcompOS RXF and, as indicated, I've set up a project site with a host of resources at http://blog.ucompass.com and encourage you to take a look at it to learn more.

I'll add that there is a project SVN repository that you can use to check the SDK source code out of to review. At this juncture, I have decided not to make the source code of the UcompOS Portal available, however, in the Developers Package, all the client-side code for the UcompOS Portal (SWF, CSS, HTML, JavaScript) is available such that you can host your full UcompOS implementation from your own webserver.

I am making detailed daily blog postings discussing intimate details of the framework, and each Sunday, I am publishing a new video tutorial that looks at how to accomplish a specific task with the UcompOS RXF.

Read more from Edward Mansouri.