Metawidget: Collections Support Part 2 (More Advanced)

In my last post I looked at some quirks of using the ICEfaces PanelTabSet with Metawidget. Specifically, because PanelTabSet stores the selectedIndex of the current tab inside the component, the component cannot succesfully be destroyed and recreated.

To work around this we looked at using Metawidget's COMPONENT_ATTRIBUTE_NOT_RECREATABLE to preserve the selectedIndex at the expense of some dynamicism. We further looked at using JSF's binding attribute to try and claw back some of that dynamicism.

However, a different approach entirely would be to stop PanelTabSet storing selectedIndex internally! It turns out ICEfaces provides an API for this. The only question is where else to store selectedIndex, but keeping it inside the current request seems to work nicely. So:

1. Forget all about COMPONENT_ATTRIBUTE_NOT_RECREATABLE and the binding attribute (and related mMetawidget inside the managed bean)


2. Change the line in the IceFacesTabsWidgetBuilder that says...
   
   
   panelTabSet.getAttributes().put( UIMetawidget.COMPONENT_ATTRIBUTE_NOT_RECREATABLE, true );
   
   ...to say...
   
   
   panelTabSet.setValueExpression( "selectedIndex", expressionFactory.createValueExpression( elContext, "#{param['tab-" + attributes.get( NAME ) + "']}", Object.class ) );

So now you get fully dynamic tabs at the same time as tab switching working! This technique only applies in those cases where the UIComponent thoughtfully exposes such an API, but in such cases it's very useful.

Hope that helps!

Metawidget: Collections Support Part 2 (Advanced)

In my previous post, I showed how to render a Collection as one item per tab. This is pretty easy in most frameworks, but ICEfaces presents a challenge because:

1. The ICEfaces PanelTabSet doesn't have an option to switch tabs on the client-side, using just JavaScript and CSS to show/hide the tabs (RichFaces has switchType="client")


2. The ICEfaces PanelTabSet stores its tab state inside the component, so when doing server-side switching you cannot destroy and recreate the component or the tabs won't switch

In my last post I resolved this by setting COMPONENT_ATTRIBUTE_NOT_RECREATABLE on the PanelTabSet. I noted this would allow the user to switch tabs, at the expense of making the tabs themselves less dynamic. But a couple people wanted to know how to get the best of both worlds: how to switch tabs and have them be dynamic.

There are a few answers to this question:

1. There is still quite a lot of dynamicism, even with COMPONENT_ATTRIBUTE_NOT_RECREATABLE set. Metawidget is smart enough to work around the COMPONENT_ATTRIBUTE_NOT_RECREATABLE components, and still recreates their siblings and even their children. As the project from the previous post shows, you can have an 'Edit' button that makes the components (both inside and outside the tab) turn from read-only labels into input boxes


2. The COMPONENT_ATTRIBUTE_NOT_RECREATABLE only applies during POST requests. Re-rendering the page afresh as a GET request works fine. So if your user clicks a link to navigate into the page with the TabPanelSet on it, no problem

But there is a further case: what if I want to be able to add tabs with a POST request? Here we need something new. We need to be able to tell Metawidget: don't recreate the tabs normally (else we won't be able to switch between them), but do recreate them when I click 'add tab'.

I have put together a complete project you can download from here. It'll produce something that looks like this:


The trick is to use JSF's binding attribute. As I blogged previously, this is a little-used but very useful feature of JSF that allows programmatic control over your components. So in your page you do:

<m:metawidget value="#{headerDemo}" binding="#{headerDemo.metawidget}"/>

And in your managed bean you do:

public UIMetawidget getMetawidget() {

   return mMetawidget;
}

public void setMetawidget( UIMetawidget metawidget ) {

   mMetawidget = metawidget;
}

@UiAction
@UiComesAfter( "details" )
public void addTab() {

   mDetails.add( new Detail( mDetails.size(), "Detail #" + mDetails.size() ) );
   mMetawidget.getChildren().clear();
}

Hope that helps!

Metawidget: Collections Support Part 2

I was recently asked:

"I would like to create a widget that displays each item contained in a List using an ICEfaces PanelTabSet. I would like the widget inside each panelTab to be generated through Metawidget. How can I accomplish this?"

This represents (yet) another aesthetic preference for rendering Collections. Namely, rendering one item per tab. Some other preferences, such as rendering one item per row of a table, have been covered in a previous blog entry). As I said in that entry:

To support this, Metawidget provides WidgetBuilders.

So it's a case of writing a WidgetBuilder that will return a PanelTabSet for the List. I have put together a complete project you can download here. It'll produce something that looks like this:

Code for the WidgetBuilder part below:

package com.myapp;

import static org.metawidget.inspector.InspectionResultConstants.*;

import java.util.List;
import java.util.Map;

import javax.el.ELContext;
import javax.el.ExpressionFactory;
import javax.el.ValueExpression;
import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;

import org.metawidget.faces.FacesUtils;
import org.metawidget.faces.component.UIMetawidget;
import org.metawidget.faces.component.UIStub;
import org.metawidget.faces.component.html.HtmlMetawidget;
import org.metawidget.util.ClassUtils;
import org.metawidget.util.simple.StringUtils;
import org.metawidget.widgetbuilder.iface.WidgetBuilder;

import com.icesoft.faces.component.paneltabset.PanelTab;
import com.icesoft.faces.component.paneltabset.PanelTabSet;

public class IceFacesTabsWidgetBuilder
   implements WidgetBuilder<UIComponent, UIMetawidget> {

   //
   // Public methods
   //

   @Override
   public UIComponent buildWidget( String elementName, Map<String, String> attributes, UIMetawidget metawidget ) {

      // Not for us?

      String type = attributes.get( TYPE );

      if ( type == null ) {
         return null;
      }

      Class<?> clazz = ClassUtils.niceForName( type );

      if ( !List.class.isAssignableFrom( clazz ) ) {
         return null;
      }

      // Create a Stub to wrap around the PanelTabSet.
      //
      // This is because:
      //
      // 1. PanelTabSet will not switch tabs if it is destroyed/recreated. We must set
      // COMPONENT_ATTRIBUTE_NOT_RECREATABLE on it (see
      // http://metawidget.sourceforge.net/doc/reference/en/html/ch02s04.html#section-architecture-widgetbuilders-implementing-your-own-faces).
      // This limits some dynamicism, such as being able to dynamically add tabs, but there are
      // further ways around that
      //
      // 2. COMPONENT_ATTRIBUTE_NOT_RECREATABLE only works if there is a 'value' expression that
      // OverriddenWidgetBuilder can match against
      //
      // 3. PanelTabSet is a little unusual in how it treats its 'value' expression (binding it to
      // a UI mechanism, rather than a model mechanism) so we need to avoid using it. We use the
      // Stub's 'value' expression instead

      UIStub stub = new UIStub();

      FacesContext context = FacesContext.getCurrentInstance();
      ELContext elContext = context.getELContext();
      ValueExpression metawidgetValueExpression = metawidget.getValueExpression( "value" );
      String metawidgetValueExpressionString = FacesUtils.unwrapExpression( metawidgetValueExpression.getExpressionString() );
      ExpressionFactory expressionFactory = context.getApplication().getExpressionFactory();
      String tabSetValueExpressionString = metawidgetValueExpressionString + StringUtils.SEPARATOR_DOT_CHAR + attributes.get( NAME );
      ValueExpression tabSetValueExpression = expressionFactory.createValueExpression( elContext, FacesUtils.wrapExpression( tabSetValueExpressionString ), Object.class );

      stub.setValueExpression( "value", tabSetValueExpression );

      // Create tab set

      PanelTabSet panelTabSet = new PanelTabSet();
      panelTabSet.getAttributes().put( UIMetawidget.COMPONENT_ATTRIBUTE_NOT_RECREATABLE, true );
      stub.getChildren().add( panelTabSet );
      List<UIComponent> tabs = panelTabSet.getChildren();

      // Lookup the List from the parent Metawidget to see how many items it has

      List<?> list = (List<?>) tabSetValueExpression.getValue( elContext );

      // Create one tab per item...

      for ( int loop = 0, length = list.size(); loop < length; loop++ ) {

         PanelTab tab = new PanelTab();
         tabs.add( tab );

         // ...with each tab itself containing a Metawidget.
         //
         // The 'value' expression of each Metawidget uses the EL #{foo.bar[0]} notation for
         // accessing arrays

         HtmlMetawidget tabMetawidget = new HtmlMetawidget();
         ValueExpression tabValueExpression = expressionFactory.createValueExpression( elContext, FacesUtils.wrapExpression( tabSetValueExpressionString + '[' + loop + ']' ), Object.class );
         tabMetawidget.setValueExpression( "value", tabValueExpression );
         tabMetawidget.setValueExpression( "readOnly", metawidget.getValueExpression( "readOnly" ) );
         tab.getChildren().add( tabMetawidget );
      }

      // Return tab set

      return stub;
   }
}

Towards a General Purpose Architecture for User Interface Generation

Kennard, R. & Leaney, J. 2010, Journal of Systems and Software

Abstract

Many software projects spend a significant proportion of their time developing the User Interface (UI), therefore any degree of automation in this area has clear benefits. Such automation is difficult due principally to the diversity of architectures, platforms and development environments. Attempts to automate UI generation to date have contained restrictions which did not accommodate this diversity, leading to a lack of wide industry adoption or standardisation. The authors set out to understand and address these restrictions. We studied the issues of UI generation (especially duplication) in practice, using action research cycles guided by interviews, adoption studies and close collaboration with industry practitioners. In addressing the issues raised in our investigation, we identified five key characteristics any UI generation technique would need before it should expect wide adoption or standardisation. These can be summarised as: inspecting existing, heterogeneous back-end architectures; appreciating different practices in applying inspection results; recognising multiple, and mixtures of, UI widget libraries; supporting multiple, and mixtures of, UI adornments; applying multiple, and mixtures of, UI layouts. Many of these characteristics seem ignored by current approaches. In addition, we discovered an emergent feature of these characteristics that opens the possibility of a previously unattempted goal - namely, retrofitting UI generation to an existing application.

1. Introduction

Many software projects spend a significant proportion of their time developing the User Interface (UI). Research in the early 1990s found that some 48% of application code and 50% of application time was devoted to implementing UIs (Myers 1992). These figures are still considered relevant today, more so with the increased demands of richly graphical and web-based UIs (Jha 2005; Daniel et al. 2007), therefore any degree of automation in this area has clear benefits. This automation is difficult because UIs bring together many qualities of a system that are not formally specified in any one place, or are not specified in a machine-readable form. For example, a dropdown widget on a UI screen may have a data type specified in a database schema, a range of choices drawn from within application code, and a look and feel specified by a human-readable design document. Bringing these diverse characteristics together to enable automatic UI generation is a significant challenge and research in this field dates back over two decades. The work was given increased urgency with the emergence of ubiquitous computing (Weiser 1993) and its proliferation of different UI devices with widely varying capabilities. Approaches to date can be broadly grouped into three categories: interactive graphical specification tools, model-based generation tools, or language-based tools (Myers 1995). Each has significant disadvantages which have limited its success in industry (Myers, Hudson & Pausch 2000).

The main disadvantage of the first two approaches - interactive graphical specification tools and model-based generation tools - is that they inherently require software developers to restate information that is already encoded elsewhere in the application. This duplication is both laborious and a source of errors, as the developer must take care that the application code and the UI model stay synchronised (Jelinek & Slavik 2004). The main disadvantage of the third approach - language-based tools - is that generally programming languages "are not sufficient enough for complex UI modelling. To completely and formally depict the UI composition and behaviour, new attributes and properties are needed to describe the object data members" (Xudong & Jiancheng 2007, p. 540). Without these new attributes and properties, language-based tools must resort to generalised heuristics when generating their UIs. These generalisations invariably mean "the generated User Interfaces [are] not as good as those created with conventional programming techniques" (Myers, Hudson & Pausch 2000, p. 13).

UI generation has not experienced the same wide industry adoption and standardisation as, say, Object Relational Mapping (ORM) (JPA 2008). We claim that this is because existing approaches are impractical, not because the issue itself lacks urgency. A series of interviews conducted with practitioners across industry segments and software platforms (Kennard, Edmonds & Leaney 2009) found common experiences of duplication (Jelinek & Slavik 2004), common experiences of bugs caused by it, and a common desire for it to be addressed. One interviewee confirmed "the problem definitely exists. It's more from the business layer forward to the screen is the biggest problem because there are things out there like [ORM] which do from, sort of, business layer down". Another lamented that, when making a typical change to an enterprise system "the drudgery at the moment is adding the UI code, and adding the validation and giving that feedback. That's really quite unpleasant. It's the most complex of all the steps, actually, depending on the magnitude of the change". Some practitioners gave concrete examples "we've got a BigDecimal (Gosling 2005), and [the back-end has] set the scale to 8 but the GUI puts through 10, it [gets silently rounded and] passes all the way through. That becomes a real issue because it's really hard to find. That's caused us huge problems before". One developer reflected "it's a fairly established software engineering principle that the more you have to repeat something [defining fields in both the business layer and the UI layer] the higher the chances there's going to be an error in the code". Finally one engineer summarised "every developer who writes anything more than a Hello World application will have this problem. Most developers encounter this problem on a daily basis as a constant friction in their daily work". During publication of our 2009 paper, reviewers reframed our interviews in an academic context "the work is exceptionally well motivated... it is important for the [research] community to hear... nobody in a senior position in a software company today is going to not be aware of this problem and the various hacks, workarounds, and band-aids used to cover up the pain that it causes (at least not in a successful software company). Again, academics may be surprised by some of the comments and the gravity of the concerns, but I wasn't; this is a serious problem and there are partial solutions out there that various people employ with varying degrees of success".

Having established the urgency of the problem, the authors set out to address the impracticalities with existing UI generation approaches. We sought a well-motivated, well-justified approach guided by practice based research and human centred design approaches. These included open ended interviews, adoption studies and close collaboration with industry practitioners, as described in section 2. In doing so we identified five key characteristics we believe are necessary for any UI generation technique to achieve wide adoption or standardisation. Many of these characteristics seem ignored by current approaches. The full adoption studies will be published at a later date, but we discuss each characteristic in detail in section 3. In addition, we discovered an emergent feature of these characteristics is that they open the possibility of retrofitting - a previously unattempted goal - which we explore in section 4. Finally, we discuss future work in section 5.

2. Methodology

Given our strong focus on industry practice, and ensuring any UI generation is practical, it was important to engage our target audience early and often. One industry-based approach effective in doing this is iterative development. There are various definitions of iterative development, but all are common in trying to avoid a single-pass, document-driven, gated-step approach (Larman & Basil 2003). The iterative development methodology has interesting parallels to the research methodology of action research (Dick 2000). Indeed, action research's definition of a cycle of 'plan, act, observe, reflect, then plan again' (Kemmis & McTaggart 1988) would be a fitting description for iterative development. The outcomes from each cycle drive the planning for the next cycle, both in terms of expanding those areas that worked well and revisiting those that were less successful. This is particularly effective when either the problem or the solution are not well defined, as they afford the work the agility to change as its goals become clearer.

Our research methodology employed action research as a framework within which to formalise iterative development, allowing the work to be both accessible to, and guided by, observations from both industry and the research community. Observations were gathered through forum messages, open-ended interviews using simplified grounded theory (Dick 2005) and adoption studies1. Adoption studies were gathered retroactively from companies who had independently discovered and decided to apply our work, of their own volition, based on publicity from previous action research cycles. Companies were discovered through message forums then contacted to solicit a study of their experiences. We conducted seven such studies in all, ranging from private biotechnology and telecommunications companies, to government departments and academic institutions.

The last phase of each action research cycle reflected upon the observations from interviews and adoption studies as drivers for the next cycle. Action research delineates an explicit 'reflect' phase (Kemmis & McTaggart 1988) so as to bring academic rigour to the proceedings. During the 'plan', 'act' and 'observe' phases, reflection happens 'in action' (Schön 1983) with the 'action present' measured in minutes or hours. During the 'reflect' phase, however, the 'action present' is much more deliberate, being measured in days or weeks, which lends more diligence and formality to the Validity, Verification and Testing (VVT) of the research. It facilities the reconsideration of all design decisions, implementation details and observations from the preceding action research cycle in a holistic light, leading to key new insights.

This practice based methodology, conducted across three action research cycles over a period of three years, afforded us a breakthrough in our understanding of the problem domain. Our most significant finding is the identification of five key characteristics any UI generation technique needs before it can be practical in an industry setting. Notably, many of these characteristics seem ignored by current UI generators, which we believe is hindering their widespread adoption. The next section presents our action research results in detail.

3. Characteristics of a Practical User Interface Generator

This section explains the five characteristics we believe, based on our action research cycles, are key to a practical UI generator. We have derived these characteristics through interviews, adoption studies and close collaboration with industry practitioners. They can be summarised as: inspecting existing, heterogeneous back-end architectures; appreciating different practices in applying inspection results; recognising multiple, and mixtures of, UI widget libraries; supporting multiple, and mixtures of, UI adornments; applying multiple, and mixtures of, UI layouts. We will justify each of these characteristics in turn in the following sections. We will begin each section by first framing the characteristic within the literature and within observations from our discovery research. We will then move to justify each characteristic and discuss its technical details. Because of our strong focus on a practical user interface generator, we will discuss these technical details in the context of our own implementation, which we have called Metawidget. This implementation is the outcome of our action research, and the proof of our work.

Before we begin, however, it is important to first frame how the five characteristics fit together. There are a number of ways they could be designed into a UI generator, though we would caution against any approach based on presenting practitioners with multiple options or 'flags' - such approaches likely underestimate the sheer volume of variations and combinations the characteristics need to accommodate. In our particular implementation we have implemented the five characteristics as a pluggable pipeline (Vermeulen, Beged-Dov & Thompson 1995) as shown in below. Practitioners can plug in alternate implementations, or custom implementations, of each characteristic. This allows our implementation to accommodate the volume of variability while avoiding the performance overhead and maintenance cost of an exponential combination of 'flags'.


The leftmost 'lifeline' in the UML sequence diagram (the Metawidget) serves to coordinate the others and is not considered part of the pipeline. The remaining five UML lifelines correspond to the five key characteristics we have identified from our action research. The UI generation proceeds in a well-defined fashion along each stage of the pipeline, from left to right. Each stage is pluggable. As an implementation detail, each stage is also immutable. This helps with memory consumption and performance when multiple Metawidgets are used in the same UI.

Each of the UML lifelines and their corresponding characteristic is discussed in turn in the sections to follow. We begin with the first UML lifeline, the 'inspector'.

3.1. Pluggable Inspectors

Most UI generation solutions dictate that practitioners provide the generator with a centralised, single source of truth (SSOT). The solutions do this by defining their own UI modelling language or graphical builder tool, then require the practitioner to use their tool to define the UI. For example, UsiXML (Vanderdonckt et al. 2004) consists of "a User Interface Description Language (UIDL) that is a declarative language capturing the essence of what a UI is or should be independently of physical characteristics. UsiXML describes at a high level of abstraction the constituting elements of the UI of an application: widgets, controls, containers". GUMMY (Meskens 2008) is designed "in a similar way to traditional GUI builders in order to allow designers to reuse their knowledge of single-platform user interface design tools... there is a toolbox showing the available user interface elements, a canvas to build the actual user interface and a properties panel to change the properties of the user interface elements on the canvas". Internally, "GUMMY builds a platform-independent representation of the user interface and updates it as the designer makes changes. This allows for an abstract specification of the user interface" which it then uses to drive UI generation for multiple physical devices. However as Jelinek and Slavik (2004) observe, "a common disadvantage [of modelling languages and graphical builder tools] is the fact that the user interface is defined explicitly and separately" and therefore "the application and the corresponding [UI] model need to be kept consistent". Prat et. al (1990) agree, finding that in practical application design "the [back-end] requires a considerable amount of knowledge [much of which is] similar to that required by the [UI] modules".

Some UI generation solutions acknowledge this shortcoming and seek to reuse existing information already embedded in an application's architecture. Unfortunately they still require this to be rigidly centralised. For example, Naked Objects dictates "all the functionality associated with a given entity [must be] encapsulated in that entity, rather than being provided in the form of external functional procedures that act upon the entities" (Pawson 2004). Most industry systems do not adhere to such a 'behaviourally-complete' methodology. Rather, they use what Firesmith (1996) calls "dumb entity objects controlled by a number of controller objects". They do this in order to benefit from a rich ecosystem of technologies. What Firesmith terms 'controller objects' industry practitioners would term, but not be limited to, validation subsystems, workflow subsystems, rule engines and Business Process Modelling (BPM) languages. Indeed, as Pawson himself later concedes "most object-oriented (OO) designs, and especially object-oriented designs for business systems, do not match this ideal of behavioural-completeness". It is important to appreciate this is not because most business systems are poorly designed. Rather, they are seeking to leverage functionality provided by the large number of mature subsystems available in industry, in order to increase productivity and reduce development cost. It is still possible to have an SSOT whilst being decentralised amongst multiple subsystems, provided there is no overlap in the decentralisation (i.e. the workflow subsystem is concerned with different aspects of the application to the validation subsystem).

Our adoption studies underscored this point with industry practitioners. One commented "many frameworks or tools enforce the designer's vision on how solutions should be architected. What I liked about [your implementation] is that I could drop it in whatever architecture I was using". The phrase 'whatever architecture I am using' turned out to be critical, because real world architectures were found to vary widely - dependent on both hard, business requirements and softer, aesthetic judgements.

As an example of a business requirement, many architectures abstract their UI data into OO classes. It is certainly possible to generate UIs based on instances of those classes - indeed, this is the approach Naked Objects mandates. But business requirements often prevent this approach and it was found that being able to plug in a company's own back-end inspector was fundamental to the usefulness of a UI generator. One adoption study had defined the UI in their own, proprietary XML. "[Being able to write our own] inspector that knows our XML schema and can find all restrictions of the currently inspected field and add that to the attributes returned [was a key strength]". Another study had used rules in a database: "The main feature for us was the possibility to dynamically, based on rules stored in our database, create input screens based on user selections... it was important it supported our back-end. Being able to plug-in our back-end inspectors gave us the flexibility needed, it is impossible to support everyone's requirements [out of the box]... otherwise we probably would not have even tried it". Another adoption study used a mixture of third-party libraries: "we work with JDO, OVal, and some custom annotations, so being able to extend was a must for us". Another adoption study "we did not want to place view stuff into the model, and we did not want to place it in an [external] XML file either, because we would have to replicate the property name. [Instead] we built [an inspector] based on our properties files". By 'properties files' the team is referring to reading UI information from localization (internationalization) resource bundles. These examples demonstrate there are a multiplicity of sources of UI metadata. Furthermore, it is not difficult to posit other useful sources, such as Web Services Description Language files (WSDL 2001).

A common example of an aesthetic judgement revolved around the mixing of presentation information with business logic. Some adoption studies reported "there was some spirited debate [in the development team], since [annotating the business objects can] degrade gracefully if not in use. It still, to us, seemed cleaner to put UI-specific code outside of our business objects [in XML files]". Another said "business objects should be neutral regarding presentation - I am a supporter of separated tiers". But other adoption studies disagreed "while I appreciate the power within the XML inspectors, I used annotations to configure [my business objects]". Another "I don't mind [annotating], an annotation is just metadata". Interestingly, one study considered it a matter of scale: "for small projects it might not be a concern, so we find [the fact that it is supported] valid, but for larger projects where the architecture is more important, usually we want to keep a clear separation between layers, and it is not desirable to 'pollute' the model".

It is important to note practitioners are not simply talking about supporting many different back-end technologies. Rather, they are talking about being able to mix technologies, including custom subsystems and alternate implementations of the same subsystem. The latter is less an issue in 'full stack' proprietary software environments such as the Microsoft application stack, but in Open Source enterprise ecosystems such as Java EE there are often dozens of competing implementations of the same subsystem (Shan et al. 2006). There are even competing implementations of the core language (e.g. Java versus Groovy versus Scala). Software architecture therefore involves a myriad of choices, many of which have no 'right' or 'wrong', and opinions on which evolve over time. For example, business rule engines are becoming increasingly popular (Rouvellou et al. 1999). Any UI generator that seeks to dictate, rather than adapt to, a system's architecture therefore has limited practical value.

Our implementation addresses this characteristic of supporting mixtures of back-end technologies by defining pluggable 'inspectors'. It defines a minimal 'Inspector' interface and ships with a number of implementations of this interface to support extracting metadata from different, heterogeneous subsystems. The parent Metawidget (leftmost lifeline in UML diagram) requests information regarding a particular business object and it is the responsibility of each individual inspector to gather as much information as possible about that business object from its particular subsystem. A current limitation and open question of this approach is how to validate the completeness of the inspection. The issue of completeness is ongoing work.

Returning to our theme of an SSOT, our implementation also supplies a CompositeInspector, named after the composite design pattern (Gamma et al. 1995), to support combining the inspection results from multiple inspectors into a more detailed whole result, as shown below. This more detailed whole result forms a temporary centralised SSOT from the subsystems it is split across, so that it can be used to drive UI generation. This extraction and collation of metadata from multiple, heterogeneous subsystems is commonly referred to as software mining.


It is often said in software development that each design decision should "pull its weight" (Bloch 2001). That is to say, it is a validation of good design if each decision provides multiple advantages that demonstrably outweigh the inevitable disadvantage of its added complexity. Encouragingly, several of our five characteristics demonstrate such emergent advantages. For inspectors, an emergent advantage of CompositeInspector is that it becomes possible to run remote inspections. Multiple groups of inspections can be run remotely on different application tiers, passing the inspection results back to the UI in a well-defined, secure manner, where they can be recombined. This is important in real world architectures where often the UI layer is prohibited from, say, directly accessing the database schema.

To reiterate, throughout section 3 we are referencing our own particular implementation of each characteristic in order to provide a deeper analysis. Clearly, however, ours is not the only approach. For example, the Naked Objects team report (Haywood 2008.1) they are introducing pluggable 'facets' as a method of supporting mixtures of back-end technologies, including XML and database sources. This somewhat relaxes their 'behaviourally-complete' methodology and suggests some convergence (Haywood 2009).

This section has demonstrated that supporting a mixture of heterogeneous sources of UI metadata is an important characteristic for a practical UI generator. Having retrieved and collated all available metadata from the back-end subsystems, it is generally necessary to post process it. This characteristic is discussed in the next section.

3.2. Pluggable Inspection Result Processors

The raw inspection result returned from the inspector invariably needs post processing before it is suitable for consumption. For example, the fields generally need to be arranged in a business-defined order. There are various ways to achieve this, dependent on the metadata source. For example, if the data is sourced from an XML document its nodes are inherently ordered (XML 2008). But if the data comes from JavaBean properties in Java class files then it will not retain any ordering information (Gosling 2005) so one must be imposed. In the latter case, our adoption studies showed that the method used to impose ordering is open to practitioner taste. By default our implementation uses a 'comes after' approach, whereby each business field can specify the field that immediately precedes it. But some adoption studies reported "I would rather give the properties priorities so that I can say 'this one comes first' instead of 'this one comes after that other one'. It's just more natural to me". Equally, the Naked Objects team reports "by way of comparison (and as an alternative idea), the Naked Objects programming model uses an annotation called @MemberOrder, which takes an ordering in Dewey decimal notation. So, we have @MemberOrder("1.1")" (Haywood 2008.2).

Such explicit field ordering at the business model-level has disadvantages, however, as one practitioner noted "adding [field ordering information] to basically every field of your business model strongly reduces clarity... one of the key principles of [pluggable inspectors] is the possibility to directly use your unchanged domain objects [but this] doesn't really follow that principle". It is also less flexible in cases where "one wants to automatically create many different views based on a single business object with components of different sequence and visibility". The alternative, ordering the fields at the UI-level, introduces duplication - re-stating the fields used in a business object (Jelinek & Slavik 2004) - and compromises polymorphism - the UI needs to statically know the fields in advance - but practitioners advocated both sides: "I agree, the default behaviour [model-level ordering] should be as it is now... still, I see [UI-level ordering] as an advantageous option for cases with specific concerns such as flexibility".

Field ordering, then, whether specified by the back-end or the front-end, must be pluggable. Another example of an inspection result post processing operation, open to similar interpretations of practitioner taste, is excluding fields: should the model-level dictate which fields are to be excluded from the UI, or should this be decided on a per-screen basis? Most likely, a combination of both would be required - some clearly inappropriate fields, such as database primary keys, should be excluded from the UI at the model-level whereas other fields may need excluding on a per-screen, or per-user-role basis. Such post processing requirements are commonplace and a UI generator that does not accommodate different practitioners' preferred approaches would limit its appeal.

Our implementation addresses this characteristic of supporting multiple ways to post process the UI data by defining pluggable 'inspection result processors'. It defines a minimal 'InspectionResultProcessor' interface and ships with a number of implementations of this interface to support post processing metadata. Distinct from inspectors, which are designed to be detached from the UI and executable on application tiers inaccessible to the UI, InspectionResultProcessors maintain a reference to the current UI page. This is required for the aforementioned ability to implement UI-level ordering and exclusion.

This section has demonstrated that supporting a variety of ways to post process UI metadata is an important characteristic for a practical UI generator. Once post processing is complete, the inspection result is ready to drive the UI generation, as discussed in the remaining three sections.

3.3. Pluggable Widget Builders

An SSOT acts as a valuable starting point for UI generation. We have discussed how, in industry, this metadata is seldom centralised but rather must be brought together from disparate sources. There does not appear to be any movement among industry systems to converge this situation. On the contrary, the movement is generally towards additional types of subsystems, such as business rule engines (Rouvellou et al. 1999). Similarly, and despite research community ideals to the contrary, industry UI frameworks continue to diverge. Most notably, the Web browser does not appear to be the ubiquitous UI for which many were hoping.

For example, when Apple debuted their iPhone in 2007, they originally advocated their Safari Web browser as the recommended way to develop applications for the mobile device. A year later, however, the pressure for native UIs was recognised and a traditional SDK was released. This allowed better performance and access to device-specific hardware such as accelerometers and third-party peripherals (Square 2010). The Google Android mobile platform similarly supports native UI applications in addition to browser-based ones. Even if the browser were to become the ubiquitous UI, the plethora of Web frameworks and approaches to Web development (Shan et al. 2006) suggest there will not be a convergence of UI platforms in the near future.

This need to support a variety of front-end frameworks was apparent in several adoption studies. One reported: "We needed to integrate with a Spring MVC app, and in the future we may want to integrate with some existing Swing applications... also possibly Java Server Faces (JSF)". Another: "if I'd had to [design my architecture] differently because of [your implementation] I would have been unhappy. As things are I was just able to treat it as a normal Swing widget which was nice".

Another important requirement for a UI generator is that it support third-party, or custom, widgets. This is important not only for flexibility but also robustness. For example, a frequent problem when developing Web applications is ensuring compatibility across browsers. By leveraging existing widget libraries, rather than attempting to generate HTML directly, a UI generator can delegate all issues of browser incompatibility to the widget library - which has typically already been vetted in a variety of production environments. An adoption study from an earlier action research cycle criticised "if you have a more exotic GUI component used for certain properties, [your implementation requires] more work needed to get that to render, as opposed to simply creating the component in your GUI layer". After we improved this, adoption studies from later action research cycles reported: "We wrote our own widget builder.... [to use custom] components we developed and Metawidget instantiates them".

Implicit to this requirement to support third-party widget libraries is the ability to mix multiple third-party widget libraries in the same UI. Most third-party libraries only specialise on a certain set of widgets, rather than trying to replace every widget the platform provides.

Our implementation addresses this characteristic of supporting mixtures of widget libraries by defining pluggable 'widget builders'. It defines a minimal 'WidgetBuilder' interface and ships with a number of implementations of this interface to support popular UI frameworks, such as the aforementioned Spring MVC, Swing and Java Server Faces. Notably, our implementation also supplies a CompositeWidgetBuilder, named after the composite design pattern (Gamma et al. 1995), to support combining the widget libraries from multiple WidgetBuilders. The ordering of the WidgetBuilders is significant, so that widget choice can prefer one third-party library's widgets over another, or fall back to the default platform widgets, as shown below.


As with inspectors, widget builders demonstrate emergent advantages. Specifically, they present a compelling use case for practitioners to adopt UI generation. Once the developer has delegated their widget creation to a widget builder, it becomes possible to plug in new widget libraries as they become available - either new versions of existing libraries, or competing libraries offering more desirable widgets. For example, a third-party widget library may be released that offers a 'colour picker' widget with a user-friendly colour wheel. Imagine a practitioner has an application whose existing approach is to present a text field constrained to only accept hexadecimal input in RGB format (e.g. #ff00ff). The text field works, but the practitioner decides the colour wheel is more usable (it doesn't require the user understand hexadecimal, for one). Using widget builders, the practitioner would simply need to insert a WidgetBuilder for this new widget library as the first in a CompositeWidgetBuilder's list of priorities. Every screen in the application that previously used the hexadecimal text field would be immediately upgraded to use the colour picker, and this would happen automatically across the entire application - a significant saving in practitioner time over upgrading each screen manually. Notably, the WidgetBuilder itself could be provided by the widget library author, their incentive being to increase ease-of-adoption of their library. This reasoning extends to other areas of our pipeline too, such as inspectors, widget processors and layouts (covered in subsequent sections): an author of a new product, such as a business rules engine, a validation subsystem, or a layout manager, could increase its install base by providing UI generator plugins for it - alleviating the need for a practitioner to learn much of their product's API and significantly easing its adoption. Such plugins are not unprecedented, and grow the ecosystem of a product segment by levelling the playing field for new entrants. For example, database vendors typically provide plugins to popular ORMs so as to ease adoption amongst practitioners using those ORMs.

This section has demonstrated that supporting mixtures of widget libraries is an important characteristic for a practical UI generator. Widget builders simplify the process of choosing the most appropriate widget for a business field. Simply choosing the widget is rarely sufficient, however. There are generally a host of supporting technologies that also need to be attached, such as data validators, data binding frameworks, and event handlers. This characteristic is discussed in the next section.

3.4. Pluggable Widget Processors

In raw form, a widget is not likely to be suitable for inclusion in a UI. For example, end users interacting with a raw text field are able to enter arbitrary text. However the business requirement may be for, say, a credit card number. Widgets therefore need to be further adorned with data validators, data binding frameworks and event handlers. Of particular note is that some of these mechanisms, such as validators, may come from a different third-party library than the raw widget.

Processing such adornments is made difficult because of a general problem with automatic generation of any kind, not just UI generation: generated code is opaque to the practitioner. It is difficult to reference and attach mechanisms to objects that are not well-known in advance. One early adoption study identified this as "when you want to customise [the generated widgets], like replacing or adding more info to [them] you have to refer to them by property names. We have this problem not only for [UI generation], but when you have a lot of dynamic stuff [such as ORM frameworks]. It would be nice to either solve this or offer a solution for that". Another gave a concrete example, needing "a way to attach event handlers to widget value changes. This would allow you to respond to change... not just do a bi-directional binding (for example you could enable a save button that starts disabled)". A third adoption study had custom mechanisms they wanted to attach: "[we'd like to be] able to integrate our own validation and custom rendering of components".

Practitioners require a pluggable mechanism that allows post processing of a built widget. Critically, this mechanism must expose the same richness of metadata as the original widget building did, so that widgets may be identified not just by their name but also by their type, their constraints, their labels or any amount of other metadata.

Our implementation addresses this characteristic by defining pluggable 'widget processors'. It defines a minimal 'WidgetProcessor' interface and ships with a number of implementations of this interface to support popular adornments, such as the aforementioned data validators and data bindings, as shown below. Many of these implementations are defined by third-party libraries, not by the same base UI library as the raw widget. Notably the list of widget processors is maintained not by an immutable CompositeWidgetProcessor, as with CompositeWidgetBuilder, but by a mutable list. This is important so that individual UI screens can dynamically add widget processors that, say, attach event handlers. The methods these event handlers call are, by definition, tied to a particular UI screen rather than being immutable across the entire application. If we were to implement an immutable CompositeWidgetProcessor we would be unable to add such event handler processors without invalidating the immutability of the overall composite. Equally however many other types of widget processor, such as data validators and data bindings, are not tied to a particular screen and are immutable. We do not want to unnecessarily instantiate multiple instances of such processors. Designing the widget processors as a mutable list, therefore, allows us the best of both approaches.


This section has demonstrated that supporting a variety of ways to post process UI widgets is an important characteristic for a practical UI generator. Following post processing, the widget is robust enough to be placed in front of the user. However, it still remains to lay it out appropriately among its siblings. This final characteristic is discussed in the next section.

3.5. Pluggable Layouts

Having inspected, built and processed the final widget its layout on the screen is perhaps the most intractable issue in UI generation. In particular, it significantly detracts from the practicality of automated generation if it in any way compromises the final product in usability, or even in aesthetics (Myers, Hudson & Pausch 2000, p. 13). This realisation exposes a myriad of small details around UI appearance, navigation, menu placement and so on. The problem is so difficult, in fact, we believe it insoluble.

Our implementation sidesteps the issue by sharply restricting the bounds of its generation (Kennard & Steele 2008). Specifically, it does not attempt to generate the entire UI. Rather, it focuses on generating only a small piece of it - the 'inside' of each page, the area around the fields themselves. Ultimately, this is the only piece that is actually constrained by the back-end architecture. The UI appearance, navigation, menu placement and overall usability are far more device-specific, not to mention specific to the aesthetic taste of the UI designer. We explicitly keep these out of scope. Our adoption studies confirmed: "I think that although it is theoretically possible to solve this [automatically], in practice, it is generally not feasible to re-write the view into different technologies [automatically]. Even in scenarios where you have to design, for instance, the same screen with different versions for desktop and mobile, the screen cannot fit/support the same functionality". Human-based, aesthetic judgements must be made as to what can fit, what can be supported, and what is most usable.

As testament to how impractical generation of an entire UI is, even after restricting UI generation to just the area around fields we find there is still a formidable degree of variability. Fields may typically be arranged in a 'column', with the widget on the right and its label on the left. But other times the practitioner may want two or three such columns side by side. If so, they may need some widgets - such as large text areas - to span multiple columns. Or they may abandon columns altogether and want the fields arranged in a single, horizontal row. Furthermore, it is not difficult to posit other real world arrangements, such as right-to-left arrangements for the Arabic world. It is important to accommodate this variety if the generator is to achieve the exact look the practitioner desires. If it cannot achieve that exact look, the practitioner is compromising usability - the most determining factor of a UI - for the sake of automatic generation (Myers, Hudson & Pausch 2000, p. 13).

Our implementation addresses this characteristic of supporting multiple ways to arrange widgets by defining pluggable 'layouts'. It defines a minimal 'Layout' interface and ships with a number of implementations of this interface to support different layouts. Notably, our implementation also supplies a LayoutDecorator, named after the decorator design pattern (Gamma et al. 1995), to support decorating one layout with another. For example, fields may need to be divided into sections separated by headings, or sections divided into tabs in a tab panel. Such concerns should be orthogonal to the field arrangement themselves (i.e. one column or two columns, labels to the left of the widgets or the right) to curb a combinatorial explosion of UI options.

Adoption studies informed and agree the benefits of achieving parity between the UI designer's intent and the automatically generated UI are invaluable: "It is really hard to keep consistency, visual or functional standards when building [a] GUI in a large team. However, when it is generated dynamically, the rules are centred and even the customisation is somehow controlled".

As with inspectors and widget builders, layouts further demonstrate emergent advantages. Specifically, it becomes possible to mix layouts from third party widget libraries. Third party libraries often supply 'layout widgets' in addition to their data entry widgets. For example they may provide collapsible panels. If the practitioner is accustomed to using these layout widgets, the UI generator must support them or it will not be able to achieve parity with the original UI design. In addition, leveraging layout widgets affords the inherent robustness of delegating Web browser incompatibility issues, as discussed in section 3.3.

This section has demonstrated that supporting multiple ways to arrange widgets is an important characteristic for a practical UI generator. This, combined with the other four characteristics demonstrated in previous sections, results in a richly flexible UI generator. As shown, many of these five characteristics individually exhibit emergent advantages. However, when all five are combined there is a further emergent advantage - one that appears unique in the literature. We turn to this advantage in the next section.

4. Retrofitting

The previous section demonstrated five characteristics that are necessary for a practical UI generator. In addition, it showed how these characteristics give rise to a number of emergent advantages, which in themselves are an encouraging validation of their value. However there is a further notable advantage that emerges when all five characteristics are present in a UI generator - an advantage that is seldom even discussed, much less targeted, in the literature. Specifically, these five characteristics combined make it possible to retrofit UI generation into existing applications.

Retrofitting is a laudable but largely unpursued goal. It is laudable because the number of existing applications, both mature and currently under development, far outweighs the number of 'green field' applications that could reasonably be expected to adopt a new UI generator. The ability to remove boilerplate code from existing applications, in addition to preventing boilerplate code in new ones, has potential savings of many orders of magnitude. Retrofitting is largely unpursued presumably because it requires a level of UI generator flexibility, particularly flexibility towards back-end architectures, that is difficult to target. However several adoption studies successfully applied our implementation to existing applications. This included them being able to partially migrate applications one screen, or even one piece of a screen, at a time. This prompted us to conduct internal experiments retrofitting our implementation to other projects. For example, we chose three applications from the samples included with the Open Source JBoss Seam distribution (JBoss Seam 2010). We discovered the retrofitting activity encompassed three main areas.

First was to explore what existing metadata could be leveraged from the application's back-end architecture. For example the Seam Hotel Booking sample contained some UI metadata embedded within its persistence subsystem, some within its validation subsystem, and some within a scripting language. Conversely, the Seam DVD Store sample contained UI metadata embedded within its BPM subsystem. We were able to plug in inspectors for each of these. The second activity was to introduce UI metadata that did not exist in the application but was required for generation. For example business field ordering information had to be incorporated. The final activity was to replicate the application's original UI appearance. We were able to plug in widget builders for this. In particular, we were able to plug in a mixture of widget builders to replicate the application's original choice of two third-party widget libraries.

Overall there was a significant amount of existing code that could be removed, though notably some new code also had to be introduced - such as field ordering information and configuration files. Nevertheless, when comparing aggregate sizes of the files in the sample projects before and after retrofitting, we realised between a 30% to 40% reduction in UI code through the introduction of our implementation. For some individual files this metric was as high as 70%, as shown below. On the left is the original XHTML source code for a single UI screen, and on the right the retrofitted version (the source code is not meant to be legible in the figure, it suffices just to be able to discern its structure). The red boxes and lines convey which portions of the original source were able to be replaced, and their equivalent size in the retrofitted version.

This section has introduced retrofitting as an emergent advantage of the five characteristics demonstrated in the previous section. The ability to retrofit existing applications is an encouraging indicator of the overall value of the five characteristics. We now turn to this 'overall value' for our final section.


5. Summary, Conclusions and Future Work

This article has emphasised the need for UI generation within mainstream software development, and underscored impracticalities with existing approaches. It has employed practice based research and human centred design approaches to identify five characteristics that are necessary for a practical UI generator. Interviews, adoption studies and industry collaboration suggest these characteristics are key to the real world adoption of a generator. These characteristics can be summarised as: inspecting existing, heterogeneous back-end architectures; appreciating different practices in applying inspection results; recognising multiple, and mixtures of, UI widget libraries; supporting multiple, and mixtures of, UI adornments; applying multiple, and mixtures of, UI layouts. Many of these characteristics seem ignored by current UI generators and we believe this is hindering their widespread adoption. This article has further identified the impact of implementing all five characteristics: they allow practitioners to retrofit UI generation into existing applications. This significantly broadens the range of applications amenable to UI generation and increases its value to practitioners.

This article has drawn several far reaching conclusions. First, that any UI generator that seeks to dictate, rather than adapt to, a system's architecture has limited practical value. Second, it is important to appreciate that the need for diversity in industry architectures is not because most business systems are poorly designed. Rather, it is because business systems seek to leverage functionality provided by a large number of mature subsystems available in industry, in order to increase productivity and reduce development cost. Finally this article has emphasised that action research, as a methodology for research and development, is fundamental to the usefulness of a resulting product in supporting diversity and richness of practice.

Immediate future work will concentrate on further developing our UI generator implementation. There are many design decisions for which the five characteristics identified in this article could be implemented either way. For example, there are opposing schools of thought whether generation should be runtime based or statically generated. We also plan to continue evaluating our implementation against real world business systems, to assess the degree to which those systems can be retrofitted to reduce UI code. A longer term goal is to standardise the five UI generation characteristics, such that they can be adopted as part of mainstream UI development.

References

Bloch, J., 2001. Effective Java programming language guide, Sun Microsystems, Inc. Mountain View, CA, USA.
Cao, L., Yu, P.S., Zhang, C. & Zhao, Y., 2010. Domain Driven Data Mining, Springer-Verlag New York Inc.
Daniel, F., Matera, M., Yu, J., Benatallah, B., Saint-Paul, R. & Casati, F., 2007. 'Understanding UI Integration: A Survey of Problems, Technologies, and Opportunities', IEEE INTERNET COMPUTING, pp. 59-66.
Dick, B., 2000. 'A beginner's guide to action research', http://www.scu.edu.au/schools/gcm/ar/arp/guide.html
Dick, B., 2005. 'Grounded theory: a thumbnail sketch', http://www.scu.edu.au/schools/gcm/ar/arp/grounded.html
Firesmith, D.G., 1996. Use Cases: The Pros and Cons. Wisdom of the Gurus: A Vision for Object Technology
Gamma, E., Helm, R., Johnson, R. & Vlissides, J., 1995. Design patterns: elements of reusable object-oriented software, Addison-wesley Reading, MA.
Gosling, J., 2005. The Java Language Specification, Addison-Wesley.
Grcar, M., Grobelnik, M. & Mladeni, D., 2007. 'Using text mining and link analysis for software'.
Haywood D., 2008.1. Comments section under http://blog.kennardconsulting.com/2008/04/useful-bounds-of-automatic-ui.html
Haywood D., 2008.2. Comments section under http://blog.kennardconsulting.com/2008/07/metawidget-javassist-versus.html
Haywood D., 2009. Comments section under http://www.theserverside.com/news/thread.tss?thread_id=58283#328193
JBoss Seam, 2010. http://www.seamframework.org
Jelinek, J. & Slavik, P., 2004. 'GUI generation from annotated source code', Proceedings of the 3rd annual conference on Task models and diagrams, pp. 129-136.
Jha, N.K., 2005. 'Low-power system scheduling, synthesis and displays', Computers and Digital Techniques, IEE Proceedings-, vol. 152, no. 3, pp. 344-352.
JPA 2008. http://jcp.org/en/jsr/detail?id=220.
Kagdi, H., Collard, M.L. & Maletic, J.I., 2007. 'Comparing Approaches to Mining Source Code for Call-Usage Patterns', Proceedings of the Fourth International Workshop on Mining Software Repositories.
Kemmis, S. & McTaggart, R., 1988. 'The action research planner'. Deakin University.
Kennard, R., Edmonds, E. & Leaney, J., 2009. Separation Anxiety: stresses of developing a modern day Separable User Interface. 2nd International Conference on Human System Interaction.
Kennard, R. & Steele, R. 2008, 'Application of Software Mining to Automatic User Interface Generation', New Trends in Software Methodologies, Tools and Techniques, p. 244.
Larman, C. & Basili, V. R., 2003. 'Iterative and Incremental Development: A Brief History', Computer, pp. 47-56.
Li, X., Zhang, S. & Wang, S. 2006, 'IJDWM Special Issue: Advances in Data Mining Applications', International Journal of Data Warehousing and Mining, vol. 2, no. 3.
Manheimer, J.M., Burnett, R.C. & Wallers, J.A., 1989. A case study of user interface management system development and application. Proceedings of the SIGCHI conference on Human factors in computing systems: Wings for the mind , 127-132.
Meskens, J., Vermeulen, J., Luyten, K. & Coninx, K., 2008. 'Gummy for multi-platform user interface designs: shape me, multiply me, fix me, use me', ACM, pp. 233-240.
Myers, B.A., 1995. 'User Interface Software Tools', ACM Transactions on Computer-Human Interaction, vol. 2, no. 1, pp. 64-103.
Myers, B., Hudson, S.E. & Pausch, R., 2000. 'Past, present, and future of user interface software tools', ACM Transactions on Computer-Human Interaction (TOCHI), vol. 7, no. 1, pp. 3-28.
Myers, B.A. & Rosson, M.B., 1992. Survey on user interface programming, ACM Press New York, NY, USA.
Pawson, R., 2004. 'Naked Objects', Trinity College, Dublin.
Prat, A., Lores, J., Fletcher, P. & Catot, J.M., 1990. Back-End Manager: An Interface between a Knowledge-based Front End and its Application Subsystems. Knowledge-Based Systems, vol. 3, no. 4.
Rouvellou, I., Degenaro, L., Rasmus, K., Ehnebuske, D. and Mc Kee, B., 1999. Externalizing Business Rules from Enterprise Applications: An Experience Report. Practitioner Reports in OOPSLA, vol. 99.
Schön, D.A., 1983. The Reflective Practitioner: How Professionals Think in Action, Basic Books.
Shan, T.C., Hua, W.W., Bank, W. & Wilmington, N.C., 2006. 'Taxonomy of java web application frameworks', pp. 378-385.
Square 2010. http://www.squareup.com
Vanderdonckt, J., Limbourg, Q., Michotte, B., Bouillon, L., Trevisan, D. & Florins, M., 2004. UsiXML: a User Interface Description Language for Specifying Multimodal User Interfaces, W3C Workshop on Multimodal Interaction, 19-20.
Vermeulen, A., Beged-Dov, G. & Thompson, P. 1995, 'The pipeline design pattern', OOPSLA ’95 Workshop on Design
WSDL 2001. http://www.w3.org/TR/wsdl
Weiser, M., 1993. 'Hot topics-ubiquitous computing', Computer, vol. 26, no. 10, pp. 71-72.
Xie, T., Pei, J. & Hassan, A.E., 2007. 'Mining Software Engineering Data', International Conference on Software Engineering, pp. 172-173.
XML 2008. http://www.w3.org/TR/REC-xml
Xudong, L. & Jiancheng, W., 2007. 'User Interface Design Model', Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing, 2007. SNPD 2007. Eighth ACIS International Conference on, vol. 3.

Duplication in User Interfaces: 6 Interviews With Industry Practitioners

Abridged from Kennard, R., Edmonds, E. & Leaney, J. 2009, 2nd International Conference on Human System Interaction

1. Introduction

A peer reviewer of our earlier paper on UI generation (Kennard & Steele 2008) questioned whether 'UI duplication' (that is, restating information between the UI and the business layer) was really a problem. Was it really a detrimental source of errors, or did it provide an advantageous level of flexibility? At the time I had to concede I lacked evidence other than my own experience as an industry practitioner. Given this was a fundamental premise of my thesis on user interface generation, it was important to validate it. To do so, I conducted 6 interviews with senior software developers chosen from different segments of industry - including finance, medical and middleware - across the UK, the US and Australia.

I chose a standardized, open-ended format for the interviews (Valenzuela & Shrivastava 2002). This approach involves asking the same standardized set of questions to each interviewee, but the set is necessarily short because each question is framed broadly so as to allow the candidates to talk openly about their experiences. Standardized, open-ended interviews allow accurate comparison and analysis of results, whilst avoiding leading the interview and therefore minimizing bias. To analyse the results, I employed a simplified version of Grounded Theory (Dick 2005). This approach involves coding, comparing and sorting categories that emerge from the interview sessions. Of principal interest to this paper was the category of duplication. Other categories that emerged will be used in future work.

2. Duplication

I began each interview by informing the practitioner I wanted to talk about the mechanics, not the aesthetics, of developing a UI and its relation to the rest of an application. I asked each practitioner to describe the process they would go through to add, say, a Date of Birth field to an existing Person business object in their current software system, including both the back end and front end. This initial question was deliberately phrased to be as open-ended as possible. Specifically, it avoided the bias of mentioning duplication. However, because I didn't explicitly prompt duplication, it was important to have each practitioner talk not just about the UI but all steps of the process, from back end to front end. In this way, the duplication would become apparent of its own accord. Finally, I phrased the question around updating an existing business object, rather than a new one. I did this in order to expose the weaknesses of static code generation tools, but again because I didn't explicitly refer to 'static code generation' I didn't feel this biased the responses.

All the practitioners gave answers similar to the example in the previous section. One enumerated "first off we would add [the Date of Birth field] to the database, in the table. We'd then add it to the stored procedures going up. Add it into the Data Access Layer for the purposes of getting it out of the recordset. And then you'd add the property into the business level, the business layer. And then, on the UI, on the front-end, we'd have to add the field in the HTML". Another practitioner said "I would go to the persistence level, I'd work out how that field should be modelled in the problem domain. For date of birth, you'd have a date column. I'd look at the Person class, work out its relationship with the Person schema. Work out its name, what its type would be, date or datetime depending on the database. Then I'd work out how I should change the Person class - they'd probably just be a getter and setter - and then I'd tie it back to the persistence layer, map it back to the table. For validation constraints, yeah, this is always a problem, you need to validate it both in the UI and at the persistence layer if that's a business rule, so it's always a problem. In terms of the UI, I'd go and find the bit of UI code and work out the position where this field should be added".

It was noted those practitioners using newer technologies had considerably fewer steps. One said "we would obviously add that field to the actual business object that [JPA] maps to the database, that's already there. And then any validation constraints that are around that - we use Hibernate Validator so we'd put the validation constraints on the entity, we don't have to do anything more for validation other than that, and all that's left now is dropping the field on to the UI, and that should be it really. Using the IDE we have we'd drag and drop UI components, then we'd have to apply some kind of formatting as well, some formatting to the underlying XHTML". However I observed this sub-category (Dick 2005) of reducing steps was generally from the business objects 'down' through to the persistence layer, removing the manual coding of schemas, stored procedures and recordsets, not 'up' to the UI layer.

I then summarised the steps back to the practitioner and asked whether they thought any steps were deficient. Not all the practitioners were immediately aware of any problem. This is to be expected for such an entrenched issue: some interviewees simply don't know any different. One said "what we have now is pretty good, certainly compared to a Java Server Pages (JSP) or something like that. 2 steps to add a field is pretty good. The framework handles quite a lot and we can develop much faster than we normally do". For those practitioners I used a further probe question (Valenzuela & Shrivastava 2002), which specifically raised awareness of restating information. I asked whether any steps seemed redundant, or contained duplicated information from previous steps. Such a question has inherent bias, so it was not asked unless the practitioner failed to identify duplication naturally.

Following the probe question, all interviewees converged on recognising duplication amongst the steps. "The problem definitely exists. It's more from the business layer forward to the screen is the biggest problem because there are things out there like Hibernate (Hibernate 2009) which do from, sort of, business layer down". Another echoed this sentiment "the drudgery at the moment is adding the UI code, and adding the validation and giving that feedback. That's really quite unpleasant. It's the most complex of all the steps, actually, depending on the magnitude of the change. Given a very simple change, just adding a single field, the bulk of the work, the bulk of the drudgery, in the coding is at the UI level. Being able to more concisely express the relationship between the UI and the model and the change I want to make in one place, or at most two places, in a very concise fashion would help". Another warned "it's a fairly established software engineering principle that the more you have to repeat something the higher the error is, the higher the chances there's going to be an error in the code".

3. Defects

Following on from this, I asked each practitioner whether they had ever encountered defects that were a result of this recognised deficiency in their process. All of the interviewees responded that such defects were common. "Definitely. There's always a chance that someone's going to get a bug somewhere along the line, especially with Date of Birth - as it goes down the date gets mixed up because someone's used the incorrect data type. With some of our junior developers we have here that's quite a common thing where they get a bit muddled up... it's definitely an issue that should be far simpler". Another agreed "All the time. That would be me overlooking various aspects of the user feedback loop, in the validation, me forgetting to persist various fields that I've added, so the validation happens but then it never persisted, so having to tie the new field to the model, with validation, in multiple places, gives a number of points where I could fail to do that". Another said, of reviewing other developer's code, "a large percentage of mistakes were always they'd copy and pasted and they'd changed that one, and that one, and that one - but not that one. So it creates a higher chance of there being a minor error".

Several practitioners echoed this difficulty of identifying duplication related defects, because they generally evade static checking and developers must rely on runtime testing to detect them. One financial software practitioner explained "we've got a BigDecimal (Gosling 2005), and [the back end has] set the scale to 8 but the UI puts through 10, it [gets silently rounded and] passes all the way through. That becomes a real issue because it's really hard to find. That's caused us huge problems before". Another agreed "it's the biggest problem I personally face. These sorts of errors. You're updating, say, you change the type of a field and you try updating it with, say, a datetime object but you've actually now changed it to an integer field, you don't realise until you actually start testing the application, or if you miss it in testing and send it out to customers, you don't realise that there's a problem until you get the bug reports - not ideal".

One practitioner described how, because duplication is generally not understood by refactoring tools, it works against his preferred methodology of aggressive refactoring: "if you change a field name, and I do like to change field names - I don't know why - so I'll decide after a year of using the program 'what's that field name doing there?' I did it the other day: I've got a stock control module in the program and there's [a field] called stock_reorder_level_reminder and I thought 'what a stupid name for a field', so I just changed it to reorder_level because that's much easier. Now, generally changing that could have massive implications couldn't it? You could change that and it could break the application in several parts".

4. Prevalence

Finally, I asked each practitioner whether the themes explored in the interview were commonplace across all software systems they had developed. One said "I've built a number of UIs over the course of my career, some of them have been desktop applications, some of them have been web applications, and I think this is a general problem. For desktop applications it's hard but it's relatively easy. For web I think it becomes a lot more difficult because the technologies involved are a lot more fiddly, there are a lot more moving parts in web application UIs. But yes I think it's a general problem.". Another said "quite honestly laying out UI forms is time consuming, it's fairly standard how a UI is - it shouldn't be a problem to say, okay, you have these things you probably want to interface in a particular way, here's what we suggest - we being the computer - you've got a datetime here, here's the calendar control we suggest. Oh you don't want a calendar, you want to use a textbox, go for it. Something along those lines would definitely detract from the tedium of putting together the UI, which is an important step and everything but is a really repetitive process. If it's a varchar in the database, it's going to manifest as some form of a textbox on the form. If I've got a foreign key in my database, it's going to manifest as some form of listbox, dropdown, radio button, checkbox. It's not a huge leap". One practitioner summarised it as "every developer who writes anything more than a Hello World application will have this problem. Most developers who strive to make their work better, who aren't lazy, do sense this problem, do encounter this problem on a daily basis as a constant friction in their daily work".

I observed a sub-category (Dick 2005) that this friction had driven several practitioners to fashion their own ad hoc solutions by combining existing tools. "For a brand new screen we're currently using CodeSmith (CodeSmith 2009), so if you design the database table you can hit generate and it'll go through and generate everything right up to the screen". However, because of subsequent editing of the generated code, they found CodeSmith to be of limited use outside of new screens: "if you could do the same thing where you could add a new field to the database and it generated and added it into the [existing] code for you as it goes up that'd be excellent". Other solutions had similar shortcomings. Microsoft LinQ (LinQ 2009) helped with the persistence layer, but "if I go in and create a field, LinQ creates a nullable version of that field, where the [UI] control I'm binding it to is expecting a non-nullable version. That's caused a number of problems. That's come up a number of times and you've really got to kind of juggle to make it work right. Keep in mind when that could happen and keep track of the potential for it to happen". Asked why they had invested the considerable resources to fashion their own solutions: "I do genuinely believe that kind of thing makes the development cycle better in the long run. It makes things much cleaner, there's less coding to go on. If I were to have to write, well, in my application the basic objects I have, I have patients, contacts, appointments, items, invoice, payments, refunds, credits and then a load of secondary objects like appointment status', patient categories, all of these are objects. If I had to code a separate form for each one it's just tedious. Interface work is not that much fun. It's quite tedious, dropping controls on a form, lining them up with the other controls and fiddling around for ages". Another practitioner echoed this sentiment saying, if such tedium could be reduced, "you'd have more time for the actual problem solving: defining, clarifying, implementing the problem rather than the mechanics of the 'auto pilot' of gotta code up this method, gotta code this, gotta code that. Give you more time to concentrate on the more energy-requiring things rather than the monotonous reproducing of stuff. Because, I mean, despite the fact they tell everyone not to, normally you end up copying and pasting things".

5. Conclusion

The results of my interviews suggested UI duplication was indeed a prevalent and serious problem in software development. I observed developers across industry segments and across software platforms, and saw they had common experiences of duplication, common experiences of bugs caused by it, and a common desire for it to be addressed. These results were compiled into a research paper (Kennard, Edmonds & Leaney 2009) and this time its reviewers seemed more convinced. One wrote "In this paper, the authors provide extensive evidence for the problem of manual code duplication among subsystems in the process of software... the work is exceptionally well motivated". Another: "the work is important for the [research] community to hear... nobody in a senior position in a software company today is going to not be aware of this problem and the various hacks, workarounds, and band-aids used to cover up the pain that it causes (at least not in a successful software company). Again, academics may be surprised by some of the comments and the gravity of the concerns, but I wasn't; this is a serious problem and there are partial solutions out there that various people employ with varying degrees of success".

References

CodeSmith. 2009. http://codesmithtools.com
Dick, B. 2005, 'Grounded theory: a thumbnail sketch', http://www.scu.edu.au/schools/gcm/ar/arp/grounded.html
Gosling, J. 2005, The Java Language Specification, Addison-Wesley.
Hibernate. 2008. http://www.hibernate.org
Kennard, R., Edmonds, E. & Leaney, J. 2009, Separation Anxiety: stresses of developing a modern day Separable User Interface. 2nd International Conference on Human System Interaction.
Kennard, R. & Steele, R. 2008, Application of Software Mining to Automatic User Interface Generation. 7th International Conference on Software Methodologies, Tools and Techniques.
LinQ 2009. http://msdn.microsoft.com/en-us/vcsharp/aa904594.aspx
Valenzuela, D. & Shrivastava, P. 2002, 'Interview as a Method for Qualitative Research', http://www.public.asu.edu/~kroel/www500/Interview%20Fri.pdf.