I have created some mockup screens for my app in HTML/CSS. I have 4 screens in total.
They contain no client-side coding i.e. Javascript or jQuery.

The screens themselves are quite bland at the moment, and I realise they require some further work. Some of my plans for the app going forward are:-

  • Introducing client-side templating : eg Mustache/Dust.js
  • Add some effects and transitions using jQuery
  • Improve the visual look of the screens (through css and images)

I'm indecisive on the best way forward. My main aim is that I want changes to be easy to manage, and that's why I did mockup screens first as per the recommendation in the Getting Real book by 37Signals.

I'm currently in the process of gathering feedback for the mockup screens.

From a programming point of view, which of the 3 steps above, would be a good logical step forward considering my requirement of making changes easy to manage?

I should point out that i am very new to programming and development, and this is the first time i am learning programming. Some terms may not make sense to me and you may have to elaborate.

3 Answers 3


What the others say: don't deal with technology first, make sure it works in theory.

For example, to improve navigation, create a user flow.

A user flow in programmers' terms is a finite state machine, with some transitions labeled as "the" main transition (also called the happy path). It is well-defined and deterministic, that is, for every action that can be taken in the respective states, there exists an output defined, and the conditions which decide what can happen are complete (eg, if there is an "if user has something in the basket", there is an accompanying "if user doesn't have anything in the basket").

Every screen is a state, and every click which does something is a transition (albeit the user might remain on the same screen). The transition always has some condition on when it can happen. Usually such screens are called Key Screens, although I add a special kind of screen called "Error Screen" for the "whoopsie" situations.

There is an abstract start state (from which there are conditions which makes the user arrive on the page, eg. google search), and one or more abstract end states (eg. some could be happy end states, some could be unsuccesful end states). Simple site abandonment isn't mentioned as an end state.

The main flow is usually organized horizontally, while the side flows (eg. error and exception handling) are organized vertically, starting from the first screen where they can go wrong. I usually highlight the main flow by having a much bolder line between them.

The main problem which designers leave out is that they don't care about non-happy issues, or it takes too much steps to achieve a goal.

Remember, a user always has a goal which (s)he wants to fulfill with the site. It can be that that goal is emotional, but sometimes it's rational - eg. Google Maps can help you reach the goal of knowing how to go from A to B, Facebook can help your emotional goal of feeling closeness to your friends, etc.

How easily this goal can be reached is a key issue, it's covered by the GOMS model (about which you can read in the Humane Interface by Raskin)

But, alas, this is not about technology, as technology doesn't matter that much. You can use a vast array of templating technologies (by master template, they mean having a 'layout' template and just modifying some content parts based on situation).

As for technology, try to solve transitions with CSS transitions instead of jQuery.

A technological next step could be to make the mock-up screens work with mock-up data, that is, to make them "live". Use any technology which fits.

  • Thanks for elaborating further. I did work out the workflow, user flow for the app very early on. Although i havent worked in error states, so i guess i should work on that. But overall the workflow of the app is already worked out. I started the screens after that. So technologically would the next step be actually making that workflow "live" ? Jul 25, 2012 at 19:53
  • Yeah, and for first, try not to deal with technology. Templating is a key issue, I understand, and especially nested templating is hard always, but the important thing is to display data and retain state. You can try out nested templating in a side-project to feel confident about it. But applications are not about technology. Applications are about software solutions APPLIED to human problems. Get that first.
    – Aadaam
    Jul 25, 2012 at 21:06

Step 4, work on navigation and usability, at this stage very easy to work on alternative flow and navigation ideas. I suppose step 3 could be part of this, depends on how visual heavy your apps needs to be or if you just have a few icons etc.

  • My app has a buttons and icons in place, but i was told it needs a background image. When you say usability are you referring to the User Experience? Jul 25, 2012 at 17:09
  • Yeah thats what I meant, usability when you are playing with html files you can easily test/change flow etc. Jul 26, 2012 at 9:52

Work on usability and maintainability of your templates and pages. It includes the navigation and ease of updating.

You may definitely want to consider benefits of master template technique. This will also provide consistency between pages, look and feel, and ease in maintainability.

  • Would the maintainability of the templates and pages come from using a templating option such as dust.js ? what do you mean by usability of templates and pages? Jul 25, 2012 at 17:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.