Monthly Archives: February 2011

Empowering Users with UI Design

Good user interfaces (UI) are a vital component of great software applications. It is not enough to have great functionality on the backend. After all, UIs are the human-computer interface. If you don’t get the UI right then the entire system will be wrong…regardless of how clever the code is.

Some developers struggle with this concept. Have you heard the joke about the introverted vs. extroverted programmer?

“How can you tell an introverted programmer from an extraverted programmer? The extroverted programmer stares at YOUR shoes when he is talking to you.”

While the joke is humorous, it illustrates how disconnected some developers are with the people that use the software they build.

Developers that are also skilled at UI design are rare. As such, it is almost always beneficial to get a designer involved in the UI development. The designer can focus on appearance and usability and not worry about anything else.

So how do you design a good UI? Answering that question is a challenge since much of design is subjective. My daughter’s favorite color is pink and my son’s favorite is black. Which one is correct? They both are since it is a matter of personal preference. The definition of good UI design is also somewhat subjective. Some people like dark backgrounds when using computers so they don’t feel like they are staring at a light bulb all day. Other people find that dark backgrounds are depressing and they prefer light colors. Once again, both groups of people are correct since it is a matter of personal preference.

This begs the question, how do you choose the correct UI design for an application when people have different tastes? One option is to let the people choose. Here is a process that accomplishes that:

  1. Build light, dark and medium themes for your UI.
    UI themes
  2. Make it easy for your users to choose the version they prefer. This allows each person to use the UI that is right for them.
    UI themes

For my fellow geeks out there, the ability to switch between themes at runtime was achieved by setting stylesheet references at runtime. The technology used was XHTML, CSS, JQuery and MVC.

There are many other factors when it comes to UI design besides color themes. This article only scratches the surface. If you want to dive deeper then visit

Here are some helpful links:

Power to the people baby! Enjoy.

–Dan Crowell

How about a little BREX 101 this week?

One of the most common points of confusion I hear about in the S1000D industry is concerning what the BREX data module does and how S1000D business rules are used to generate a BREX data module. It is believed by some that a BREX DM contains all of the business rules for a program, and by handing a BREX to a partner company, you can effectively instruct them on how to develop S1000D to conform to your business rules. 

This is not completely accurate. A BREX document is really only capable of storing rules that are enforceable on the actual S1000D XML content. This is due to the fact that a BREX rule must be enforced via an XPath statement. Decisions pertaining to the use of optional elements are perfect examples of S1000D business rules that exist in, and are enforced by, the BREX.

Rules governing the overall usage of S1000D cannot be enforced or expressed in the BREX data module. Examples of such rules include:

  • the decision to use process data modules instead of the fault isolation data module, or
  • to use an Arial font instead of Times for chapter titles.

Although these are important rules, they cannot be expressed using an XPath statement and, thus, are not included in the BREX document. 

When conducting training classes or when explaining S1000D constructs to our customers, we have found it useful to think of S1000D business rules as consisting of two distinct categories:

  1. Program Rules
  2. Authoring Rules 

A program rule is an S1000D business rule that dictates specific usages of the standard that does not specifically address XML content. Program rules include rules such as graphic formats, CSDB configuration, type of data modules to be used, etc. As program rules are meant solely for human use, these are generally provided as documentation (a Word file, HTML, etc).  

Authoring rules are data oriented and can be expressed as an XPath statement and, as such, can be enforced by a program or software application. The decision to disallow an optional element can be enforced via an XPath statement, and thus should be included in your BREX document. It is then the duty of a BREX-aware processor to read the BREX document and enforce these authoring rules.

So, when exchanging business rules, it is important to not only exchange your BREX data module, but supporting documentation containing program rules as well.

Any questions? Give us a call!

–Eric Lawson