BPMCAMP Sessions: Building Modular User Interfaces for BPM
Our very own Brian and Nik led a discussion on building modular user interfaces for BPM. They’ve been the force behind a lot of our UI development at BP3 – including the first version of Brazos Portal and several customer projects. BPM benefits greatly from modular user interfaces – and Brazos UI is an exemplar of doing modularity right. Composing interfaces with Brazos UI is dramatically more productive and effective than building UI without Brazos. But this talk was an opportunity to dig into why that’s the case.
The discussion was loosely organized by slides, but the focus was really to foster the next part of the discussion, interspersed with Q&A. What follows are some notes from roughly the “BP3” voice in the discussion:
The experience of building Brazos Portal, and then customizing it with modular components for customers, made us think about how we could generalize some of the modularity, what we could learn from it, and how we could productize it.
We focused more on coach views, but everything we discussed also applies to other types of User Interface frameworks and directives. We discussed what a module is, and how to identify one, and encapsulate it. We got into a little bit of the methodology and science behind the magic.
The discussion started with “What is a UI?”, and getting everyone to think beyond visual presentation:
- an HTML template
- HTML updates when data changes or updates
- Data changes when user makes a change (and updates back to server)
- It is a two-way binding and thinking process
So what are the benefits of a modular UI?
- Re-usability – the most obvious one. Stop copying-and-pasting.
- Adaptability – to change without rewriting the modules
- Simplicity – the code is easier to understand when it is leveraging common components
- Quality – by not starting from scratch for similar designs and components
- Speed- composing an interface with existing pieces is simply faster than building that UI from scratch
Some of the keys to a modular UI are to not try to design everything up front, but to start with a version and iterate and evolve it as a project is developed. Instead of rewriting when a project gets big, we can modularize. Each piece can then be rewritten separately and evolve without breaking or affecting the rest of the product. Modularity allows for a different way to refactor and improve a product over time.
Important to note that we see a form of benefit of modularity with task based interfaces in IBM BPM – each screen can be redesigned o re-implemented without affecting or breaking screens that come before or after in the process. Each process step can be refactored and redesigned and re-implemented without breaking steps before after or outside of the current step. Modularity is a big win.
Nik and Brian then revealed their approach to understanding the ask, rough identification of high level pieces and areas of the screen, a focus on a low-investment implementation attempt, followed by demo and feedback. Then break it up, rinse and repeat.
A key learning from this is that it is actually super easy to mock up IBM BPM Coach Views when you’re using Brazos UI – so it is much faster to just quickly put something together and play with it than it is to do wire frames and then proceed through several iterations of static designs before building an interactive model. And this is just a big advantage of composing UI with great coach views or UI components.
Another key takeaway is that in order to understand design decisions better, designers and UI builders must understand the technical framework better, so that they can speak that language and understand the constraints involved. Otherwise, designs are for things that can’t be easily built, or can be built at 10x the effort. Or design rework ensues, causing delays. The longer the distance between a requirement and a user using real software is, the less likely you get the design right.