Topic
  • 12 replies
  • Latest Post - ‏2013-09-12T14:09:21Z by AndrewPaier
Ganzales
Ganzales
19 Posts

Pinned topic Choosing Ui technology for Process Portal

‏2013-09-06T12:46:58Z |

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?

  • dogren@gmail.com
    dogren@gmail.com
    401 Posts

    Re: Choosing Ui technology for Process Portal

    ‏2013-09-06T16:11:00Z  

    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.

    David

    Updated on 2013-09-06T16:12:14Z at 2013-09-06T16:12:14Z by dogren@gmail.com
  • SMNair
    SMNair
    8 Posts

    Re: Choosing Ui technology for Process Portal

    ‏2013-09-06T21:45:39Z  

    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.

    Regards,

    Sreeja

  • Ganzales
    Ganzales
    19 Posts

    Re: Choosing Ui technology for Process Portal

    ‏2013-09-09T10:09:00Z  

    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.

    David

    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?

     

  • dogren@gmail.com
    dogren@gmail.com
    401 Posts

    Re: Choosing Ui technology for Process Portal

    ‏2013-09-11T15:00:36Z  
    • Ganzales
    • ‏2013-09-09T10:09:00Z

    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?

     

    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.

    David

     

    Updated on 2013-09-11T15:23:32Z at 2013-09-11T15:23:32Z by dogren@gmail.com
  • AndrewPaier
    AndrewPaier
    795 Posts

    Re: Choosing Ui technology for Process Portal

    ‏2013-09-11T19:21:05Z  

    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.

    David

    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.

    Andrew Paier | Director | BP3 Global, Inc.
    BP3 Global's |  Website  |  Twitter  |  Linkedin  |  Google+  | Blogs

    Updated on 2013-09-11T19:21:21Z at 2013-09-11T19:21:21Z by AndrewPaier
  • dogren@gmail.com
    dogren@gmail.com
    401 Posts

    Re: Choosing Ui technology for Process Portal

    ‏2013-09-11T20:36:28Z  

    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.

    Andrew Paier | Director | BP3 Global, Inc.
    BP3 Global's |  Website  |  Twitter  |  Linkedin  |  Google+  | Blogs

    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.

    David

    Updated on 2013-09-11T20:39:49Z at 2013-09-11T20:39:49Z by dogren@gmail.com
  • AndrewPaier
    AndrewPaier
    795 Posts

    Re: Choosing Ui technology for Process Portal

    ‏2013-09-11T21:50:52Z  

    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.

    David

    Well, where we disagree is where you said -

    • If you just want a different look and feel, customize the existing portal: don't build a new one.

    Given the number of customers where I have to go through the various stages of grief (and usually get to come in on "Anger", yeah!) when they find out that all to the customizations they did in a previous version have to be redone in the new version, I'm very careful to find out the extent of what they mean by "different look and feel", since as I said, you cannot assume those changes will work in the next release.

     

    Of course many of these people didn't follow some best practices, like knowing exactly what it was that they did to the previous version so that we can redo it, assuming the new version is fairly close to the old one.  That makes the conversation significantly worse, since before you can begin you have to figure out what all the changes were.

     

    So, I tend to fall in the category of "If we are talking minor CSS and graphics changes, then yes, just edit what is there.  If you need more, we need to talk and make sure you understand the risks."

     

    Andrew Paier | Director | BP3 Global, Inc.
    BP3 Global's |  Website  |  Twitter  |  Linkedin  |  Google+  | Blogs

  • dogren@gmail.com
    dogren@gmail.com
    401 Posts

    Re: Choosing Ui technology for Process Portal

    ‏2013-09-11T23:29:49Z  

    Well, where we disagree is where you said -

    • If you just want a different look and feel, customize the existing portal: don't build a new one.

    Given the number of customers where I have to go through the various stages of grief (and usually get to come in on "Anger", yeah!) when they find out that all to the customizations they did in a previous version have to be redone in the new version, I'm very careful to find out the extent of what they mean by "different look and feel", since as I said, you cannot assume those changes will work in the next release.

     

    Of course many of these people didn't follow some best practices, like knowing exactly what it was that they did to the previous version so that we can redo it, assuming the new version is fairly close to the old one.  That makes the conversation significantly worse, since before you can begin you have to figure out what all the changes were.

     

    So, I tend to fall in the category of "If we are talking minor CSS and graphics changes, then yes, just edit what is there.  If you need more, we need to talk and make sure you understand the risks."

     

    Andrew Paier | Director | BP3 Global, Inc.
    BP3 Global's |  Website  |  Twitter  |  Linkedin  |  Google+  | Blogs

    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
    Brian.L.Witherly
    1 Post

    Re: Choosing Ui technology for Process Portal

    ‏2013-09-12T04:44:05Z  

    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.

    Andrew Paier | Director | BP3 Global, Inc.
    BP3 Global's |  Website  |  Twitter  |  Linkedin  |  Google+  | Blogs

    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.

    Options:

    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 Witherly

    Updated on 2013-09-12T04:46:58Z at 2013-09-12T04:46:58Z by Brian.L.Witherly
  • AndrewPaier
    AndrewPaier
    795 Posts

    Re: Choosing Ui technology for Process Portal

    ‏2013-09-12T13:04:42Z  

    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.

    Options:

    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 Witherly

    Brian -

    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

    Andrew Paier | Director | BP3 Global, Inc.
    BP3 Global's |  Website  |  Twitter  |  Linkedin  |  Google+  | Blogs

  • dogren@gmail.com
    dogren@gmail.com
    401 Posts

    Re: Choosing Ui technology for Process Portal

    ‏2013-09-12T13:55:20Z  

    Brian -

    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

    Andrew Paier | Director | BP3 Global, Inc.
    BP3 Global's |  Website  |  Twitter  |  Linkedin  |  Google+  | Blogs

    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 )

    David

  • AndrewPaier
    AndrewPaier
    795 Posts

    Re: Choosing Ui technology for Process Portal

    ‏2013-09-12T14:09:21Z  

    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 )

    David

    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...

    Andrew Paier | Director | BP3 Global, Inc.
    BP3 Global's |  Website  |  Twitter  |  Linkedin  |  Google+  | Blogs