You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Datasources component is only relevant for users who are using Germinate / Gigwa / secondary Pretzel servers, so for most people it is not the focus and should be less obvious.
Background : The idea of it being placed at top-left is that the user work-flow starts from the datasource at top-left, flows down to choosing a dataset in the explorer, then results are displayed in the middle where the user can select features of interest, which are then displayed at the right, i.e. the work flow is from top-left to right.
For most users, there is only 1 Datasource, i.e. the primary Pretzel server which they are logged in to, so the Datasources component could be hidden. Then there is the question of how users would access the Datasources component when they need it.
The Datasources component is a panel-container, so an easy change is to make that container closed initially; it was felt that it was still too distracting for users.
We discussed moving Datasources to below Datasets, but Datasets can be long so it will be hard to notice and require a lot of scrolling.
Another idea is to move Datasources into a separate tab parallel to Explorer. It was felt that this achieved his goal of reducing the complexity.
A couple of reservations : currently the tabs Explorer / View / Search / Upload fit neatly on one line, but adding another tab name would cause a flow to another line; Datasources is normally small, whereas the other tabs Explorer / View / Search / Upload are quite substantial; we may need to add another tab eventually, but Datasources by itself doesn't seem enough to justify it.
The main options under consideration ATM are this, or switching the Datasources container to hidden initially.
2024Nov28
The decision is to put display of Datasources behind a feature flag options=dataSources
This will enable the documentation to explain that there are "advanced" features that we use for other reasons,
whereas explaining the purpose of Datasources to a new user only leads to confusion.
The text was updated successfully, but these errors were encountered:
manage-explorer.js and .hbs : factor .urlOptions.dataSources (added 4dad538 for #436) from .hbs to form showDataSources() in .js; this enables adding config.environment === development as a fallback value, i.e. show Datasources if development
This sub-issue is part of #431.
Introduction and Discussion of options
The Datasources component is only relevant for users who are using Germinate / Gigwa / secondary Pretzel servers, so for most people it is not the focus and should be less obvious.
Background : The idea of it being placed at top-left is that the user work-flow starts from the datasource at top-left, flows down to choosing a dataset in the explorer, then results are displayed in the middle where the user can select features of interest, which are then displayed at the right, i.e. the work flow is from top-left to right.
For most users, there is only 1 Datasource, i.e. the primary Pretzel server which they are logged in to, so the Datasources component could be hidden. Then there is the question of how users would access the Datasources component when they need it.
The Datasources component is a panel-container, so an easy change is to make that container closed initially; it was felt that it was still too distracting for users.
We discussed moving Datasources to below Datasets, but Datasets can be long so it will be hard to notice and require a lot of scrolling.
Another idea is to move Datasources into a separate tab parallel to Explorer. It was felt that this achieved his goal of reducing the complexity.
A couple of reservations : currently the tabs Explorer / View / Search / Upload fit neatly on one line, but adding another tab name would cause a flow to another line; Datasources is normally small, whereas the other tabs Explorer / View / Search / Upload are quite substantial; we may need to add another tab eventually, but Datasources by itself doesn't seem enough to justify it.
The main options under consideration ATM are this, or switching the Datasources container to hidden initially.
2024Nov28
The decision is to put display of Datasources behind a feature flag options=dataSources
This will enable the documentation to explain that there are "advanced" features that we use for other reasons,
whereas explaining the purpose of Datasources to a new user only leads to confusion.
The text was updated successfully, but these errors were encountered: