Heads Up - Bonita BPM 7.0 UI designer - great idea, poor implementation

1
+12
-1

The intention of this post is to serve as a "heads up" for Bonita BPM creators. But since this is a space for answers, here I ask: When will the questions below be addressed/corrected/resolved and features recreated?

The new UI Designer may be paradise for programmers (which I doubt), but it is surely hell for users involved in creating process automation. From AIIM (Association for Information and Image Management) what I've heard is that users want PRODUCTS, not PROJECTS, and that large organizations are tired of spending significant resources on customization. BonitaSoft seems to be going in the exact opposite way. What was mainly about building a form using an intelligent, USER-friendly design tool, now has turned into development and test cycles.

For those who are not understanding, let me explain.

a) Begining with the "lacks of", or "user's, developer's and administrator's" perspective:

a.1) There is no ctrl-Z, no undo or redo, in the UI Designer editor (tested on IE and Chrome). If you delete a widget, it's gone.

a.2) A developer must rely on his memory to remember what business data model properties are to be used on form fields properties. There is, of course, the "context" variable, but - as far as I understood - it demands the process to be run until the specific step in order to obtain a link, then to be run again to obtain the content of the link, then you need a notepad to write it down. Imagine a 10 human steps process and the fact that you'll have to run it 20 times to get the context in order to prepare the forms (because contracts can be different). In the previos interface all you had to do was to click on a combo box.

a.3) Process variables simply do not exist for the new UI Designer. It only "sees" what is in the Contract, and the Contract knows no Process Variable.

a.4) The pre-built field validators and the possibility to use a Groovy Script on it no longer exist. You ought to do some coding to have it.

a.5) Error message exibition (derived from fields) on form submition, which was automatic in the previous versions, now must be custom maded, and also added and placed form by form, field by field.

a.6) The following Bonita 6 widgets disappeared (and most of them will be missed): duration, password, list, rich text area, editable grid, hidden, iFrame, html widget.

a.7) Forms of all processes appear as a single list (no folders, no process separation). Imagine now a hundred processes with 10-20 forms and pages each. In my case, when I deletes processes, the forms did not go with them, they stayed. It is administration hell.

a.8) Custom widgets seem to belong to the Studio/UI Designer installation, not to a company wide repository. Since Studio is not a client-server application, but a standalone one, the more you create, more differences will appear between departments using their own copies of Studio. Widgets are all stored in the same place, just like forms. In a large company, you'll soon have widget hell in hands.

a.9) Whenever you click in "new Form" one is created and saved. It does not matter if you do not click on "save" in the UI Designer. The result is that you may accidentally create a vast list of "newForm" named forms.

a.10) You cannot delete any form from within the task's Execution tab. You have to call UI Designer from its button on the Studio top menu. And since the Designer accepts more than one form with the same name, you may have to play "eeny, meeny, miny, moe" to find the right one.

a.11) Each and every form created for a specific process appears on the forms list of all processes. And to get things worse, since we can have identical names, "James" may play havoc with "John's" form.

a.12) If you delete a process in Studio, its forms remain - they are not deleted with it. Once again you must appeal to the UI Designer button (cannot call it from within a task "Execute" tab).

b) Now from the "buyer's" and "manager's" perspective:

b.1) There were transient process variables, now form variables came to the spotlight, so we have business data objects, process variables (transient and non-transient), contract variables and form variables to deal with while trying to document the process (and form variables certainly won't appear on automatically generated process documentation, since they are decoupled from the BPM engine).

b.2) Not to mention that in a large company, with many sites and local IT departments, it will be extremely hard to keep track and standards of all the forms produced with this new UI Designer.

b.3) Some training on AngularJS and BootStrap seems to be needed for the person in charge of the design, who must be a programmer.

Regards.

Ricardo

Comments

Submitted by Sean McP on Thu, 07/23/2015 - 10:00

First, thank you Ricardo for writing this down, you are not alone with some of your frustrations with the New UI. It does in someway seem to be a backward step compared to the easy to use previous form editor. I also suspect its development is driven by corporate needs (paid for subscription purchasers) rather than the free community users.

I also note the power for generating new and better forms for use within a business environment, however the complexity of it does make you wonder which is preferred. At the moment we’re still using 6.x forms rather than 7.x. It’s just too complex, my developers want to write processes, not write REST calls…

Here are some of our thoughts…

The new UI is great for forms designers, but the interaction with data is wanting. We shouldn’t be needing to write REST calls to get to the data, it should just be there in a drop-down list fully automated. And returning values seems much more difficult, what’s wrong with the data just being available to the process, automatically?

*Regarding Development and Test-Cycles. We like this, is brings the concept of simple development into the real world of governance of systems development, however that doesn’t mean it has to be complex, it can be as easy as you want it to be. *

Regarding your specific issues, I will add my two pennies worth…

a.1) There is no ctrl-Z – Agreed, what a pain…this has always been a fundamental part of every editor, why not here!

a.2) A developer must rely on his memory to remember what business data model properties are to be used on form fields properties.

This should be self-evident to the development and automated by the system.

a.3) Process variables simply do not exist for the new UI Designer. It only "sees" what is in the Contract, and the Contract knows no Process Variable.

This should be self-evident to the development and automated by the system.

a.4) The pre-built field validators and the possibility to use a Groovy Script on it no longer exist. You ought to do some coding to have it.

This could be implemented via Jaascript, but you are right, could be easier.

a.5) Error message exibition (derived from fields) on form submission, which was automatic in the previous versions, now must be custom made, and also added and placed form by form, field by field.

Agreed, not as easy as it was before.

a.6) The following Bonita 6 widgets disappeared (and most of them will be missed): duration, password, list, rich text area, editable grid, hidden, iFrame, html widget.

I’ve already raised this as a bug here:

https://bonita.atlassian.net/browse/BBPMC-289

Note Bonita’s Answer…

Hi Sean, Thank you for reporting this. We are aware that there are still some functionality gaps between v6 and v7. Please keep in mind that the UI Designer is brand new compared to the 5 years of existence of the old form builder. As we release other 7.x versions, we will most likely add some missing widgets. In the meantime, remember that we now propose a custom widget feature that can allow any user to re-create these widgets. Cheers,

You might also want to read another thread which also says, something about 5 years of old form, and wait…

https://bonita.atlassian.net/browse/BBPMC-280

Personally I find both these answers rather disappointing.

a.7) Forms of all processes appear as a single list (no folders, no process separation). Imagine now a hundred processes with 10-20 forms and pages each. In my case, when I deletes processes, the forms did not go with them, they stayed. It is administration hell.

Totally agree here, there needs to be better segregation of forms.

a.8) Custom widgets seem to belong to the Studio/UI Designer installation, not to a companywide repository. Since Studio is not a client-server application, but a standalone one, the more you create, more differences will appear between departments using their own copies of Studio.

Widgets are all stored in the same place, just like forms. In a large company, you'll soon have widget hell in hands.

Disagree – In a large company you should be using the subscription version rather than the free community version. The Subscription version allows the use of GIT or SVN for all manner of artefact (not sure which), which would mitigate the widget/form hell you describe.

a.9) Whenever you click in "new Form" one is created and saved. It does not matter if you do not click on "save" in the UI Designer. The result is that you may accidentally create a vast list of "newForm" named forms.

I would raise this as a bug on Atlassian…

a.10) You cannot delete any form from within the task's Execution tab. You have to call UI Designer from its button on the Studio top menu. And since the Designer accepts more than one form with the same name, you may have to play "eeny, meeny, miny, moe" to find the right one.

I would raise this as a bug on Atlassian…

a.11) Each and every form created for a specific process appears on the forms list of all processes. And to get things worse, since we can have identical names, "James" may play havoc with "John's" form.

I would raise this as a bug on Atlassian…

a.12) If you delete a process in Studio, its forms remain - they are not deleted with it. Once again you must appeal to the UI Designer button (cannot call it from within a task "Execute" tab).

I would raise this as a bug on Atlassian…

b) Now from the "buyer's" and "manager's" perspective:

b.1) There were transient process variables, now form variables came to the spotlight, so we have business data objects, process variables (transient and non-transient), contract variables and form variables to deal with while trying to document the process (and form variables certainly won't appear on automatically generated process documentation, since they are decoupled from the BPM engine).

It’s definitely not as easy as it used to be…

b.2) Not to mention that in a large company, with many sites and local IT departments, it will be extremely hard to keep track and standards of all the forms produced with this new UI Designer.

In a large company you should be using the subscription version rather than the free community version. The Subscription version allows the use of GIT or SVN for all manner of artefact (not sure which), which would mitigate the widget/form hell you describe.

b.3) Some training on AngularJS and BootStrap seems to be needed for the person in charge of the design, who must be a programmer.

Yes, agreed, it is too complex to use.

2 answers

1
+2
-1

Hi,

First of all thank you for taking the time to provide such detailed feedback.

You will find below some solutions and workarounds to your questions.

Sometimes you’ve spotted some limitations that Bonitasoft has also identified and already plans to address.I will try to provide some insights about ongoing discussion and possible solutions that will come up in future releases.

User profile for process based application development

First I’ll clarify the expectation we have for our users about their technical skills.

Bonita BPM version 7 provides an environment to develop process based applications. For this, two different user profiles are expected to be involved:
Business analysts
Developers

We expect business analysts to be able to do BPMN modeling and (eventually also) some UI mockups.

Meeting end users’ expectations in terms of richness and dynamic user interfaces is a big challenge. Software that can be used by non-technical users usually has strong limitations when it comes to customization, and leads to creation of user interfaces too far away from what end users need and want (as we learned, is the case with Bonita BPM 6).

So, with UI Designer, we created an extensible tool for developers to build UIs that meet the final business analysts and user expectations, to help real adoption of the new application. We expect business analysts to work and collaborate with developers by designing mockups with the UI Designer.

Benefits of the new architecture

The new architecture with a clear separation between UI, process definition and business data model is something that bring key benefits in collaboration and evolution of applications.

Once contract and data models are defined, the UI designer and process developer can work independently. This makes collaboration a lot easier compared to a solution that bundles user interface and process definition together and more or less simultaneously.

Also the loosely coupled architecture bring new capabilities for live update after deployment. This is something that really sets the Bonita BPM solution apart - by enabling the system administrator to adapt of a deployed process to an evolving execution context. You can for example easily deal with situations such as: a change in company organization, evolution of information systems, various UI evolutions (because of the use of contracts), and more. With such capabilities you avoid risky and costly deployment of a whole new application.

Roadmap and releases

I’d like to share some information about the way we handle roadmap and releases.

A minor release (e.g. 7.0 to 7.1) happens every 3 to 6 months. Such releases add new features and improvements in a backwards-compatible manner. This is a key opportunity for us to evolve the platform based on your feedback.

A maintenance release (e.g. 7.0.2 to 7.0.3) happens every month (on the first Thursday of each month). Usually this release is all about bug fixes. But from time to time it might includes improvements that present a low risk of regression. Based on feedback, since the launch of version 7, we have decided to include some UI Designer enhancements in maintenance releases to quickly remove and improve current limitations.

Answers to individual points

And to address the individual points you report:

a.1 ctrl+z / undo & ctrl+y / redo

We agree that this is a major limitation in the current UI Designer. This feature is in our roadmap and should come in a future release. We are working to include this improvement in a release before the end of the year.

a.2 forms and data

When you create a form you should separate two different scenarios: data you want to display to the end user, and data that the end user needs to send for process instantiation/execution.

Data to display

Data that you can display to the end user usually comes from a business variable declared in the process definition. To bind a widget with a business variable attribute you need to know the name of the business variable and the name of the attribute.

For example, if a business variable is named “vacationRequest” with an attribute named “startDate”, you can get the business variable value using this URL: ../{{context.vacationRequest_ref.link}}, store the result in a form variable (e.g. myVar) and bind to the widget myVar.startDate.

As you can see there is no need to run the whole process. What you need is to have the UI Designer and Studio side-by-side so you can check for the names of business variables, and you need your business data model so you can look at object attribute names.

Note that if needed you can actually call the REST API to get business variable value without running a process instance.

Data to submit

When it comes to the submission of data for process instantiation or user task execution you need to use a form variable (i.e. a JavaScript variable) with a JSON object. JSON objects have associated names and values. Name needs to be set with the name declared in the “contract” and value is the actual value to send to the process (usually set by a widget).

Again here you don’t need to run the process, you simply need to take a look at the contract in the Studio.

Note that Studio provide a tool to generate the form based on contract definition.

I agree that making sure that you create a form that complies with the contract can be tricky as it relies on a specific naming convention between your form variable and contract input names. In a future version, we plan to provide completion on the context variable and on the variables used to fill up the contract. This means you should get something even easier to use than version 6.

a.3 process variables

Currently, you can update process variables using contract inputs in an operation.

If you want to display some process variables in a form, call some REST APIs, store the results in form variables and use them in your form widgets. An example is available on the community website.

Note that for most common use cases we recommend using business variables over process variables. We added this new feature to allow better performance for search operation (which rely on DB indexes), lifecycles independent of process instances (this allows several process instances/definitions to collaborate on shared data). This recommendation hasn’t changed since v6: process variables are recommended for flow conditions as their data become useless when the process ends.

a.4 form validator

Here is a list of replacements for each of these previously existing validators:

  • Email: “email” type on “input” widget
  • Length: you can use properties “min length” and “max length” on “input” widget
  • Date: will be natively embedded in date widget in a future version
  • Double, Float, Integer and Long: use “number” type on “input” widget or implement your custom validation based on a JavaScript form variable and enable a condition on submit button.
  • Phone number / Groovy expression / Character: you can create any custom validation using JavaScript form variables or create a custom widget (this is the best option for easy reuse across several pages)

Currently our advice is that you should create a custom widget that lets you embed the validation directly into the widget definition. This solution lets you reuse easily a widget and its associated validation.

Another option is to use the JavaScript form variable to define your own custom logic depending on widget value and use this form variable to enable or disable the submit button.

Our aim is to provide out-of-the-box validation (similar in rendering to version 6) but with more flexibility and better performance. As this default validation will run on the client side (JavaScript), response time will be shorter (more reactive) and you will be able to debug it right from your web browser (browser development tool).

In the meantime, we plan to provide a doc page to describe how to properly use the current validation mechanism and how to extend it. This should be ready next month.

a.5 validation error message

See a.4

a.6 missing widget

You can check this table that compares widget in version 6 and in UI Designer in version 7. As you can see only the Rich Text Area widget is missing. This one is in our backlog and should come in a future version.

a.7 forms and pages management

I agree that in UI Designer the long flat list of forms and pages make it very difficult to locate a form based on information such as which process uses it. The best recommendation for now is to start from the process and choose to edit the form.

When you delete a process definition, associated forms are not deleted because a single form might be used by multiple process definitions.

A future version will bring improvement on this point, to categorize forms and pages based on which processes and steps use them.

a.8 share custom widget

Note that collaboration using shared repositories is a feature of our Subscription edition.

a.9 newForm default name

Default form names should become contextual in future release.

a.10 delete a form

This should be covered at the same time as a.7.

One temporary workaround is to edit the form (from Studio, click on “pencil” icon). In the editor window of UI Designer, rename the form (e.g. “to delete”), then go to the home page and locate the form and delete it.

a.11 list of forms in Studio

This item should be addressed at the same time as a.7 and a.10.

a.12 form not deleted when deleting process definition

See answer on a.7.

b.1 different type of variables

The basic rules to remember is: use business variables as much as you can.

Note that documentation generation is not the current top priority, but ifwe do some update here, I will make sure that we take care of including business variables.

b.2 collaboration in a large company

A use case like this is covered by Subscription edition features.

b.3 requirement for UI developer

I would say that training on AngularJS is a plus. I agree that a developer profile is a prerequisite for implementation of dynamic forms. However, a profile without a development background should still be able to build a UI mockup.

Comments

Submitted by romualdo.s.rs on Tue, 02/07/2017 - 17:54

need to display the records that are in my BDM in UI Designer, so far I have only been able to display what is in my process variable, through the following code:

../API/bpm/caseVariable/{{task.caseId}}/listaTransportadoras

However I need to display my BDM records in a table in the UI Designer, how can I do this?

Submitted by Sean McP on Tue, 02/07/2017 - 20:25

Please create a new question for this, it is not directly related to this post and will be confusing.

I suggest a title something like, How to display BDM in table might get people to repond better.

regards

1
0
-1

There is one more point I want to add for v 7.2.0, which was probably missed by r torres.

If in contract for a human step, a document (file) is specified then the user must upload the document in corresponding web form to pass validation. Otherwise the form shows some kind of validation error message which to my surprise goes away in 2-3 seconds. Why a user must upload a file. What if it is not mandatory to upload file.

  1. How can I allow user to still submit the form without a file being uploaded?
  2. In a two step workflow, will it allow to update the same file with a new one in an approver step?

It gives error:
Error while trying to execute the task. Some required information is missing (contract not fulfilled).

Log message:

2016-02-23 15:17:01.620 +0530 org.bonitasoft.web.rest.server.api.resource.CommonResource org.bonitasoft.web.rest.server.api.resource.CommonResource doCatch
SEVERE: USERNAME=applicant | org.bonitasoft.engine.core.process.instance.api.exceptions.SContractViolationException: Error while validating expected inputs: [{} cannot be assigned to FILE, {} cannot be assigned to FILE, {} cannot be assigned to FILE, {} cannot be assigned to FILE, {} cannot be assigned to FILE, {} cannot be assigned to FILE, {} cannot be assigned to FILE, .......

Comments

Submitted by geovanny.campoverde on Mon, 09/19/2016 - 23:02

I have the same problem friend.

Did you get to fix it?

Submitted by Sean McP on Tue, 09/20/2016 - 06:37

You have to add a function in the return that gives NULL as the file.

This has been covered in several other posts.

regards

Notifications