Home > javascript, software, tech > Rethinking Mockups

Rethinking Mockups

At work we are writing an application which is delivered in a single webpage with heavy use of JavaScript. Lately, I have come to realise that writing a web application using JavaScript does have effects in the way we work as a team. The rest of this post explains what I mean.

Initially, web pages had static content – the users requested a resource from a server and the server served out an HTML page it had. Then came dynamic web pages and web applications. The widely accepted way to create dynamic web applications was to use a template language eg: JSP, Velocity, XSLT, erb etc.

Two kinds of people collaborate when a dynamic page is built using a template language:

  1. designers who are good at deciding the user interaction and look n’ feel of the page
  2. programmers who are good at writing programs that generate the dynamic bits on a page.

The designers would design a static HTML page – a mockup – and get it reviewed by the business analysts. The analysts get an early chance to see how the web page would look like eventually; they can detect deviations from expectations early and might be able to correct them at this stage. Hard-coded data would typically be used in a mockup; it is the programmers job to replace it with dynamic content, resulting from some computation database query typically. Frameworks like Tapestry and Rife take great pains to make sure that designers and programmers can work together smoothly in creating dynamic web pages.

This is roughly the model we have been following so far at work – designers make mockups and deliver it to the programmers, who annotate those mockups to create the actual web pages. Throwing in JavaScript to the mix changes this workflow.

Designers when they work out a mockup use a series of HTML pages to show a dynamic interaction which in the actual application should be done with JavaScript. Writing JavaScript is a programmers job and it is unfair and unwise to expect designers to deliver the mockups with functional browser-side JavaScript interactions. Also, to decide the user interaction and look n’ feel and for analysts to set expectations a series of HTML pages would do. But such HTML mockup pages cannot be directly used by programmers as a starting point for writing the application. This is different from the way we have been working so far.

The solution would be to have another set of mockups created by programmers. This would retain the user interaction and look n’ feel designed by the designers, but would have functional browser-side JavaScript interactions. The data displayed on these mockups are still hardcoded ones though. The actual application can be built starting from these mockups. This essentially creates three kinds of roles (instead of the two earlier):

  1. designers who decide the user interaction and look n’ feel of the application
  2. client-side programmers who code the user interaction into JavaScript
  3. server-side programmers who code the computations, database fetches etc.

In many situations, more than one of these roles might be handled by a single person; but the existence of these distinct roles would help manage the project better.

Categories: javascript, software, tech
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: