I have created some mockup screens for my app in HTML/CSS. I have 4 screens in t

Question

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.

Explanation / Answer

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.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.