Deskspace Blog

Chapter 2: Post Production Pro

[Back to deskspace.com]

Attending IBC in Amsterdam early in September in order to do a Press Conference to Launch Post Production Pro I took the opportunity to visit the Stands (Booths if you are North American) of the main competitors to our product. One wasn't actually at the show although I gather they held a party, perhaps to celebrate not having to stand on a stand for 5 days? I also talked to various resellers and actual users of the competing products to find out what they thought of the competition so we could plan how best to market Post Production Pro.

Several things struck me:

Software DNA

You can see the DNA denoting the origin of each of these products quite clearly in their current form. The DNA of an software product encompasses the key assumptions about the main purpose of the system made by its original architect. Such assumptions are virtually impossible to remove later when marketing say the product should also do something else, not originally envisaged, unless you rewrite the entire system. Having recently rewritten our original first generation Deskspace system, aimed at the law firms market, into the second generation aimed at any type of professional - using a very high level of configuration to achieve this - I have learnt alot about software DNA. For example, one competitor was originally a room booking system. Today may years later, if you want to plan an activity that will not occur on your own premises you still have to create an imaginary "Room" in which that activity takes place.

Powerful but difficult to use

The competiton produce undoubtedly powerful products, if you know how to do it you can do some great things with them. Some very clever people have laboured for years to extend and develop further the original information systems envisaged by their creator and you have to give them great respect for that.

However, the key word here is "IF". In reality, talking to actual users, they generally find much of what these systems will do far too complex to use in practice in a frantically busy working environment.

True Ease of Use

Thus when we presented Post Production Pro and said that at our first deployment at Shepperton Studios they had used it for 12 weeks before asking for any training - I detected an element of surprise in the room.

In our design we have focused on what we call "true ease of use". That means that a member of the target user group can sit down at Post Production Pro and use it without formal training. They may require training or master classes to learn about the more sophisticated power user shortcuts, but that comes later after they have become familar with basic use of their new information system.

What users of competing products say

Interestingly, having talked to quite a number of users I have yet to find any actual user of the competition willing say anything really positive about the system they are using. Comments like:

"the best of a mediocre bunch"

"I hate it but we have paid for it so we have to use it for several years minimum"

"I can't wait to get rid of it - as soon as my boss will agree"

"It falls over regularly when linking to our core enterprise content management system and we have to wait for several days before they fix it. After a few months the supplier's interest in supporting us has much reduced"

are all I have heard. In fact so negative I searched hard for a positive comment I could include here for balance, unsuccessfully. So it is up to me to give the positive comment that, as I mentioned above, I am personally very impressed by what these systems will do, if you know how.

Charcoal Interface

I could hardly help but notice that many of the current generation of digital asset management and editing software made extensive use of grey and near black interface elements and thus decided to offer an alternative interface for Post Production Pro inspired by this approach.

Three days later we has a trial version we shipped to several users to try, got their feedback which was enthusiastic, made a couple of adjustments and released it. Thus our users can now select from three interfaces:

"Lite" using simple graphics for low powered machines

"Pro" our original much loved colour keyed interface in mathematically balanced shades

"Pro Charcoal" using mainly mid / dark greys and near black with a few hints of the original colours

===ENDS===

How to deal with Address Management?

[Back to deskspace.com]

Basic Decisions

When designing any information system that includes some form of contact management system there are a common set of decisions to be made before you get very far:

(1) How will we handle peoples' alternative contact details, work, home etc?

(2) How will we handle addresses?

Over the last ten years my approach has developed from the keep it simple, home and work details in a contact record approach, essentially a flat architecture linking into a related work "Organisation", to our current approach where:

(a) every contact has unlimited different personalities [ie different personas for home work and other activities]
(b) every organisation has unlimited different locations [ie different offices etc]
(c) every personality can relate to a specific organisation location or not as required
(d) every personality and/or location can relate to a specific address if required
(e) every different address comprises a record in the address table but no address is ever duplicated

Pros and Cons

The advantage of our earlier approach was simplicity, always a virtue, and it took very little time to produce.

The downside is its very severe limitations. Generally with this sort of approach there are never enough places to put the new information users want to store and you end up with address data in the notes field. It offers no means of retention records of previous employment, always useful when analysing social and business personal networks or considering employment history.

The downside of our more sophisticated approach is the time and work involved in developing the model so that it actually offers users what they expect to see. The work was been a great deal more than I had originally envisaged. The investment in pursuing and completing this aspect of our system design has been significant.

The upside is that we do now have an amazingly flexible powerful but easy to use contact management system which through its relational structure offers the ability to record whatever information our users wish and also offers lots of real added value. Now, for example, our users can see who shares an address, who used to work together or do work together, how far apart are different people and/or organisation locations, which contacts and/or offices are any given country, region, county/state, city, town - ie all the "natural" questions that are not so easy to answer using post codes.

Automatic Address Cleanup

We have necessarily had to create address cleanup procedures which is able to take the various forms of address data in legacy systems, from everything in one address field upwards, and correctly parse the different elements out into Country, PostCode, County/State, Place, subPlace, Road etc fields.

This gives us an enormous advantage when starting to work with a new client - since our ability to take their existing legacy contact data, which is seldom in good order, and automatically create from it a full relational address structure has significant value add from their perspective.

UK Geographic Address Structure

As a consequence we have created our own UK structure for all the main geographical elements in the UK including postcodes which has proved a very useful resource.

Useability

In terms of useability - always the key measure of successful design - our approach is to give the user with a simple requirement a simple interface which merely stores and displays the required single name, address and other contact information. On input they can select from existing addresses or input a new one. If they input an existing address the system identifies this and gives them the existing address.

It is only when they want to create a further address that more options appear and it becomes evident that they can store many more different addresses.

Future Proof

The long term upside for us is that our investment in creating this level of sophistication future proofs our data architecture since its completely relational and extensible structure can easily accommodate any conceivable future requirement and hence we will have to do very little to it for the forseeable future.

===ENDS===