By guest author Ritchie Macefield...

Abstract

Amongst other things, the bursting of the dot.com bubble signalled a reassertion of the principle that only businesses who have a good customer proposition can succeed in the long term. Simply offering products and services on-line via the web is no substitute for a sound 'go to market' model. Further, this paper demonstrates how many would be e-businesses, seduced by the lure of the emerging 'virtual-world' on the web, have ignored 40 years of accumulated wisdom in how to design usable information systems, and have seemingly forgotten that a satisfying 'user experience' is key to the successful implementation of any information system, particularly one in that operates in the public domain. The paper uses the allegorical experience of a 'real' user to provide some powerful insights into how, and by what rationales, the e-marketeers, graphic designers, web designers and programmers responsible for many B2C sites are creating user experiences on the web that are confusing, frustrating and time consuming. Having explained the main problem areas, it goes on to explain why 'clicks and mortar' companies may be better placed to exploit the web than many pure e-tailers, not just because of their business experience, brand identity and multi-channel capability, but because they retain a focus on the importance of user-centred thinking.

Download the whole paper [PDF]

From the Proceedings of ForUse2003, here is the paper I co-presented at the conference.

"Lean Interaction Design and Implementation: Using Statecharts with Feature Driven Development"

Abstract

Lean UI development in Feature Driven Development is achieved through right-first-time implementation of the interaction designer's intent using David Harel's Statechart notation to model the interaction design. Statechart notation can be directly mapped to an MVC Type-II architecture and Mediator Pattern. With a few minor extensions Statechart notation can be used to model complex application behavior such as exception handling and transactions. Statecharts can be mapped into UI Features for tracking using an FDD Knowledge Base. The Statechart can be drawn using a UML modeling tool, and imported into the JStateMachine engine which implements a table driven Mediator and Command pattern system in either a Web Servlet or JFC (Swing) environment. The result is reduced variation in UI development and precise implementation of the interaction designer’s intent. JStateMachine (an application framework) validates the runtime code against the original interaction model insuring accurate runtime implementation of the UI design.

[Download in PDF]

This is the long awaited third part in the series of articles describing a generic server-side architecture for transactional eCommerce websites, using a Model View Controller architecture or Mediator Pattern [Gamma 95] configuration.

Part 1, outlined the architecture to be used to handle the event driven nature of an http request - html response, server to client system, and detailed how to deliver this in a 3 tiered model of Presentation Layer, Business Layer and Persistence Layer. The Presentation Layer is modeled using UML Statecharts [Horrocks 98] which lend themselves to easy implementation using Mediator Pattern which provides the View and Controller elements of the MVC model.

Part 2, explained how to implement the infrastructure to run the MVC model using UML Class Diagrams, Statecharts and Java code to process and respond to http request events.

In Part 3, we look at how all this hard work developing infrastructure can be made to pay off and deliver real advantages. We look at how to protect the system from unexpected browser (client-side) events or activities such as refresh, back, and bookmarks. We will see that this can be achieved with a single piece of code to manage all of this activity.

We will also see how Statecharts can be used to cleanly model the boundaries of logical transactions and how the MVC engine can be used to provide protection of these transaction boundaries (transaction isolation [Gray 93]) and scoping using a single piece of code.

Finally we will look at how exceptions to normal operation can be cleanly handled and implemented within the same system.

Handling Statecharts Generically

With interaction architecture documented using a UML  Statechart, it is possible to simply develop a hard coded solution where one HTML page invokes another. Event transitions would be hard coded into links and form submissions, and the next states into the requested URLs. I have seen very adequate implementations of this - particularly using Servlets. However, it is an inflexible approach which doesn't easily support condition evaluation and is likely to involve considerably more maintenance. It does not provide for a central facility to protect against unexpected use of bookmarking, back button or refresh and can lead to extensive code to protect the back end application from unexpected browser events. As a result many transactional implementations simply ban the use of the highly desirable web browser features.

Far better, if you have time and are willing to make the long term commitment, to invest in a genericised architecture which allows you to "soft" code the design of the system as a description in a database. This is the 2nd paper is a series of three which shows how to build an  engine for the generic treatment and processing of events and state transitions.

Why do we need a server side Presentation Layer Architecture?

The Presentation Layer of a web server application is rarely designed. It's usually just coded. For small and medium sized sites this can work perfectly well but it becomes chaotic on larger sites. This article provides and structure and notation for designing the implementation model for large scale web server presentation layers. This can lead to better project management, more accurate tracking and ultimately better time estimating and closer control. This leads to developer and management confidence that the system under construction will work soundly and will be finished within a reasonable time frame. The advantages for project management and how to track a Presentation Layer development cycle using the techniques in this paper will be discussed in a future White Paper at this site.

The increasing demand on web applications is making them more and more complex. Very quickly they are becoming as sophisticated as many GUI Client/Server applications. This is puting a strain on the traditional "stateless, thin client" idea of a web application. Modern web applications have to carry out conversational transactions with the client. This requires the server to have a firm idea of the client state and a strong knowledge of the transaction boundaries. Part 3 of this article will show you how to scope the transaction boundaries within a Presentation Layer and how to enforce them leading to improved Transaction Isolation.