Mobile Device Convergence

Watching the development and evolution of portable digital devices is the most interesting tech story at the moment. In theory, as I have said before, all media is now digital, so we could have one portable device for a media player, portable game console, media capture, and two way communicator of voice, text and anything else digital.

It is obvious that all the players are working towards this convergence from their own angle, and the phone people have pushed it the furthest. Nowadays it is difficult to buy a phone that does not also have a camera, many phones have simple games and phones are quickly developing their media player capabilities. So why am I skeptical? For example, I have just bought a cell-phone without a camera and an iPod. I expect to buy a new digital camera before the summer.

One problem is form factor. In reality there are different sizes to portable devices, and something with a usable keyboard or screen may be too big and clumsy to be taken everywhere. For example, I bought the iPod Shuffle to listen to podcasts mainly at the gym. The Shuffle is perfect size and weight for listening to audio while working out, but it is too small for most anything else.

There is also some utility to keeping functions separate. For example, I do not want to bring my phone with me when I work out, so I have a have a separate iPod for playing media. At other times, I have my phone with me and play media on my iPod. Another example is that I may have a PDA for work and prefer to have a separate cell phone so that I do not have to bring the PDA everywhere.

However the most important problem is ownership. I do not own my phone, "The Man" owns my phone. In this case the man is the phone company and they are not going to let go. A specific example of this is the experience we had with my son's camera phone with a removable media card. We copied pictures he had taken for a school project to the card and used a USB adaptor to load them on to the computer for editing and printing. There we discover that the pictures are in a proprietary format that a photo editing suite cannot handle. The only way to access the pictures is through the phone companies data service and lame web based picture editor.

I was not in the slightest bit surprised by this. Long ago I had concluded that there is no point in buying media for a phone as I am sure that the media will turn out to be incompatible with the next phone that I will have to get in a couple of years time. I do not like being owned, particularly by the phone company, which is why I will not buy a camera phone or a media player phone, and I will be very leery of using a phone based device for business purposes. End of convergence.

HDTV - Not

While there is plenty of chatter about HDTV, there is remarkably little action. Pundits say the problem is consumers who have not upgraded to a HDTV set. However there is another more important problem, and that is that there is absolutely no reason to go out and buy a HDTV set because there is no content.

Four years ago, we bought a 16x9 TV set expecting the HDTV revolution to arrive real soon now. So, for four years we watched even the slimmest TV starlet come across as unnaturally broad. Recently, we upgraded the cable box to HDTV with a DVR. I can report that the DVR is a great hit with my family and that the HDTV component is not used.

The first problem is that there very little HDTV content in the first place. We get 11 HDTV channels and most of them only broadcast HD content for part of the day, or only broadcast for part of the day. Today, one HDTV channel from a local station came up with black bars all around. It was a HDTV show that was being broadcast as a normal TV show with black bars top and bottom, and then it was sent out on a HDTV channel with black bars on either side.

However, the serious problem is that the HDTV channels are in the obscure 7-mumble-mumble range on the cable system. So I frequently find my family watching a show that is available in HDTV on the regular channel. Either they do not know, or they have not looked to see if it is available in HDTV. I cannot get my family to change their channel selection habits, and in truth it is inconvenient to go an look for a show that may not be there in an obscure part of the "dial".

There are more problems. For example, I want to upgrade our second TV to one of these new LCD models, however I am not going to pay the rapacious cable company for a second cable box. (Don't get me started, I can rant about the horror, inconvenience and annoyance of cable boxes for hours.) So I am going to hold out for the elusive cable card, whenever that arrives.

The end result is that HDTV is just not happening and everyone is waiting around for someone else to put the pieces together.

More on Microformats

Don't let the tone of my last post fool you, the Emerging Tech SIG meeting on Microformats was not a waste of time. My problem is that I know what Microformats are, or at least I know what I want them to be, and I am frustrated that they not being presented in a way that is clear and comprehensible to everybody. Microformats are a good thing, and a good clear story will help their broad adoption more than anything else.

Apart from that I took away a couple of ideas of note. Because a Microformat is both human and machine readable, there is only one copy of the information. As a good database person, I know that duplicated data is dangerous. Previous attempts to achieve the same goals as Microformats had the information in a human readable format and the same information repeated in metadata on the same page. This immediately leads to a data quality problem as the software readable form cannot be easily proof read and quickly diverges from the human readable copy as the page is edited.

In this context, the acronym DRY (Don't Repeat Yourself) was used. I keep hearing this acronym, particularly at the Emerging Tech SIG. Perhaps it is the battlecry of the Noughties.

Microformats

Tonight's Emerging Technology SIG meeting on microformats was a mixed bag. On the one hand there were a lot of clever people in the room, in the audience as well as the panel, who knew a lot about microformats. During the discussion there was some interesting fencing between certain audience members and the panel and they maneuvered to capture the high ground.

On the other hand most of the talks went over the head of the general audience who came along to find out what microformats are. Fortunately there was a person in the front row who after the initial talk baffled most of us, was old and wise enough to be able to ask the question "What are microformats and can you give us three simple examples of how they are used?"

Part of my problem is that I went into the meeting with some concept of what I want microformats to be. I want little pieces of embedded HTML/XML that can go in web pages, emails etc. that both renders as a normal text and at the same time contains structured data that can be interpreted by software.

For example if I am looking at a web page or an email that contains a meeting announcement in a microformat, I would like to both read the meeting announcement and to right click it and be given a context menu that would contain "Add to Calendar ..." amongst other actions. Selecting "Add to Calendar ..." would bring up the Calendar application which then could add the event without further intervention.

To make this happen the browser or email client would have to know that I was right clicking a microformat, and know a list of applications that would be able to deal with that microformat. For example, I may want to add the calendar entry to my calendar or to my blog. Also, the application receiving the microformat needs to know how to deal with it.

From the meeting, I gather that this is close to what microformats are, although they also seem to be something that is elusively more that this. Unfortunately the microformats.org web site is particularly unwilling to take a position on what they are, preferring to have a completely abstract definition, while at the same time give concrete examples of particular microformats.

iPod Fever

I got an iPod Shuffle for listening to podcasts a couple of weeks ago, and despite some initial problems, I am very pleased with it. There are still a few rough edges with iTunes. It may be fine for someone who wants to collect and listen to music, but it does not work quite so well for podcasts.

A big rap against the iPod is that it does not have a radio. I got an iPod because I wanted to listen to podcasts while I worked out, and as radio reception is broken at the gym, I was not looking for a radio anyway. With a little experience I have come to realize that a radio in an iPod would be completely superfluous.

The point of the iPod and a podcast is that I can listen to the talk show I want to listen to, when I want to, rather than being tied to the tyranny of the radio schedule. Initially I thought that I would miss the serendipity of having to listen to the available talk radio, however there is plenty of serendipity when you subscribe to the right podcasts.

Software Development and Content Management

Recently, after I wrote about Content Management for consumers, I realized that the software that I use every day in my job as a Software Developer is also a Content Management system. In bald terms, a Content Management system consists of a content repository and workflow that define and controls how the content is managed.

A software system comes from a collection of source code that is maintained in a Software Configuration Management system (SCM). It allows you to see each change to the code and who made it. A sophisticated SCM allow for code development along different branches at the same time. A SCM is in effect a content repository.

Some people on reading this will say that a Content management system means that all content is kept in a database. I will explain on another occasion why it a bad idea to lock content away in a database and propose a better solution for a content repository.

In the system I use we have a bug tracking system that is called an issues system because issues is good newspeak for bugs, and also because the system is used for tracking not only bugs, but also features and enhancement suggestions. Moreover the system is set up so that you cannot do a code checkin without tying the code change to an issue. This allows the system to check that the code change is made to an appropriate version of the code.

The point of all this is that the bug tracking system defines and controls the code development workflow and is tightly tied to the content repository. Thus the whole thing is a Content Management system.

Ruby on Rails

Slashdot must be getting desperate. Yesterday they had a lengthy discussion on the Future of Emacs, and today they had yet another discussion as to whether Java is so 90s. Meanwhile, tonight at the SDForum Emerging Tech SIG, we heard Tom Hill (founder of the SDForum Java SIG) talk about Ruby on Rails, the hottest new software technology on the block.

Ruby is another of those object oriented scripting language that is apparently typeless but seems to always do what is expected without overspecification. Rails is a web application framework written in Ruby that is also designed to do just the right thing. Together they make a terrific base for web based applications. All you need is Ruby on Rails, a database, a web server and a little development time and you are in business.

Tom touched on many interesting topics during his presentation. The one that struck me is the treatment of persistence in Ruby compared to say Hibernate. Hibernate is a Java framework that I mentioned in my last post for persisting Java objects in a database. With Hibernate you specify the object in Java and also specify the database schema and Hibernate does the mapping and transference between these two representations.

In Ruby, the ActiveRecord component gets the object specification from the database schema and creates an object based on the database record structure. There is only one specification of the object structure, so there is no problem with synchronization of specifications. Moreover, the Ruby object automatically adjusts to changes in the database schema without necessarily needing changes to the program.

In practice, a database needs its schema otherwise it would not know how to access and deliver its data. In this light, having the application language bend to use the database schema for its object structure seems sensible, and Ruby makes it seamless.

POJO

As a young newly minted software person, one of the first things I remember hearing was an engaging a talk on the issue of separating business logic from implementation. That was mumblety-mumble years ago. How times do not change. Tonight at the SDForum Java SIG we heard a talk on exactly the same subject.

This time the talk was wrapped around the subject of POJO, which stands for "Plain Old Java Objects". Chris Richardson, author of a new book "POJOs In Action" spent most of the talk telling us what POJO are not. In particular POJOs are not Enterprise Java Beans (EJB).

Underlying all the negativity was a positive message. Write your business logic as a set of plain old Java objects. Then implement the application through lightweight frameworks. Use Hibernate or JDO to make the objects persistent and Spring to provide transactions.

The important concept is that you do not change the business logic code. These frameworks are declarative specifications in XML that describe the implementation of the business logic without you having to change it. I know from my experience with JDO that it is not quite as easy as all that, however it seems like we are still headed in the right direction if not making a lot of progress.

The Future of Music

Some time ago I wrote the following in a piece on intellectual property in the digital age:

"... record company that on one hand pays radio stations to BROADCAST its hit song, while at the same time complaining that it is losing money because people are sharing the song on their computers"

Today I was looking at internet radio software that receives a broadcast stream from an internet radio station, and converts each song into a MP3 complete with ID3 tags. The point is that to build an MP3 collection, you do not need to illegally download music, all you need to do is capture the broadcast stream.

In practice this turns the economics of music on its head. In the past, performers made most of their money from recordings and used live performances to promote the recordings. The emerging business model is that performers give away their music to build an audience and then make their money from live performances.

In practice, this model has a lot to recommend it. As the audience grows older, they tend to become financially better off and willing to pay more for live performances. Properly managed, a performer can build a lifelong career that becomes more and more rewarding. Not surprisingly, this business model is both well proven and emerged in Silicon Valley.

Consumer Content Management

Could there really be a huge and important consumer software category that is not being properly addressed? I got to thinking this when I happened across a piece that proposed the emergence of a new type of software, the media file "Type Manager". The concept is that each type of media like pictures and music needs its own file manager that knows about that type of media.

I could write a long harangue about how awful these programs are and how far I will to go to avoid them. For example, one major peeve is that they deliberately hide the location of the file so that when I want to edit it or use it in another application, I have to resort to some trick to find out where it is located so that I can open the file in that application.

However a long harangue would just obscure a much more important point. There already exists a category of software that addresses all the issues raised by the media file type manager and does a lot more. It is called Content Management.

As a software category, Content Management has gone through the usual evolution. The original applications were high-end one off applications created for demanding users like CNN and the BBC that have enormous content management problems. At the same time a mid-range thread emerged from web media organizations like Salon who developed their own software to manage their production (and which has now gone Open Source). Now Content Management is expanding into general use as all organizations discover that they have digital content to manage. The final step is for Content Management to become a consumer product.

Content Management has three major components:

• Version management. Every time you edit a media file, for example, changing the level of an MP3 or cropping a digital image, you create a new version of the file. Version management keeps track of all the versions of a piece of media and how they are related.
  
• Metadata management. All types of media files contain metadata, sometimes known as tags. However, there is always the need for more metadata, some of which, like version information, does not really belong in the file. Better to extract all the metadata and put it in a database where it can be searched, collated and aggregated.
• Workflow. This is the major part of professional Content Management and in some sense its reason for being. In a consumer application, a single person does all the tasks so there is less need for workflow, however it can still be useful for automating repetitive tasks.

The most important feature of Content Management is that it handles all media types. I do not want a separate application for each media type, each with its own user interface and set of annoying little quirks. Also, it is useful to relate media, such as keeping documents of lyrics with songs, keeping track of the music used in video and slide shows, connecting pictures, text and perhaps music in web posts.

There is a lot more to say about metadata, version management and the structure of a universal content manager. We will have to get to them at another time. For the mean time, are you ready for Consumer Content Management? I know that I am.