The Issue

One of the problems many people experience in developing web applications is the product bridge between non-developers and developers. The process roughly goes like this:

1. A concept is discussed between a team
2. The concept is prototyped using static methods such as Photoshop, Balsamiq, screenshots, sketches and/or email notes
3. This prototype is handed to a developer, who then makes assumptions based on static presentation
4. Iterations are required since the static prototypes missed a lot of unforeseen scenarios
5. Development is halted to review the iterated changes
6. Iterations are soon discouraged outside of development as product is almost built and the launch date is nearing

What problems do we have in this work flow? Well, there are a couple of obvious ones and they are a hindrance to rapid prototyping and development. One is that iteration cycles from the non-developer perspective are forced up front and discouraged once development starts. As a result, last-minute compromises end up increasing the risk that the quality of the end product is less than ideal. This affects performance, questionable code, a bad user experience and/or a combination effect.

Another issue related to the first one is that prototyping without functional code from the onset is like throwing darts in the dark. This is especially difficult for someone who isn’t a developer as they are designing based on an idea in their mind but without the immediate feedback of whether it is possible to even create such a scenario.

So now you have two worlds – one that is creating concepts and the other who is going to tell you it is not possible architecturally and the cycle repeats. This increases the chances that deadlines will be missed and feeds team stress.

What About Existing Solutions?

There are programs you can use that either provide static solutions, provide limited hybrid solutions or provide an entire framework with an interface and a code editor (a.k.a. an IDE).

Static solutions such as Photoshop, Balsamiq or screenshots give visual feedback versus stately behaviour on what happens with data in a database if an action is executed. You can provide separate pages to mimic the different states or provide layers but this is not naturally intuitive and both the non-developer and developer experience is sub par.

Limited hybrid solutions such as Proto.io for mobile development are great but they only focus on mobile development. If the mobile landscape changes rapidly, then they have to catch up – since they aren’t open sourced, it makes it difficult to contribute and iterate on their software.

IDEs like Eclipse or Sencha Architect give you everything to build anything you want but the level of framework knowledge expected from a non-developer is too high.

So What Are We Missing?

What I think would be interesting is a way to combine the drag and drop behaviour of something like Balsamiq but automatically plugs into working code. This would create a scaffold that is functional enough to formalize agreements between teams, such that the functioning prototype can be handed off to a developer to execute with minimal confusion. In theory this would lead to the following optimized work flow:

1. A concept is discussed between a team
2. The concept is built using the application as a real-time collaboration. Iterations occur more frequently and a final decision is made
3. The prototype can be be used as a working demo and developers can make the correct assumptions

So what do we do – sit back and deal with it? Never! We go ahead and try to build a better solution.

How Do We Start Building?

We don’t code or work on feature requirements on this project right away – we start by interviewing individuals who do a lot of prototyping in their job and might find a tool like this useful in their work flow. I have an idea of what the tool looks like and what it does but the interviewing process gives me a better idea of what the actual feature set should be. As a result, I sent out emails to a group of people in various prototyping disciplines to gather more information.

What Are the Interview Response Patterns?

Most of the responses from the emails converged around the following:

1. Many prototypes are completed via pen and paper. Non-developers tend to use tools like Balsamiq and Keynote
   while those who can code mocked directly in HTML and CSS.
2. Work is primarily being done on desktop, infrequently on a tablet and never on mobile – this means realistically we can maintain a minimal dimension that provides ample space for dragging and dropping.
3. There is emphasis on requiring the ability for custom component support (being able to import your own HTML elements), a grid that one can align components to and the ability to reuse templates.
4. Real-time collaboration is also quoted as being important as immediate feedback enables faster iteration to finalize functionality for an initial development phase.

Where Do We Go From Here?

Based on the responses received, we can build an initial static mock – in this situation I am using Photoshop, as it is what I normally use for doing static prototype concepts. After creating a few concepts, we’ll review this with the research participants and adjust based on suggestions as needed.

Where Is There More Info?

We will be updating with blog posts throughout the project from beginning to end but we also keep a wiki page
where you can follow project status updates or join our channel on IRC.