I live in a small town of about 5,000 people on the Sunshine Coast in BC, Canada.  Meeting my neighbors Grandpa was an interesting experience.  Grandpa grew up in the Northern part of the Sunshine Coast and has lived here most of his life.  I got to know him a bit when we were launching fireworks (its big here!) last Halloween with our families.

 

Over 4 months I would have occasion to bump into Grandpa on the ferry as I take a 40 minute ferry ride into Vancouver everyday, as does anyone that needs to make it to Vancouver from the Sunshine Coast.

 

Yesterday, I was sitting at the local Tim Hortons having a coffee and working on my new Acer 8204 laptop (which I purchased specifically for WinFX, Vista development), and I met Grandpa after I had been sitting for an hour, long enough for me to disappear completely into the computer.  He said, Are you actually doing something or trying to look intelligent.  I said I was coding.  He said, What do you do for a living.  "I write software".  He said, that he used to program assembler way back when.  He said, "if just one letter or number is off, it doesnt work!.  I said nothing has changed.

 

First, I was a bit taken back that he could even remember assembler, I cant, and he does not even remotely look the type.  Second, I was surprised by my own comment of nothing has changed since assembler.  Now really, we have come a long way since assembler, see Raising the Level of Abstraction .  But otoh, it is still true today one character or number is off in your source code that you are hand writing and it wont compile.  It is much easier to find the compile error today, I suppose.  And with Intellisense, how can you miss? (ha ha).  The point is, the computer is excellent at repeating precision instructions and we humans are not.  So why not get the computer to do the work of writing precision code based on a higher-level abstraction (i.e. tool) where we don't concern ourselves with hand writing low level code.

 

This makes me wonder about how far programming languages have come over the last twenty five years.  Personally, I am a Smalltalk fan.  The concept of everything is an object and message passing made much more sense to me than C.  The fact that objects in Smalltalk could do only three things made it easy for my brain to understand what was going on.  However, from an employment perspective, I chose and have been working with Microsoft technologies since 91 when VB1 was first introduced.

 

The only language that has come my way that makes me as excited like Smalltalk did is XAML.  I have discussed a bit about XAML in my previous posts.  Here is a snippet from the WinFX SDK help file for Build 5308:

I am impressed with XAML.  It is early game, but GDI has done well for 20 years, Microsoft is betting on XAML, WPF, WinFX and Vista as a worthy successor to GDI and hoping it will last as long.  For the computer user, the next generation XAML based applications will be like when HTML first hit the web, (then FLASH), where everyone, all of a sudden, is a web site designer   However, what shakes out is the next level of computing interactions based on these Microsoft technologies.

 

However, to make life a bit confusing, XAML is but one of the 5 ways, just using Microsoft Technologies to develop user interfaces.  Tim Sneath has an interesting angle on explaining these five UI technologies called, "Windows Forms, ASP.NET/Atlas, DirectX, WPF, Win32 - that's five UI technologies to choose between. How do I decide?"

 

Having read his article I am satisfied that using XAML and WPF to develop my Storyboard Designer Application is the right choice.  Once I have developed something, I can say to Grandpa that we dont have to worry about each individual character or number anymore, thats what the software tool does!

This last post in the series is to describe a few more details around the Storyboard Designer application I am building.  Storyboard Designer is targeted at Power Users and/or Business Analysts (BAs) to enable a quick way to design and construct custom business user interfaces, which will in turn become business applications. The application will allow for the design and construction of workflows, business rules and data access associated with these user interfaces.  This is done so in a storyboard fashion similar to what has been successfully done in the film industry for over sixty years.

 

Whats different about Storyboard Designer than other storyboard type applications?  From a marketing perspective it is targeted at business Power Users and/or BAs tasked with defining the requirements and specifications for a custom business application, including the UI, workflow, business rules and data access.  The idea is that requirements become specifications as defined (read: modeled) by the BA using the designer.  Since we are using XAML, the resulting specifications become the implementation.  Key point.

 

Storyboard Designer has a drawing canvas that will allow the organization of businesses and business applications.  A Power User can drag and drop UI components onto a canvas to build a user interface in XAML.  Storyboard Designer will offer catalogs of composite UI parts that are commonly used in business applications, plus the capability to reuse complete user interface definitions for common business objects like Invoices, POs and any other set of forms for that matter, built or purchased, all XAML.

 

One design goal is to ensure the BA can define (read: design) a business application using Storyboard Designer without writing any code.  Or at the very least meet the 80/20 rule.  Another goal is to provide an intuitive drawing tool that will allow the BA to specify (and as a result, implement) a business application in the shortest time possible.

 

Toolboxes of components will represent real world business application constructs, for example, an invoice form, people interacting with the invoice form in a workflow, invoice form business rules and invoice form data, all need to be easily specified (i.e. drawn) on the canvas.  In addition, objects need to be configured and hooked together to represent a real world business application.

 

Using XAML, we can more easily come up with a 3D virtual world that represents these objects in a way that dozens or even hundreds of user interface screens (plus associated roles, workflow, business rules and data for those screens) can be easily navigated to on the canvas, as thumbnails.  Clicking on any thumbnail will zoom the object to screen for editing.  Those that have played with the workspace zoom in Expression Interactive Designer will know what I mean as an analogy.  XAML will provide, layering, zoom capabilities and levels of transparency to show the connections to the various objects without the screen real estate becoming overwhelming or cluttered.  Look at how Google Earth or Virtual Earth is displayed essentially on one canvas using layers and zoom.  AutoCAD works in a similar way.  Storyboard Designer will implement similar concepts except we are looking at a map or CAD blueprint of a custom business application from a 3D drawing perspective.

 

Over the coming months I will put together a prototype of Storyboard Designer based on the specs described in this series.  I will come back to this topic when something is built.

 

The purpose of this ten part series was to discuss industrializing parts of the software development process we use to design and construct business software.  Storyboard Designer is my small contribution to industrializing software.  I have been in the software development business for 15 years and one conclusion I have come to is that the state of the art of developing software today is still trial and error most of the time.  Further, rarely does what we build meet what the business user actually required.  This is the semantic gap between requirements (i.e. the intent of the business application) and the executables (i.e. the ruin-time business application).  Talk about lost in translation!

 

Storyboard Designer provides the capability for business Power Users and/or BAs to easily draw business applications using a 3D visualization tool with the output being the actual executables for a custom business application.  Not only does the tool close the large semantic gap between requirements and executables, more importantly the tool can be used by the very people that know everything there is to know about their own business and what the business application is supposed to automate.  As a result of these tool capabilities, the time frame for designing and constructing business applications is dramatically reduced and on its way to becoming a predictable and repeatable process for delivering business applications that actually meet business user requirements.

 

Lets see if I can make this real

As described at the beginning of this series, I have a specific requirement for a Storyboard Designer application.  The specific requirement is to industrialize some level of the software development process used to design and construct business applications. The rational is that the end-user of a business application interacts with software through a GUI 100% of the time.  Therefore, provide a designer tool aimed at Power Users and/or Business Analysts (BA) who can quickly storyboard user interfaces, workflows and data access in the shortest time possible.  Storyboard Designer is not a traditional developers tool, but rather a visualization tool that can be used by a Power User and/or Business Analyst (BA) to quickly build scalable and robust business applications.

 

Think of it this way, senior management at FedEx, in the book, Reeenginering the Corporation, realized that the people actually performing the work on the shop floors knew their business processes inside and out.  And more importantly, knew what most of the solutions were to the problems they were encountering using traditional business applications and consequently, the business processes they imposed.  As a result of senior management listening to employees in the trenches, FedEx reengineered their way into an incredibly successful business.  In other words, they were the first to industrialize the way packages were shipped and delivered for a specific market.

 

Remember the introduction of FedExs online package tracking software?  So simple that anyone with some degree of being able to navigate the internet could use this tool.  Thats why it became #1.  Another example, closer to home in the software world, is MS Access and Excel, which are reasonably complicated software, but yet Power Users and BAs have developed an entire subculture of business applications running organizations today.

 

With respect to Storyboard Designer, a Power User and/or BA (the people that really know the business application in question), can create their own business applications in the shortest time possible.  The goal is to quickly create or reuse user interfaces, (composite controls and complete UIs from catalogs), plus being able to visually hook up the UI to a data source or workflow, with or without business rules and all without writing any a single line of code.  Is it possible? 

 

From a marketing point of view, all that is required is to put a usable storyboard designer tool in the hands of the people that know how their business works so they can build their own custom IT automation applications to suite their specific needs.  Just like how they build sophisticated Excel applications and Access database programs today, except I am hoping much easier using Storyboard Designer.  Thats the level of abstraction I would like to achieve.

 

As discussed in this series of posts, I came to the conclusion that XAML would be an excellent language to not only build a Storyboard Designer, but also have the output of the Storyboard Designer produce XAML as well.  XAML can be used to declaratively define user interfaces and workflows that run on WinFX without any further interpretation.  In other words, once compiled, it can be run directly on the OS.  This is very powerful.  Even more powerful is that fact that XAML is public specification and therefore portable language format that can easily be exchanged with our XAML enabled tools.  This means it is possible to create catalogs of real user interfaces and workflows that can be shared amongst people.  The specifications become the implementations using the designer tool.  This dramatically reduces the gap between requirements (i.e. intent) and deliverables (i.e. executables) that is so prevalent in the way we design and construct business software today.

 

Storyboard Designer will be a visualization tool in which Power Users and/or BAs can draw their business applications on a canvas using toolboxes of objects that they can drag and drop on the screen.  Objects will represent UI, workflow, data access. people and businesses all connected together and can be viewed all together.  This is a key design goal.  It is in someway like traditional architectural blueprints in the construction or manufacturing industry.  Think AutoCAD for designing business applications. 

 

So doesnt Cider, Expression Interactive Designer (which I am still evaluating), SharePoint Designer offer this already?  No, all of these (low level) tools require highly skilled developers and designers to be productive with these tools.   Storyboard Designer is aimed directly at the Power User and BA for an organization.  We are raising the level of abstraction in the designer tool itself so that a Power User and/or BA with minimal training or expertise can productively build their very own business applications.

 

Next post will describe some of the design details of Storyboard Designer and then we will wrap up this series of 10 posts.

In this series of posts, I describe a real problem in the software development process of designing and constructing business applications.  Not only is the design and construction process trial and error, (i.e. not predictable or repeatable), there is a tremendous semantic gap between describing requirements (i.e. intent) and the resulting deliverable (i.e. executables).  The reality is that business users interact with software 100% of the time through a user interface.  Thats it.  Business users dont care about technology.  They care about getting their customized business application designed and constructed in the shortest time possible for minimal cost (including TCO) and perhaps more importantly, does exactly what they envisioned it do to.

 

Having designed and constructed software for business users over 15 years, it seems that using a storyboard designer application to define user interfaces descriptions and business workflows is one way to help industrialize the software development process.  Further a catalog or library of pre-built storyboards with corresponding workflows, would allow a business user to choose from a catalog a set of storyboards that would assist in defining their specific business application in a short time period.

 

After more research described in the previous post, it seems that completely abstracting user interfaces is still unrealistic given the immaturity of language standards and tools. XAML as an eXtensible Application Markup Language looks very promising for describing Windows user interfaces and workflow.  Since the reality is that the majority of business applications are targeted for the Windows platform, XAML appears to be a great way to quickly define business user storyboards that can immediately be run on XP and Vista.  XP and Vista can execute compiled XAML (i.e. C# code) on their run-time platforms with WinFX installed, and render the user interfaces and execute the workflows on the business users computer screen.

 

There are a handful of XAML applications and tools on the market that may provide an environment for quickly defining Business User storyboards.  As discussed in the last post, we are going to start to look at Cider and Interactive Designer, both from Microsoft and targeted at different audiences.

 

Cider is used inside of Visual Studio 2005.  Anyone that has used Visual Studio WinForms Designer knows how quickly one can define user interfaces.  However, using traditional WinForms, the problem is that the user interface description is tightly bound to the code-behind.  Cider on the other hand, uses XAML to define the user interface and is completely separate from the code behind.  The fact that Cider is embedded in Visual Studio means you can hook up your XAML with any programming language and other components, all within the IDE.

 

However, the quick synopsis is Visual Studio 2005 is a full blown Integrated Development Environment (IDE) and while fine for me as developer, it may cost too much and will be too complicated for a Business Analyst or Power Business User to rapidly define a business user storyboard.  Also Cider still presents a relatively low-level toolbox full of discrete controls, whereas I was hoping to have a library of common composite controls and even fully defined user storyboards (like an invoice storyboard) as catalog items to browse, select and edit.

 

While Cider is great for an IDE and directly targeted at developers, I was hoping to have a higher level of composite controls and catalog capabilities.  Also by raising the level of abstraction, I want a simple storyboarding application that is purpose-built to rapidly define business user storyboards that a Business Analyst or even a Power Business User can quickly define, including composite controls and cataloged items (i.e. completed storyboards) to select from.  This is the main goal of my storyboarding application.  Perhaps Cider can assist me in building this application.

 

We will come back to Cider, but first we will take a quick look at Microsofts Expression Interactive Designer which just released as its first CTP.  Next post.

Last post we discussed several different XML markup languages for user interface definition looking for a candidate language for designing and constructing storyboards or at least assist in building a simple storyboard designer if no suitable storyboarding applications exist.  I hinted that I found a candidate.  It looks like XAML is good language candidate.  A concise overview of this technology can be read in a recent Forrester article called, WPF Will Dominate Rich Client Development.  Carl definitely gets it.

WPF stands for Windows Presentation Foundation which is Microsofts new user interface presentation technology that runs on Windows XP and Vista through WinFX runtime components. eXtensible Application Markup Application or XAML is the design-time language that is suitable for defining and construction user interfaces and workflows that are separate from code-hind (e.g. C#) as this is the code interface separation point, sometimes referred to as the plug-in interface. That means the user interface and workflow definitions are 100% portable and are distributed through a standard plug-in package (i.e. XAML).  XAML can be shared between XAML design-time applications without any translation cost or loss of fidelity.  XAML can also be run on Microsofts new application execution environment, WPF for business user presentation of the user interface and WF for run-time workflow execution.

 

One very interesting paragraph in the article is, The key is that XAML is a description of the user interface, not an abstraction of the user interface.  This is a subtle but critical distinction.  Other XML-based user interface (UI) languages, such as User Interface Markup Language (UIML), have attempted to describe the common capabilities of multiple UI technologies or even devices, and in order to do so, they must abstract the specifics of a given platform into a common generic format.  Inevitably, something gets lost in translation. XAML makes no claim to universality; it describes Windows user interfaces.

 

Telling statement lost in translation.  While I was thinking of having my storyboarding application generate multiple user interface implementations for different platforms as a goal, it now seems unrealistic.  The reality is that most business applications are written with a Windows user interface, which ultimately is my target audience.  The fact that XAML describes a design-time Windows user interface description using an XML markup language that is completely separate from code-behind is a key technology trait required for toolability which is one of the key concepts behind why XAML

 

Carls article further states, picture a prototyping tool that could be used by usability specialists to rapidly prototype and test designs. Authors note: hey, thats my idea! Users could also consider defining web server based process flows and integrations in a business process tool and then easily handing off specifications for the interfaces of individual services to a programmer who will populate them in Visual Studio.  Interestingly enough, it is no surprise that business workflows can also be defined (just recently) using XAML in Windows Workflow Foundation. 

 

Next post we will explore a number of designer applications and tools for rapidly defining business user storyboards using, or can output XAML.  First we will look at Microsofts Orcas Cider as a CTP XAML designer in Visual Studio 2005 and the first CTP release of Expression Interactive Designer (aka Sparkle) which is a standalone product.

In part 5, I discussed a vision for a catalog of storyboards that represent user interface screens, business processes and the metadata that describes these storyboard definitions.  For example, storyboards are descriptions of a user interface i.e. they contain no technology implementation details, but rather metadata descriptions of the user interface elements.  This metadata can be used by code generators to generate a technology specific implementation.  As discussed in this series, a business user interacts with the user interface 100% of the time and does not care about the technology implementation or the technical details, the business user just wants their application ASAP and for a minimal cost.

 

Storyboarding in the film industry is used to minimize requirements risk and maximize production efficiency.  Storyboarding in the film industry models the complete film in a very short period of time and cost.  The design of the film is complete up front and then the actual construction of the film is an implementation of the storyboards i.e. film rolling, sound rolling, lights, actors, action!. The software industry could learn from the film industry.

 

Lets put the concept of a catalog of business user storyboards aside for the moment and focus on the tools and languages that are available to design and construct business user storyboards.

 

As a quick reference check, lets look at a storyboard tool that already exists to see if it meets my requirements.  A company called Caretta has produced this fine storyboarding application.  While I think this is an excellent storyboarding tool, it has no code generation facilities or even the ability to output a definition of the storyboards in any standard format.  This is unfortunate, as this storyboarding application would have met most of my requirements.

 

After more research, I could not find any storyboarding tools that meet my requirements, so we need to take a step back and look at some language standards for defining user interfaces.  I found a good reference to start from, XML Markup Languages for User Interface Definition.  There are several possible candidates to choose from.  AAIML, AUIML, XIML, XUL, XMAL, UIML, UsiXML, DIWG, XForms, and on it goes! 

 

It is amazing to see how many XML markup languages there are specifically designed for defining user interfaces.  It also is amazing to see what various stages each standard is at on its quest to becoming a real standard.  The process is slow and lengthy. I wonder if the electronics engineering world went through the same arduous process of becoming an industrialized engineering discipline. 

 

At one point in the electronics world, (70's) it seemed to all converge around the invention of the 14 pin DIP as a standard plug-in or interface that allowed chip manufactures world-wide to package their circuits in a standard package and distributed through a catalog.  Today, there are millions of different circuits on these chips in the market world-wide, all offered through standard plug-in packages.  This is a good example of "technology" industrialization where a standard interface is highly beneficial to the industry overall.

 

Ok, now what?  I spent the last week researching these XML markup languages for user interface definition, to find a suitable candidate for designing and constructing storyboards.  I think I found one that will work.  Next post we will look at the findings.

Lets take a break from whats new in software development for 2006.  In Part 1 and Part 2 of why software industrialization, I discussed some basic concepts around what does software industrialization mean and why we need it. Software industrialization is designing and constructing software in a predictable and repeatable manner.  Software industrialization is also producing a software, of any sort, that actually meets the user communitys requirements, whatever and whomever they happen to be.  Thats it.

 

In our software industry, there is a still a tremendous gap between requirements (i.e. describing the intent of the software) and the actual software deliverable (i.e. executables).  In fact, if you look at and believe statistics, our numbers aint so good!  The reality is that, we as software developers or engineers, dont have any predictable and repeatable process for creating software and we dont get the software right the first time.  In fact, we may never get it all right.

 

I have been involved in the software development industry for 15 years and have worked for several companies both in Canada and the United States ranging from my own start-up company, that I co-founded with Barry Varga, called, 5by5Software, now Bridgewerx to the very large (Kodak, Motorola and lots in-between.  Each company had their own process for designing and constructing software.  These development processes ranged from fly by the seat of the pants to highly process controlled CMMI complete with formal assessments.  In these companies I participated in several different development methodologies including RUP, extreme programming, Agile, old school waterfall for those that remember, and a mix of pretty much everything in-between.

 

I have read several dozens of books on the subject of software engineering, hundreds of articles and attended many a conference/seminar on the subject area.

 

Based on 15 years experience, I draw a few observations and maybe a conclusion or two:

 

1. Its still the Wild West" when it comes to software development.

 

2. None of the software development processes or methodologies that I have participated in has proven that one is no better than the other. The harsh reality is that manual labor software development is still mostly a trial and error process.  Meaning we are still far away from making it a predictable and repeatable process.

 

3. I have had the good fortune to work with several dozen extremely talented and brilliant software developers/engineers, project amangers, BA's, etc., who are directly responsible for the success of the projects/products I have participated in.  It is these people that have made the difference between success and failure and had nothing to do with processes or methodologies or toolsets or programming languages or technologies.  Its all about the people!

 

4. There have been a few critical innovations of late that appear very promising for increasing the level of predictability and repeatability of designing and constructing software.  These innovations are described in a book called Software Factories  

 

5. Another critical innovation is the renewed interest around Domain Specific Languages (DSLs).  Every programmer should take the time to read Martin Fowlers most excellent paper called, "Language Workbenches: The Killer-App for Domain Specific Languages?  DSLs assist in raising the level of abstraction for developers to produce software in a more predictable and repeatable manner thats the real point behind DSLs.

 

6. All the business user ever interacts with 100% of the time is the user interface, graphical, text or otherwise.  All the business user cares about is that through the user interface they can get at, manipulate, save data in an intuitive and functional manner.  Functional manner means that the software does what the business user expects or wants it to do.  In our technical world, this maybe written as workflow or business rules or custom C# libraries, or whatever development artifact(s) represents this functionality.  However, we software developers forget that the business user does not care how it is done, or what with - when I click on this thing, here is what I expect to happen, your software needs to do that.  Its that simple from a business users perspective.

 

Point 6 will be a topic of a future post, because after 15 years in the biz, I finally get the business user.  And interestingly enough, from a programmer perspective, not getting the business user is the number one reason why software projects/products failed in 1994, and still failing today

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.