The perfect web application technology, part 3: the test application

Well, I gave up and ended using balsamiq (free) web interface.

In the mean time, I realized that finding the perfect web application technology could easily become a huge, really really huge project (Leo say something like ‘I was trying to fix the world’… that sounds huge!). And my fears of not finishing it all by myself in my spare/free/study/procastination time just appeared. So, I’m taking two strategies for this:

1. So many girls, so little time! I’ll start with something small, then grow as necessary: I mean, I will start with only one of the major functionalities I have in my mind for the test application, later I will cover the rest or improve the existing ones.
2. Ask for help: Please, you are already invited into this quest: talk to me, send me patches, re-create this application in the technology of your choice, fixs my bugs or find better ways of doing things, etc. Thanks!

So, functional requirements: here we go!

Functional requirements (version 2010-01-02)

The test application is a rich internet application for clients of a fictional bank. The clients of the bank can do the following tasks: see a balance report of their saving/deposit/whatever accounts, transfer money to other accounts, and chat directly with an executive, if they are available.

The six major functional requirements of the test applications are:

1. Layout of the web page that makes easy to compare a technology with others.
2. A very secure login and logout, user-password based.
3. Balance reports of different type of accounts, including excel and chart exporting.
4. Money transfer to other accounts of the same bank.
5. An embedded calculator, with bank-related functionality included.
6. A live chat with your executive, if she/he is available.

Remember the ‘so many girls, so little time’ phrase: I’m trying to meet as much sexy (and ugly!) girls/technology first rather than know them very well. So, in this version we are covering only the first two requirements. It will be long, however, take your notes!

Requirement 1: Layout of the webpage

This is easy, the layout of the page has to be something similar to this:

Let me explain each section of the layout:

1.1 Top-left section:

• first line is “the perfect web application technology” linking to this page
• second line is the number of the test (ex: “technology 05″) and the name of technologies used (ex: “gwt, java servlets”)
• third line is an about page, linking to a page with notes about this version of the application (who made it, where is the code, licensing, etc)

1.2 Top-right section:

• first line is the name of the connected user, only if she/he is already connected to the application
• second line is the roles available to the user, ONLY if the user has more roles other than “bank client”
• third line is a logout link

1.3 Evaluation accordion: The right column is a summary of evaluation points. The interface is an accordion widget, and the titles should indicate the number of issues found for a given requirement. For example: “Logon (4/10)” means that logon functionality has a total of 10 requirements, and 4 of them has issues in the current implementation”.

If the user clicks on a requirement, a new floating window should appear (inside the browser! example) with the page fragment of the evaluation page. Note that “the evaluation page” will be a post on this blog.

This will allows us to see the evaluation of a technology without leaving the same application. Bonus if the application reads the evaluation post and updates the accordion automatically (ie: no database or code to keep the count of issues!).

1.4 Link bar: just above the content pane, there should be a link bar with all the functionality for this application. Of course, if the user is not logged in, it must be forced to logon.

1.5 Content pane: It can’t based on frames, that sucks for many reasons. It should have vertical scrollbar and an horizontal scrollbar only if needed.

1.6 Expected web page behavior:

• The back, forward and reload browser buttons should work with your application. Not sure how to explain this, so I’ll do it later…
• Copy and paste should work, and also mouse scrolling (both horizontal and vertical)

Requirement 2: Login

2.1 User accounts: Because this is a bank, there is no account creation via web. We’ll may cover an administration interface later. All user accounts consist of an user and (strong) password.

2.2 Login interface: it should be something like this:

Note that the top-right section is empty.

2.3 Login failure: if the user fails, a message should appear below indicating the number of attempts left before the account will be locked (1). The failed attempts are by hour, and reseted if the login is successful. If the user has failed within the hour, a link to recover your password must appear (2).



2.4 Lost password: if the user click the ‘lost your password?’ link, a dialog should appear asking for the username or email of the account.

When the user press the ‘Sent me instructions’ button, an email will arrive with a link to reactivate the account (if it was locked) and to create a new password. The confirmation message should look like this:

The user has 1 hour to recover its password, after that the link sent is expired and must not work again. Besides that, the user cannot send new instructions until the recover links expires. Instead, it gets a message like this:

2.5 Account locking: if there are too many login attempts in the period of an hour, the account must be locked and the user must not be able to login after a pause of X minutes.

A clock should appear, with the minutes:seconds left until the user is able to try login again, once the counter reach zero, the account dialog must disappear and reveal the login. Account locking is an standard in the bank, so it must be implemented with functionality supported by remote services.

2.6 Services: The following remote services are available to build all the above functionality. These services can be made available in the protocol of your choice (from EJB/RMI to JSON). I will post the API + examples later, once I implement them.

• login_status remote_login_status(string username);
• user_info remote_login(string username, string password) throws login_error;
• remote_update_password(string username, string password) throws update_error;

Note there are things that must be implemented in the webserver (ie: not available as services), an example is the link to create a password.

Summary

To summarize, here is the list of all requirements (including those stated in the previous post). Bonus: If the evaluation accordion extracts the names from here.

List of requirements

1. Layout
1.1 Top left
1.2 Top right
1.3 Evaluation accordion
1.4 Link bar
1.5 Content Pane
1.6 Common behavior

2 Login
2.1 User accounts
2.2 Login interface
2.3 Login failure
2.4 Lost password
2.5 Account locking
2.6 Services

What’s next

All following post will talk about the experience of writing the test application implemented under a technology. I’m keeping a summary of versions and a changelog in the perfect web application technology page, check that regularly for changes and improvements.