What is the best practice to decouple GUI design from server-side development when developing modern web applications?

Question

We are currently developing a few web applications and are letting our designers convert signed off paper prototypes into static web pages. In addition to having hyperlinks between pages the designers have started adding jquery calls to update elements on the pages by fetching data from static json files. Once the designers are finished and handoff the completed web pages, CSS, and JavaScript files; the server-side developers then edit the pages and replace the references to the local static json documents with references to live json urls that return the same json data structures.

My question: What are efficient ways to decouple GUI design from serverside dev and reduce the integration time and effort? Some examples:

• Do you have the developers manually change every json reference in the designers' prototype web pages?
• Do you add a global variable somewhere to enable the designers' pages to be easily switched back and forth between using static and dynamic data?
• Do you make the web pages self-aware of when they are running from a web server or just being served from a folder somewhere?

Answer 1

One of the things I have seen work fairly successfully for the whole "url/path" problem (dev vs test vs production, etc) is to create a subdomain for your project of "proto" (so proto.mycoolapp.company.int) and have that be the basis for all urls used anywhere in the app.

On top of that using whatever framework you are using set up global page handlers to identify section/page/function+[url data] for all of your data files (i.e. json calls etc).

This allows you to segregate your app into sections and build up functionality as you go and allows both the UI team and the dev team to work on hints for the other team.

For example say I have an app with three sections (login, account management, preview) I would have a login url service (data, files, whatever) at proto.mycoolapp.company.int/frontend/login/securelogin?user=GrayWizardX. The UI team can add these as they identify a need for data and your app dev team can see what functions are being requested (through server logs, etc) and make sure everything is matching up.

The good part is that when you move to production, the only change is to find "proto" and replace it. If that is in your global var, then its a quick and simple change.

Answer 2

It's not real clear what exactly your environment is (plain html only? or something like php?), so this is a bit of a shot in the dark...

If it's plain old HTML + javascript, you could probably use a javascript include on each page to get the right set of addresses. When the include file with all this environment specific information (i.e. use local or use server) remains in the same relative place, you don't need to worry about modifying the actual page. Just tell the GUI guys to always use this same set of variables for the address information and define the address information in that include file. The variable names don't change whether your getting locally or from the server, just the values stored in the variables.

I'm low on Vitamin Coffee, so hopefully that makes sense.

Answer 3

It depends on how much state information does your application need to manage. The examples you have given mention only read operations from the server. Are there any writes? Both read and write operations can potentially fail. Do your designers take care of those cases, or the server-side team jumps in and patches up the GUI later on?

I think it's best to provide a mock server-side implementation of your services for the designers. The server mock could simulate real life behavior as in throw errors and exceptions beyond just the happy path. It really is much less of a hassle to install a simple web server nowadays and a single script that acts as a mock service, rather than trying to create processes for later integration.