BPMN provides a default process portal . But if the business user wants a different kind of process portal with some custom look and feel ( or may be some rich UI )what could be the different consideration while choosing the UI technolgies for the process portal ? As I know , the BPM provides Rest API which allow to create custom portal. But as there are various UI technologies ( JSF, Struts . Portlet factories etc. ) available in the marlet , what could be the different consideration to pick any one of them?
Re: Choosing Ui technology for Process Portal2013-09-06T16:11:00ZThis is the accepted answer. This is the accepted answer.
The following are just opinions of mine but:
- If you just want a different look and feel, customize the existing portal: don't build a new one.
- If you don't have a compelling reason to use a specific technology already in mind, you probably shouldn't be building a new one. The best reason to build a custom portal is "I already have this UI that the user is looking at: and it's written in technology XXX, so I have to build the portal in technology in XXX." If you don't have a mandate like that, you are probably better off starting with the out of the box stuff.
- It is going to depend on what version of the product you are using. 8.5, for example, gives you more customization options.
- If you really need to build a new portal because of some business reason: then what technology you use is probably going to be directly related to that business reason. If you need a new portal because it has to be mobile-first, then obviously you are going to choose a technology related to that. If you need to build a new portal because in needs a rich client option, then obviously you are going to choose a technology related to that. So without knowing why the default portal isn't acceptable, it's hard to know what to recommend.
- Similarly, what choice you make for a custom portal would also probably depend on whether you plan on using coaches. If you are abandoning not only the out of the box portal, but also the out of the box UI, then that opens up new challenges, and new choices.
- Fundamentally, in the end, if you choose to abandon the out of the box portal, it's a UI choice just like any other UI choice. At that point, IBM BPM is just a REST backend, so you'll pick whatever best suits your business needs and your current skillset.
One other caution is that building an custom portal can be a pretty big undertaking. Obviously, it depends on what you are building. If you are intentionally building a "stripped down" UI, then you might be able to build one pretty quickly. But there is a lot of functionality available in the out of the box portal: recreating something from scratch with equal functionality is nearly impossible: IBM probably has more engineers available to work on BPM portal interfaces than any single enterprise does on their own and they've been investing pretty heavily in the stock portal.
DavidUpdated on 2013-09-06T16:12:14Z at 2013-09-06T16:12:14Z by email@example.com
SMNair 270003WMA78 Posts
Re: Choosing Ui technology for Process Portal2013-09-06T21:45:39ZThis is the accepted answer. This is the accepted answer.
Here are few things we have tried out in our company for one of our business group.
-- Created a custom portal using HTM5L,jQuery. All calls to BPM was made using REST APIs. One of the main reason we had to create a custom UI was to provide a dashboard to the user. The dashboard was loading data from other sources. This was one single landing page for users to access thier IBM BPM & non BPM tasks. The effort was time consuming & we had to rebuild many OOB features to view comments, attachments, diagram, tasks etc. Launching coaches/ BPD diagrams were done using URL(s), which were not part of supported REST API calls.
--- We had a need to create an intrim portal during our BPM product upgrade to show tasks from old and new version during a trasition period. It was accomplished using a "Coach Service". The approcah was very simple showing both the portals in two different tabs & instead of portal URL, the users accessed the coach URL.
However please note majority of our user community still uses the out-of- box portal. Also if you are in 8.5, you should have customization options in portal. Even in 8.0, we were able to do basic customizations to show the company Logo etc.
Also one caution on a custom portal, is there may be on-going maintenance needed during udgrade due to un-supported REST APIs or URLs. Which ever approach you take I won't recommend re-creating custom task UIs for your portal; that is a maintenance nightmare.
Ganzales 270006MNV219 Posts
Re: Choosing Ui technology for Process Portal2013-09-09T10:09:00ZThis is the accepted answer. This is the accepted answer.
- firstname.lastname@example.org 270002TGMJ
The main reason why we are looking for a different UI technologies are the following :
1> The business user does not like the look and feel of the default process portal provided by the BPM tool. They want some thing different . Our UI designers are working on it . But on the other hand , we want to evaluate if the customization or building from scratch of the portal is good for us to support that . We are using BPM 8.0.1 and does it have enough customization option to change the look and feel and to provide the Web based portal ? you may say that without knowing what are UI features it is hard to recommend ,but what I want to know is the best practices in the market in this situation .
2> Currently we are using the Coach UI and the default process portal . But it seems the Coach UI is pretty slow and we need an alternative option . So we were thinking of throwing out not only the default process portal but also the coach UI and build a custom UI (using some vanilla web technologies like JSF, struts or Spring Web flow etc.) on top of of REST APIs only. But as I got the idea from the answers that maintaining the custom UI could become a nightmare as the REST APIs keep changing on version to version what could be the other alternatives ? Could performance tuning only is a good alternative ? Could we use the JAX WS instead of REST API ( i am not sure even if it is possible ) to reduce the risks?
Re: Choosing Ui technology for Process Portal2013-09-11T15:00:36ZThis is the accepted answer. This is the accepted answer.
- Ganzales 270006MNV2
So, I think you get the gist of my initial post. If you ask "what I want to know is the best practices in the market in this situation", the answer is "do not customize the portal". Yes, sometimes you might have to. Yes, there are APIs and features that allow you to. But the best idea is to use the out of the box functionality. I think SMNair's post highlights this perfectly. He had some compelling reasons to build a custom portal, and he did so. He did achieve his goals, and it sounds like he would do it again if he had a compelling reason again. But it was difficult, caused maintainence problems, and the majority of his users ended up using the out of the box portal anyway.
But, to follow up, I want to make a couple of other comments, and pose a few more questions. This post has been haunting me a bit all week because I think you might be headed down a really ugly path.
- First, you don't go into why they don't like the UI. But, even without knowing anything about the objection I can tell you one thing. If you are trying to solve a business problem and the business sponsor says "That's great, but I don't like the look and feel of the portal" then you haven't picked a good business problem to solve. Part of me wants to go into more detail on this point. But hopefully it will be self-evident: if UX is the primary concern then you have two problems. There isn't enough business pain (the business should be saying "I don't care what it looks like, I need a solution to this problem yesterday") and the second problem is you probably aren't picking the right tool for the job.
- The fact that you are considering throwing away the coach functionality as well makes me doubly concerned for the same reasons. It's pretty much the same exact story as the portal except more extreme. Yes, you can do it and there may be times that you have to do it. Yes, there are APIs to support it. No, it's not a best practice. But, most importantly, if the first reaction to the business solution is "those coaches are kind of slow" then you picked the wrong business problem to solve. Not only because it reflects a lack of urgency but also because of a difference in priorities. The goal of coaches is to support robust collaboration, increase involvement of the business in the design/implementation of the interfaces, and provide tight integration with the process. If flat out performance is the business sponsor's first concern, you aren't looking at the right tool for the business problem.
- You comment on the "REST APIs constantly changing. That's not really a concern here, the problem isn't the REST APIs: they've been quite stable (at least since they've been officially part of the product.) The problem is threefold. First, the portal isn't just a dumb client to the REST APIs. There is a lot of functionality in the portal layer as well, and you will have to rebuild all of that from scratch in whatever tech you use . Second, that not all of the functionality of the portal can be easily replicated and may end up having to link into the portal's URLs to provide that functionality anyway. (Which isn't a stable API: those URLs are not documented.) And just the fact that you are rebuilding something that is undergoing a lot of change in the base product. The 8.5 portal does have a lot more options/functionality/customization points than 8.0, for example. The REST APIs are the same, but a lot of functionality is being built by IBM at the portal layer.
- Perhaps the most important question is "Why are you considering using IBM BPM?" If you aren't going to use the Portal, and you aren't going to use coaches, then you've already thrown out half the product. A BMW might have a great sound system, but if you are buying a BMW for the sound system and then throwing away the engine and the drive train to rebuild it with custom parts, you might have a better starting point than buying a BMW.
DavidUpdated on 2013-09-11T15:23:32Z at 2013-09-11T15:23:32Z by email@example.com
Re: Choosing Ui technology for Process Portal2013-09-11T19:21:05ZThis is the accepted answer. This is the accepted answer.
- firstname.lastname@example.org 270002TGMJ
This may be the rare occasion where I don't agree with David's response. Actually to be clear I agree with all of his subsequent points where he says "if XYZ is true you may not be addressing an important business problem". But where he recommends customizing the current portal, that may not be the right answer.
It is the right answer if you user's issue is "We really want to change the colors to our corporate standard and change some of the icons." Something relatively small in scope. I don't think it is the right answer if the underlying problem is "The way the data is currently displayed is really bad for the way our end users work and we need a very different approach." I think the current layout is fine if you are someone who works less than 20 tasks a day. If you are a person who need to burn through 10's to 100's of tasks a day as the main thing you do, then the current UI is just way to expensive in terms of real estate. I have a 21" monitor and the current portal struggles to show me more than 5 or so items because of the wasted space.
The big thing here is if your "customization" is something that takes 1 person say 20-40 hours to do, then customize the portal, but understand You will be re-doing that customization on every significant upgrade. That is to say if I customized the 8.0.1 portal, IBM's upgrade does not, to my knowledge, merge those customizations into the 8.5 portal. So when we upgrade, I have to re do all of them. And I really hope you didn't customize the 7.5.1 portal since it went away in the 8.0 upgrade (with no warning). So now if you customize 8.5, it may need to all be revisited when 9.0 comes out. 9.0 may use yet another IBM technology, so none of your customizations are applicable.
So there is a break point here. You need to understand that if you customize IBMs portal, all your work is basically wasted effort when the next version comes out (or that should be your assumption unless you can get some sort of promise from IBM). Whereas if you create your own portal based off of published APIs, then you should just be able to upgrade and have the same experience for your end user as before the upgrade.
Again, it is a tradeoff though. You won't get whatever IBM rolled into that new portal. And this may upset your business users after they get an awesome demo from IBM. But you also don't have to go and rework a bunch of customizations to something where IBM fundamentally changed the underlying architecture and gave you no upgrade route (looking at you IBM BPM 7.5.1).
Now, if you are having coach problems, that is a whole separate thread, and my first question would be have you analyzed where the performance problem lies. But like I said, maybe that should be a separate thread.Updated on 2013-09-11T19:21:21Z at 2013-09-11T19:21:21Z by AndrewPaier
Re: Choosing Ui technology for Process Portal2013-09-11T20:36:28ZThis is the accepted answer. This is the accepted answer.
- AndrewPaier 2700040K2Q
No, I don't disagree with you Andrew.
In all of my posts, I concede that there are times where you must develop a custom portal. I listed a few technology-driven ones in an earlier post. But you gave a really excellent example of a business-driven reason. Not only is it a great reason from the perspective of a business justification ("our workers will be more productive for these heads down tasks because of factors X,Y, and Z") but it also is an example of how these business justifications can also keep the custom portal within a reasonable scope ("all the custom portal needs to do is pull one task after the other; no need to write a bunch of sorting/searching/reporting/ad hoc/instance management/BPMN viewer functionality.") In fact, despite your warnings, a "portal" like that would pretty much work with any IBM BPM product from 7.5 to 8.5 since the REST APIs for getting tasks and the URLs for launching tasks have stayed pretty stable.
I guess some of it may have to do with my definition of "best practice". I consider "best practices" as "recommended ways of using the product for most users". And I think that is in line with how I feel about custom portals. My default position is that custom portals have too little business benefit (they are by definition just implementing the same functionality in a different form), and too high a technology cost (in development, in maintainence, in complexity). But there are certainly use cases where those rules can be broken or bent.
My concern with this user is fundamentally that the values of the business sponsor don't really seem to align with the business benefits of BPM.
I mean, let's compare this to another type of software. If I were to go to a CIO and say "We are going to buy SAP. But we don't like the the look and feel of the UI. So we are going to rewrite an entire new UI layer for SAP. Don't worry, there's a supported API for accessing the functionality of SAP. Any ideas on what technology we should write it in? We also think that the supply chain module might be a little slow. We are thinking of not using that and building something from scratch" I would be fired so fast I'd break the sound barrier leaving the building.
Does that mean that there is never a reason for not building a custom UI for SAP? Absolutely not. (BPM often is one of those custom UIs.) But it means that you have to start with a really good business reason, because you are essentially going to be going "against the grain". It also means that you need to be realistic in intentions and in scope. Rewriting that one SAP interface in a more simplified way so that it is more meaningful to a particular kind of user? Totally makes sense. Rewriting every piece of UI, even without prior experience in doing so? A path to woe.
DavidUpdated on 2013-09-11T20:39:49Z at 2013-09-11T20:39:49Z by email@example.com
Re: Choosing Ui technology for Process Portal2013-09-11T23:29:49ZThis is the accepted answer. This is the accepted answer.
- AndrewPaier 2700040K2Q
OK. Don't particularly disagree with that either.
People do need to customize look and feel. But regardless of whether they are only making minor changes to CSS and major changes to the code of the portal your advice is solid. (i.e. know what you've changed, understand the risks, expect to have to redo your work with every major release).
Brian.L.Witherly 270003XFJV1 Post
Re: Choosing Ui technology for Process Portal2013-09-12T04:44:05ZThis is the accepted answer. This is the accepted answer.
- AndrewPaier 2700040K2Q
So the scope of our conversion to 8.5 we have a users that. Burn through 100's of tasks a day as the main thing you do, the current Portal is just way to expensive in terms of real estate. We complete some 75,000 - 95,000 tasks a day.
The current Portal will not cut it. We need an inbox, saved searches for the many teams, we also have many different processes, and adhoc services and reports that need to be exposed.
We have customized the previous portal pretty heavily, CSS, but also JSP's for removing unwanted and dangerous features and better performance.
1) Custom from scratch portal using Rest API to much work, with future version upgrade risk ?
2) Custom Portal using coaches. Flexible, but will it perform, what if they change the whole Coach paradigm again.
3) Or Business Spaces does this require IBM BPM advanced ? is this a valid option and is anyone else using this.
Now you and I have customized the portal many times over the years, so I have a pretty good idea which OTB features I will need and which I do not and how to implement them.
What are your thoughts on the options with the best performance due to high volume and lots of users in mind. and is there another option ?
I am also unsure about our future ability to update server assets with future cloud environment restrictions.
Brian WitherlyUpdated on 2013-09-12T04:46:58Z at 2013-09-12T04:46:58Z by Brian.L.Witherly
Re: Choosing Ui technology for Process Portal2013-09-12T13:04:42ZThis is the accepted answer. This is the accepted answer.
- Brian.L.Witherly 270003XFJV
You are the 2nd person in this thread to say that there is upgrade risk if you build your own stuff using the REST API. This statement confuses me. Since the REST API became part of the product in 7.5 it has been just as stable as the JS API has been since it was introduced in 7.0. Having been on the development team, one of the goals of the REST API was to give the team the flexibility to change the UI presentation technology without having to recreate the underly code that implements that functionality.
So, is there a reason why you feel that there is upgrade risk if you wrote your own stuff using the REST API?
Custom portal using coaches is a bad idea. I've blogged as to why here - IBM BPM and Taskless Services
As far as Business Space is concerned, I'm not sure that really buys you much over custom development, unless you already have Business Space developers
Re: Choosing Ui technology for Process Portal2013-09-12T13:55:20ZThis is the accepted answer. This is the accepted answer.
- AndrewPaier 2700040K2Q
Andrew: Any thoughts on some of the new paramters for invoking services via URL? Most notably zResumable? I haven't actually used them, but they seem to be there to avoid the old traps that existed for taskless services? It would seem to deal with a some of the objections you have in your article. ( http://pic.dhe.ibm.com/infocenter/dmndhelp/v8r0m1/index.jsp?topic=%2Fcom.ibm.wbpm.wle.editor.doc%2Fmodeling%2Ftopic%2Fcreating_services_C.html )
Re: Choosing Ui technology for Process Portal2013-09-12T14:09:21ZThis is the accepted answer. This is the accepted answer.
- firstname.lastname@example.org 270002TGMJ
Hmmm... Well I was running the memory problem tests using services exposed as "startable" and not as dashboards, and it does not appear that there is a way to say "change the behavior of the startable service".
I'll need to play around with the resumable one and see how it behaves. I have 2 concerns with respect to this. Both of these have to do with the pattern where someone creates an inbox replacement that shows you the results of a search and lets you then launch a task from there (thus abandoning the service that showed you the tasks)
- Need to make sure the resume is per user, not shared among users, since we don't want Bob getting Mary's task list.
- When a the service "resumes" does it pick up where it left off? If so then is it showing me a stale task list?
Given the other work in the pipeline it may be a while to get these tests created...