ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Reshaping IT Project Delivery Through Extreme Prototyping
Pages: 1, 2, 3, 4

Static Prototyping Phase in Detail

The Static Prototype starts with a vision first. From the vision you recognize and write down a series of users that would be using the system. You write down goals for the system. The analysis can take the form of actors and use-cases, or a word-processing document outlining each need. The key to Extreme Prototyping is to minimize the details in these documents so that most of the requirements are captured primarily in the prototype.

One of the early resources that needs to be engaged is the prototyper. You want to hire a prototyper that can grasp your vision for the project after a few sittings with the users and can lead them to a final solution ably and quickly. The key for the prototyper is to understand the system well enough, either by talking to the users or reading documents, whichever is faster and more efficient. You want this prototyper to have the following skills:

  • Ability to imagine the site from start to finish
  • Ability to design style and content
  • HTML, CSS, and JavaScript
  • Communication, understanding, and empathy
  • Ideally, would have developed a few websites before
  • At least 5 to 10 years in website design would be a plus
  • Experience with Flash etc., if the site is more interactive
  • Experience with portals
  • Experience with marketing in that space

I expect web-based tools to emerge rapidly in the next few years to aid in Static Prototyping. I am especially fond of project portals where a project is started in a company by allocating a website to it. Everything that happens to the project is captured with ease on the project web site. I have used this very effectively for a couple of projects, as described in How to Publish Multiple Websites Using a Single Tomcat Web Application. All project-related communication and assets are portrayed via web presence. For instance, users can enter their wishlists for the system as a series of documents online with out any additional tools. Discussions and elaborations can take place for each posted item. The items can be classified into modules and searched if required. The prototyper can take notes on the project website while in meetings and capture the tacit knowledge. All emails related to the project can be tagged and made available as conversations on the website. This early knowledge aggregation will help the developers downstream to quickly decide what needs to be done on a particular screen or in a given situation.

Prototypers typically use Dreamweaver, FrontPage, or just plain HTML-enabled editors for developing the actual prototype. Whichever tool you choose, the following support will be useful:

  • Good support for CSS
  • Good support for background or master pages
  • HTML tag completion
  • HTML tag or in general code assistants
  • Optionally some kind of content management support
  • Ability to quickly publish over the internet or intranet so that users could quickly see results

I expect online web tools to emerge in this space as well. Recently, I have been experimenting with knowledgefolders to do the following:

  • Create/start a prototyping account for a particular project.
  • Design background pages for this project to nail the look and feel.
  • Have the background pages include or define the CSS, JavaScript, etc.
  • Free prototypers to focus on each page without worrying about the background in which it sits, much like "master pages" in PowerPoint or other presentation apps. This will give the prototyper a nimble ability to quickly prototype online.
  • Design screens in this online form to make readily available for users to critique.
  • Crosslink in the system to a critique page so that users can type their feedback directly about the screen in question.
  • Crosslink the prototype screen to another document that will talk about field validations and specifications.
  • Provide every possible bit of information needed by the developers to turn the prototype in to a working system without ever leaving the online prototype.
  • Publish the online prototype account as its own web domain, such as mysystem-prototype.mycompany.com.
  • Publish the service signatures, particularly the API, needed by these screens.
  • Crosslink the prototype screen to a set of test cases that the developer has to test the screen with.

The conclusion of this phase will be a clickable website that will reproduce the user experience as close to the real thing as possible. Usually the following would have gone into this effort:

  • A Static Prototype with navigation
  • Proper background pages
  • Proper CSS
  • Detailed specifications to accompany the prototype (optional)

Idea of an Extended Static Prototype

A Static Prototype that is fairly complete has hidden assets that can be mined. The primary one is the logical data model that is necessary to support the prototype. Screens, much like use-cases, will make evident the main topics or logical entities or tables in a database. The summary and detail screens will reveal the relationships between tables. Various form elements and display elements will clarify field-level attributes of a table. In short, it is possible to derive the logical data model from the screens. The logical data model can further be converted into a physical data model. At the end of this, it is possible to produce a database ready for development by the developers. I call this Static Prototype, when accompanied with an instantiated database, is an Extended Static Prototype. The Extended Static Prototype is a logical unit that can play a role in division of duties.

Companies often evaluate to see if certain software is best developed outside due to expertise or time and resource constraints. The main drawback to outsourced development is how the delivered software will fit into the internal architectures and resources, not to mention to the coding standards and the rigor expected internally. An Extended Static Prototype can solve this problem. A company can choose to outsource an Extended Static Prototype and the variability of an Extended Static Prototype is small. This means there are very few places that the outsourcing company can go wrong. The technologies are known and what is delivered is conceptual. On the other hand, the source code for a website has a substantial variability. So by outsourcing elements of least variability you will come out more satisfied. Under this scheme, an outsourced company that specializes in websites and can give a working prototype along with the logical data model to the in-house development team. The development team can then develop the concept using any of the chosen frameworks. It is like a tag team, ready to run from the start.

Another asset that can be directly derived from the prototype is the set of test cases for each screen. Together the additional deliverables of an Extended Prototype can be summarized as:

  • Logical and physical data models
  • Test cases

Dynamic prototype

The primary goal of a dynamic prototype, abstractly speaking, is to separate the known and unknown so that progress can be made in the known space. UI programmers, on the receipt of a Static Prototype, will proceed to create a UI layer that is completely functional. UI layer will talk to the service implementation through one or more of service interfaces. It is possible to complete this working UI layer without ever implementing a single line of the real implementation. The finished UI layer will be complete in the following respects:

  1. The HTML of the static prototype will be transported to the UI elements of the respective frameworks.
  2. All the CSS and the look and feel will be in place.
  3. Client-side validations will be functional.
  4. Server-side validations will be functional.
  5. A domain object model will be in place to support the screens.
  6. Service calls will be made for all the updates or actions on the pages.
  7. Navigation of the screens will be in place.
  8. A simulated service implementation will provide the data for screens either in terms of Java objects or XML.

Despite the seemingly hard exterior of typed languages, they provide the basics needed to successfully execute a dynamic prototype. The key is enforcing the contracts in terms of well-defined objects and the service API.

The one question that begs to be asked is: if you're going this far, why not implement both layers together? The primary reason is to break down the dependencies between the service implementation team and the UI team so that both teams can be productive simultaneously. It is very common for the UI team to sit paralyzed until a database instance, domain objects, or a service layer is in place. How can they code unless they know all these details? The goal of dynamic prototyping is to answer this question with simulated APIs and allow UI to proceed without service implementations. By having conceptual domain models for screens and screen-level objects it is possible to envision the system in terms of these objects and then let the service layer contracts translate these objects into proper implementations. By taking this approach both UI and services teams can start their work simultaneously.

While following this process UI programmers often question about what goes into the UI layer and what goes into the services layer. How far should they go in the UI layer? How do you draw the boundaries? Some of this is clear enough where data access, storage, and business logic that is devoid of screen influence is relegated to the service layers. Sometimes another way of looking at this can help you. If you know how to execute or perform a certain function clearly with the information you have in the UI layer, then do so. The moment you run into a roadblock where you can not proceed in the UI without knowing some piece of information, make that unknown a service and simulate it, like everything else, allowing you to postpone that unknown while you proceed with the rest of the UI. In this sense the interfaces are treated like the boundaries between known and unknown.

Pages: 1, 2, 3, 4

Next Pagearrow