View Cloud

The Workflow Carousel Library/Framework: Overview

rubik-logo The Workflow Carousel (Project development name: Rubik) project began as a mobile SPA (single-page application).

The first iteration of this application was a project that allowed the user to swipe through a process; selecting various settings and then moving on to the fine details needed to complete a process. In all, the first version of this application had about 1.2 meg of code and maintained roughly 1 meg of data on the device. In user-testing, we found the application was slow and the code behind it was convoluted and difficult to manage.  We also found that about once in every forty loads, the browser crashed on the iPOD it was designed for. We suspect that it was the sheer amount of code and data being presented that caused this issue. This application was tied to a specific set of data and had purely horizontal navigation (based on a carousel effect).

It was decided at that point to move forward with something a bit more streamlined. We moved as much of the business logic as possible into the back-end (databases and WebAPIs). This meant that the application on the device could focus primarily on presentation and collection of data.

We started with a mobile-first approach; what is currently in place can, and will, change size cleanly, based on the screen it is displayed on (mobile, tablet, laptop, or desktop)

We developed a framework for presenting the data that would allow for greater use of the mobile devices inherent qualities while minimizing the amount of live data that got stored on the device. This eventually evolved into The Workflow Carousel Framework which has The Workflow Carousel Library developed on top of the framework.

Additional Articles in this Series:
Basically, we track five positions:
  1. Current
  2. Left
  3. Right
  4. Up
  5. Down
The Workflow Carousel Framework handles positioning of the HTML DIVs that fill these positions. These DIVs are called Cards within this context. As the current card is swiped (up, down, left, or right), the current card is dragged along with the card being moved onto the visible display area. Workflow Carousel itself manages setting dimensions for the cards (portrait and landscape), determining whether the user can move in the direction selected, performing the actual movement (slide) into the final position, as well as swapping the IDs (if the left card is swiped in, it then becomes current and current is moved into and becomes left).

The Workflow Carousel Framework navigation (management of swiping) is managed with HammerJS.

Cards then became the manager of the content to be displayed. Management of cards is broken into four key areas, which are:
  1. Card Handling
  2. Card Settings
  3. Card Subscriptions
  4. Card Events
Card Handling is the core functionality (the framework portion) that, when combined with the Workflow Carousel Framework, makes all the magic happen. This is where presentation of information happens; what cards are filled in and when. It uses Card Settings, Subscriptions, and Events to manage all of what happens on the cards defined.

Card Settings is a part of the Workflow Carousel Library and is used to define an array of cards. These allow us to define the interaction between cards (what is to the left, right, up, and down), as well as manage what we termed cycles or cards that have some repeating pattern (for example, if the card is a Set, the next card could be another Set). We can also indicate that a card cannot be swiped in a particular direction (generally depending on selection from a list to move in the blocked direction. And finally, this array allows for the current card to "force" a refresh of the data displayed, rather than depending on the data loaded when it was off the screen.

Card Subscriptions is a part of the Workflow Carousel Library and is the means used to bind developer-created functions in a means Card Handling can utilize effectively. Basically, the subscription information defined in Card Settings is used to fire the defined functions, telling them the title and direction being applied.

Card Events is a part of the Workflow Carousel Library and functions much the same way as Subscriptions (definition and created functions), except for the simple fact that event information is passed to the functions defined so that a card can react to some form of touch event (these can be managed as non-touch events, as well).

The current version of this project, as well as the examples posted on GitHub, utilize some basic frameworks. These are:

Also, in some versions, Bootstrap is used.

Basically, all of this gives us a framework/library that allows for a SPA that, at most, manages five (5) Cards worth of information in memory. Given the speed (slow) and memory requirement (high: about 2.2 meg) of the original version of this project, we now have a quick, responsive application that now runs in under 185 k of code with a framework/library that can be utilized elsewhere within our organization.

Additional Articles in this Series:

GitHub Files

by User Not Found
10 Apr 2014
  • Workflow Carousel
  • Mobile
  • Javascript
  • Front-End
  • Development


You are not allowed to post comments.