Object-oriented media: has its time arrived?

Earlier this week I was in Amsterdam and came across a heron, sitting patiently on the top of a car on Lindengracht in the Jordaan. Since gracht means canal you are probably not surprised. However, this particular canal was filled in many years ago (after a riot over a game involving catching an eel suspended on a rope over the canal, since you ask) so this heron's vantage point was nowhere near water. Two days later I returned to the Lindengracht and the bird was again sitting on a car. Is this, I wonder, a triumph of hope over experience?

I've been hoping for many years that broadcasting would be able to embrace the idea of transmitting a programme made of independent component parts ... objects. Multitrack audio is an easy example to understand: mix the instruments (objects) in the receiver instead of the studio. A listener could change the mix if required, to give a different balance between voice and background for example. The intended, or default, mix would be transmitted along with the objects.

This concept has recently gained traction in BBC R&D with a great paper from Tony Churnside linking to an interactive drama based on their concepts. A special kind of radio receiver, a perceptive radio, has been developed which adjusts a programme based on what it knows of the listener's environment.

The idea of building programmes from objects isn't new but in the past the technology (ie computer power) was restrictive and there wasn't really a distribution channel. The basics of this are actually part of the MPEG-4 standard, although they seem to have been forgotten behind the bright and shiny new video codecs. At one time we would consider using objects to counter bandwidth problems: distribute relatively static components early and slowly ready in the receiver to be put together on-the-fly with low bandwidth dynamic information. This is like the sprites used in video games or symbols on a weather map. The same techniques would allow an end user to take some control over a programme.

It is this last idea that is still the most exciting to me. Is it still a triumph of hope over experience? I note that Tony links interactivity to objects at the end of the paper, so I think we're getting closer.

Your clients and how they brief you

Briefs have been problematic, leading to misunderstandings and breakdown of relationships in many projects. How do you try to avoid this? We've long advocated having a company scoping questionnaire that is devised by the staff from their experience and tailored for particular clients. We've also suggested that you make sure this questionnaire is updated regularly to keep on top of changes and innovations that the teams have come across.

However, some clients feel the need to use their own way to brief. They may have an in-house approach and this can make it difficult for you to influence exactly what information you get from them. The best way in this case is to marry your own needs by finding the gaps unanswered for your scoping questionnaire matched against the brief you are given. Many clients will see this as a professional approach and be happy to provide the extra information. Some may not be so forthcoming. Whatever approach is taken - to scope together or for the client to brief you - the clearer the information at the start of a project, the better for all, as we know.

Educating your clients is in your interest. So where might they find help with briefing? Can you point them in directions that will allow a better fit with the information you need. If they use briefs, do they have a mechanism for revising the brief? Here is where you might influence them for the future.

With that in mind take a look at some of the guidelines for briefs for iMedia projects. Which guidelines line up with your needs better than others? What would help you work better with clients? Do some raise issues that your own scoping questionnaires neglect? You might use the guidelines to drive change to your own guidelines. Some companies use their guidelines to drive business to themselves as well.

• How to write the perfect brief, Harmony
• Writing a brief and how to get a project started, The Design Council
• Writing a website design brief that gets results, Mark Kelly, Smart Insights, February 2013,
• How to write a website brief, Method and Class

Using Prince2 and Agile simultaneously: symbiotic or chaotic?

Have these two approaches been causing your company friction? We've been concerned that they can seem to pull in different directions from a management point of view; but the business situation in iMedia - flexibility, fast-changing scope, and clients who want to see faster results - all play towards Agile.

It can come across as an us versus them situation between programmers and the rest of the team and management. Yes, you guessed it, it all comes down to control!

First let's clear up the Agile/DSDM approach conundrum. Agile techniques can fit under a Dynamic Systems Development Method (DSDM). DSDM has guiding principles that back iterative and incremental development: Agile seems to fit perfectly here. But DSDM goes further as it enshrines higher level management aspects like focusing on the business need, communication and quality: aspects of a project that fit with Prince2 methods. The linking mechanism may well lie in understanding DSDM.

However, DSDM, like Agile, is seen as an IT project methodology, whereas Prince 2 fits an international general project management image. There's the positioning of the relative approaches in a nutshell. If you work with clients who have a general business background they are more likely to relate to Prince2 principles which make overall communication easier in theory. If your clients are used to working with IT, they may well be au fait with Agile and/or DSDM approaches so communication at the product development stage might not be as big an issue as it can be. Doesn't it all relate to the project context?

If there is friction between your inter-team approaches involving Prince2 and Agile, there are pros and cons on both sides and both parties need to understand the core criticisms that can be valid. So, Agile methodology can be seen as: lacking discipline, lacking rigour, over-emphasis on product development, needing strong collaboration from clients, client-driven, putting over-reliance on visual documentation, nibbling away at the true project.

Prince2 can be seen as: over-bureaucratic, using linear development (a waterfall approach in IT terms), light on product development, a straight-jacket,over- business-driven, prefers non-visual documentation, takes too long to start, over-zealous about specification.

These can all be true depending on the context of the project, and projects differ as we know. Perhaps emphasis on one approach may be needed for one project and the other for another. What is clear is that unless your team are all pulling in the same direction, your project will suffer. The answer might lie in combining the best of both approaches because then they might demonstrate that ‘flexibility and dynamism can exist from within a structure of stability and control’. See page 8 of Agile project management: Integrating DSDM into an existing PRINCE2® environment, Best Management Practice White Paper.

This white paper is worth a look if your company is having bother with these aspects. Another perspective that reinforces the two working together can be viewed at Indigo Blue Consulting.

Orphans ahoy!

I've written in the past about orphan works. These are copyright things (works we call them in the rights biz) whose rights owner is unknown or untraceable. Now the UK Enterprise and Regulatory Reform Act has been passed and the game is afoot. An act name worthy of Yes Minister's Department of Administrative Affairs and one I try not to say out loud. This, amongst stuff about landlords and whistle blowers, gives the government the ability to issue laws to permit the lawful use of orphans and said laws (called statutory instruments or SIs) will be promulgated later this year. The drive from Europe is to allow non-commercial reproduction of orphans to preserve them and to permit access. I know that the boundary between commercial and non-commercial is both hazy and full of large rocks but it does at least draw a line many people find reasonable under the circumstances. However, the UK plan for orphans goes further, notably allowing commercial exploitation.

This is proving particularly unpopular with photographers and illustrators and has even been called the 'end of photographic copyright'. I suspect the debacle will not be as dramatic as many fear but it has to be seen in the context of how photographs and other images are treated on the internet ... posted and reposted and along the way losing any information about their rights ownership. There's a good (and for once non-hysterical) roundup of the issues on the Register.

As designers, builders and managers of web sites we have a responsibility to treat the rights of things on our sites correctly. This doesn't just mean clearing the rights any more. We need to make sure that any images have suitable metadata embedded in them and that any program systems do not remove said metadata. For example, ImageMagick does not carry over metadata when you process an image to, for example, resize it. However, there is a PHP Metadata Toolkit (probably others too) so you can read the metadata and then reinsert it. But you have to actively make sure it will happen.

Remember, as I said before, some day the orphan could be yours.