In a recent statement the Advanced Media Workflow Association (AMWA) – perhaps best known for their work on the AAF format – and the EBU announced that they are co-publishing a Request For Technology through a joint working group called the Framework for Interoperable Media Services (FIMS) Task Force. The Task Force’s overall aim is to address interoperability issues in digital workflows and the purpose of the RFT is threefold:

• Define an overall architecture for integration of reusable components
• Validate this architecture by applying it to three services
• Develop a list of appropriate services for the entirety or part of the media industry

As background to the need for a standardised set of services the RFT raises two key sets of issues for our consideration (describing them as justifications would be too strong a phrase at this point):

• Limitations of current (or traditional) approaches – these include problems surrounding interoperability, maintenance, scalability, dynamic discovery, dependence on vendors for customisation and implementation of solutions, etc.
• Media industry characteristics – this lists issues believed to be unique to media technology such as large file sizes, highly collaborative workflows with significant “human” task elements, streaming, multiple resolutions, special time requirements, etc.

Both of these lists make familiar reading for industry professionals as being representative of issues that we have to deal with on a regular basis. The implication of the lists is that they describe the set of issues that a collection of reusable and standardised industry services can address, and this is where AMWA/EBU’s view differs from mine.

Firstly, the limitations of current approaches as expressed aren’t incorrect, but they are generic IT system complexities that are simply becoming more common in the media industry as the scope of IT-based media systems, their complexity and associated integration requirements grow. Some of these limitations need to be addressed with better implementation methodologies, and others will require a shift in thinking from vendors - to provide external interfaces that are as rich and robust as those available internally, for example. Some of the issues seem to be somewhat misplaced - for example, it is hard to see how a set of standardised media services will be able to address issues around the availability of appropriately skilled technical talent (the point on “dependence on vendors, above”).

Secondly, the media industry characteristics correctly identify key issues affecting system implementation in the media industry, but I can’t see how standardised services will solve, for example, network-related issues surrounding the transfer of large files. In fact, real world experience shows that although the management of transfer requests can be service oriented, the actual transfer of large files should be kept outside the SOA infrastructure.

Lastly, there is a more general problem with this approach. I believe that there is a risk that the Task Force will get plenty of responses, each of which being a version of the interface method that the respective vendor has or intends to implement, which is specific to the needs and world-view of their product. The Task Force will then have to face the choice of choosing to support one vendor's view of the world, or mixing definitions from several vendors that will end up as a least common denominator of functionality that ultimately no vendor will be prepared to implement.

I believe that AMWA/EBU have identified the appropriate architecture and building blocks that organisations need to adopt to simplify future media systems integrations, as shown in the figure below extracted from the RFT.

Taken from Section 10 of RFT from joint EBU-AMWA Task Force on FIMS

However, what is needed as a first step is an adoption by vendors of open IT standards and, as mentioned above, robust and rich service-oriented interfaces that are well documented, that are exposed using standard IT protocols such as SOAP or XML over HTTP, and that can be easily accessed using widely available integration tools. Attempting to get vendors to implement a rigid, standardised set of service interfaces that could remove their ability to differentiate their products by providing their own features is taking the standardisation efforts too far and risks distracting attention from the fundamental issues in my opinion. But maybe it should not be a surprise that the solution to these problems is seen by standardisation bodies as an opportunity to create a new standard. All this said, I would encourage all vendors to have a look at the RFT and think about how their interfaces would fit into the landscape described. It’s the right technical direction regardless of the success or otherwise of the standardisation process.

Why do so many media-oriented applications, particularly in the broadcast domain, have such awful user interfaces? One answer could be that whilst software engineers in the media technology space are very clever people, and have solved a lot of very hard problems inherent in manipulating, managing and storing video, none of them would ever be hired as UI designers. Many of them wouldn't actually ever be hired as systems architects either - but that's for another day and another blog post...

At times it is almost like there is a button in the design environment called "Make Crappy" that spits out a standard terrible looking Microsoft based interface, preferably in light sludge grey.  Media asset management/content management applications can be singled out particularly for attention - or lack thereof - most of the UIs on MAMs tend to look as if they were added in a couple of weeks at the end of development - when Marketing reminded Engineering that most creative professionals tend to stay away from the command line. Craft video editing applications tend to be better, but then they should be, as they have had substantial user input over the years.

Hopefully this will change.  There have been a couple of good blogs recently that touch upon this, and I would urge people to send these links to as many vendors as they know.

http://www.marketingtechnologydiary.com/2009/11/dam-20-user-experience-p...

http://www.alistapart.com/articles/the-wisdom-of-community/

There has been some progress - BT Mosaic's UI was actually designed by proper designers and it shows, but I do wonder just how good it would look on the 17inch or 19inch screens that are prevalent in most media organisations, as opposed to the glorious widescreen monitors that you see it running on at trade shows. Regardless of this, they deserve credit for realising the importance of providing tools that actually look and work as if they are intended to be used.

Longer term, this issue may naturally fade away. We are starting to see the emergence (or re-emergence) of 'middleware' tools in media technology that naturally separate the underlying engine that carries out tasks like indexing, searching, moving and conforming, and the user interface into which this functionality is exposed.  As an example, BT Mosaic itself is based on this architectural approach, where the underlying engine is a mixture of off-the-shelf components from vendors such as Oracle and Blue Order, and BT's own custom development, coupled with a rich, browser-based user interface. This emerging architectural approach opens up a lot of interesting potential, and in particular raised the question of just how much of a content/asset management system do most users need to see, and how much functionality should simply be accessed by users from within their existing applications, through mechanisms such as plugins.

Adobe is moving in this direction - several applications in the Creative Suite have, or are expected to have the ability to integrate external functionality using Adobe's Flash technology with a technique called Flex Panels. As an example, editors could search for library content, request transfers and even log data from within an Adobe CS5 or 6 UI, with the asset management system being only a back end that deals with requests from the Adobe tool.  This would allow the software engineers to focus on the hard back end stuff and leave the UI stuff to the Mac-heads. 

There are some systems and technologies coming on the market that support this approach - Alfresco is an advanced and feature rich open source content management system for rich media and documents, and is in fact used by Adobe in its LiveCycle workflow suite.  Vidispine is a new entrant offering media enabled middleware, which specifically does not have a UI, but which is designed to be integrated into other systems.  Even the larger Enterprise Content Management vendors, such as OpenText have the capability to support this approach through their adoption of more open technology standards (despite the fact that the Artesia UI was actually pretty decent).

But to be fair, this is not just about engineers.  It is about technology companies understanding their target users and why they buy products.  And one of the best, and graphical explanations of why we need a step-change in thinking and execution in this area can be seen by following this link.

http://www.scottmonty.com/2009/10/why-apple-google-win-and-your-company....