Prototypes

imageOK, so it’s not a piece of fine furniture, it’s a prototype. It serves many purposes and it reminds me of why we sometimes need to build prototypes when developing systems and when deploying SharePoint. Like most things related to systems development, it might be easier to think of this real world example instead of the hypothetical SharePoint example. Let’s think about why my daughter built a foam coffee table.

Raw Material Limitations – A few years ago, my father-in-law arranged for a friend of his to give me a pile of hardwood lumber out-cuts. I didn’t really want this lumber, but the friend didn’t want to see it go to waste, and it was a very nice gesture so I agreed to take it. My father-in-law has since passed away, and my daughter wants to build a piece of furniture from that lumber. It’s a collection of odd lengths and species, so we tore through it trying to identify the limiting factors: What is the longest piece that can be used to make legs, the longest piece that can be used to make the apron, the pieces that might be glued together to make the top. Clearly, SharePoint comes with limitations too. Do we have Enterprise features? Do we have enough storage space? Do we have enough CALs? Building a prototype that is subject to the real world constraints, prevents us from designing what we can’t deliver. We also should consider that constraints can be removed. As we were sifting through the pile of wood, I reminded my daughter that “we can also buy lumber”, but she likes the idea of using only what we have. My boss sometimes likes that same idea.

Expertise and Technical Limitations – In order to turn this wood into a piece of furniture, she needs to perform a variety of operations. For example, the wood has to be cut and surfaced, a process that results in some waste. The legs of the prototype are as wide and as tall as they can be, given the piece she has selected to use for legs and factoring in the effects of preparation. Building the prototype allowed her to put the “table” in her living room and see if it works. SharePoint and the shops that support it are fraught with limitations. For example; in our shop, we limit ourselves to SP Designer workflows. We have Visual Studio, but we try to avoid using it with SharePoint. We also try to handle our SharePoint work ourselves; I have a consulting budget, but I try not to spend much of it on SharePoint. SharePoint is the low-cost solution we chose to reduce the need for custom development and consultants; my job is to keep it low-cost.

Look and Feel – My daughter wants drawers under her table. She isn’t planning to load them up with cans of soup, but she wants to be able to stick a few remotes in them. She wants the drawers to be interesting – she’s an artist, and when artists use the word “interesting” buckle-up, you are in for a journey. We talked about hanging the drawers from the table top with the appearance that they were floating. Of course, we needed to see that. Look and feel is often overlooked when using SharePoint, at least in our shop. I have been trying to pay better attention to this lately, and sometimes that involves mocking up a page that helps the user understand what the solution will look like and how the solution will work. We have been using SharePoint for more than five years, but as I said a couple of weeks ago, people don’t always know what to expect.

A few thoughts on prototyping – When we were building the prototype, I really thought one drawer would be enough. One drawer would show her the size, as well as give her a good idea of how well the drawer could hide the structure (essential to make the drawers appear to be floating). My daughter wanted to build all five drawers. I lost the argument in my shop, but you need to be careful not to lose that argument in yours. Here are a few tips: 1) Avoid over-building – use the prototype to validate the concept, and then move on to real work. 2) Fight the desire to morph the prototype into the final product. While it may sound tempting, it often results in people arbitrarily limiting the creative process, or worse, carrying mistakes into the real world. We will throw away the foam coffee table when we start working in wood. 3) Look to see if you already have a model. Prototypes are great, but showing someone a working solution in another department, or even another company is often better.

6 thoughts on “Prototypes

  1. I built an Arts and Crafts style long case clock for a customer once – all 7 feet tall x 2 feetwide and made out of solid oak.Because I was working from a photo seen on the Internet, I built a prototype out of pine first. Some one wanted to buy this prototype off me, which was tempting – but to turn the prototype into somethng that he would be happy with over many years was not possible. If I had built it to sel, it would have destrpyed the reason for building it in the first place. It is very easy to over-egg a prototype – get a concept and be done.David

  2. Dan:I don't generally agree with your "Fight the desire to morph the prototype into the final product" statement. I find that building a working prototype in SharePoint and continuing to take it toward the "end solution" (which usually will never be done – a good thing) is an excellent route. Sure, there will be times when you need to say "OK, that looks good, now let's build it 'for real'", but a good prototype *should* be real.Part of my bias on this is that I primarilty develop, as you know, in SharePoint's Middle Tier. There doesn't *have* to be a lot of rework to "productionalize" a solution using those methods. I find that rapid iterations with the actual users is the absolute best way to arrive at an optimal solution which they will actually use. Any performance tuning can occur once the usage patterns are better understood. Not theoretical usage patterns, real ones.M.

  3. Mark:You raise a good point, but I am going to draw a line between what you are doing and what I find myself “normally” doing. I would tend to put the work you are used to doing in the category of “agile development.” I’m not sure what heading I would put my work under, but it wouldn’t normally include the word “agile.”Agile development techniques work well when the user is comfortable with the platform and when they have a pretty good idea of what they want. We use these techniques often, with our (fat-client) custom applications. What we tend to be doing a lot in SharePoint is introducing a new process and a new mechanism at the same time. For example, we recently built a Content Management solution for a group that had simply been dumping Word documents into a share drive for years. The concept of document management had to be illustrated, as well as the way(s) we could deliver it. One of the decisions we had to make was where this would reside in SharePoint. We started working on a test server, and once we got them comfortable with Content Types, metadata and versions, they were in a much better position to talk about how they wanted to access the content. We went from talking about an Inspection Reporting Site to an Inspection Reports Library. Before we showed them a prototype, they couldn’t really imagine the end result. I could have guessed that we would probably end-up with a certain look and feel, but I really am trying to let the users exercise some control over that. On the other hand, the example I used in the post; the survey analysis set, could have just as easily been started on the production site. I chose to prototype that because I wasn’t sure I had enough of an understanding of “middle tier development” to pull it off.

  4. David:While I am in comment response mode, I realize that I am neglecting David’s comment. Having also owned and operated a cabinet shop, I can understand your dilemma. The opportunity to make money from something you did not plan to sell is tempting. The key point of your decision was “to turn the prototype into something that he would be happy with over many years was not possible”. We have to consider the long-term value of our decisions; I think you did the right thing. D

  5. Pingback: Baby Needs a New Pair of Shoes | SharePoint Stories

  6. Pingback: Baby Needs a New Pair of Shoes - The SharePoint Blog

Comments are closed.