For a project I am working I want to implement a small prototype to try things out, demonstrate some functionality to the client and learn some frameworks used in the project.

Do you have any suggestions or do you know of best practices for implementing such a prototype?

Some more details:

  • The application will be a complex web app
  • I have to implement a mechanism where the server pushes data to subscribed clients (the data will be generated by some events)
  • I want to write a prototype which implements exactly this behaviour but nothing more
  • Here's a suggestion: write a prototype which implements exactly this behaviour and nothing more. I don't get the question. Can you clarify what more you need to know? You already defined -- fully -- what you're going to do and how to do it. What else do you need? – S.Lott Jan 26 '11 at 16:20
  • 3
    Don't forget to make it not look snazzy. – Jeremy Heiler Jan 26 '11 at 20:22

If you are creating a prototype first make sure that it is intended to be a prototype and not a light first version of the software. Many times customers ask for a prototype and then want to put that version into production. Suddenly your left supporting a product that was not intended for full time use.

To avoid this try creating a prototype that mimics the behavior that customer wants without actually implementing the features. For web applications, I usually create static html pages and mimic the behavior with JavaScript. This gives the customer a chance to play around with something visual. This will spark many questions and changes which need to occur early in the development process.

Christopher Mahan brings up a good question about the target audience. You need to define your customers. If these are technical people looking for a proof of concept to some tech they want to use then your best bet is to separate the functions request and create code samples that are properly documented. These code samples should be simple and focus on that feature. Using console applications are usually a good approach since there ins't a lot of rigging needed. If these customers are not technical then you really should convince them to focus on what they need rather than the tech. Many none technical people get caught up in the cool sounding tech rather than thinking about what they actually need.


If the client is getting stuff pushed to them, you have two options: Email, and software running on the client computer that listens on a port. For the latter, they would have to configure firewall, etc, and that requires sophisticated people on the client side.

If the client is polling, then they have to have a software on their machine that polls a server at intervals. I would suggest that an email client already does that, and that an RSS reader also does that. You might also have a self-refreshing web page but you would have to insure that they go to that page in the first place.

If your client is sophisticated (corp, geeks) have them set up a xmlrpc server try it out that way. If not, email is the best bet.


The combination of Javascript/Jquery/Dom is a pretty good environment for prototyping. It might not seem like that at first, because of all the bugs and problems, but if you persist, at some point you'll learn to quickly overcome all problems (by trial and error usually). You can write Jquery-ajax-callback to server that would usually sleep at server side, lets say for 60 seconds, but return to client (browser) if it has some data to push. If there's no data to push, client-side would keep repeating that 60 sec request until the end of time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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