Archive for January, 2010

h1

The iPad As Quorn

January 28, 2010

Yesterday, Apple announced their long-rumoured and much speculated-upon iPad.  The world, it would seem, waited with bated breath for confirmation of the “Jesus Tablet“.

What we got was a competent looking, stylish device that many have already deemed a disappointment and doomed to failure.  I wanted to try to down-play the physical iPad somewhat and think about its place in the society of the (very) near future.

The key to the iPad is to think of it as one would Quorn.

The iPad as Quorn

If you don’t know Quorn, let me elaborate: Quorn is a mycoprotein-based food-stuff made from eligible fungus and high in protein.  Doesn’t sound too tasty, no?  But wait, there’s more.  It is healthy and forms the basis for an entire industry of vegan-compatible meals.  Everything from sausages to meatballs to scotch eggs, minced beef and chicken fillets.  Except they’re not.  Quorn is most commonly regarded as a substitute for these non-vegan/vegetarian foods, and favoured, shaped and marketed as such.

However, as someone familiar with Quorn, I’ve personally found that when you treat it as a meat substitute, it is often found wanting.  I’m not vegetarian – I do enjoy the occasional piece of chicken or beef, and I know what they taste like.  I know the texture, I know the mouth-feel, I know the taste.  When I eat a Quorn ’substitute’ for any of these, I am only too aware of the differences.

My success with Quorn has been to treat it as its own category of food.  Work with its characteristic flavours and texture – don’t fight against them to make them into what they’re not.  If you do this, you end up appreciating Quorn for being its own thing; a versatile and healthy alternative, not a substitute.

So, thanks for bearing with me whilst I’ve seemingly lost the plot.  There is a point to this, and I’m getting there.  We were talking about the iPad and I was trying to give it a fair hearing.

I think the iPad should be treated in the same way – not as a substitute for anything, but more as a new device – and it should be thought of simply as a piece of a larger system, rather than as a device unto itself.  This is where it’s connectedness is key.  The iPad v1.0, then, is simply the first generation conduit into a wider ecosystem of premium content.  iTunes for the publishing industry, if you will.

Something which finally facilitates a workable model for book and magazine publishers to really exploit the possibility of paid content.  Sure, Amazon has its Kindle and a pedigree in online publishing retail (not to mention the beginnings of an e-book empire) but this is limited by the Kindle reader itself.  A fine device, it sadly falls short of providing an interactive, ‘added value’ reading experience – a void which Apple is keen to fill.

How Apple will achieve this will be down to its clout, established and new business agreements and the fact that it has made a (huge) success of doing the same within the music industry, perhaps even saving said industry along the way.  The traditional publishing ecosystem will be looking to Apple as some sort of savior, a means to finally offsetting the decline of conventional publishing with a new emergent marketplace.

Perhaps nobody else can do this – who knows?

So, whilst the masses may quibble about little things such as the size of the device, or the lack of this or that, the key here is how this ‘first attempt’ device will place the final link in the chain of a truly viable premium content publishing model.  I believe the initial iPads are largely irrelevant in the grand scheme, much as were the original iPods.

The next few months will be interesting times!

h1

Many words saved

January 20, 2010

Thought for the day:

If a picture paints a thousand words, think how many words you can save by creating an interactive prototype of your next software development. Think of how much easier it will be for people to understand what it is that you’ll be creating. Think of how the process of creating and demonstrating your prototype will highlight shortcomings in your design. Think of how much misunderstanding you will avoid, and how that will help your actual development set off on the right path. Think of the how much time will be saved by not building that feature that your users really don’t want. Think how much time will be saved by not missing that key feature that your users really do want.

Many people view software prototyping as something that’s only really worthwhile on larger projects. This couldn’t be further from the truth: prototyping brings benefits to almost any non-trivial software development.

h1

Distracted by Shiny Things

January 11, 2010

This blog likes to talk about ways to improve your chances of delivering a successful software project.  One of our mantras is the use of software prototyping, but a recent conversation got me questioning whether building a software prototype might end up creating its own problems.

“Whoa!” I hear you cry.  Take a second to pick yourself up the floor; calling prototyping a liability on a site hosted at softwareprototyping.net might seem like a rather chilly day in hell.  And you’d probably be right, but I try to present the upsides and the downsides with a (relatively) impartial hat on.  Or at least that’s the plan.

So, software prototyping creating its own problems?  Surely some mistake?

Well, to answer the question: generally, no, software prototyping is usually a highly effective way of steering the early stages of a software project, therefore increasing your chances of success. 

However, if we widen our brief and consider requirements prototyping – i.e. the use of prototyping techniques as a core part of the analysis and specification of a new system – we hit across a small problem.

This is illustrated best with the story of Jeff*, at the time a divisional director in a large financial organisation. 

I was involved in the design of a considerably wide-scoped prototype.
Using the techniques of requirements prototyping, I was able to bring in feedback from users, stakeholders and technical analysts to help shape the design.  This was going rather well; hard work but with each revision showing real progress towards a killer design.  Along the way, however, Jeff started to sniff around in an example of classic hit-and-run micromanagement. 

Despite concentrating on building up the shape of user journeys, exploring the effectiveness of our interface and so forth, Jeff really wanted us to devote our time to ‘making it look just fantastic‘.  Which, unfortunately, involved endless fiddly adjustment to such things as the precise placement of fields, the exact colour of text, whether this image looked professional enough and so on.  All very interesting, but somewhat missing the point of the prototyping process.  All this served to do was divert significant time and effort into polishing the finest details of a prototype whose main purpose lay elsewhere.

On reflection, and in Jeff’s defence, it was pretty clear that he believed in making everything look as slick and professional as possible.  He knew that the project could gain support from his superiors only if the prototype gave the illusion of completeness, and so in a way he was right to push for consistency and professionalism in the appearance. 

Our failing (as a project) was in letting him do this at far too early a stage.  After all, we hadn’t decided if we were going with User Details Capture Journey A, B, C or D at that point, so polishing them all to a high gloss was always going to be overkill.

What I learned from this was that the production of any tangible output – be it a paper design or a full interactive prototype – invites attention from those who don’t understand its role, its place.  Even though they may be senior, important people, they may not be important to the project itself. 

Sometimes, these people get distracted by shiny things, colours, minor details.  This isn’t a problem if they remain as observers or on the fringes of the project, but can be a serious risk if they attempt to push their way into the proceedings.  As prototyping practitioners, such people really slow down the responsiveness of the prototyping process and dilute the benefits of prototyping.  In other words, these people cause more harm than good. 

The skill is recognising these people and finding a way to either educate them to the purpose of the prototype or reducing their involvement/exposure to the team.  If they really must have their fully polished, ’slick’ design ideas visualised, then at least explain to them that it simply isn’t realistic to do this over the entire prototype.  Offer to ‘polish’ up a portion of the prototype once the fundamentals are stable.  In other words, don’t wallpaper the living room until you’ve finished building the walls…

As a final word, don’t take this article as a negative reflection on the use of software prototyping techniques – there are far more benefits than drawbacks…

* name changed to save on blushes and prospective lawsuits…

Here are some links to other articles which might be of some interest if you want to know when software prototyping is appropriate:

h1

Thought for 2010

January 4, 2010

And then one day you find
 ten years have got behind you
 No one told you when to run,
 you missed the starting gun

  - Pink Floyd, “Time

Once again, another year ‘gets behind us’ and another presents a new set of challenges and opportunities.  I’m fairly sure that Roger and the boys didn’t exactly have effective software project delivery in mind when they penned those immortal lyrics, but the sentiment rings true in this field as in many: time passes. 

I don’t mean to be negative, though: whatever your history of software project delivery, that’s in the past, history, done.  The present and the future are the only things you can change, so why not take a critical view of your software development processes and resolve to do things in a smarter way?  Perhaps your change process is a bit flaky, or scope creeps uncontrolled into unknown places.  Whatever your situation, I strongly recommend making a conscious decision to try something new – and software requirements prototyping is one such technique which might make all the difference…

Make 2010 your year of effective delivery.