How to Manage an Ever-Changing User Interface

Discover a philosophy of user interface management leading to adaptable front-ends that exceed dynamic market requirements and the ever-changing user interface

The user interface is the window into the needs of a business. These needs should be driven by customers either internal or external. We’ll refer to these customers as the market. As market needs shift the user interface will need to change. A responsibility of a professional front-end developer is to design the user interface implementation to support this change. How do we manage an ever-changing user interface?

Identifying what areas of the front-end are most impacted is an essential first step in managing shifts in the market. As we know from Robert C. Martin or Juval Lowy, each of these areas is an axis of change. Considering the volatility of an area can help when designing the front-end to more easily adapt to change.

We’ll see that the user interface is never done and certain areas of the user interface will likely change more frequently than others. We will also consider how we could exploit the axis of change to deliver a user interface designed with enough fluidity in the right areas to more easily flow with fluctuating market needs.

Volatility Rating

Everything about the user interface will change. This means color, size, position, text, user experience, design – everything – will change. There is no judgment here. The user interface is encouraged to change if it better suits the market. However, there are some areas that will change more frequently than others and have a greater impact on the system when they do. Considering these areas is essential when designing the user interface implementation.

Frequency

Starting with a simple example, the look and feel of the user interface may change. If, for instance, the look and feel will always change, the frequency is 100%.

Another area that may be added or altered is a data model. When a user interface contacts a service, there is a contract that defines the data that will be sent between the front-end and the service. This is the data model. When the market decides it needs an extra field in a form, that it needs a “button here that does x”, or removing a column from a table, it means altering or adding a data-model. This has its own change frequency.

Determining how frequently an area will change will help determine its volatility and how to approach its design and the design of future changes.

Impact

The look and feel of the user interface may always change which is only one part of the volatility rating. The impact of a change needs to be considered. Areas that impact the entire system will have the most impact when changed. The impact of change is reduced as its impact on the system is reduced. An example of this can be found in a previous article titled The Monolith Component. While the article focuses on a malformed component, it describes the kinds of impact code can have. Considering the impact is an important part of deciding how to make a change.

Exploiting the Evolution

Some areas are innately difficult to alter, especially when they impact a website user interface as a whole – such as look and feel. There are common practices when dealing with something like this: use a CSS pre-processor to leverage common principles and practices such as OOCSS, BEM, and SMACSS. With the advent of Modular CSS and other principles and practices, managing the look and feel of a website is less painful.

There are libraries and frameworks that aim to make front-end development less painful. Yet, they can only go so far. It will depend on the use, the application of these helpful libraries and frameworks – let’s call this advantaged code. Leveraging advantaged code becomes dependent on the application of two concepts: continuous improvement, and designing for change. These concepts attempt to answer a fundamental question: How can I make it easier to manage new or existing code in an ever-changing user interface?

Continuous Improvement

As more is learned, more can be applied. The details of the code begin to be deeply understood. The areas of the code that change most begin to reveal themselves. And, of course, the impact on the system of each change has a greater chance of being measurable.

When learning these things about the user interface, and how it is impacted by changing market needs, the code can be continuously improved to anticipate those changes.

Design for Change

Designing a user interface for change is only valuable if the rate of change and its impact on the system are measured and deemed inevitable. This is to avoid unnecessary costs such as increased user interface complexity and reduced available budgets.

As the user interface evolves with market needs it should continuously improve in the areas where the rate of change and the impact on the system are high enough. What is high enough in terms of change rate and system impact is largely determined by project concerns – available time and budget, developer experience, accessible business knowledge, etc.

I am not saying all changes are valid – meaning, there are some cases when a change should not be made. A simple example of this is security. If a requested change will compromise the security of the application, it is a responsibility of a professional developer to say, “no” preferably with an amount of tact appropriate for your relationship with the market. And hopefully, there would be enough trust in the partnership that the market will thank you for looking out for them.

Excluding the requests that are detrimental to the system, by measuring the rate of change and the impact on the system, changes to the front-end can be more easily supported, maintained, and you may even welcome them.

Dynamic Objects Using WinJS & XML

The Problem

I am writing an app for Windows 8 and need a maintainable set of values I can use in JavaScript. My first attempt included creating a Constants object that contained the values I needed. This soon became unmanageable as the number of constants increased. To fix this, something like an ASP.Net web.config file would be great. The problem is I do not want the restriction of accessing it through a sort of “AppSettings” property as with ASP.Net websites. My preference would be a JavaScript object that contains the properties I need but from a configuration file. How would I do this?

The Solution

What would solve my problem is a JavaScript object created at runtime that includes properties and values based on an XML file. A few things known about JavaScript make this solution viable:

  1. JavaScript is a highly dynamic language. Considering this fact, creating an object during runtime should be like Eddie Van Halen playing a guitar.
  2. Object properties can be accessed and manipulated using normal array syntax.
  3. Server data is accessible from JavaScript. AJAX is the acronym.
  4. Since an XML file is obtained, it can be parsed no differently than an average HTML document.

Combining the implementation of these four facts will enable me to create an object at runtime using the data of an XML file. The next section will explain how this is done.

The Implementation

There are three basic steps to implementing this. The mechanisms accessible from WinJS will help tremendously. First, the XML file needs to be obtained. This can be done using the WinJS.xhr function. More information on this function can be found on MSDN: “WinJS.xhr function (Windows)”. The next step is to parse the XML file and then to create the Constants object based on the data retrieved from the file. These steps will be explained in more detail in the following sections.

The Configuration File

To consume the file, the file will need to be created. Below is the sample content in the file:

<?xml version="1.0" encoding="utf-8" ?>
<Configuration>
  <Constant1>
    <add name="String" value="Value 1" />
    <add name="Integer" value="1" />
  </Constant1>
  <Constant2>
    <Boolean>
      <add name="IsTrue" value="true" />
      <add name="IsFalse" value="false" />
    </Boolean>
  </Constant2>
  <Constant3>
    <add name="SubConstant" value="SubValue" />
    <NextSubConstant>
      <add name="NextSub" value="NextSubValue" />
    </NextSubConstant>
  </Constant3>
</Configuration>

As can be seen, this is nothing more than an average XML file. There are various nested nodes and attributes to show some of the possible node structures supported by this solution. For this article, the name of the file is “config.xml” and the root node is “Configuration”.

The Data

The WinJS.xhr function is used to get the XML file. This function takes an object used to configure the request and returns a Promise. This is shown below:

WinJS.xhr({
  url: "config.xml",
  headers: {
    "If-Modified-Since": "Wed, 2 Feb 2000 11:11:11 GMT"
  },
  responseType: "document"
}).done(function(result) {
  if (result.status === 200) {
    var data = result.responseXML;
    var root = data.querySelector("Configuration");
    WinJS.Namespace.define("ST.Constants");
    iterate(root, ST.Constants);
  } else {
    /* … Handle missing document … */
  }
});

The xhr function is called, taking an object used to configure the XMLHttpRequest. “url” is the only required property. Other optional properties can be used to further configure the XMLHttpRequest. This is much like jQuery’s ajax method but, in this case, a Promise object is returned. The “done” method of the returned Promise is used to process the returned XML document.

Configuring the XMLHttpRequest

WinJS.xhr({
  url: "config.xml",
  headers: {
    "If-Modified-Since": "Wed, 2 Feb 2000 11:11:11 GMT"
  },
  responseType: "document"
})

The parameter passed to the xhr function is an object. This object is used to configure the XMLHttpRequest as mentioned previously. Here the “url” is set to the path to the XML file. Then, the “headers” property is used which includes the “If-Modified-Since” date. This ensures the XML file is obtained. The last property is “responseType” which is used to make sure the result of this call is a document able to be parsed by JavaScript.

Processing the XML File

.done(function(result) {
  if (result.status === 200) {
    var data = result.responseXML;
    var root = data.querySelector("Configuration");
    WinJS.Namespace.define("ST.Constants");
    iterate(root, ST.Constants);
  } else {
    /* … Handle missing document … */
  }
});

The next step is to process the returned XML file. The xhr function returns a Promise object. This object contains a “done” method that can be used for processing the results of the xhr function call. As with the average use of XMLHttpRequests, the first step is to make sure it succeeded. Using the result passed into the done handler, the status of the request can be determined. This result object is the XMLHttpRequest. It contains useful properties among these being “status” and “responseXML”. A successful status is 200. If the status is 200, the function proceeds with processing the results by first getting the responeXML from the result object. Since the responseType was set to “document”, the content of responseXML is the XML document that can be parsed by JavaScript. The iteration of this document will be described in more detail below but there are two more steps to do first. The iteration method takes two parameters. The first parameter is the node to process. To begin, the root node needs to be processed so this is what is retrieved. The second parameter is the object to process with the node. The object is meant to be static so the WinJS.Namespace.define method is used to create this. The two parameters are passed to the iterate method. The next section provides more detail.

The Iteration

There is hair, teeth, flesh, and bones but the iteration method is the meat. Within this method is the traversal of the XML file along with the additions to the Constants object. Below is the implementation:

function iterate(node, ns) {
  if (node && node.childNodes) {
    if (node.childNodes.length > 0) {
      var nodes = node.childNodes;
      var len = nodes.length;
      for (var i = 0; i < len; i++) {
        var sub = nodes[i];
        if (sub.nodeType === sub.ELEMENT_NODE) {
          var name = sub.nodeName;
          if (sub.childNodes.length > 0) {
            ns[name] = {};
            iterate(sub, ns[name]);
          } else {
            var attName = sub.getAttribute("name");
            var attValue = sub.getAttribute("value");

            if (attName && attValue) {
              // key/value attribute
              ns[attName] = attValue;
            } else if (attValue && node.nodeName && !attName) {
              // node name/value 
              ns[name] = attValue;
            } else {
              /* handle data not available */
            }
          }
        }
      }
    } else if (node) {
      var name = node.nodeName;
      var attName = node.getAttribute("name");
      var attValue = node.getAttribute("value"); //Key/Value Attribute
      if (attName && attValue) {
        ns[attName] = attValue; //Node Name/Value
      } else if (attValue && node.nodeName && !attName) {
        ns[name] = attValue; //Log Warning
      } else {
        /* handle data not available */
      }
    }
  }
}

Above is the implementation of the iteration method. This method has various validation checks for the current node, child nodes, and attributes. There is also room for handling missing data.

Handling No Children

The method begins by checking whether the given node and its children exist. If any children exist, it continues processing the child nodes. If there are no children, the method checks to make sure there is a node and upon success attempts to get the name and value attributes. This is shown below:

else if (node) {
  var name = node.nodeName;
  var attName = node.getAttribute("name");
  var attValue = node.getAttribute("value");
  
  if (attName && attValue) {
    // key/value attribute 
    ns[attName] = attValue;
  } else if (attValue && node.nodeName && !attName) {
    // node name/value
    ns[name] = attValue;
  } else {
    /* handle data not available */
  }
}

There are three possible paths than can be taken here:

  1. If both the name and value attributes exist, the Constants object is updated. A new property is added to the object. This part takes advantage of the fact JavaScript object properties can be accessed and manipulated by using normal array syntax. The new property is created with the value of the “name” attribute and is assigned the value of the “value” attribute.
  2. If the value attribute and node name exist but not the name attribute, the Constants object is updated using the node name. The name of the new property is the name of the node. The value of this new property is the value of the value attribute.
  3. If neither of the above two cases exist, there is no data available as this solution is currently implemented. This is a good place to handle such a case by either logging the occurrence, adding default data, or any other way that is necessary.

Handling with Children

If the given node exists with children, the iterate method proceeds by processing the child nodes. The snippet below shows this:

if (node.childNodes.length > 0) {
  var nodes = node.childNodes;
  var len = nodes.length;
  for (var i = 0; i < len; i++) {
    var sub = nodes[i];
    if (sub.nodeType === sub.ELEMENT_NODE) {
      var name = sub.nodeName;
      if (sub.childNodes.length > 0) {
        ns[name] = {};
        iterate(sub, ns[name]);
      } else {
        var attName = sub.getAttribute("name");
        var attValue = sub.getAttribute("value");

        if (attName && attValue) {
          // key/value attribute
          ns[attName] = attValue;
        } else if (attValue && node.nodeName && !attName) {
          // node name/value 
          ns[name] = attValue;
        } else {
          /* handle data not available */
        }
      }
    }
  }
}

The node is checked to make sure it has child nodes. If it does, each child node is processed in a simple for loop. The current child node is stored and then a check is done to be sure it is an element node. If so, the method checks this node’s children. If they exist, the name of the sub node is used to create a new property of the given Constants object. Then the iterate method is called again this time passing in the current child node and the new property of the Constants object. This provides the support needed to add nested nodes in the XML file.

If the current child node does not have any children, it is processed in the same way as what was described in the previous section “Handling No Children”.

The Outcome

As you are probably aware by now, this solution creates an object at runtime. Using the Watch window while debugging the structure of the object can be seen:

This shows that the structure of the Constants object mirrors the structure of the XML file.

Originally Perceived Enhancements

Using this solution offers numerous benefits. It is flexible, scalable, and performs well. It provides practically infinite levels of nesting in the xml file (barring any call stack limitations when the prototype chain is created). There is also no performance hit from going across a network since the configuration file is local to the app. Among these strengths, there are still improvements that can be made.

Attribute Values

So far, the values of the constants are set as the attribute values in the XML file. Node values could be used as well.

Data Types

Not every value is appropriate as a string. Additional logic could be added to the iteration to have values of appropriate data types (e.g. If the value is meant to be an Integer, make it an Integer; if the value is meant to be a Date, make it a Date).

Caching

This creates an object at runtime. Don’t create the same object every time the app is started. When the object is first created, store it. Then, retrieve it from storage when the app loads again. Only create this object when a change has been made.

Conclusion

This article presented a way to create objects that are easily configurable by updating values in an XML file. As with most things, there are pros and cons to this solution but it does the job and does the job well. Needless to say, the band is happy and the object has been brought to life.