Writing Proof of Concept RIA's

When you sit down one night and decide to road-test a theory or an idea you have, then a Proof of Concept (POC) is something you should consider. That being said, when you do decide to write a POC knowing the difference between when you are writing a POC vs Application is something you can easily fool yourself into doing the later (ie I swore it started out as a POC, but here's my RIA anyway).

I say this from experience as this week I started out with a basic POC and then it slowly evolved into an full blown RIA, which don't get me wrong is fantastic to showcase once it's ready for public viewing (closing out bugs now, and about to upload). Yet, this is not what I set out to do...

It's a struggle as when you start out with a POC, you want to evolve it or you can see points where you think to yourself "..hmmm.. if I get more traffic hitting this, it could crash there, ok better go refactor that code and fix it up a bit.. " - that's when you should halt and think to yourself - what are you doing here?

Knowing when to pause, reflect and push ideas like that aside is the true art of writing a successful POC (in my opinion). As the best part of stating "..It's just a POC.." is that you get out of jail free cards in terms of:

• Design Patterns
• Performance
• Syntax / Coding styles (aka Code Reviews)
• Expectations.

There are more if you consider it further, but those are the main four that rest on one's shoulders at times when writing a RIA.

"...How will this application handle under performance.."

"...How am I going to architect this so that I don't bloat the code or back myself into an OOP corner..."

"...Hmm.. I should really spend more time on the transitions as that's what visually people are expecting..."

What I normally do before I start a POC, is write up a list of Objectives. I call it my "POC Quest Log", in that what am I trying to prove? What are my goals and benchmarks associated with the projects.

I also keep a diary of the overall progress (In this case a Video Diary). I do this as it can at times be something you can go over again and get your bearings on say a year from now when you need to evolve a similar concept like the one you wrote further.

Knowing when to evolve later vs today, is a key balancing point when writing POC RIA's.

An example came tonight. I'm writing a Component (in Silverlight) that works like iTunes Slider, in that you have dots that represent "pages" and when you click next/back the slider animates between these "pages" within the Slider.

I got the basic prototype working in under 30mins. Yet I started to think about "well, what happens when there is like 100 items, what will this thing look like.." and began heading down this code "rabbit hole".

When, in the end the idea has been proven, that Masking, Using Animation Tweens and ensuring Mouse Behavior is intact. Mission successful, move on.

Further with this example I was so worried about making sure the GUI would react to the way it was skinned (in that the arrows were 20x20 pixels, but what if they were 45x45 pixels tomorrow!). Again, don't worry, lock it in and put a big comment in between "sorry, if you want this to be elastic, then code it your darn self.." not only to add to this, but don't be afraid to use "green squares" to represent where your actual bitmap is likely to go.

That is the spirit of POC's, achieve your objectives, put a line through them when you reach those milestones and learn to back away as you'll end up in a time sink.

POC's are also the most perfect way to embrace a new technology or illustrate to others how a technology actually works under the covers.

I'll release this POC shortly, and it's title is "..We Play well with others.."

Comments

• Anonymous
  November 14, 2007
  I've been enjoying the overall experience of what Silverlight has to offer since I started with Microsoft