In part 4, I discussed using storyboards to represent user interfaces that could be cataloged based on different industry verticals.  These storyboards are abstractions of user interfaces that contain metadata which describes the user interface elements in terms such as type of user interface control, size, location on screen, datatypes, etc.  This metadata can be used by code generators to generate technology specific implementations of these storyboards (i.e. into a working user interface).  Business users can select storyboards out of a catalog or library that collectively would make up their business applications.

 

One of the questions I asked in part 4 was why we abstract at the user interface layer?  Abstracting at the user interface layer into a storyboard achieves several design goals.  One design goal is to abstract the user interface definition from its technical implementation.  This allows us to choose a technical implementation separate from the user interface definition, and allows us to code generate the implementation based on the storyboards metadata.  The metadata describes the user interface elements for any given storyboard.  It also allows us to cheaply and repeatedly produce user interface implementations.  Also remember that the user interface, and the functionality it represents, is what the business user interacts with 100% of the time and the only thing the business user really cares about.

 

The abstraction at the user interface layer allows us to specify how the data will get to and from the user interface.  If we apply the Service Oriented Architecture approach where the transport of data is typically web services, then the user interface can be hooked up to any service that provides two-way communications.  Whether the data source is a so-called legacy application or a database or web service or any data source for that matter, it is a simple process to hook up that data source if it is being exposed as a web service.  SOA compliant products exist today, such as Bridgewerx Business Integrator, that can expose any data source through web services allowing us to easily hook up user interface implementations.

 

People would say that each storyboard (i.e. a representation of a user interface) is unique on a per customer or per organization basis.  This may be partially true and our storyboarding tool would have to be able to easily modify the cataloged storyboard (and its metadata) to suit a particular customers requirements.  Fair enough, but at the very least if I was asked by a business user to develop an invoice screen, I should be able to go to a catalog of storyboards where there are dozens of invoice screens that contain the definitions of an invoice user interface in the form of a storyboard and I can show the business user and have a 80% chance that one of them will get us 80% of the way there.  I should then be able to load the storyboard into a tool that in 10 minutes will allow me to modify the storyboard to match exactly what the business user wanted.  Behind the scenes, the metadata would also be modified to match the newly modified storyboard.  Then we would move on to the next storyboard.

 

In a matter of days or a couple of weeks at most, working with the business user(s), we would have completely defined that business users application from a user interface perspective and without writing any code using this storyboarding approach.  Now we are in position to code generate these storyboards into a technical user interface implementation.  Take a few steps further and our storyboarding tool should also allow us to define or declare the data source(s) that the realized storyboards (i.e. technical user interface implementation) will use per storyboard, plus declaratively define any workflow, business rules or transactional requirements we may also require.  Theoretically, we can code generate the entire solution based on this declarative or metadata approach.

 

Now that we have described a vision for a user interface storyboarding tool and the metadata automation required, lets look at how we could make this a reality.  This will be the subject of my next post.