Brazos UI – the best UI in BPM? Signs point to yes

Scott Francis
Next Post
Previous Post

At BPMCAMP recently we spent a lot of time reviewing great user interfaces in BPM and how to build them.  Several of our sessions focused on what a great UI looks like for BPM and what it means.  Of course there is more to UI than just the visual elements, but sometimes just the visual elements alone tell you a story as well.

Sometimes a company gets a reputation for being good at user interface. Or good at mobile. And sometimes they deserve it.  But sometimes they have really made the wrong bets in terms of technology direction and the future of mobile UI.

Appian is a company with a reputation for great UI in the BPM space, if you read analyst reports and their own press. Recently I looked at Appian’s SAIL interface on their website.

Let’s take a look at one of the screenshots of SAIL:

http://appian.com/assets/sites/2/2014/12/sail1.png

This is the UI of the much-hyped Appian SAIL interface?  It’s like watching paint dry.  By contrast, the same screen built in Brazos in less than 30 minutes:

iMac

 

Of course, you can’t experience the interactivity of Brazos in a static screenshot, but it makes an impression, and it looks great across desktop, tablet, and phone interface sizes.  But when I look at what they’re producing and compare to a few minutes work in Brazos UI, I know which interface I would prefer. A few more comparison shots:

http://appian.com/assets/sites/2/2014/12/sail2.png

And now, the equivalent screen shots with Brazos UI:

MacBook iPhone iPad

To be clear, all four of the views of this interface in Brazos UI were developed in one shot. This isn’t 3 or 4 configurations, this is just how Brazos UI works as a responsive UI.  

We’ve been saying Brazos is the best UI for IBM BPM for years.  I think it’s the best UI for BPM, period.  If SAIL was the bar, Brazos has been exceeding it. We’ve seen Pega’s user interfaces that frankly aren’t any better.  And if Brazos is a better experience than the best User Interfaces from the leading vendors in BPM, then we’re doing something right for our customers.

 

 

  • Brazos certainly does look great and is very cool… But to be honest all of us in the industry need need to provide some measures of improved worker/operator productivity to claim that our UIs are great BPM UIs.

    What worker/operator/supervisor use cases would you say that Brazos excels at when compared to Appian SAIL?

    • John, it’s an interesting standard that you’ve laid out, I’m not sure I agree with it. First, in my post, the claim I made is that Brazos UI looks as good or better than what we hear is the standard of practice in our business – Appian. Brazos also has a lot of design expertise baked into the UI controls, behaviors, interactions and standards. We did not optimize for our own internal expense, we optimized for BPM developer and BPM user/operator experience.

      You state that the industry (all of us) *need* to provide measures of improved worker/operator productivity to claim the UIs are great BPM UIs. That’s not the case. Let me explain why.

      In the context of improved productivity, UI is an important part, but not the only part – and can’t be separated from the context of the process design and engineering that also goes into developing a BPM solution. The only way to get an accurate measure for what you suggest is to implement a process in Appian, then -only changing the UI- implement that same process using Brazos UI and then compare worker productivity. Or to take a legacy system and keep its process but only swap out the UIs. While we could do that, it isn’t practically something any customer is going to pay for, they’re rightly going to push for process improvements in any migration to a new technology. However, if someone would like to volunteer their production processes and measurements for this scientific measurement, I’m up for it!

      So what can we measure?
      1. We can measure developer productivity. Brazos UI is more than 50% more efficient in development effort when compared to out of the box IBM BPM development. It also allows UI design to skip the wire framing stage, resulting in dramatic savings overall in UI development. Finally, you skip the “develop a UI for each platform” aspect of nearly all the other vendors. We develop one UI in Brazos and it “just works” across all the form factors. That’s a huge productivity boost. We saved one customer several person-years of design effort across 8 process applications.
      2. We can measure the capabilities and the effect of capabilities in Brazos UI – ADA support, WCAG 2.0 compliance, localization, browser support (Chrome, Firefox, Safari, IE, Blackberry, Good), etc. All of which can improve operator efficiency to the extent that any of those platforms or capabilities might not be available on another platform, or might require significant additional investment.

      Also, we can subjectively assess look and feel, as I’ve done above. We can attempt to turn subjective data to objective data by looking at adoption rates and reactions from customers, viewers of demos, production deployments, adoption of those deployments, etc. – all of which are quite positive with respect to Brazos.

      So if it looks better, feels better, and saves you a ton of development time and money – freeing you up to focus on process improvements and changes to your business – and allows you to address platforms and browsers and language support “for free” (no additional effort) – then we’re doing something right. And we’re doing something best in class for BPM.

      • I’m glad I asked Scott. Your reply makes a way better case than your original post ;-)

      • well if that isn’t a backhanded compliment I don’t know what is ;) Sometimes more coherent thought results from a challenging question.

        In my case, when I focus on what Brazos UI “looks like” it is at a component level. In fact, one of the benefits you get is good UI without focusing on designing something really arcane for a specific use case: the special tree control with 15 features on each node of the tree – ugh! – and instead focus on the information, the flow, and the actions – and Brazos helps you do that because you can compose your interface out of already highly functional, beautiful, UI components, instead of starting with cr*p and customizing it like crazy before you get anything visually appealing.

        So… ironically… starting with something very visually appealing actually allows you to focus on the “what UI needs to do” instead of “what UI looks like” earlier in the effort!

      • Even better reply Scott ;-)

        I can’t resist hijacking your thread to express a “BPM UI” conundrum of my own… because smart people tend to read your posts and maybe they can help me figure something out.

        To meet the operational objectives of a BPM project with realy high-volume tasks, UIs often need to be highly-tailored for the domain specific work that operators have to perform (which might be that super-tailored special tree control with 15 features on each node).

        For example, if the need to check and correct information extracted from thousands of scanned documents is a major bottleneck in your process (which it tends to be for many of Lexmark’s BPM clients) then you’ve got to have that extremely tailored “document correction” UI (which looks like something from the green-screen 3270 days but has been proven to minimize errors and time-spent-per-document).

        At the other end of the process spectrum – low volume but highly nuanced information intensive work (think Case Workers)- there’s also need for highly customized special purpose UIs. Think of the use cases that Keith Swenson is always challenging us with… UIs where the knowledge worker really has to fully understand the nuanced context of the situation before making a decision.

        This is the root of my conundrum – For high volume UIs and for high information UIs the “BPM Suite UI widget” approach doesn’t seem to be working very well. On both ends of the BPM worker spectrum it seems to be more effective to build UIs “from scratch” using the latest HTML5/Javascript (or native mobile) libraries directly on top of the APIs that the BPMS and work management systems expose.

        Which leads to my suspicion…

        BPMS vendors may in fact be wasting their efforts when they incorporate UI builders into their suites. Their effort might be better be spent in developing better APIs and client-side libraries for traditional UI developers to use with with their own favorite tools.

        Your own experience at BP-3 in building UIs for IBM BPM and for Activiti has definitely influenced this thinking – If the APIs for supporting BPM UIs were better developed, I suspect that Brazos would actually be even more useful.

        Thanks Scott

      • Jakob

        Hi John,

        I think a BPMS could have both: A developer-friendly API, maybe plus some helpful client libraries, e.g for javascript, that would help developers to build domain specific UI solutions, but also a way to create less complex or specific workflow UI, e.g. for prototyping or more simple workflow solutions.

        At Camunda we certainly focus on the first aspect, for the very same reasons you explained. And for us, that worked very well. However, I believe there is also a need for the solution Brazos provides, depending on the specific use case. I would therefore challenge your statement that the “unique UI” is absolutely mandatory in all relevant BPM situations (if that is what you meant).

        The only thing that is sometimes annoying is when line managers see a drag and drop form builder and seriously think this would allow them to build the kind of solutions you have in mind themselves, therefore getting rid of their programmers. You can still find vendors who sell that lie, and unmasking that lie is often an uphill battle.

        Jakob

      • Thanks for your thoughts Jakob…

        I completely agree about the “drag and drop” form builder’s actual utility beyond enabling a great sales demo…

        Back when I first became enamored with Lombardi (Could it really be 10 years?) it was indeed the integrated “Coach Designer” that delighted me. The ability to quickly build a UI for a process activity (and deploy it along with the process) was an enormous benefit…

        As time wen’t on, I have become less convinced in the value of the integrated designer as I began to understand that the “UI per Process Activity” paradigm only works for a very small subset of personae and an even smaller subset of activities – Much more often I found myself building UIs for each persona to interact with an entire process (rather than a form per activity)… and often the task was to add process elements to existing screens.

        We certainly need to be able to navigate between a process definition and the UI, and we certainly need to be able to deploy process changes and UI changes simultaneously – but surely there are more general ways to do that.

      • I think the thing Lombardi was missing was a cohesion between the UI that was “per process” and the overall view of a process app…and it looks like most other vendors suffer from this gap as well.

      • Agreed

      • I think you can have “both” in the sense that a vendor can provide a UI builder *and* a great API for building UIs without the form builder. In fact, IBM does okay with this – at BPMCAMP we showed how you can use BrazosOpen to solve the “headless” BPM UI case for IBM really well.

        And seriously, no one ever needs that weird specialized tree control. On a whiteboard I designed a better answer in 2 minutes,which could be built and presented to users in < 30 minutes to validate whether it would solve the problem better or not ;) Fancy tree views don't work on phones and ipads or just small browser windows.

        Having said that, there are needs for specialized *user interfaces* vs. specialized user interface *components*. You would devise specialized interfaces for high volume tasks, and you *might* develop a specialized UI component for that task (viewing/annotating a document for example). For those other low volume high information tasks – well, I think Brazos *is* the example you're looking for with the latest HTML5/Javascript trickeration.

        But there's more to good BPM UI than javascript and HTML5 – really understanding how the process/engines work, and the marshaling of data, is real work that BP3 is doing and embedding in the smarts of our controls when we're doing the "outside the form builder" approach.

        I think your last point about would they all be better served by not building those UI frameworks – I think they'd be better served by using Brazos – because UI evolves at a pace that doesn't follow annual or 6-month release cycles. Or even "customer upgrade cycles". customers will update the UI component frequently, but not the engine… There's a mismatch in impedance or something.

        scott

      • I think you’re on to something Scott… There is definitely a mismatch between Business Process (and Business Rules) and the UIs for interacting with those processes and rules.

        Perhaps it’s a very logical separation of concerns – a worker may need access to information from a myriad of sources in order to perform their “process work” which is completely irrelevant to the process and rules engines. That information – or the visualization of that information – may indeed change without the underlying process definition being concerned in the least.

      • it’s hard to get that right in a generic sense… but thinking about a specific process, not as hard. giving me some good ideas ;)

  • MarcMouries

    Here is a real nice & functional UI from a Pega customer. bit.ly/PegaOneUI
    And by the way it’s 3-4 years old.

    • The UI that I saw 3-4 years ago from Pega was far different from what’s in your presentation, btw – wonder if it was built outside of Pega and just integrates with it?:) We beat Pega’s UI at a couple places just a three years ago with an alpha of Brazos…

      What baseline technology was used, I wonder, for the x-platform html5 UI? :) (and my understanding was that the antenna acquisition was primarily to try to improve the UI, which was pretty bad before ; )