What user experience does VBET require?

[philipbaileynar]

As we contemplate a "commercial grade" VBET we find ourselves at a familiar decision; which technology should we use to build the end user VBET product? I have summarized these before during BRAT development.

Another way of asking this question is: In which environment will users interact with VBET, add datasets, parameterize runs, hand edit and refine outputs, segment, calculate attributes etc. The options and some comments:

• ArcGIS
  • Delivers the best user interface (e.g. GCD), but
  • The VBET code dependencies will never install on Windows by all but the most technically sophisticated of operators.
  • It will not only take a massive budget to write VBET algorithms in .Net but doing so would require VBET algorithms to be finalized (as was the case with GCD). This is not the case with VBET (as evidenced by all the issues in this repo).
• QGIS
  • Possible, but a) realistically no one uses it, and b) previous plugin experiences suggest that deployment is a problem.
• Command line
• Web (browser, PWA etc)
  • Very expensive UI for workflow that is still in flux.

I want to come back to an idea that I floated for BRAT but that we rejected. Now that we have production grade data warehouses, I think it should be reconsidered.

We build the VBET user interface as an ArcGIS .net AddIn. Users can add datasets to VBET projects just like they do in GCD. But when they trigger calculations the datasets are uploaded to a data warehouse where the processing occurs. The outputs are downloaded, together with GUIDs for any of the inputs that were uploaded to make the run happen. Whenever the user attempts another calculation that uses the same inputs, the UI is clever enough to realize which inputs have already been uploaded and not re-upload them again.

This is obviously complex and requires a lot of non-VBET specific infrastructure to be in place before it will work. But it's a method that we can reuse with lots of our tools. It allows us to build rich user interfaces in .net as well as easily switch to QGIS, ArcPro etc.

[joewheaton]

Hey @philipbaileynar. Great questions. I obviously didn't see this post before I responded to Riverscapes/vbet#9, but at least great minds think alike. I will digest this now...

[joewheaton]

I really like your suggestion:

We build the VBET user interface as an ArcGIS .net AddIn. Users can add datasets to VBET projects just like they do in GCD. But when they trigger calculations the datasets are uploaded to a data warehouse where the processing occurs. The outputs are downloaded, together with GUIDs for any of the inputs that were uploaded to make the run happen. Whenever the user attempts another calculation that uses the same inputs, the UI is clever enough to realize which inputs have already been uploaded and not re-upload them again.

To me this seems like a Professional Grade solution. Again, lets think about audience. I really like it and want to find the funding to do it. However, I think a simpler commercial-grade solution can get us there. In the meantime, we can do a lot of testing by just implementing all the "fancier" tool requests as beta command-line tools only for our power-users. We test, break, fix, learn (i.e. research and development) before attempting to add those into the Commercial-Grade or Professional-Grade versions of VBET. Lets not forget, as long as the inputs, intermediates and outputs get added to project and we have @wally-mac produce nice buisness logic cartography, these will still reach consumers of the outputs of the models.

This comment is the one I'm looking for and most excited about... re-usable

But it's a method that we can reuse with lots of our tools. It allows us to build rich user interfaces in .net as well as easily switch to QGIS, ArcPro etc.

[joewheaton]

@philipbaileynar and @nick4rivers Since we now have what is starting as RIPT and becomes the Riverscapes Studio - Desktop QGIS edition I think we've got a new home for our "Professional Grade - Solution" albeit "Research Grade" for now".

[wally-mac]

It’s becoming quite apparent that a lot of things depend nice business logic cartography. As such, This will be a big focus of my techs work in the coming weeks.

On Fri, May 1, 2020 at 10:27 AM Joe Wheaton ***@***.***> wrote: I really like your suggestion: We build the VBET user interface as an ArcGIS .net AddIn. Users can add datasets to VBET projects just like they do in GCD. But when they trigger calculations the datasets are uploaded to a data warehouse where the processing occurs. The outputs are downloaded, together with GUIDs for any of the inputs that were uploaded to make the run happen. Whenever the user attempts another calculation that uses the same inputs, the UI is clever enough to realize which inputs have already been uploaded and not re-upload them again. To me this seems like a Professional Grade solution. Again, lets think about audience. I really like it and want to find the funding to do it. However, I think a simpler commercial-grade solution can get us there. In the meantime, we can do a lot of testing by just implementing all the "fancier" tool requests as beta command-line tools only for our power-users. We test, break, fix, learn (i.e. research and development) before attempting to add those into the Commercial-Grade or Professional-Grade versions of VBET. Lets not forget, as long as the inputs, intermediates and outputs get added to project and we have @wally-mac <https://github.com/wally-mac> produce nice buisness logic cartography, these will still reach consumers of the outputs of the models. This comment is the one I'm looking for and most excited about... *re-usable* But it's a method that we can reuse with lots of our tools. It allows us to build rich user interfaces in .net as well as easily switch to QGIS, ArcPro etc. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/Riverscapes/vbet/issues/12#issuecomment-622458271>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFHZAUWC3YGTCS5T33YDW3DRPL2A5ANCNFSM4MW2XEAQ> .

-- Sent from Gmail Mobile Sorry for typos and brevity courtesy of my phone.

[MattReimer]

I'm moving this to discussions since that's what this is.