Web App Development Methodology

System Design and Web Design

System Design

There are many methodologies that deal well with clarifying requirements and then designing and building systems to satisfy those requirements. You have your use cases, stories, functional specs. You create logical designs that model the domain, examine how actors interact with the various systems to fulfil a business requirement. You can then start building and testing your code. Somewhere along the way, some web pages or windows forms get created out the back of this process. If developers have their way, they are usually logically correct, but terrible to use. But they do the job - don't they?
What do you mean there's a high drop-out rate?
How did I devalue the brand again?

Web Design

The other perspective that web app development gets approached from is UI design. The business go to the designers with some high level requirements, and they start the page design. Usability tests, rich interactions, brand, UI design principles, Flash demos, sitemaps, user flows, copywriting, graphic design, detailed UI specs; these all feed into a wonderful, engaging, on-brand customer experience. And then you build that code stuff on the back of the screens. I mean, the screens are the most important part of the whole thing.
Aren't they?
What do you mean you need some requirements?
And now you need to change the page flow...?

The Train Wreck

Usually these two flows happen in parallel, on the whole independently, and then towards the end of the project, there's a big crash when the two worlds collide.

What we need is...

What we need is a methodology that allows these two, largely disparate disciplines to work in harmony. User requirements need to feed into use cases which need to drive both the customer interactions with the system (usually web pages) as well as the interaction between various systems and business processes. The problem is, I'm having real trouble finding anywhere where this is taken into account. It generally seems to be either the web designer's approach or the system designer's approach. However, to be effective at writing enterprise-scale web applications with high quality systems and also a rich and engaging customer experience this is an absolute must.

High Level Idea

So how might this work? Taking the Unified Process as a starting point, we really should start out by clarifying the requirements. This is before any design starts from any perspective. Then out of the back of this you will get the use case diagrams which show the interactions between actors and systems. Customers can interact with systems via many channels: phone, web, letter, fax. These all need to be clarified and mapped onto the business processes. This should give you an idea of what the interactions are, what channel they use, and what data is required both in and out. Then you can start the system design and the web page design. There will be parts of the use cases where the actor is the customer and the channel is the web. These will give you the interactions and data flow required to start designing the customer interactions required on the website. You can then produce wireframes from these and subsequently add page-level detail, rich interactions and perform usability studies. All based on the use cases. It seems quite simple - does anyone actually do this?

Links

• Successful Development


• Successful Development 2


• Software Development Methodology


• Web Project


• Amazon


• Amazon


• Web Design Process


• Project Management


• Web Project Template Files


• System Design

More about the Coffee Cart

Delivering Coffee

Nigel Hamer modelled how IT delivers solutions to the business by looking how staff at a coffee cart dealt with customers. What interests me is how its delivered. The process.

Synchronous and Asynchronous Processing

The process of getting a coffee is something like this:

1. take order


2. take payment


3. make espresso


4. pour milk and espresso


5. hand over coffee

As I queue at the coffee cart fairly frequently, I started to notice that they had various ways of working. The two key ways were:

1. Asynchronous: Each person has a specific task (eg till, making espresso, heating milk, pouring coffee) and they communicated the order (asynchronously) using till receipts and writing "D" on the cup for decaf. The receipt and cups are Kanban in the Toyota Production System.


2. Synchronous: Each member of staff is responsible for a given order; they take order, then the payment , then make the coffee and then hand it to their customer.

There are various pros and cons of these methods. In the first, you are relying on the process and the communication mechanism, or "Kanban", to ensure that an order is fulfilled. If something goes AWOL, then the only way that they get notified of the problem is via the customer, and the person pouring the coffee won't have knowledge of what should have happened. However, as the process rarely goes wrong, sorting these problems out only take a very small overhead. At the coffee cart, if something goes wrong there is usually a degree of confusion, so you should have a well defined exceptions procedure, and a way to communicate the problem back up the process.

Using the second approach, you get somebody taking care of your order, so the scope for something to go wrong is reduced, and the resolution path is easier, as the customer refuses to take the coffee, and the member of staff dealing with that order can resolve the problem. However, the individual tasks will be less efficient, as there's nobody ensuring that there's always hot milk and espresso available, and the lead times of each may impact the delivery time of a particular order.

Choosing the right process is down to your requirements. If the asynchronous approach gives you a satisfactory success rate, even though there is no guarantee that each person gets the right coffee, if it works 99.9% of the time, it is far more efficient and gives quicker service. If you want to be very sure that each customer gets better individual attention, and a higher probability that they get the right order, and don't mind slower service as a result, then you choose the second.

The decision-making process normally seems to work the other way in the real world. People assume that 99.9% success, even with an exceptions process, isn't good enough, and happily take the hit on efficiency to get this percieved guarantee of successful delivery.

I would suggest that the first process, when applied to computer systems, will usually provide the best solution, with a perfectly good success rate.

Preventing Multiple Form Submits

Synchronizer Token Pattern

The Synchronizer Token Pattern is a server-side way to prevent multiple form submissions which is widely used in J2ee.

• Synchronizer Token Pattern (java world)


• Synchronizer Token Pattern (Core J2EE Patterns)


• Synchronizer Token Pattern (javajunkies)

Extract from Core J2EE Patterns

Duplicate Form Submissions

Users working in a browser client environment may use the Back button and inadvertently resubmit the same form they had previously submitted, possibly invoking a duplicate transaction. Similarly, a user might click the Stop button on the browser before receiving a confirmation page, and subsequently resubmit the same form. In most cases, we want to trap and disallow these duplicate submissions, and using a controlling servlet provides a control point for addressing this problem.

Synchronizer (or Déjà vu) Token

This strategy addresses the problem of duplicate form submissions. A synchronizer token is set in a user's session and included with each form returned to the client. When that form is submitted, the synchronizer token in the form is compared to the synchronizer token in the session. The tokens should match the first time the form is submitted. If the tokens do not match, then the form submission may be disallowed and an error returned to the user. Token mismatch may occur when the user submits a form, then clicks the Back button in the browser and attempts to resubmit the same form.

On the other hand, if the two token values match, then we are confident that the flow of control is exactly as expected. At this point, the token value in the session is modified to a new value and the form submission is accepted.

You may also use this strategy to control direct browser access to certain pages, as described in the sections on resource guards. For example, assume a user bookmarks page A of an application, where page A should only be accessed from page B and C. When the user selects page A via the bookmark, the page is accessed out of order and the synchronizer token will be in an unsynchronized state, or it may not exist at all. Either way, the access can be disallowed if desired.

ASP.NET client-side solution

The common way used to prevent multiple form submissions in ASP.NET seems to be to use javascript to disable the button on the page. This is not an ideal solution, with many drawbacks, but will work in the majority of situations.

Disable button (blog)

The Honda Way

Introduction

When there are many people in an organisation that don't want to work in an Agile way, they would obviously like to see the approach fail so that their way of working will prevail. This puts a lot of pressure on the Agile process to work perfectly, and for there to be no errors. This means that a risk-averse attitude is adopted, which goes against the concepts of 'refactor mercilessly' and 'have courage'. It also means that any worthwhile new ideas or techniques will be put to one side if there is any perceived risk involved in trying to progress.

The Honda ethos disapproves strongly of this, as recently re-iterated by their F1 Racing senior technical director Shuhei Nakamoto.

He encourages the team not to be afraid of making mistakes - because that is the only way the team will progress. He believes that a philosophy of experiment encourages the team's younger staff members to come up with fresh ideas - rather than being afraid to put forward concepts for fear of failure.

We flattened the organisation so that everyone working in (each) department can talk freely about their ideas and opinions. As long as an idea is theoretically correct and considered useful, we will discuss it - even if it comes from an inexperienced staff member. But they have to take responsibility for the ideas they provide. That is the Honda way.

Another thing I always tell the young staff is that they shouldn't be afraid of making mistakes. The failures will eventually improve our know-how. The important thing is to use that know-how correctly to make the next step forward. I kept telling them this. As a result, young people started to speak up and contribute more, which I believe was reflected in the gradual improvement in our performance.

I am happy about this, because it provides proof that the Honda Spirit of 'never be afraid, never give up' is penetrated thoroughly into the team. What Honda disapproves of is 'no action, no error'. I want all our staff to always keep the philosophy in mind.