Topic
  • 5 replies
  • Latest Post - ‏2013-02-08T00:45:15Z by F7QD_Nicolas_Echavarria
F7QD_Nicolas_Echavarria
59 Posts

Pinned topic To coach or not to coach... that is the question...

‏2013-02-05T19:03:03Z |
Hello Forum and Neil!

We are working on a mobile application developed using Worklight. This application is basically a "web view container" that shows a list of processes(via REST API) and tasks and that allows the user to start a process(via REST API) and to start working on the process viewing the defined coaches for each human service(here it behaves as a little browser that shows the actual IBPM coach).

The Worklight layer for us is very important, as it allows us to use Apache Cordova plugins to interact with each mobile device physical resources as camera (Photo, Video and Barcode scanning), GPS, storage, etc.

Our GUI's expectations are no different than what is already available in the Dojo Mobile framework.
So the question is:

Should we do all of our GUI development IN RAD(Worklight Studio) using Dojo Mobile (probably with the help of Maqetta) and interact with IBPM on a REST API level as an "orchestrator" of the application sending and receiving messages (JSONs)?

or....

Should we do all of our GUI work INSIDE IBPM creating reusable coach views using all Dojo Mobile components?

What are the pros and cons of each approach?

In your experience what would be more "sustainable" and "reusable" in the long run?

As always, thanks so much for all your help and insights!!
Best,

Nicolas E.
Updated on 2013-02-08T00:45:15Z at 2013-02-08T00:45:15Z by F7QD_Nicolas_Echavarria
  • F7QD_Nicolas_Echavarria
    59 Posts

    Re: To coach or not to coach... that is the question...

    ‏2013-02-06T17:46:31Z  
    Thoughts anyone?
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: To coach or not to coach... that is the question...

    ‏2013-02-07T18:23:27Z  
    Thoughts anyone?
    The problem here is that giving you real advice would require someone sitting down with your for an hour or so and having a conversation. It isn't really a problem that lends itself to a forumn post. Some of the issues are -

    • What are the skill sets of your team?
    • How do those skills align with each of the UI technologies?
    • In the longer time frame, will there be non-mobile (desktop) UIs as part of the solution or customer's work?
    • Is that desktop UI going to be delivered as web content?
    • How good is your team at making reactive UI? A mobile UI looks bad on desktop and vice versa (unless you are good at reactive UI design)

    Those are just the start. The question is so open that it is pretty hard for anyone here to really give you useful data.

    Andrew Paier | Director of Special Operations | BP3 Global, Inc. www.bp-3.com
  • F7QD_Nicolas_Echavarria
    59 Posts

    Re: To coach or not to coach... that is the question...

    ‏2013-02-07T21:52:25Z  
    The problem here is that giving you real advice would require someone sitting down with your for an hour or so and having a conversation. It isn't really a problem that lends itself to a forumn post. Some of the issues are -

    • What are the skill sets of your team?
    • How do those skills align with each of the UI technologies?
    • In the longer time frame, will there be non-mobile (desktop) UIs as part of the solution or customer's work?
    • Is that desktop UI going to be delivered as web content?
    • How good is your team at making reactive UI? A mobile UI looks bad on desktop and vice versa (unless you are good at reactive UI design)

    Those are just the start. The question is so open that it is pretty hard for anyone here to really give you useful data.

    Andrew Paier | Director of Special Operations | BP3 Global, Inc. www.bp-3.com
    Andrew,

    Thanks a lot for your time and your response!
    I understand is open ended and difficult to have a straight answer.

    To answer your questions:
    • What are the skill sets of your team?
    R./ In BPM, we are comfortable and have been able to fulfill our needs.

    • How do those skills align with each of the UI technologies?
    R./ In the GUI side have good skills in Sencha, working our way in Dojo... but we'll soon be there.

    • In the longer time frame, will there be non-mobile (desktop) UIs as part of the solution or customer's work?
    R./ Yes, that's for sure.

    • Is that desktop UI going to be delivered as web content?
    R./ Yes, via browser.

    • How good is your team at making reactive UI?A mobile UI looks bad on desktop and vice versa (unless you are good at reactive UI design)
    R./ We've worked a lot with responsive design and are comfortable with all the concepts. However when we move forward with GUI development INSIDE BPM the "encapsulation" of the BPM coaches inside the App web-viewing environment renders the powerful "responsive" features of Worklight semi-useless for multi-platform purposes.
    So, our feeling is that developing the GUI's inside coaches will limit our GUI flexibility and responsiveness to really offer the best experience in every environment (mobile-tablet-desktop).

    Do I make sense?

    Thanks so much for your thoughts Andrew!, we value them a lot!

    Best,

    Nicolas E.
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: To coach or not to coach... that is the question...

    ‏2013-02-07T22:31:56Z  
    Andrew,

    Thanks a lot for your time and your response!
    I understand is open ended and difficult to have a straight answer.

    To answer your questions:
    • What are the skill sets of your team?
    R./ In BPM, we are comfortable and have been able to fulfill our needs.

    • How do those skills align with each of the UI technologies?
    R./ In the GUI side have good skills in Sencha, working our way in Dojo... but we'll soon be there.

    • In the longer time frame, will there be non-mobile (desktop) UIs as part of the solution or customer's work?
    R./ Yes, that's for sure.

    • Is that desktop UI going to be delivered as web content?
    R./ Yes, via browser.

    • How good is your team at making reactive UI?A mobile UI looks bad on desktop and vice versa (unless you are good at reactive UI design)
    R./ We've worked a lot with responsive design and are comfortable with all the concepts. However when we move forward with GUI development INSIDE BPM the "encapsulation" of the BPM coaches inside the App web-viewing environment renders the powerful "responsive" features of Worklight semi-useless for multi-platform purposes.
    So, our feeling is that developing the GUI's inside coaches will limit our GUI flexibility and responsiveness to really offer the best experience in every environment (mobile-tablet-desktop).

    Do I make sense?

    Thanks so much for your thoughts Andrew!, we value them a lot!

    Best,

    Nicolas E.
    Well, the new coach views framework is very flexible. I have seen some of our teams deliver very responsive designs for customers handling both mobile and deskotp UI's in their processes. The team that as most successful basically ignored all of the OOTB coach views and created their own base coach views from scratch, with a responsive design approach taken right from the start. I think if you look closely at their code, they are not even using any dojo in their base implementation. I'm not clear on why but one of the web guys seemed to think there was large overhead associated with the dojo files in the base coach views.

    So, really, it comes down to where you want to work and what you need to do. No matter how you answer this question, someone can make an argument it is the wrong answer. If you do most your stuff in worklight, you disconnect the UI from the process snapshot, meaning they can get out of synch. That seems bad. However if you build all your UI in coach designer, then if you want to change the UI, you need to deploy a new snapshot. That could be deemed bad by a different camp. Which is right? Neither is right, and both are as well.

    Since our team (BP3) specializes in only BPM, we will tend to put more things in the BPM product. Because my team is very unlikely to create a work light UI to integrate to, say, something backed by filenet or DB2 on their own (we may access these through BPM, but are unlikely to access them entirely on their own). However your team may support other solutions beyond BPM, so there could be utility in not having those items in the BPM tool. That way they can possibly be leveraged in other non BPM use cases. Of course this opens up questions of IP ownership etc. but lets nto worrry about that for today….

    The last paragraph is a strategic view. On a tactial single project view, how many of the UI's really need to support mobile and desk top? How much effort is it to support WorkLight and BPM UIs if you need to do so? These are all things to take into consideration.

    Andrew Paier | Director of Special Operations | BP3 Global, Inc. www.bp-3.com
  • F7QD_Nicolas_Echavarria
    59 Posts

    Re: To coach or not to coach... that is the question...

    ‏2013-02-08T00:45:15Z  
    Well, the new coach views framework is very flexible. I have seen some of our teams deliver very responsive designs for customers handling both mobile and deskotp UI's in their processes. The team that as most successful basically ignored all of the OOTB coach views and created their own base coach views from scratch, with a responsive design approach taken right from the start. I think if you look closely at their code, they are not even using any dojo in their base implementation. I'm not clear on why but one of the web guys seemed to think there was large overhead associated with the dojo files in the base coach views.

    So, really, it comes down to where you want to work and what you need to do. No matter how you answer this question, someone can make an argument it is the wrong answer. If you do most your stuff in worklight, you disconnect the UI from the process snapshot, meaning they can get out of synch. That seems bad. However if you build all your UI in coach designer, then if you want to change the UI, you need to deploy a new snapshot. That could be deemed bad by a different camp. Which is right? Neither is right, and both are as well.

    Since our team (BP3) specializes in only BPM, we will tend to put more things in the BPM product. Because my team is very unlikely to create a work light UI to integrate to, say, something backed by filenet or DB2 on their own (we may access these through BPM, but are unlikely to access them entirely on their own). However your team may support other solutions beyond BPM, so there could be utility in not having those items in the BPM tool. That way they can possibly be leveraged in other non BPM use cases. Of course this opens up questions of IP ownership etc. but lets nto worrry about that for today….

    The last paragraph is a strategic view. On a tactial single project view, how many of the UI's really need to support mobile and desk top? How much effort is it to support WorkLight and BPM UIs if you need to do so? These are all things to take into consideration.

    Andrew Paier | Director of Special Operations | BP3 Global, Inc. www.bp-3.com
    Andrew,

    I think you made very interesting statements that clearly help us a lot in our debate, but currently and in the future.
    Thanks so much!!

    Best,

    Nicolas E.