The Oasis Digital Blog

Introduction

Modl Buildr is a configurator that allows users to select and configure a product of choice. It was inspired by a desktop configurator application and the question, “How can this problem be solved better in the browser?.”

As with many of our projects, we used AngularJS. Built as a framework for enhancing and augmenting the HTML language, Angular provides developers with a toolset supporting web applications consisting of dynamic, data driven content. Angular’s primary components include services for the isolation of business logic, routing for application architecture, controllers for marshaling data and directives for concise templates and view. Modl Buildr is created on these four core concepts.

We introduced Modl Buildr in a previous blog post.

If you prefer a video exclamation to text, the video below explains how it works in considerable detail.

For text, read on.

Routing

Client side routing is needed in most non-trivial Angular applications. The router allows users to navigate between features of the application without the need for additional server round-trips. When establishing the routes of the application Modl Buildr takes advantage of the syntax and creates a declarative road map of the application’s “pages”. The state declarations that are added highlight what routes are available and their associated models, views and controllers. By utilizing the resolve mechanism it is immediately clear what pieces of data are needed in order for any given route to function properly. This also removes the need for the controller to communicate with an API service or contain promise handling boilerplate.

Controllers and Services

Connecting the models to the view are various combinations of controllers and services. The router takes advantage of custom services to allow the creation of clean, simple and maintainable controllers. Consider the following code used to connect the landing page’s view to its model.

Controller:

(function () {
   'use strict';
   angular.module('app.home', [])
       .controller('HomeCtrl', function ($state, featuredProducts, popularProducts, productDataService) {
           var hctrl = this;
           hctrl.featured = featuredProducts;
           hctrl.popular = popularProducts;
           hctrl.selectProduct = selectProduct;

           //Prefetch for next route in navigation
           productDataService.getProductList();

           function selectProduct(selectedProduct) {
               $state.go('configure', {productId: selectedProduct.qsBaseID});
           }
       });
}());

Services:

that.getFeaturedList = function () {
   return that.getProductList().then(function (list) {
       return _.where(list, { Featured: true });
   });
};

that.getPopularList = function () {
   return that.getProductList().then(function (list) {
       return _.where(list, {Popular: true});
   });
};

The code responsible for obtaining and shaping the data is isolated nicely in a service, consumed by the router, and made available to the controller. Meanwhile, the controller simply passes the data to the view. This MVVM (MVC, MVW*) pattern is seen throughout the application.

Not all of the controllers and services are this simple. Some data bindings require constant updating in the form functions. For example, as a user configures a product there is a significant amount of calculation that occurs to determine if the product’s configuration is still valid. The result of this calculation is bound to the view for the user to see. Best practices encourage a clean separation of controllers and services while allowing the service to take responsibility for complex computation. The following code snippet demonstrates how Modl Buildr achieves this separation while maintaining two way data binding.

(function () {
   'use strict';
   angular.module('app.configure')
       .controller('ConfigureCtrl', function ($scope, $stateParams, $state,
                    productDataService, productStateService,appStateService) {
           var confCtrl = this;

           //the result of execution valid changes with every user input
           confCtrl.valid = valid;
           confCtrl.reset = reset;
           confCtrl.goToSummary = goToSummary;
           confCtrl.optionDisplay = optionDisplay;

           //Guard against extra API calls by only updating when the user’s selections have changed
           $scope.$watchCollection(function () {
               return confCtrl.selections;
           }, function (n, o) {
               if (n && n._seriesId) {
                  productDataService.getValidity(n).then(function () {
                       updateAll();
                   });
               }
           });

           function goToSummary() {
               var modelNumber = productStateService.productOptions.BaseLabel;
               modelNumber += _.map(productStateService.levelsToBuildModelNumber(), function (level) {
                   return productStateService.selections[level.Tag];
               }).join('');
               $state.go("summary", {productId: productStateService.productOptions.qsBaseID, number: modelNumber});
           }

           //This is called after every change to the user options
           function updateAll() {
               confCtrl.levels = productStateService.levelsToConfigure();
               confCtrl.modelDisplayOptions = productStateService.levelsToBuildModelNumber();
               confCtrl.valid = productStateService.valid;
               confCtrl.selections = productStateService.selections;
               confCtrl.productInfo = productStateService.productOptions;
           }
       });
}());

In the example above productInfo (the model number) and selections (the user’s choice of options) are bound to the view. The data in productInfo is a result of a function whose input is the selections. This approach not only provides a simple set of bindings, but also matches the application’s primary use case perfectly. The primary use case of the application is to select from a set of options and generate the corresponding model number. The challenge with this solution is that the server acts as a block box while performing the calculation. Fortunately the binding function is designed in such a way that it doesn’t matter where the complex calculation takes place or what it does. As the selections are updated the controller makes a service call and updates the bindings based upon the updated data that’s returned. The services handle the question of what to do and isolates the controller from any complexities or potential changes to this process.

Directives

There are several elements that appear on multiple screens of the application. These include simple pieces of functionality such as a hover text explaining why a button is disabled to custom widgets such as the product tiles. While controllers and services are great for laying out the big picture. Directives shine when used to create reusable and named components.

Modl Buildr contains a custom product tile directive. A reusable tile with a card-like appearance is created by combining a bootstrap panel, an image and a styled definition list. This tile is used to present products to the user. By specifying a few custom properties the same tile directive can be used across multiple situations.

Jade Template:

div.panel.panel-default.products-container(ng-click="click()",
   ng-class="{'product-tile': configure==='false', 'configure-tile': configure==='true'}")
   div.panel-heading
       | {{product.BaseLabel}}
       i.fa.fa-2x.fa-star.pull-right.featured(ng-show="product.Featured")
   div.panel-body.product-details
       img(ng-src="{{product.Image}}")
       hr
       dl.dl-horizontal.centered-block
           dt Name:
           dd {{product.BaseDesc}}
           dt Mfr:
           dd {{product.Manufacturer}}
           dt Item Type:
           dd {{product.ItemType}}
           dt Subtype:
           dd {{product.ItemSubType1}}

Javascript:

(function () {
   'use strict';
   angular.module('app.tile', [])
       .directive('descriptionTile', function () {
           return {
               restrict: 'E',
               templateUrl: "app/tile/descriptionTile.html",
               scope: {
                   product: '=info',
                   click: '&',
                   configure: '@'
               }
           };
       });
}());

With this definition and an ng-repeat these tiles are easily stamped out in a grid formation. This directive is also used on subsequent screens to display the product being configured.

Another helpful directive is the model number directive. The model number at the top of the configure and summary screens is generated by the users actions. Rather than complicate the main page controllers with the logic for displaying this interactive control a directive was created to isolate this concern. Now a model number can be displayed anywhere in the application by adding the following line of HTML (Jade) in the desired location:

model-number(product-name='{{cfg.productInfo.BaseLabel}}',
    current-selections='cfg.modelDisplayOptions',
    scroll-target='scroll-container')
// (the above is Jade, http://jade-lang.com/

Conclusions

Angular turned out to be a good fit for this application, yielding a working solution with a modest amount of code. Moreover, the application works quite nicely in a browser, at least as nicely as the native desktop application we were inspired by. The browser environment in 2015 is completely suitable for complex rules-based configurators.

 

 

Introduction

Modl Buildr is a demo application we created at Oasis Digital, a rules-based “configurator”. Its inspiration comes from older desktop application configurators. Modl Buildr can be used to generate model numbers for highly customizable products. A user can select a product, choose from a set of options for that product, review the final product and request a quote. This article explains the details of this process and highlights some key features.

For this demo application, we picked an example of a product with lots of options – hospital beds. All of the data used for this demo is openly available on the Internet; it is not from any customer project. (Our customers’ real information is all hidden behind firewalls and NDAs…)

Choosing a product

Users can select a product from a short list of common products, or by searching a catalog. The common products are shown first:

Should the user choose to browse the product catalog, they see each product presented as a “tile” containing an image of the product and any additional spec information.

Adjacent controls provide the ability to filter through the catalog. This is done by typing a product’s name or choosing one of several product categories. This was designed to resemble many other online marketplaces to create a familiar experiences for first time users.

As the user interacts with the filters the catalog responds immediately by adding or removing the products that fit the user’s criteria. The results respond to the user’s input without the need for the user to request an update. This type of workflow greatly speeds up the process of identifying the desired product and moves them forward in the process quickly.

For users desiring a more compact view of the data there is also a grid view that displays the product information in a dense format. The grid view behaves in the same way as the tile view when interacting with the filtering tool. Once a user clicks on a product they are taken to the configuration page to set the product feature options.

Configuration

The configuration page contains a display of the model number associated with the selected product. The display updates automatically to reflect the changes from interacting with the product options.

A user configures the model by scrolling through the products feature list and selecting various options. As options are selected additional features will be added and removed automatically. If a user’s selection becomes invalid at any point that option will appear in red with an icon indicating that a conflict has occurred. The corresponding component in the model number will also turn red. The user can click on this portion of the model number and the list of features will automatically scroll to the problematic feature allowing the user to update their selection. Once a valid model number is configured the user can click on the “next” button to navigate to the review screen before requesting a quote.

The rules that determine the validity of a product are not “hard-wired” into the application. Instead they are entered by the application administrator and executed on the fly. Examples include, “There are no options for TV controls unless the electric option has been selected” or “Choosing a manually positioned bed invalidates the electric footrest option.” These English phrases can be easily into rules and are associated with a product. These rules are then used by the configuration page to guide the user towards generating a product that meets their needs and the suppliers capabilities.

Having selected and configured the product the user arrives at the summary page. The details of the product and the user’s customizations are displayed and they are presented with a simple contact form from which they can request a quote.

Conclusion

Once the user submits a quote the application demo reaches its end. But the usage for this platform could be extended in a number of directions. Modl Buildr could be extended to include an additional step for browsing and manipulating the components that go into manufacturing the final products at another level of detail. The application could be expanded to include sales information and trends. Additional features common to other marketplace applications could be added such as shopping carts, order history, billing information, etc… On the administrative side of the software additional screens could be added for the management of products, orders and other common administrative tasks.

Modl Buildr is a small example of the kind of business-centric software that we create every day. If you are interested in how it works we would love to show you more.

More about Modl Buildr:

• A technical article explaining how it works
• A technical video explaining how it works
• Try it yourself online (coming soon)

 

 

At Oasis Digital we host a St. Louis Angular Lunch each month. Many months an outside speaker comes in (especially if anyone volunteers!), other months someone from Oasis Digital speaks. In July 2015 we did something a bit unusual, several of us sat around and just talked about our Angular 2.0 preparations for a while. Although quite informal, it was well received. See the video embedded here.

 

Preparation for Angular 2.0 can include a lot of things, here are a few of the most important which came up in the discussion:

• Now is the time to learn/use TypeScript. (We have converted a large Angular project to TypeScript.)
• Now is the time to learn/use ES6/2015. (We have converted a large set of Protractor tests to ES2015.)
• Angular 2.0 uses native ES6/2015 modules – which already work today.
• The new “component router” for Angular 2 is also intended to arrive as a backcourt in Angular 1.x; it is very different from both the old Angular router and the very popular angular-ui-router. Although much work remains to be done, it is possible to start learning it now.

One topic of lively discussion was guessing when Angular 2.0 might ship. No ship date has been released, but several of us in this discussion thought it could be problematic for the Angular community if another major US spring conference goes by without A2. Therefore one obvious guess: Angular 2.0 will ship, perhaps just as “beta”, approximately around the next spring Angular conference. No one present has any connection to the Angular team, so this is just an outside, educated guess.

Transcript

We have also transcribed the discussion to text, provided below. This is a rough, first-draft transcription, so any errors are probably from that process.

 

Continue reading Angular 2.0 Discussion – Angular lunch

This month at the St. Louis Angular Lunch I spoke about Angular’s upcoming “component router”. Originally created for Angular 2 and to-be-back-ported to Angular 1.x, the component router serves as a replacement to the current routing options. While still too early to use in production it looks like a promising alternative. In this talk (video below) I outline where the component router stands and a brief example of how it can be used.

 

Transcript

Here is the talk, transcribed to text. This is a lightly edited, draft transcription, so any errors are probably from that process.

Continue reading Angular 2 Component Router

This month (May 2015) at the Angular Lunch we had a very special guest speaker. Matt Follett (currently working at Observable Networks) shared his extensive experience working with end-to-end testing of browser-based web applications, including Angular applications. Although Matt only briefly mentioned Protractor (the Angular specific wrapper around Selenium), nonetheless almost everything he said was highly relevant to protractor.

Matt did not pull any punches in describing the difficulties of this type of test, and his comments certainly match our experiences at Oasis Digital testing Angular applications using Protractor. Still, the payoff of this level of testing is so high that we find it generally worth the effort. Automated testing is a (the?) way to keep quality up and regressions away as an Angular application grows in complexity and size.

Perhaps the best part of Matt’s talk is toward the end, when he (gently) compares the various available hosted browser/selenium services.

Transcript

We have also transcribed the the talk to text, provided below. This is a rough, first-draft transcription, so any errors are probably in that process, rather than in Matt’s actual content!

 

Continue reading Automated User Acceptance Testing – Matt Follett – Angular Lunch

Several members of the Oasis Digital team attended ng-conf in Salt Lake City recently. This month for the St. Louis Angular Lunch (April), we had a roundtable discussion of the conference and what we all learned at it. Here’s a video of the discussion:

Transcript

Here is the discussion, transcribed to text. This is a lightly edited, draft transcription, so any errors are probably from that process.

Continue reading ng-conf Review Roundtable – Angular Lunch