WellBore Open query versus on-demand ?

[Pascal62223]

All,

I notice that at start time, WE is performing two set of WITSML queries (unless I miss-read the code/trace):

1. Query all the authorized well for the logged in user

2. Open query for all the wellbores the logged user has access to

   My issue is with the 2nd bullet. The volume of information transported can be important in scenario where the user is for example an asset administrator with access to large number of wells (and possible multi-child) wellbore, or during testing on servers with +1000 wells and equivalent wellbores...

   Shouldn't teh wellbores be queried only when a user expand a well node ? (impact usability on well selection compare to a pre-loading. Might be addressed by background lazy load)

   Opinions ?

[steinsiv]

Yes that is correct, you did not miss-read, I just checked to be double sure 🙂

I do not have the information at hand to why there is two GetFromStore on both well and wellbores initially, so I will have to check if someone knows the decisions behind it. And if WE perhaps should ease up on that. I think it is a good point with regards to potential initial load. Thanks for raising the question! 👍

[Pascal62223]

Following on that topic, is it also on purpose that teh left tree seems to be limited to display only 30 wells. ?
I'm testing against our development server ( ++30 wells ), only 30 first ones are displayed

[marmid74]

This is an explanation of why we (Equinor) have chosen this approach -querying for all wells and wellbores in initial render for the sidebar navigation
The "driving" force has been user experience feedback from our users which are using WE for data management purpose.

Why both request wells and wellbores for initial render
Initially we only rendered the list of wells, and for each expansion of well, a new request for wellbores was triggered.
However the feedback from users, were that this was experienced as slow response while they were expanding several wells quickly after each other. Hence a request for wellbores was added and the two lists were combined into a hierarchy of wells and wellbores by the WE backend, so when the user expands a well, the list of wellbores are instant displayed (without new request to witsml server). Further details of a wellbore such as logs, rigs and trajectories are requested when a user expands a specific wellbore.

Why only show 30 wells
To keep responsiveness of rendering the well/wellbore list in the sidebar navigation, it was choosen to only display the first 30 wells (number or rows fits ok with the space available in the sidebar view). The user instead uses the filter function to "zoom in" on the relevant set of wells (which is available, but not shown in display). The entire list of wells and wellbores are combined into a hierarchy and when a user enters a filter, the list of wells matching the filter is shown in sidebar.

[Pascal62223]

Hi,

I understand aspect of the initial motivation, this raise a different user experience issue. When the number of well/wellbore is large, it do appear to take a long among of time to only retrieve 30 wells/wellbores (from a user point of view).

Considering the Open Source aspect, how is the usability going to be addressed across the various participating organizations ?

[marmid74]

To make sure we don´t misunderstand each other regarding the 30 wells/wellbores.
All wells/wellbores are retrieved and available in frontend, but only 30 rendered in the DOM. The filter will ensure to render the 30 most relevant wells to the DOM. However, it is easy to increase this number of wells rendered, and a vertical scrollbar will appear. It was just a choice we made at time of implementation, that instead of scrolling, the users used the filter to find the wells quickly.

Regarding your question Considering the Open Source aspect, how is the usability going to be addressed across the various participating organizations
I don´t have a good answer at the moment, and we are open for proposals from you and the community how this should be solved.

[Pascal62223]

Marita,

 Re-thinking to that '30' visible wells (all other wells being in front-end cache waiting for filter). What is going to be the user journey when it comes to operates on multiple wells at once in order to fix some of these wells properties. Is it expected to have an extra "smart filtering" dialog to allow user to select all the wells he/.she wants to operate on based on various properties of well, or is the selection going to be based on the '30' visible wells only.   
 Maybe that is a question to be answered as part of #179 , not sure.