The Hemingway Approach

Hemingway is a multi-tier content management system. It was originally built using MS SQL Server, ASP, COM and a variety of custom C components. The main interface to Hemingway was through a browser.

Originally, building a client application to interface with the server-side components of Hemingway was thought to be a too lengthy and expensive proposition. After working with Revolution, Altuit decided it could be done in a cost and time effective manner-- by prototyping the interface, then hooking it up one piece at a time.

User Experience

The quality of user experience including ease-of-use and speed is increased significantly by using a client application rather than a browser interface. Now round-trips to the server involve only a few K of significant data, instead of having to pull down another new web page of HTML. Plus, control over what the user can do and see is enhanced by using a client app versus a browser-based app.

By embedding some of the error-checking and other business logic in the client, we can also save traffic on our server. For instance, the status of certain form controls is based on other control selections made elsewhere. One can imagine how difficult this is for a web-based application, but can be easily handled in a client application.

Also, because HemPC (the client) is 'stateless' (unlike the 'stateful' web application), sessions never time out. So a user can have HemPC open on their desktop for as long as they wish. In addition, users can have multiple versions open simultaneously as well-- which, cannot be done with the browser application. Having a 'stateless' application has the added benefit of allowing the server architecture to scale easily.

Recently, Altuit has been asked to port HemPC (the Revolution Hemingway PC client application) to the Mac. We've estimated this to take about 60 hours-- including all relevent plugins. This is another significant advantage of Revolution: it's ability to develop for multiple OS's (including Linux, too.)

Development

Of course, one of the main strengths of Revolution is the speed at which products can be developed with. Case in point: The first working version of Hemingway (albeit without the many plugin features it's known for) was completed in a week-- and worked with the existing server architecture with little rewrite on the server-side.

An advantage to this approach is Revolution's ability to modularize code as plugins. Hemingway's architecture involves a single small 'splashscreeen' application which when launched, checks for updates to the main app. If either a new version of the splashscreen or main app is available, it is then automatically downloaded and installed.

When users access any of the dozen-plus plugins, the version is checked against the latest on a server and if necessary the user is prompted to automatically download the new version. This architecture allows for the dynamic growth of both the functionality and user interface of Hemingway, while also keeping users up-to-date with the latest versions.

Plugins

Here are some descriptions of a few of the many plugins for Hemingway:

ImageGadget
An image generator/editor with screen capture capabilities. It supports multiple layers, text, blurred drop shadows and hilites as well as a number of special effects. All written in native Revolution Transcript.

HTMLBuilder
A simple WYSIWG HTML editor, with support for tables, font settings, links, and more.

FormBuilder
An automated FORM generator using a wizard-like interface.

HTMLtoPDF
An advanced plugin which can render a PDF file from a set of Hemingway generated web pages.

File Manager
An 'FTP-like' tool for uploading and deleting files to and from a Hemingway website. Uses the more secure HTTP protocol instead of FTP.

Share Manager
A plugin which allows users to designate parts of their websites to share with other Hemingway users

PayPal wizard
A form-based solution for adding quick e-commerce capabilites to a website

Why Multi-Tier?

Revolution has excellent 2-tier (client-server) capabilites with database connectors to the majority of DB servers available. So, why would Altuit choose a multi-tier approach?

We've been developing multi-tier web applications for awhile, using both MS (Microsoft) and LAMP (Linux, Apache, MySQL and PHP). There are a number of reasons we choose to use multi-tier:

1) It's very easy to segment parts of the application workload. In multi-tier, we have the bulk of the business logic on the server, with the client taking care of the user experience. In 2-tier (client-server) the majority of the business logic stays with the client.

2) Because the business logic is on the server, we can also create web services (SOAP or other) to interface our web application with future applications, servers, and clients. This is a very valuable option and we use it frequently.

3) It's easier for us to debug. We can test both the server and the client separately.

4) It allows our clients (and ourselves) more options for a given application. If needed, a browser interface can be constructed at a later date.

5) We can do server-side management tasks by having a middle-tier on the server. This enables us to upload files, move and delete files on the server, and build html pages on the fly. This is impossible using a classic client-DB server architecture. Also, Revolution has excellent internet connectivity capabilities, including the ability to do multi-part form posting (posting of binary data via HTTP).